Да, я тоже думал об этом. Бывали времена, когда я открывал почтовик и почти начинал клянчить у Ментора разрешение/помощь для разбора его алгоритма паковки, но всегда останавливало то, что там есть нерешенные проблемы ещё до самого паковщика:
1) Динамическая линковка в эльфе не то, чтобы особо sizecoding-friendly. У меня в urotsuki (и нерелизнутых потомках) есть наработки, но они не шибко вылизанные; про них всё не доходят руки написать в части 2 про линукс-1/4k.
2) Свой линкер. Это тоже относительно объёмная и утомительная задача. У которой, к тому же, нет и явного выхлопа самой по себе. Можно, конечно, попробовать избавиться от gzip-дроппинга, прилинковавшись к какой-нибудь системной zlib, но из соображений размера тут будет только поражение по очевидным причинам.
Хотя, конечно, если линкер поможет избавить от выпиливания эльф-заголовков под каждый чих вручную, да ещё и сможет переставлять секции и варьировать прочие свободные параметры, оптимизируя их для гзипа, будет удобно.
Вообще, думаю, что даже с одним гзип-дроппингом можно делать вполне конкурентноспособные вещи — по субъективным ощущениям, для 1к по крайней мере, места для творчества остается больше, чем под виндой. Ну и вообще в 1-4к очень много всего неизведанного. Как минимум, например, ни один из существующих синтов меня не устраивает звучанием.
Другое дело, что современная sizecoding линукс-сцена, похоже, состоит только из нас двоих :D.
думаю, что туда можно звук еще засунуть, если очень постараться — пожертвовать сложностью графики и совместить их синтез.
аж руки зачесались, жаль занят сейчас другим проектом :D
Не могу пройти мимо.
FYI, насколько я знаю, полноценная оффлайн-версия для WP7 технически невозможна — пользуясь случаем, передаю привет Microsoft и её отсутствию средств нативной разработки для WP7 и принуждению всех к шарпу (hand-crafted ассемблерные оптимизации для ARM плачут!).
Вы, ей богу, правы — мир чёрно-белый и простой-простой. И разработка ничего не стоит, шейдеры волшебным образом взлетают на GLES1, программы автоматически работают на 486SX25 с 4Мб памяти, да и вообще пишутся сами собой без участия человека, еда сама возникает из квантовых флуктуаций прямо во рту, и девочки сразу раздеваются, стоит на них только посмотреть.
К сожалению, ситуация несколько сложнее, чем просто «ниже планку опустить». Дело в том, что устройства младше третьего поколения обладают более старой архитектурой процессора, что влечет за собой некоторые технические сложности.
Привет!
Windows XP да, тоже хороший вариант. Но, к сожалению, у меня, например, его нет — всё линуксы, да семёрки с макосями.
По асму и оптимизации скажу честно: я завидую :D. Потому что когда писал свои 256 для линукса, обнаружил, что совершенно не хватает ни фантазии, ни знания ассемблера для того, чтобы сделать что-нибудь интересное. Ни времени, чтобы за обозримые неделю-месяц их выработать.
Ну и еще там есть проблемы с производительностью и a/v sync, которые тоже требуют исследований. Но, я думаю, оно стоит того — там могут быть свои плюшки от, скажем, честного защищенного 32-битного режима.
Но, возможно, правда следует попробовать для начала заколбасить любопытное под дос, чтобы научиться и прочувстсвовать.
Это довольно толстая реализация плазмы :D — судя по видео, её com-файл весит более 1кб. Конечно, для полнценного заражающего вируса это даже неплохо, но для только эффекта — очень много.
Можно посмотреть, что ребята умудряются запихивать в 256 байт (например, puls by Rrrola), или даже меньше — в последнее время сжигает напалмом некто fsqrt (возможно, наш соотечественник). Очень рекомендую к просмотру у него буквально всё. Для этого, правда, потребуется DOSBox (или же машина с досом, но кто их сейчас держит).
Можно делать сразу strip -s и, по идее, оно вырежет сразу всё, что считает безопасным. Но sstrip всё равно идёт дальше.
Ещё раз забегая вперёд во вторую часть — на самом секции вообще не нужны для запуска программы, и их все можно вымести поганой метлой. И даже от program headers можно безболезненно откусить ощутимый кусок.
Боюсь, что тут нужно уже писать полноценное приложение с проверкой на ошибки, логами и прочим — похоже, что что-то по пути валится (не открываются библиотеки, не создается gl-контекст, не компилируются шейдерные программы и т.п.), но интра продолжает смело шагать по трупам как ни в чем не бывало, и в итоге травится трупными ядами.
По этому вопросу нет единого мнения. С одной стороны, SDL не является частью системы де-юре — оно не входит ни в какой LSB, есть системы, где оно не поставляется и пр. С другой стороны, де-факто он есть почти везде, относительно стабильный и очень удобный — я даже для больших программ им часто пользуюсь. И в нем нет ничего криминального — он всего-лишь инициализирует GL-контекст и дает минимальный mainloop с обработкой сообщений. Никаких функций, вроде make_me_a_demo(), как в d3dx (шутка), там нет.
Ну и люди, делающие интры под линукс, SDL'ем пользуются и, насколько я знаю, еще не получали отказов от организаторов демопати.
Лол, она у меня уже три недели как дописанная почти была, всё руки не доходили перечитать, исправить шероховатости и выложить.
Следующая будет про ассемблер и elf. Про фреймбуфер потом. Можешь, в принципе, сам написать, если хочешь.
sstrip можно взять здесь: www.muppetlabs.com/~breadbox/software/elfkickers.html
Простого strip не хватит — он довольно дурацкий и не вырезает, например, секции, которые для работы программы нафиг не нужны, только для отладки и всякой расширенной информации
(между нами, sstrip тоже не идеальный — он вырезает только то, что находится после всех-всех полезных частей программы, совершенно не трогая мусор, лежащий где-то посередине. В принципе, зная формат elf, можно наколбасить полноценный ssstrip, который перемешивал бы содержимое по-взрослому, но так лень, так лень).
>> i915_program_error: Unsupported opcode: IF
Похоже, что i915 не все функции из там написанных понимает нативно и пытается развернуть их во что-то более сложное, с ветвлениями и прочим неподдерживаемым. Можно поэкспериментировать — аккуратно повыключать «сложные» функции — и понять, в чем именно дело. Но дальше я не подскажу.
Ровно про это — как наколбасить elf-заголовок ручками на ассемблере — и будет следующая статья. Забегая вперед скажу, что там удается отжать у gcc/ld еще примерно 200-300 байт, что в масштабах 1кб, мягко скажем, очень много.
Да, импорт по хешу лучше не делать, он довольно нестабилен оказывается почему-то — то ли между версиями/сборками libc какие-то различия есть, то ли еще что. В любом случае это выливается в то, что старые интры не работают больше — падают в коде подгрузки функций по хешу.
1) Динамическая линковка в эльфе не то, чтобы особо sizecoding-friendly. У меня в urotsuki (и нерелизнутых потомках) есть наработки, но они не шибко вылизанные; про них всё не доходят руки написать в части 2 про линукс-1/4k.
2) Свой линкер. Это тоже относительно объёмная и утомительная задача. У которой, к тому же, нет и явного выхлопа самой по себе. Можно, конечно, попробовать избавиться от gzip-дроппинга, прилинковавшись к какой-нибудь системной zlib, но из соображений размера тут будет только поражение по очевидным причинам.
Хотя, конечно, если линкер поможет избавить от выпиливания эльф-заголовков под каждый чих вручную, да ещё и сможет переставлять секции и варьировать прочие свободные параметры, оптимизируя их для гзипа, будет удобно.
Вообще, думаю, что даже с одним гзип-дроппингом можно делать вполне конкурентноспособные вещи — по субъективным ощущениям, для 1к по крайней мере, места для творчества остается больше, чем под виндой. Ну и вообще в 1-4к очень много всего неизведанного. Как минимум, например, ни один из существующих синтов меня не устраивает звучанием.
Другое дело, что современная sizecoding линукс-сцена, похоже, состоит только из нас двоих :D.
аж руки зачесались, жаль занят сейчас другим проектом :D
FYI, насколько я знаю, полноценная оффлайн-версия для WP7 технически невозможна — пользуясь случаем, передаю привет Microsoft и её отсутствию средств нативной разработки для WP7 и принуждению всех к шарпу (hand-crafted ассемблерные оптимизации для ARM плачут!).
Windows XP да, тоже хороший вариант. Но, к сожалению, у меня, например, его нет — всё линуксы, да семёрки с макосями.
По асму и оптимизации скажу честно: я завидую :D. Потому что когда писал свои 256 для линукса, обнаружил, что совершенно не хватает ни фантазии, ни знания ассемблера для того, чтобы сделать что-нибудь интересное. Ни времени, чтобы за обозримые неделю-месяц их выработать.
Ну и еще там есть проблемы с производительностью и a/v sync, которые тоже требуют исследований. Но, я думаю, оно стоит того — там могут быть свои плюшки от, скажем, честного защищенного 32-битного режима.
Но, возможно, правда следует попробовать для начала заколбасить любопытное под дос, чтобы научиться и прочувстсвовать.
Можно посмотреть, что ребята умудряются запихивать в 256 байт (например, puls by Rrrola), или даже меньше — в последнее время сжигает напалмом некто fsqrt (возможно, наш соотечественник). Очень рекомендую к просмотру у него буквально всё. Для этого, правда, потребуется DOSBox (или же машина с досом, но кто их сейчас держит).
Мечта хорошая, но на Assembly только в наступающем году теперь. А в этом один tUM остался из крупных: www.demoparty.net/
Ещё раз забегая вперёд во вторую часть — на самом секции вообще не нужны для запуска программы, и их все можно вымести поганой метлой. И даже от program headers можно безболезненно откусить ощутимый кусок.
Ну и люди, делающие интры под линукс, SDL'ем пользуются и, насколько я знаю, еще не получали отказов от организаторов демопати.
Следующая будет про ассемблер и elf. Про фреймбуфер потом. Можешь, в принципе, сам написать, если хочешь.
Простого strip не хватит — он довольно дурацкий и не вырезает, например, секции, которые для работы программы нафиг не нужны, только для отладки и всякой расширенной информации
(между нами, sstrip тоже не идеальный — он вырезает только то, что находится после всех-всех полезных частей программы, совершенно не трогая мусор, лежащий где-то посередине. В принципе, зная формат elf, можно наколбасить полноценный ssstrip, который перемешивал бы содержимое по-взрослому, но так лень, так лень).
>> i915_program_error: Unsupported opcode: IF
Похоже, что i915 не все функции из там написанных понимает нативно и пытается развернуть их во что-то более сложное, с ветвлениями и прочим неподдерживаемым. Можно поэкспериментировать — аккуратно повыключать «сложные» функции — и понять, в чем именно дело. Но дальше я не подскажу.
Да, импорт по хешу лучше не делать, он довольно нестабилен оказывается почему-то — то ли между версиями/сборками libc какие-то различия есть, то ли еще что. В любом случае это выливается в то, что старые интры не работают больше — падают в коде подгрузки функций по хешу.