svofski, извини, но если честно то я не понял как твой ответ соотносится с моим вопросом. Если сжимать по байтово то будет хуже сжиматься?
svofski, извини, но если честно то я не понял как твой ответ соотносится с моим вопросом. Если сжимать по байтово то будет хуже сжиматься?
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Байты битпланов сжимаются хуже, чем байты с парами пикселей.
Что касается сжатия pic2.pic
w256 - 23620
w512 - 22705
w1024 - 21265
w2048 - 20780
Видно, что до 1024 включительно выигрыш от сжатия растет быстрее, чем пенальти от увеличения буфера. Распаковка и getbyte конечно будут медленнее, но если расположить буфер впритык к 8000h, то не сильно медленнее (проверяем знак). Надо ли это делать - не уверен, но если что - резерв по сжатию есть.
parallelno(21.09.2022)
Значит я не понял твоего вопроса. Что значит сжимать побайтово? С моей точки зрения все уже и так сжимается побайтово.Сообщение от parallelno
- - - Добавлено - - -
256 все-таки хороший компромисс. Но если dzx0 в принципе через условную компиляцию будет поддерживать разные размеры буферов -- это дело хорошее. Не только ведь картинки сжимать, и не только прогрессивные и не только полноцветные. А если чисто для этой демки, смысла нет, тут уж получилось что получилось по-моему.
Больше игр нет
svofski, я имел ввиду данные картинки в том виде в котором она лежит в видеопамяти сжать как линейный кусок памяти от $8000 до $ffff.
- - - Updated - - -
ivagor уже ответил что так хуже сжимается.
parallelno, понятно. Да, так хуже. Кроме того тут не только упаковка, но и эффект.
Обновил все файлы с последними мегаспидапами от ivagor-a. Тут конечно можно разворачивать циклы и все такое, но заметного прироста это не дает.
Мозолят глаз всевозможные push-pop-ы, но я думаю это все от лукавого. Без них только если совсем радикально как-то все менять.
Больше игр нет
ivagor(21.09.2022)
svofski и ivagor, вопрос не по теме как таковой, т.к. я далёк и от железа и от математики, но вы сейчас тут походу одни кто считает такты ;-) Если представить гипотетический однотактовый процессор, которую любую арифметическую и логическую операцию над 1-2 байтами выполняет за 1 такт, а над последовательностью байт за количество байт тактов. То вся ваша аппаратная оптимизация потеряет смысл и перейдёт в плоскость математической оптимизации?
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
Насчет терминов - я бы все же назвал эти два аспекта "оптимизация реализации" и "оптимизация алгоритма". Оптимизация реализации имеет смысл и для RISC-подобного конвеерного процессора. Пусть базовые команды выполняются в идеале за такт, но с учетом конвеера там возникают конфликты по доступу к исполнительным устройствам. И даже без конфликтов конвеера (или для гипотетического неконвеерного процессора) выбор конкретных команд важен (смотря еще какие команды). Ну а оптимизация алгоритма, или выбор более удачного алгоритма - это как правило более действенное средство, если такие алгоритмы существуют или их можно разработать.
Я про гипотетический процессор, где любая команда выполняется за так, без всяких конвейеров.
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
Хочу порекомендовать Retro assembler. Очень много возможностей, встраивается как плагин в VS Code.
https://enginedesigns.net/retroassembler/
Документация
https://enginedesigns.net/download/retroassembler.html
Проект GameNoname написан на нем. Если есть желающие могу рассказать подробнее как и что в нем есть.
Improver(21.10.2022)
Посмотрел слегка. Не увидел IRP/IRPC... грустно.( У меня был проектик в начале 2000-х, 36000 строк, на m80 (1981г!) под CP/M небезизвестного Б.Гейтса. Попытки перевести на что то более другое (современное) не возымели успеха! Многие вообще сыпались на таком объёме (Zilog в т.ч.), у многих не хватало требуемых директив... В общем, забил и успокоился.(
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
