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, потому что я что-то не совсем понимаю как это можно сделать оптимально, особенно с учётом того, что укорачивать коды вроде тоже декомпрессор позволяет.
Для ловли блох такого рода, рекомендую пересобрать избранный оптимальный пакер, добавив к нему функцию печати итогового числа бит. Часто бывает, что есть 2-3 варианта кода, вроде примерно одно и то же, на итоговый размер в байтах не влияет, но в таком упаковщике с битами видишь, какой вариант был реально оптимальнее. Я много сберёг используя такой подход в «Down with the rules». Очень много циклов развернул и т.д. У меня гораздо больше итоговый неупакованный размер интры, по сравнению с тем, что делал ты. Подозреваю, что на 4кб должно получаться 6-7кб кода «оптимизированного под упаковщик». Например, вместо декранчера писать хорошо жмущийся код — ну, ты понимаешь.
Т.е. для себя я сделал такой вывод: нужно переписать Hrust 1 и Hrum для работы с битовым потоком в байтах (вместо битов) и переписать их распаковщики примерно по той же схеме, по которой написаны сейчас ApLib, Exomizer и ZX7. Думаю, это уменьшит их размер Hrust 1 и сделает его вполне конкурентными в чём-то вроде 4K; в случае с Hrum я думаю больше смысла пытаться конкурировать с пакерами типа ZX7, т.е. брать размером распаковщика и скоростью распаковки.
Кнопка «оставить комментарий» внизу страницы добавляет комментарий к основному топику, а не к тому комментарию на который ты отвечаешь.
И тредом, и делом =)
Спасибо большущее.
(СОХРОНИЛ)
В следующем материале попрошу разобрать проблему, каждую осень волнующую неокрепшие умы — «Bruteforce sizecoding на своременных вычислительных мощностях: вкалывают роботы, а не человек!»
А вообще, компрессия — реально другой способ делать size-intro. Требует другие навыки, во многом ортогональные нормальному size-coding. Поэтому, с моей точки зрения, это скорее способ поддержать основы, путём увеличения видового разнообразия.
«Splash 1K» и «Chaos Construction 1K» используют ZX7 со стандартным распаковщиком.
Так вот, первый и второй чип как бы перепутаны. Когда все 6 каналов сведены в стерео, попробуй догадайсО, какой чип звучит.
Авот когда выходы второго чипа отключены, и при этом первый молчит, а второй работает(судя по тесту) — тут я и задумываюсь, у меня ли перепутано или все же в сабже. На скорость конечно не влияйет, но все жЫ…
Ещё возил программу по памяти, чтобы константы брать из случайных регистров. Ещё, в самом конце уже, модифицировал распаковщики, чтобы сберечь несколько бит на настройках уже самого распаковщика (скажем, zx7mini копирует первый байт вслепую, а потом уже следит по битовому потоку. У меня выходило, что всё равно первые 6-8 байт не паковались, поэтому я просто копировал их автоматом, меняя настойки самого распаковщика).
Хотя, нужно будет расследовать, как именно там выбираются моменты для вставки кодов расширения ссылок в Hrust 1, потому что я что-то не совсем понимаю как это можно сделать оптимально, особенно с учётом того, что укорачивать коды вроде тоже декомпрессор позволяет.
возможно, возможен «optimal hrum packer», как для hrust'а? ;)
мы это все проходили в 2012 году, прям 1в1