Комментарии 54
Зачетный стиль изложения!
НЛО прилетело и опубликовало эту надпись здесь
Про Виндовс информации много. Например:
in4k.untergrund.net/ — вики про 4к, много-много разной любопытной инфы
www.iquilezles.org/www/material/isystem1k4k/isystem1k4k.htm — болванки проектов, примеры кода
pouet.net/prod.php?which=18158 — crinkler, самый сумасшедший паковщик для 4к в настоящее время
pouet.net/prod.php?which=52796 — 1kpack, еще один паковщик, более предназначенный для 1к
in4k.untergrund.net/ — вики про 4к, много-много разной любопытной инфы
www.iquilezles.org/www/material/isystem1k4k/isystem1k4k.htm — болванки проектов, примеры кода
pouet.net/prod.php?which=18158 — crinkler, самый сумасшедший паковщик для 4к в настоящее время
pouet.net/prod.php?which=52796 — 1kpack, еще один паковщик, более предназначенный для 1к
Прочитал — захотел даже написать. Ух!
Помню в сырцах демки для спектрума (какой не помню) был коммент
Вообще люди делающие такие вещи (особенно для слабых процев) порой гении в прямом смысле…
; KOLBASING Text (don't try to understand this function name)Вообще люди делающие такие вещи (особенно для слабых процев) порой гении в прямом смысле…
ооо, тема!
когда то под DOSом была у меня директория, в которой были собраны сотни таких демок, там были и плазмы, и огонь, и молнии… и эти эффекты выглядели очень правдоподобно, даже без каких либо библиотек… даже на старых SVGA мониторах… ностальгия… ммм…
А меня почему то всегда интересовала математика таких эффектов…
Спасибо за статью, жду вторую часть. хочется увидеть немного демо(сцена)математики :)
когда то под DOSом была у меня директория, в которой были собраны сотни таких демок, там были и плазмы, и огонь, и молнии… и эти эффекты выглядели очень правдоподобно, даже без каких либо библиотек… даже на старых SVGA мониторах… ностальгия… ммм…
А меня почему то всегда интересовала математика таких эффектов…
Спасибо за статью, жду вторую часть. хочется увидеть немного демо(сцена)математики :)
А сейчас халява, сэр — расчеты перекидывают на шейдеры…
Эта халява, с одной стороны, достаётся совсем не бесплатно — у неё есть свои особенности и ограничения, и, с другой стороны, она делает возможным то, что раньше таковым не являлось. Так что баланс примерно там же остался :D.
Всё-таки, накладных расходов на 3д эффекты гораздо меньше.
Ну что значит меньше? Меньше для чего? Есть что ли какой то стандарт на то как надо делать графику и что там должно быть?
Есть разные номинации и разные весовые категории. Скажем, энтузиасты до сих пор пишут демки под DOS, не прибегая ни к каким ухищрениям. Есть и другие, где наоборот, задается только верхняя планка размера файла. Вот тебе 512 байт и делай что хочешь — у кого круче, тот и выиграл. Единственное ограничение — нельзя выносить логику во внешние библиотеки. То есть SDL и OpenGL можно, ибо это библиотеки общего назначения. А вот вынести 10 мб своего кода в либу и вызвать ее из исполняемого файла в 40 байт это уже, извините, не труъ.
Если же говорить о собственно накладных расходах, то и тут не все однозначно. Простейший рейтрейсер можно уложить в сотню байт, тогда как GL код зачастую получается куда более жирным из-за всей этой чехарды с инициализацией. Опять же, шейдеры нельзя в класть бинари.
Вы же предлагаете запретить велогонки, оставив только марафон, ибо велосипед — это неспортивно и накладные расходы на перемещение гораздо меньше.
Есть разные номинации и разные весовые категории. Скажем, энтузиасты до сих пор пишут демки под DOS, не прибегая ни к каким ухищрениям. Есть и другие, где наоборот, задается только верхняя планка размера файла. Вот тебе 512 байт и делай что хочешь — у кого круче, тот и выиграл. Единственное ограничение — нельзя выносить логику во внешние библиотеки. То есть SDL и OpenGL можно, ибо это библиотеки общего назначения. А вот вынести 10 мб своего кода в либу и вызвать ее из исполняемого файла в 40 байт это уже, извините, не труъ.
Если же говорить о собственно накладных расходах, то и тут не все однозначно. Простейший рейтрейсер можно уложить в сотню байт, тогда как GL код зачастую получается куда более жирным из-за всей этой чехарды с инициализацией. Опять же, шейдеры нельзя в класть бинари.
Вы же предлагаете запретить велогонки, оставив только марафон, ибо велосипед — это неспортивно и накладные расходы на перемещение гораздо меньше.
Хабр торт!
У меня чего-то не работает(sstrip не было в дистрибутиве, пришлось использовать strip):
Показывает только чёрную картинку. Попробовал погуглить, но пока безрезультатно.
Да и в размер как-то превышает 1кб, у меня 1456 байт занимает intro.sh(Собирал gcc 4.4.5)
А нормально что исполняемый файл intro с таким количеством библиотек связан?
$ ./intro.sh
i915_program_error: Unsupported opcode: IFПоказывает только чёрную картинку. Попробовал погуглить, но пока безрезультатно.
Да и в размер как-то превышает 1кб, у меня 1456 байт занимает intro.sh(Собирал gcc 4.4.5)
А нормально что исполняемый файл intro с таким количеством библиотек связан?
>> i915_program_error: Unsupported opcode: IF
предполагаю, ему не нравится шейдер.
>> исполняемый файл intro с таким количеством библиотек связан
а можно вывод ldd?
предполагаю, ему не нравится шейдер.
>> исполняемый файл intro с таким количеством библиотек связан
а можно вывод ldd?
sstrip можно взять здесь: www.muppetlabs.com/~breadbox/software/elfkickers.html
Простого strip не хватит — он довольно дурацкий и не вырезает, например, секции, которые для работы программы нафиг не нужны, только для отладки и всякой расширенной информации
(между нами, sstrip тоже не идеальный — он вырезает только то, что находится после всех-всех полезных частей программы, совершенно не трогая мусор, лежащий где-то посередине. В принципе, зная формат elf, можно наколбасить полноценный ssstrip, который перемешивал бы содержимое по-взрослому, но так лень, так лень).
>> i915_program_error: Unsupported opcode: IF
Похоже, что i915 не все функции из там написанных понимает нативно и пытается развернуть их во что-то более сложное, с ветвлениями и прочим неподдерживаемым. Можно поэкспериментировать — аккуратно повыключать «сложные» функции — и понять, в чем именно дело. Но дальше я не подскажу.
Простого strip не хватит — он довольно дурацкий и не вырезает, например, секции, которые для работы программы нафиг не нужны, только для отладки и всякой расширенной информации
(между нами, sstrip тоже не идеальный — он вырезает только то, что находится после всех-всех полезных частей программы, совершенно не трогая мусор, лежащий где-то посередине. В принципе, зная формат elf, можно наколбасить полноценный ssstrip, который перемешивал бы содержимое по-взрослому, но так лень, так лень).
>> i915_program_error: Unsupported opcode: IF
Похоже, что i915 не все функции из там написанных понимает нативно и пытается развернуть их во что-то более сложное, с ветвлениями и прочим неподдерживаемым. Можно поэкспериментировать — аккуратно повыключать «сложные» функции — и понять, в чем именно дело. Но дальше я не подскажу.
нужно встряхнуть стариной и покопаться в доках про ELF, посмотреть, откуда берется лишний жир.
вполне возможно, что в бинарник вставляется stdlib — я пока не проверил, но явных указаний линкеру не делать этого не вижу.
можно поиграться с linker scripts — попробовать выиграть размера бинарника.
можно посмотреть в исходники dlsym и попробовать заменить импорт по имени импортом по хешу — древняя вирмейкерская техника, не знаю, правда, заработает ли под линукс.
короче, я знаю, чем займусь сегодня вечером, спасибо за напоминание. =)
вполне возможно, что в бинарник вставляется stdlib — я пока не проверил, но явных указаний линкеру не делать этого не вижу.
можно поиграться с linker scripts — попробовать выиграть размера бинарника.
можно посмотреть в исходники dlsym и попробовать заменить импорт по имени импортом по хешу — древняя вирмейкерская техника, не знаю, правда, заработает ли под линукс.
короче, я знаю, чем займусь сегодня вечером, спасибо за напоминание. =)
Ровно про это — как наколбасить elf-заголовок ручками на ассемблере — и будет следующая статья. Забегая вперед скажу, что там удается отжать у gcc/ld еще примерно 200-300 байт, что в масштабах 1кб, мягко скажем, очень много.
Да, импорт по хешу лучше не делать, он довольно нестабилен оказывается почему-то — то ли между версиями/сборками libc какие-то различия есть, то ли еще что. В любом случае это выливается в то, что старые интры не работают больше — падают в коде подгрузки функций по хешу.
Да, импорт по хешу лучше не делать, он довольно нестабилен оказывается почему-то — то ли между версиями/сборками libc какие-то различия есть, то ли еще что. В любом случае это выливается в то, что старые интры не работают больше — падают в коде подгрузки функций по хешу.
Лол, ты ее таки дописал =) Провод, ты будешь писать про фреймбуфер? Или сначала просто про асм?
Ну и это, выложил бы ссылки на творения. Или боишься что засмеют? :D
Не хочу превращать информативную статью в саморекламу.
Тоже верно
Ну тогда я выложу =)
pouet.net/groups.php?which=11436
pouet.net/groups.php?which=11436
Лол, она у меня уже три недели как дописанная почти была, всё руки не доходили перечитать, исправить шероховатости и выложить.
Следующая будет про ассемблер и elf. Про фреймбуфер потом. Можешь, в принципе, сам написать, если хочешь.
Следующая будет про ассемблер и elf. Про фреймбуфер потом. Можешь, в принципе, сам написать, если хочешь.
WeirdWire как всегда на высоте.
Изложение доставляет как и много лет назад… :)
Изложение доставляет как и много лет назад… :)
Помнится, когда читал про интро для Windows там говорили, что, помимо прочего, минимальны зависимости, то есть интро запускается даже при наличии у пользователя kernel.dll и либо opengl32.dll либо d3d9.dll/d3d8.dll.
Тут же еще тянется в зависимостях SDL и, возможно, с ним еще много разных пакетов, которые, вероятно, следует так же учитывать при определении размера интро.
Получается, что не совсем то интро, что под Windows, или я не прав ???
Тут же еще тянется в зависимостях SDL и, возможно, с ним еще много разных пакетов, которые, вероятно, следует так же учитывать при определении размера интро.
Получается, что не совсем то интро, что под Windows, или я не прав ???
По этому вопросу нет единого мнения. С одной стороны, SDL не является частью системы де-юре — оно не входит ни в какой LSB, есть системы, где оно не поставляется и пр. С другой стороны, де-факто он есть почти везде, относительно стабильный и очень удобный — я даже для больших программ им часто пользуюсь. И в нем нет ничего криминального — он всего-лишь инициализирует GL-контекст и дает минимальный mainloop с обработкой сообщений. Никаких функций, вроде make_me_a_demo(), как в d3dx (шутка), там нет.
Ну и люди, делающие интры под линукс, SDL'ем пользуются и, насколько я знаю, еще не получали отказов от организаторов демопати.
Ну и люди, делающие интры под линукс, SDL'ем пользуются и, насколько я знаю, еще не получали отказов от организаторов демопати.
Там, просто упомяну, что сейчас в мире Linux стандартным архиватором для высокого сжатия считается xz. Не уверен даст ли выигрыш в Вашем случае, но попробовать можно.
Под 64 бита собирается, но Segmentation fault :(
Падает при вызове glLinkProgram…
Боюсь, что тут нужно уже писать полноценное приложение с проверкой на ошибки, логами и прочим — похоже, что что-то по пути валится (не открываются библиотеки, не создается gl-контекст, не компилируются шейдерные программы и т.п.), но интра продолжает смело шагать по трупам как ни в чем не бывало, и в итоге травится трупными ядами.
В общем, падает из-за самих шейдеров. Если в версию без динамической подгрузки адресов функций вставить последний шейдерный код — падает :( А если в версию с динамической подгрузкой старые шейдеры — не падает. Более того дело в строчке
«2.*abs(.2*sin(p.z*3.+z*3.)+sin(p.z+a*4.)*p.xyxx*sin(vec4(z,a,a,a)))+(z-1.)*.1;»
если заменить её на
«p;»
То не падает :)
«2.*abs(.2*sin(p.z*3.+z*3.)+sin(p.z+a*4.)*p.xyxx*sin(vec4(z,a,a,a)))+(z-1.)*.1;»
если заменить её на
«p;»
То не падает :)
Спасибо, обязательно попробую, как дойдут руки.
И да, strip --remove-section=.comment немного убирает ненужного. И по идее .shstrtab тоже можно убрать, но не знаю для чего оно нужно.
Ага, .shstrtab содержит имена секций, её убрать не получится. А жаль :)
Можно делать сразу strip -s и, по идее, оно вырежет сразу всё, что считает безопасным. Но sstrip всё равно идёт дальше.
Ещё раз забегая вперёд во вторую часть — на самом секции вообще не нужны для запуска программы, и их все можно вымести поганой метлой. И даже от program headers можно безболезненно откусить ощутимый кусок.
Ещё раз забегая вперёд во вторую часть — на самом секции вообще не нужны для запуска программы, и их все можно вымести поганой метлой. И даже от program headers можно безболезненно откусить ощутимый кусок.
Про музыку-звук будут статьи?
Да, конечно. Но, боюсь, в часть 2 не влезет уже и пойдёт только в третью.
А когда стоит ждать новые части?
/me собрался осуществить мечту детства и выбраться на Assembly хотя бы в этом году :)
/me собрался осуществить мечту детства и выбраться на Assembly хотя бы в этом году :)
Если на меня ничего не свалится (например, автобус), то планирую каждые две-три недели выкладывать что-нибудь по теме, пока мои знания не закончатся.
Мечта хорошая, но на Assembly только в наступающем году теперь. А в этом один tUM остался из крупных: www.demoparty.net/
Мечта хорошая, но на Assembly только в наступающем году теперь. А в этом один tUM остался из крупных: www.demoparty.net/
Эх, вспомнил старый-добрый вирус LSD :)
www.youtube.com/watch?v=wM_PDC05Y4o
www.youtube.com/watch?v=wM_PDC05Y4o
Это довольно толстая реализация плазмы :D — судя по видео, её com-файл весит более 1кб. Конечно, для полнценного заражающего вируса это даже неплохо, но для только эффекта — очень много.
Можно посмотреть, что ребята умудряются запихивать в 256 байт (например, puls by Rrrola), или даже меньше — в последнее время сжигает напалмом некто fsqrt (возможно, наш соотечественник). Очень рекомендую к просмотру у него буквально всё. Для этого, правда, потребуется DOSBox (или же машина с досом, но кто их сейчас держит).
Можно посмотреть, что ребята умудряются запихивать в 256 байт (например, puls by Rrrola), или даже меньше — в последнее время сжигает напалмом некто fsqrt (возможно, наш соотечественник). Очень рекомендую к просмотру у него буквально всё. Для этого, правда, потребуется DOSBox (или же машина с досом, но кто их сейчас держит).
Привет!
Спасибо!
Лучше всего — машина с Windows XP, в ней делаю финальное тестирование и всё идёт быстро.
Многое тормозит в DosBOX, особенно в случаях чтения памяти (особенно нижних сегментов) и операциях fpu. Он в некоторых случаях может быть тормознее XP в десятки раз даже с максимальными настройками на скорость.
Насчёт плазмы — неплохую можно сделать в 54 байта или даже поменьше.
Так что пишите всё на асме и не жалейте времени на оптимизацию =)
ПС Осваиваю псевдо-воксели, сегодня вечером выложу кое-что на 128б.
Спасибо!
Лучше всего — машина с Windows XP, в ней делаю финальное тестирование и всё идёт быстро.
Многое тормозит в DosBOX, особенно в случаях чтения памяти (особенно нижних сегментов) и операциях fpu. Он в некоторых случаях может быть тормознее XP в десятки раз даже с максимальными настройками на скорость.
Насчёт плазмы — неплохую можно сделать в 54 байта или даже поменьше.
Так что пишите всё на асме и не жалейте времени на оптимизацию =)
ПС Осваиваю псевдо-воксели, сегодня вечером выложу кое-что на 128б.
Привет!
Windows XP да, тоже хороший вариант. Но, к сожалению, у меня, например, его нет — всё линуксы, да семёрки с макосями.
По асму и оптимизации скажу честно: я завидую :D. Потому что когда писал свои 256 для линукса, обнаружил, что совершенно не хватает ни фантазии, ни знания ассемблера для того, чтобы сделать что-нибудь интересное. Ни времени, чтобы за обозримые неделю-месяц их выработать.
Ну и еще там есть проблемы с производительностью и a/v sync, которые тоже требуют исследований. Но, я думаю, оно стоит того — там могут быть свои плюшки от, скажем, честного защищенного 32-битного режима.
Но, возможно, правда следует попробовать для начала заколбасить любопытное под дос, чтобы научиться и прочувстсвовать.
Windows XP да, тоже хороший вариант. Но, к сожалению, у меня, например, его нет — всё линуксы, да семёрки с макосями.
По асму и оптимизации скажу честно: я завидую :D. Потому что когда писал свои 256 для линукса, обнаружил, что совершенно не хватает ни фантазии, ни знания ассемблера для того, чтобы сделать что-нибудь интересное. Ни времени, чтобы за обозримые неделю-месяц их выработать.
Ну и еще там есть проблемы с производительностью и a/v sync, которые тоже требуют исследований. Но, я думаю, оно стоит того — там могут быть свои плюшки от, скажем, честного защищенного 32-битного режима.
Но, возможно, правда следует попробовать для начала заколбасить любопытное под дос, чтобы научиться и прочувстсвовать.
я кончил.
ничего из кода практически не понял (не совсем чтобы моя область), но ради такого стиля изложения готов даже перечитать ещё раз.
и даже не думай останавливаться!
ничего из кода практически не понял (не совсем чтобы моя область), но ради такого стиля изложения готов даже перечитать ещё раз.
и даже не думай останавливаться!
Буду показывать эту статью в ответ на вопрос «что такое хабр?».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание 1k/4k intro для Linux, часть 1