Работ пока прислано не очень много. 3 работы уже есть + должен прислать еще один человек + моя. итого будет оринтировочно 5 работ. очень надеюсь к концу сентября пришлют еще.
oisee ну это понятно! я думаю что те кто участвует регулярно просматривают топик на предем новостей а тем кому это безразлично бесполезно создавать отдельную тему. но за совет спасибо!
boris, небольшой совет: лучше пользоваться кнопкой «ответить» под комментарием, тогда будет понятно на что ты отвечаешь, и тот, кому ты отвечаешь получит уведомление.
Кнопка «оставить комментарий» внизу страницы добавляет комментарий к основному топику, а не к тому комментарию на который ты отвечаешь.
Всем доброго дня суток! До конца конкурса осталось чуть больше полумесяца! все кто принял участие просьба поторопиться с работами! напоминаю высылайте работы на мыло zxgame.basic@yandex.ru. призовой фонд конкурса 6000 рублей. напоминаю что приз 1 места — 3000 рублейБ 2 мести — 2000 рублей и 3 места — 1000 рублей. всем удачи!
перепутано у меня: я нашёл этот баг ещё в прошлую среду, и уже исправил — но потом была судорожная подготовка к verve и безумные выходные, так что до публикации не дошло… сейчас доделываю версию с бипером + слегка доработал функционал, в этой версии уже будет всё ок.
Крафтовый sizecode не может быть сравним с индустриальной компрессией, не подрывайте устоев веры!
В следующем материале попрошу разобрать проблему, каждую осень волнующую неокрепшие умы — «Bruteforce sizecoding на своременных вычислительных мощностях: вкалывают роботы, а не человек!»
Которых будут сетовать предлагаю расстреливать. Чтобы не мучались.
А вообще, компрессия — реально другой способ делать size-intro. Требует другие навыки, во многом ортогональные нормальному size-coding. Поэтому, с моей точки зрения, это скорее способ поддержать основы, путём увеличения видового разнообразия.
распространение этой информации нужно немедля запретить — она подрывает основы. вместо того, чтобы оптимизировать код люди будут сетовать на несовершенность компрессора, лишающего их шансов принять участие в size-compo
«Down with rules 256b» использует чуть подпиленный ZX7mini. Лично для меня это было важной частью задачи — показать, что компрессия актуальна в 256b, тем более что бут-сектор для Atari ST, послуживший моим вдохновением, занимал 512б и распаковывался, по словам автора, до 39438 байт: www.pouet.net/prod.php?which=57063
«Splash 1K» и «Chaos Construction 1K» используют ZX7 со стандартным распаковщиком.
Возможно ошибаюсь, у меня все жИ как бы не-настоящий TS, но зато хорошо отключать хоть чипы, хоть каналы по одному\оптом.
Так вот, первый и второй чип как бы перепутаны. Когда все 6 каналов сведены в стерео, попробуй догадайсО, какой чип звучит.
Авот когда выходы второго чипа отключены, и при этом первый молчит, а второй работает(судя по тесту) — тут я и задумываюсь, у меня ли перепутано или все же в сабже. На скорость конечно не влияйет, но все жЫ…
«Я делаю миниинтры (от 256б» — хотелось бы продолжать верить, что в sizecoding вплоть до 512 байтов никакие типовые упаковщики-распаковщики не используются.
Да, тоже этим занимался :) Хотя это очень быстро меня утомляет, экспоненциальный рост сложности такой оптимизации всё же парит :)
Ещё возил программу по памяти, чтобы константы брать из случайных регистров. Ещё, в самом конце уже, модифицировал распаковщики, чтобы сберечь несколько бит на настройках уже самого распаковщика (скажем, zx7mini копирует первый байт вслепую, а потом уже следит по битовому потоку. У меня выходило, что всё равно первые 6-8 байт не паковались, поэтому я просто копировал их автоматом, меняя настойки самого распаковщика).
это можно делать ifdef и сразу несколькими вариантами кода в исходнике, потом автоматический перебор всех вариантов включенных/выключенных definе, автокомпиляция-упаковка каждого состояния, сравнение всех и автовыбор минимальной интры… ;)
Упаковщик Hrum в составе mhmt УЖЕ оптимальный. Нет, Hrust 1 объективно лучший пакер Пьянкова на данный момент. Но по сжатию их вроде выжали на 100%. Теперь есть запас только по скорости.
Хотя, нужно будет расследовать, как именно там выбираются моменты для вставки кодов расширения ссылок в Hrust 1, потому что я что-то не совсем понимаю как это можно сделать оптимально, особенно с учётом того, что укорачивать коды вроде тоже декомпрессор позволяет.
Кнопка «оставить комментарий» внизу страницы добавляет комментарий к основному топику, а не к тому комментарию на который ты отвечаешь.
И тредом, и делом =)
Спасибо большущее.
(СОХРОНИЛ)
В следующем материале попрошу разобрать проблему, каждую осень волнующую неокрепшие умы — «Bruteforce sizecoding на своременных вычислительных мощностях: вкалывают роботы, а не человек!»
А вообще, компрессия — реально другой способ делать size-intro. Требует другие навыки, во многом ортогональные нормальному size-coding. Поэтому, с моей точки зрения, это скорее способ поддержать основы, путём увеличения видового разнообразия.
«Splash 1K» и «Chaos Construction 1K» используют ZX7 со стандартным распаковщиком.
Так вот, первый и второй чип как бы перепутаны. Когда все 6 каналов сведены в стерео, попробуй догадайсО, какой чип звучит.
Авот когда выходы второго чипа отключены, и при этом первый молчит, а второй работает(судя по тесту) — тут я и задумываюсь, у меня ли перепутано или все же в сабже. На скорость конечно не влияйет, но все жЫ…
Ещё возил программу по памяти, чтобы константы брать из случайных регистров. Ещё, в самом конце уже, модифицировал распаковщики, чтобы сберечь несколько бит на настройках уже самого распаковщика (скажем, zx7mini копирует первый байт вслепую, а потом уже следит по битовому потоку. У меня выходило, что всё равно первые 6-8 байт не паковались, поэтому я просто копировал их автоматом, меняя настойки самого распаковщика).
Хотя, нужно будет расследовать, как именно там выбираются моменты для вставки кодов расширения ссылок в Hrust 1, потому что я что-то не совсем понимаю как это можно сделать оптимально, особенно с учётом того, что укорачивать коды вроде тоже декомпрессор позволяет.