CP/M для Вектора и Форматы файлов

[AzAtom]

А потом все вместе на 4

Проглядел. 12 ночи

Это во обоих форматах?

Смотрел только в .rmb.

Вот этот файл. Просто он уже был размером 256х256 пикселей, специально не тестировал.
002_Foto_andresr-176-4b.rar

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

я уже писал
Сообщение от ivagor
Работу с rbr/rmb в sprview надо править

Т.е., и там тоже должно быть сначала все первые строки от всех плоскостей, затем все вторые строки и т.д.?

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

Да вроде скорости более, чем достаточно.

Это я со своей колокольни смотрю просто. Делал преобразователь из формата спектрума в bmp, в дальнейшем задумываю свой эмулятор накалякать, поэтому скорость была интересна и критична. Начал с варианта со сдвигами, 1200 fps, закончил самым оптимальным вариантом с 15000 fps на core i5-2520M, причём, это преобразование сразу в 2 варианта, с flash и без него.

[Advertiser]

[ivagor]

RMB и RBR - это одно и тоже?

Насколько я знаю - да

Т.е., и там тоже должно быть сначала все первые строки от всех плоскостей, затем все вторые строки и т.д.?

Конечно

[Black Cat / Era CG]

Насколько я знаю - да

Спасибо за внесение ясности

[AzAtom]

ivagor, А там sprview ещё выдаёт файл с расширением .grf. Странное там что-то открывается, полосатое. Может, помните его описание или сохранилось?

[ivagor]

файл с расширением .grf

Это узкоспециальный формат, который я "изобрел", чтобы сохранять в удобном для компоновки с игрушкой виде тайлы малобюджетных Hudsonовских игрушек. Если кто вдруг захочет заняться конверсиями с msx, я посижу над исходником и накропаю описание.

[AzAtom]

ivagor, понятно. Вроде разобрался с ним, только непонятна осталась одна вещь.

Картинка 128х128 пикселей, разбита на блоки 8х8 пикселей. Блоки идут слева направо, потом сверху вниз.
В блоке строка представляется 4 байтами, аналогично представлению в векторе и с такими же цветовыми плоскостями. Одному блоку соответствует 32 байта следующим образом:

Плоскость:                                0                        1                        2                        3
Строка в блоке (сверху вниз): 0  1  2  3  4  5  6  7 | 7  6  5  4  3  2  1  0 | 0  1  2  3  4  5  6  7 | 7  6  5  4  3  2  1  0
Байт:                        00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F  10 11 12 13 14 15 16 17  18 19 1A 1B 1C 1D 1E 1F

Непонятен зачем был нужен такой зигзаг в порядке байтов.

[KTSerg]

ivagor, понятно. Вроде разобрался с ним, только непонятна осталась одна вещь.
Картинка 128х128 пикселей, разбита на блоки 8х8 пикселей. Блоки идут слева направо, потом сверху вниз.
...
Непонятен зачем был нужен такой зигзаг в порядке байтов.

Я с ним (с этим форматом) не разбирался конечно, но мне кажется я понял идею...
При переносе данных картинки на экран, можно использовать указатель адреса экранной памяти без "восстановления" его начального значения при переходе с "блока" на "блок" (или между плоскостями), просто сначала значение указателя увеличивается, затем - уменьшается (младший байт указателя), остаётся корректировать только старший байт указателя. Мне кажется элегантно.
Или я снова ничего не понял...

[ivagor]

зачем был нужен такой зигзаг в порядке байтов

Как написал KTSerg, для ускорения вывода на экран. PPC писал про это (вывод зигзагом) подробнее