Новый формат графического изображения для ZX совместимых компьютеров.

[Ynicky]

А я тут решил еще один эксперимент сделать.
Если оставить знакоместа как есть (8х8), только атрибуты сделать по 2 байта (64К на INK и 64K на PAPER), размер изображения станет равен 0х2400 (9216) байтам. Совсем не много. Зато картинки остаются вполне смотрабельными.
(Но это так - зарядка для мозгов.)

Слева направо: RGB888, RGB565_4x4, RGB565_8x8:

[bigral]

С первого взгляда концепция нового изображения годится разве что для full screen video (через какой-нибудь datagear), потому что attribute clash критически сказывается на графике которая двигается попиксельно. Впрочем, у ZX если графика занимает четко несколько знакомест и шаг движения только по знакоместам то никакого attribute clash нету, значит тут можно будет двигать предметы с шагом 4pix ну и размер теперь можно делать кратный четвертям знакоместа. Другое дело что размер атрибутов вырос в 8 раз?, в принципе можно это компенсировать через турбо процессора. Т.е. вроди как идея имеет смысл. Надо обкатать в эмуляторах чтобы прикинуть какая частота процессора будет нужна.

[Lethargeek]

С первого взгляда концепция нового изображения годится разве что для full screen video (через какой-нибудь datagear), потому что attribute clash критически сказывается на графике которая двигается попиксельно. Впрочем, у ZX если графика занимает четко несколько знакомест и шаг движения только по знакоместам то никакого attribute clash нету, значит тут можно будет двигать предметы с шагом 4pix ну и размер теперь можно делать кратный четвертям знакоместа. Другое дело что размер атрибутов вырос в 8 раз?, в принципе можно это компенсировать через турбо процессора. Т.е. вроди как идея имеет смысл. Надо обкатать в эмуляторах чтобы прикинуть какая частота процессора будет нужна.

Какой смысл - "как бездарнее потратить ресурсы плис"? Уже есть режимы с цветом на точку, где графика ворочается процессором в общей памяти - вообще без атрибутных ограничений, двигать можно с шагом 1-2pix, но софта под них - alone coder наплакал. В то время как на исторический Спектрум игорей клепают десятки в год, всё под тот же самый старый экран, всё под те же самые 3.5мгц. Потому что лень кодить под несовместимый режим, потому что у классики на порядок больше аудитория, потому что выходить за рамки классики неспортивно... Из всех новшеств только юла+ довольно регулярно поддерживается, ибо просто и наличие некритично. При несоблюдении этих принципов любой монстр неизбежно будет мертворождённым (в лучшем случае - кумиром немноголюдной секты с автором-первосвященником во главе).

[bigral]

Какой смысл - "как бездарнее потратить ресурсы плис"?

Про ПЛИС забудь, интерес падает и уже почти 0, так же как и эмуль. Про 16c и ATM ega тоже можно забывать, так как даже такой крутой alone не смог ниче туда портировать (не хватает скорости? не удобно? х.з.). Eсли запилить шото по моще типа как у MSX2+, и в таком же виде как divide, то как раз оно пойдет пачкой так же как и сам divide (даже если плата будет размером с 2 harlequin-a).

[Lethargeek]

Про ПЛИС забудь, интерес падает и уже почти 0, так же как и эмуль.

ну, автор пишет же в заглавном посте про плис

Про 16c и ATM ega тоже можно забывать, так как даже такой крутой alone не смог ниче туда портировать (не хватает скорости? не удобно? х.з.).

А также времени, ведь кроме собственно кодирования заново даже тайминги надо распланировать по-другому. Ящетаю, что взлететь способно сейчас лишь то, что позволит без больших усилий улучшить графику даже старых игр, доступных только в виде бинарника, с минимальным изменением оного (в идеале - вовсе без изменений). Что значит - автоматически и для новых (каковые пишут всё равно под старый стандартный Спек).

То есть нужен некий "внешний" девайс, у себя внутри рисующий улучшенную картинку "по мотивам" нарисованного на Спеке. Причём даже не подробно проработанная железка, а минимальный общий стандарт на простые пиксельные операции в духе Спека и "подсказки" или "теневые команды", выполняемые параллельно с кодом на Спеке, и на механизм предварительной загрузки данных в девайс. Само железо может быть и разным теоретически, с разными нативными наворотами, разными физическими режимами и способами доступа к ним. Лишь бы только успевало за Спеком пиксели в своём формате модифицировать, и чтобы узнавался оригинал.

[Smalovsky]

Lethargeek, ну вперёд. Никто тебе мешать не будет. Ты начинал про парабайты и парабиты. Может, есть смысл это развить на базе внешнего арма?

- - - Добавлено - - -

Хорошо бы 4х4 256 обкатать в эмуляторе.
Ynicky, тут мне написали, что нужно потестить изображение на картинках где много мелких разоцветных деталей. Сомневаются в видеорежиме...

[Ynicky]

Ynicky, тут мне написали, что нужно потестить изображение на картинках где много мелких разоцветных деталей. Сомневаются в видеорежиме...

Давайте пример, сделаю.

[Smalovsky]

vlad, может, у тебя есть идея нового видеорежима?
Уже вступил в клан тэсэлыча?

- - - Добавлено - - -

Я помню таких залётных зст отправлял сразу на тсу. )) И как результат много людей заинтересовалось Метеором.

[Ynicky]

[Smalovsky]

Ynicky, найди 256 цветное изображение с мелкими деталями и обработай. Нужно посмотреть на сколько изменится клэшинг( в смысле какое преемущество 4х4 над обычным экраном).
Можешь перевести в 256 цветов изображение которое ты привёл, а потом обработать конвертером.