ооо, тема!
когда то под DOSом была у меня директория, в которой были собраны сотни таких демок, там были и плазмы, и огонь, и молнии… и эти эффекты выглядели очень правдоподобно, даже без каких либо библиотек… даже на старых SVGA мониторах… ностальгия… ммм…
А меня почему то всегда интересовала математика таких эффектов…
Спасибо за статью, жду вторую часть. хочется увидеть немного демо(сцена)математики :)
Эта халява, с одной стороны, достаётся совсем не бесплатно — у неё есть свои особенности и ограничения, и, с другой стороны, она делает возможным то, что раньше таковым не являлось. Так что баланс примерно там же остался :D.
Ну что значит меньше? Меньше для чего? Есть что ли какой то стандарт на то как надо делать графику и что там должно быть?
Есть разные номинации и разные весовые категории. Скажем, энтузиасты до сих пор пишут демки под DOS, не прибегая ни к каким ухищрениям. Есть и другие, где наоборот, задается только верхняя планка размера файла. Вот тебе 512 байт и делай что хочешь — у кого круче, тот и выиграл. Единственное ограничение — нельзя выносить логику во внешние библиотеки. То есть SDL и OpenGL можно, ибо это библиотеки общего назначения. А вот вынести 10 мб своего кода в либу и вызвать ее из исполняемого файла в 40 байт это уже, извините, не труъ.
Если же говорить о собственно накладных расходах, то и тут не все однозначно. Простейший рейтрейсер можно уложить в сотню байт, тогда как GL код зачастую получается куда более жирным из-за всей этой чехарды с инициализацией. Опять же, шейдеры нельзя в класть бинари.
Вы же предлагаете запретить велогонки, оставив только марафон, ибо велосипед — это неспортивно и накладные расходы на перемещение гораздо меньше.
У меня чего-то не работает(sstrip не было в дистрибутиве, пришлось использовать strip): $ ./intro.sh
i915_program_error: Unsupported opcode: IF
Показывает только чёрную картинку. Попробовал погуглить, но пока безрезультатно.
Да и в размер как-то превышает 1кб, у меня 1456 байт занимает intro.sh(Собирал gcc 4.4.5)
А нормально что исполняемый файл intro с таким количеством библиотек связан?
sstrip можно взять здесь: www.muppetlabs.com/~breadbox/software/elfkickers.html
Простого strip не хватит — он довольно дурацкий и не вырезает, например, секции, которые для работы программы нафиг не нужны, только для отладки и всякой расширенной информации
(между нами, sstrip тоже не идеальный — он вырезает только то, что находится после всех-всех полезных частей программы, совершенно не трогая мусор, лежащий где-то посередине. В принципе, зная формат elf, можно наколбасить полноценный ssstrip, который перемешивал бы содержимое по-взрослому, но так лень, так лень).
>> i915_program_error: Unsupported opcode: IF
Похоже, что i915 не все функции из там написанных понимает нативно и пытается развернуть их во что-то более сложное, с ветвлениями и прочим неподдерживаемым. Можно поэкспериментировать — аккуратно повыключать «сложные» функции — и понять, в чем именно дело. Но дальше я не подскажу.
нужно встряхнуть стариной и покопаться в доках про ELF, посмотреть, откуда берется лишний жир.
вполне возможно, что в бинарник вставляется stdlib — я пока не проверил, но явных указаний линкеру не делать этого не вижу.
можно поиграться с linker scripts — попробовать выиграть размера бинарника.
можно посмотреть в исходники dlsym и попробовать заменить импорт по имени импортом по хешу — древняя вирмейкерская техника, не знаю, правда, заработает ли под линукс.
короче, я знаю, чем займусь сегодня вечером, спасибо за напоминание. =)
Ровно про это — как наколбасить elf-заголовок ручками на ассемблере — и будет следующая статья. Забегая вперед скажу, что там удается отжать у gcc/ld еще примерно 200-300 байт, что в масштабах 1кб, мягко скажем, очень много.
Да, импорт по хешу лучше не делать, он довольно нестабилен оказывается почему-то — то ли между версиями/сборками libc какие-то различия есть, то ли еще что. В любом случае это выливается в то, что старые интры не работают больше — падают в коде подгрузки функций по хешу.
Лол, она у меня уже три недели как дописанная почти была, всё руки не доходили перечитать, исправить шероховатости и выложить.
Следующая будет про ассемблер и elf. Про фреймбуфер потом. Можешь, в принципе, сам написать, если хочешь.
Помнится, когда читал про интро для Windows там говорили, что, помимо прочего, минимальны зависимости, то есть интро запускается даже при наличии у пользователя kernel.dll и либо opengl32.dll либо d3d9.dll/d3d8.dll.
Тут же еще тянется в зависимостях SDL и, возможно, с ним еще много разных пакетов, которые, вероятно, следует так же учитывать при определении размера интро.
Получается, что не совсем то интро, что под Windows, или я не прав ???
По этому вопросу нет единого мнения. С одной стороны, SDL не является частью системы де-юре — оно не входит ни в какой LSB, есть системы, где оно не поставляется и пр. С другой стороны, де-факто он есть почти везде, относительно стабильный и очень удобный — я даже для больших программ им часто пользуюсь. И в нем нет ничего криминального — он всего-лишь инициализирует GL-контекст и дает минимальный mainloop с обработкой сообщений. Никаких функций, вроде make_me_a_demo(), как в d3dx (шутка), там нет.
Ну и люди, делающие интры под линукс, SDL'ем пользуются и, насколько я знаю, еще не получали отказов от организаторов демопати.
Там, просто упомяну, что сейчас в мире Linux стандартным архиватором для высокого сжатия считается xz. Не уверен даст ли выигрыш в Вашем случае, но попробовать можно.
Боюсь, что тут нужно уже писать полноценное приложение с проверкой на ошибки, логами и прочим — похоже, что что-то по пути валится (не открываются библиотеки, не создается gl-контекст, не компилируются шейдерные программы и т.п.), но интра продолжает смело шагать по трупам как ни в чем не бывало, и в итоге травится трупными ядами.
В общем, падает из-за самих шейдеров. Если в версию без динамической подгрузки адресов функций вставить последний шейдерный код — падает :( А если в версию с динамической подгрузкой старые шейдеры — не падает. Более того дело в строчке
Можно делать сразу strip -s и, по идее, оно вырежет сразу всё, что считает безопасным. Но sstrip всё равно идёт дальше.
Ещё раз забегая вперёд во вторую часть — на самом секции вообще не нужны для запуска программы, и их все можно вымести поганой метлой. И даже от program headers можно безболезненно откусить ощутимый кусок.
Это довольно толстая реализация плазмы :D — судя по видео, её com-файл весит более 1кб. Конечно, для полнценного заражающего вируса это даже неплохо, но для только эффекта — очень много.
Можно посмотреть, что ребята умудряются запихивать в 256 байт (например, puls by Rrrola), или даже меньше — в последнее время сжигает напалмом некто fsqrt (возможно, наш соотечественник). Очень рекомендую к просмотру у него буквально всё. Для этого, правда, потребуется DOSBox (или же машина с досом, но кто их сейчас держит).
Привет!
Спасибо!
Лучше всего — машина с Windows XP, в ней делаю финальное тестирование и всё идёт быстро.
Многое тормозит в DosBOX, особенно в случаях чтения памяти (особенно нижних сегментов) и операциях fpu. Он в некоторых случаях может быть тормознее XP в десятки раз даже с максимальными настройками на скорость.
Насчёт плазмы — неплохую можно сделать в 54 байта или даже поменьше.
Так что пишите всё на асме и не жалейте времени на оптимизацию =)
ПС Осваиваю псевдо-воксели, сегодня вечером выложу кое-что на 128б.
Привет!
Windows XP да, тоже хороший вариант. Но, к сожалению, у меня, например, его нет — всё линуксы, да семёрки с макосями.
По асму и оптимизации скажу честно: я завидую :D. Потому что когда писал свои 256 для линукса, обнаружил, что совершенно не хватает ни фантазии, ни знания ассемблера для того, чтобы сделать что-нибудь интересное. Ни времени, чтобы за обозримые неделю-месяц их выработать.
Ну и еще там есть проблемы с производительностью и a/v sync, которые тоже требуют исследований. Но, я думаю, оно стоит того — там могут быть свои плюшки от, скажем, честного защищенного 32-битного режима.
Но, возможно, правда следует попробовать для начала заколбасить любопытное под дос, чтобы научиться и прочувстсвовать.
Создание 1k/4k intro для Linux, часть 1