Так парсер цвет умеет только в scr. Значит цепочка софта удлиняется минимум на bmp2scr.
Думал о цветных GIF. Упирается всё в написание собственного (очередного) аналога bmp2scr. Я не готов.
Кстати, а где подробности о методах сжатия анимации в сабже?
Ну в методе «fast» и описывать нечего. Там просто заполнение адресов через ld. Достаточно открыть исходник любого фрейма и всё станет понятно.
А вот метод «memsave» похитрее. Там два блока: блок команд и блок данных. Данные — это собственно байты, которые выкидываются на экран. А в командах каждый байт делится на собственно операцию (три бита) и числовой параметр (5 бит). Таким образом получается 8 команд с параметром от 0 до 63. И еще есть текущий адрес экрана.
Общий принцип такой. Берется очередная команда — выполняется. При необходимости берется следующий байт из блока данных. И так пока не пройдем весь блок.
Описание операций я потерял вместе с умершим винчестером, но по исходникам можно восстановить. Если интересно. Основные команды, это выкинуть текущий байт на экран N раз со сдвигом указателя экрана, увеличить указатель экрана на N байт (short jump), увеличить указатель экрана на N*256 байт (long jump). Остальные не помню.
Сам парсер настроен на адрес #4000. Изменить на #c000 оно вроде бы один байт поменять, да. Но придется кучу PHP-кода переписывать. Но. Если использовать метод memsave, то достаточно один байт заменить в ресурсе каждого фрейма.
А так, читай выше. «Возможность тонкой настройки распределения памяти.» Не проблема зарезервировать нужные куски оперативки под экран.
Берется пачка цветных scr-файлов. Отрезается атрибутная информация и приклеивается ниже пикселей в виде 1-битной графики. Получается размер каждой картинки 256x212. Всё это склеивается в GIF-файл, который можно скормить парсеру. Написано это было до того, как появилась нативная поддержка SCR-файлов. Сейчас проще запаковать эту пачку SCR в ZIP-архив и залить в парсер.
Попробую все-таки разъяснить основную идею переделок в графике. Конкурс хайэнд графики не взлетел, ну и черт с ним. На других пати он работает, вот и отлично. Хотя и бывает, что компо взлетает не спервого года, и не со второго… Но самое главное, это то, что мы делаем еще один шажок назад, к олдскулу!
По различиям между компо PixelArt и 8bit Graphics. В первом случае художник работает в режиме «цвет-на-точку». Во втором рисует с использованием атрибутов. Вот и вся разница. Да, картинки из разных компо могут оказаться очень похожи технически. Но мы-то с вами понимаем, что это не так.
Я еще раз подумал, и решил, что все равно всем не угодишь. Всегда бывают такие ситуации, когда автор хочет выставиться для определенной платформы, а её нет в списке. И приходится выставляться в другом компо, или даже на другом пати.
Перетасовал в правилах список платформ более правильным образом. В частности, Amstrad CPC, MSX2 (Screen 5), ATM2 — это всё PixelArt. MSX2 (Screen 6/7/8) не попадают ни под какую категорию. Ну значит не судьба. А так-то, список этот ориентировочный, для примера. Художник и сам понимает (лучше меня), атрибутами он рисует, или попиксельно. Ну и спросить никто не мешает.
На счет несбалансированности и избыточности я не совсем согласен. Точнее согласен, что проблема есть, но не считаю её такой уж страшной.
А вот по третьему пункту получается неаккуратненько. MSX2 Screen7/8 в пролете, и это грустно. Расширяться до 640x480х256c не хочется. Во-первых, 16-цветные режимы встают в невыгодное положение. А уж 4-цветные тем более. К тому же лично мне больше всего нравится именно текущий вариант. Вводить еще одно компо тоже не хочу.
Ну в методе «fast» и описывать нечего. Там просто заполнение адресов через ld. Достаточно открыть исходник любого фрейма и всё станет понятно.
А вот метод «memsave» похитрее. Там два блока: блок команд и блок данных. Данные — это собственно байты, которые выкидываются на экран. А в командах каждый байт делится на собственно операцию (три бита) и числовой параметр (5 бит). Таким образом получается 8 команд с параметром от 0 до 63. И еще есть текущий адрес экрана.
Общий принцип такой. Берется очередная команда — выполняется. При необходимости берется следующий байт из блока данных. И так пока не пройдем весь блок.
Описание операций я потерял вместе с умершим винчестером, но по исходникам можно восстановить. Если интересно. Основные команды, это выкинуть текущий байт на экран N раз со сдвигом указателя экрана, увеличить указатель экрана на N байт (short jump), увеличить указатель экрана на N*256 байт (long jump). Остальные не помню.
Поддерживается. ZIP-архив с SCR файлами.
А так, читай выше. «Возможность тонкой настройки распределения памяти.» Не проблема зарезервировать нужные куски оперативки под экран.
По различиям между компо PixelArt и 8bit Graphics. В первом случае художник работает в режиме «цвет-на-точку». Во втором рисует с использованием атрибутов. Вот и вся разница. Да, картинки из разных компо могут оказаться очень похожи технически. Но мы-то с вами понимаем, что это не так.
Я еще раз подумал, и решил, что все равно всем не угодишь. Всегда бывают такие ситуации, когда автор хочет выставиться для определенной платформы, а её нет в списке. И приходится выставляться в другом компо, или даже на другом пати.
Перетасовал в правилах список платформ более правильным образом. В частности, Amstrad CPC, MSX2 (Screen 5), ATM2 — это всё PixelArt. MSX2 (Screen 6/7/8) не попадают ни под какую категорию. Ну значит не судьба. А так-то, список этот ориентировочный, для примера. Художник и сам понимает (лучше меня), атрибутами он рисует, или попиксельно. Ну и спросить никто не мешает.
А вот по третьему пункту получается неаккуратненько. MSX2 Screen7/8 в пролете, и это грустно. Расширяться до 640x480х256c не хочется. Во-первых, 16-цветные режимы встают в невыгодное положение. А уж 4-цветные тем более. К тому же лично мне больше всего нравится именно текущий вариант. Вводить еще одно компо тоже не хочу.
Может кто-то еще из художников выскажется?