Новый графический режим для игр

[Alex Rider]

Пока чтение для новых режимов не предусмострено, FLASH тоже.

Ну чтение, хрен с ним, нужно только для определения столкновений во время отрисовки, не велика поетря с учетом того, что такой способ не дает ответа на вопрос "с чем столкнулись". А что будет делать бит FLASH в 2-цветном режиме? Поднимать яркость PAPER'а? Кстати, в стандартном режиме (с выключенной фкнуциональностью совсем и в слое стандартного экрана) FLASH надо сделать обязательно, ибо придется что-то мудрить в играх, где FLASH используется. Не хотелось бы его делать программно.

[Nesser]

В старом режиме (с кратностью 8) надо еще и переход через трети детектить на кажом сдвиге на одно знакоместо вниз, а по пиксельным строкам вообще только на 7 ниже можно опуститься без фокусов

У меня всегда была таблица адресов по Y - 384 байта, никогда с этим не заморачивался

---------- Post added at 23:27 ---------- Previous post was at 23:23 ----------

Вот посмотри
http://zxaaa.untergrund.net/view_demo.php?id=4898
Я делал хер знает когда, только не ржите, графику не я рисовал
С адресацией Y никогда проблем не было

[Alex Rider]

Я одного не могу понять, если пытаться вкорячить это в старые игры переделывая им только часть вывода на экран то что измениться?

Вырастет скорость отрисовки. Исчезнет клешинг. Это уже немало.

Кроме того почти во всех играх спрайты ЧЁРНО-БЕЛЫЕ, а атрибуты выставляются принудиловкой после вывода спрайтов, то есть самих цветов то и нет, если накладывать сверху цветовую маску в 2 бита так это увеличение объёма спрайта на 2 раза, был 1 бит ч/б стал 1 бит ч/б+2 бита цвета, то есть надо раздвигать код и скорее всего всё это не влезет в память и придётся делать драйвер страниц.

Возможно. Не обязательно переделывать все спрайты, возможно, пепекраска лишь некоторых спрайтов (особенно, статичных) сделает игру намного красивше. Если будут реализованы палитры, можно будет еще больше разнообразить игры в плане цветов (как в ULA+, например). Собственно, карта позволяет переделывать игру постепенно: сначала убрали клешинг и разогнали, потом переделали графику обрамления экрана, потом раскрасили ГГ... Частые релизы с небольшими изменениями подпитывают интерес к переделке и позволяют собрать больше мнений сообщества. Можно действительно допеределываться до того, что старого кода и не останется совсем Лишь бы людям было интересно.

Да и получается что надо делать редактор спрайтов, выковыривать старые и дорабатывать их из 1 бита в 1+2 бита, то есть по сути заново сделать саму игру.

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

---------- Post added at 22:33 ---------- Previous post was at 22:30 ----------

Вот посмотри

Неплохо

У меня всегда была таблица адресов по Y - 384 байта, никогда с этим не заморачивался

Выход за пределы этой таблицы же тоже надо контроллировать, правильно? И inc hl на 31-м столбце тоже. Так что у zst как минимум не хуже, только таблица не нужна от слова "совсем"

[zx-kit]

О линейной адресации байтов на экране

Для новых режимов графики в дополнительных слоях 1-8 адресация байтов на экране линейная, экран располагается с адреса 0000 и занимает 8 KB.
Если в hl записан адрес байта, то для перехода к байту справа надо выполнить команду inc h, для перехода к байту снизу - inc l.

Преимущество линейной адресации:
Проще и быстрее вычислять адрес байта на экране.
Нет деления экрана на трети/секторы.
Для копирования/стирания тайлов/спрайтов можно использовать более эффективные комбинации команд Z80.
Можно выводить тайлы/спрайты/буквы с точностью до пиксела по-вертикали.
В дальнейшем можно будет увеличить разрешение экрана до 320х240 точек.

При линейной адресации экрана с адреса 0000:
Первый столбик байтов имеет адреса 0000, 0001, ... 00BF.
Второй столбик - 0100, 0101, ... 01BF.
Последний столбик - 1F00, 1F01, ... 1FBF.

[Nesser]

Так это уже не линейная адресация а НЕлинейная
Линейная это когда номер пикселя совпадает с адресом, а тут получается 192*32 ?
А 320*240 это 240*40 ?
Я так и не понял а как вычислять смещение пикселя в байте? программно?

---------- Post added at 23:57 ---------- Previous post was at 23:55 ----------

Эээээ а как считывать байт? считается пзу ?

---------- Post added 07.09.2015 at 00:00 ---------- Previous post was 06.09.2015 at 23:57 ----------

И я не понял как это переделывать игру постепенно ?
Она или переделывается сразу и полностью или делается заново с модульным строением для добавления новых функций "видеорежима".

[Alex Rider]

Так это уже не линейная адресация а НЕлинейная

Никто и не спорит

Я так и не понял а как вычислять смещение пикселя в байте? программно?

Да

Эээээ а как считывать байт? считается пзу ?

Пока да. Надеюсь, потом уговорю zst читать что-то вразумительное из текущего слоя.

И я не понял как это переделывать игру постепенно ?
Она или переделывается сразу и полностью или делается заново с модульным строением для добавления новых функций "видеорежима".

Откуда инфа?
В чем я вижу плюс "Метеора" - в том, что игру можно переделывать именно постепенно. Потому что непеределанный код работает так же, как и раньше - пишет в стандартный слой, соответствющий видеорежиму Спектрума. Захотели отрисовать что-то по-другому, переделали кусочек, наслаждаемся результатом. Потренировались на статике, переделали передний слой, потом ГГ, потом врагов, в общем, как хочешь. Остальные реализованные видеорежимы требуют переделки всей отрисовки сразу. Ну, может быть, в TS-Conf из-за строчных прерываний можно оставить, к примеру, какую-то часть экрана срандартной и переделать, скажем, какую-нить приборную панель внизу.

[Nesser]

А чё экран боком?

[Nesser]

Для такой простой графики не много ли 2 проца по 4 МГц ?

[zx-kit]

Так это реально работающий проект на z80, а то что здесь намечтали уже работает?

А игры там можно модернизировать/писать ? Или это совсем со Спектрумом не связано ?

zst, у тебя на Specy2010 заработала тестовая конфигурация?

Я пока железом и кодированием не занимался. Только синхроимпульсы VGA на VERILOGе. Твои проекты слишком сложные и не подходят мне. Надо будет все видеорежимы писать с нуля. Сейчас я пока мечтаю, проектирую режимы, а кодированием займусь потом.

---------- Post added at 18:25 ---------- Previous post was at 18:10 ----------

Предлагаю сделать палитру в 512 байт (коли 16 бит на цвет). Загружать по ldir в некую область ПЗУ, во время записи карта будет вычитвать палитру (желательно менять палитры динамически, чтобы можно было иметь разные палитры в разных локациях; желательно иметь возможность менять любой цвет в палитре, можно будет делать fade-in-эффекты).
Как адресовать палитры:
1 цвет - атрибут слоя задает номер цвета в палитре (0-255), номер палиты слоя не используется.
2 цвета - номер палитры слоя (старшие 4 бита) задают одну из 16 палитр, из которой выбираются цвета INK и PAPER (0-7), включенный бит BRIGHT означает, что к номеру цвета INK добавляется 8. После сброса номер палитры для такого режима - 0, а сама палитра инициализируется стандартными цветами Спектрума (16 одинаковых 16-цветных палитр). Кстати, бит Flash будет поддерживаться?
2 цвета + прозрачный - то же, что и 2 цвета, но цвет №0 - прозрачный (так же и для 3, 7 и 15 цветов).
3,4 цвета - каждая пара бит кодирует один из четырех цветов одной из 64 палитр, номер (смещение 1-го цвета) которой задают 6 старших бит номера палитры слоя.

Очень хочется вот этот функционал сразу. Объясню почему: избавление игр от клешинга не дает такой wow-эффект, как появление коричневенького, оранжевенького или сиреневенького хотя бы на статичной рамке экрана в игре

512 байтов - это наверно для палитры VGA, для остальных на 2-4 бита по 256 отдельных палитр, расположить во внутреннем ОЗУ SDRAM.

На первом этапе в слоях будут использоваться номера цветов от 0 до 15, соответствующие стандартным цветам. Только вместо темного черного с номером 0 будет писаться в слой яркий черный с номером 8. Зачем нам два черных ? А номер 0 - будет для прозрачного цвета.

Как говорили в этой теме MVV и другие - надо сначала сделать что-то простое. Сразу то все не получится. Вот к этим номерам для каждого слоя потом можно добавить старшие 4 бита номера палитры для слоя. Тогда номера цветов при выводе в буфер экрана будут от 0 до 255.

Сменой номера палитры слоя и 15 цветов в этой палитре можно делать затемнение или использовать для этого палитру VGA.

А палитра VGA 255 -> 32768 будет общая для точек из буфера экрана. С другой стороны, 255 цветов на экране может не хватить в будущем. И надо об этом подумать сейчас. Может важнее затемнений возможность рисовать в каждом слое со своей палитрой 255 -> 32768.


Переменная attribute не очень подходит для разных режимов цвета. Наверно надо сделать несколько переменных для разных режимов:
1 цвет - color - номер цвета 0-15 (в дальнейшем до 255)
2 цвета - attr - атрибут как в стандартном режиме, только FLASH не используется
3-4 цвета - pl2bit - номер двухбитной палитры
7-8 цветов - pl3bit - номер трехбитной палитры
15-16 цветов - pl4bit - номер четырехбитной палитры

Надо подумать как сделать так, чтобы после сброса все палитры показывали стандартные цвета. Наверно палитры с номером 0 делать аппаратные со станlартными цветами, а палитры 1-255 уже в ОЗУ.

Окно размером 256 или 512 байтов во области ПЗУ можно выделить для загрузки палитр. Теперь надо выбрать, как указывать, какую палитру мы загружаем для каждого режима.

[Nesser]

А палитра VGA 255 -> 32768 будет общая для точек из буфера экрана. С другой стороны, 255 цветов на экране может не хватить в будущем. И надо об этом подумать сейчас. Может важнее затемнений возможность рисовать в каждом слое со своей палитрой 255 -> 32768.

Дык не проще сделать тупо по 16 бит на точку, а все перепаковки предварительно сделать программно?
Я боюсь всех этих палитр, смахивает на сжатый bmp, только тут его походу придётся пережимать в реальном времени на каждый пиксель