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

[Smalovsky]

Я вспомнил старинный прием для изображения фона, состоящего из мелких деталей, в играх для спектрума. Суть в том, что первый раз фон формируется в видеопамяти медленно, а в последующих кадрах он не изменяется целиком, перерисовываются( изменяются, восстанавливаются) только те участки фона, которые были затерты спрайтами . Но это решение хорошо только для статических фонов.
На основе этого приема,но существенно изменив технологию, я придумал следующее решение:
Добавить в видеокарту дополнительный буфер памяти, добавить команды печати спрайтов в буфер, добавить команды отображения части буфера( или целиком) в основную видеопамять карты в любое место( участок отображаемого видеобуфера воспринимается как один огромный спрайт) .
Применение этой технологии для высокодетализированного фона:
1. Заполняем буфер фоном спрайтами фона;
2. Каждый новый кадр отображаем уже сформированный фон в видеобуфере в основную видеопамять карты( или выбранный для построения изображения банк памяти). Далее рисуем спрайты в видеопамять карты уже поверх готового фона.
Буфер желательно иметь больше размером чем участок видеопамяти экрана на случай нескольких перекрывающихся со спрайтами планов ( например, заносим в видеопамять экрана первый план из участка буфера, затем рисуем спрайты непосредственно в видеопамять экрана, и накладываем поверх передний план из другого участка буфера).
Если буфер достаточно большой( 4 экрана), то можно реализовать скроллинг. Для этого первоначально нужно заполнить буфер большим участком карты (обычной печатью спрайтов), затем часть буфера равного размеру экрана ( это как бы окно) выводить на экран. Получится, что мы двигаем окно по карте.

[Advertiser]

[Lethargeek]

Добавить в видеокарту дополнительный буфер памяти, добавить команды печати спрайтов в буфер, добавить команды отображения части буфера( или целиком) в основную видеопамять карты в любое место( участок отображаемого видеобуфера воспринимается как один огромный спрайт) .

да не надо там никаких буферов отдельных от основной памяти видеокарты, и вообще -
это всё самый примитивный блиттер лишь с одной командой переброски строк с разрывом и так умеет
но увы, автору просто нравится бессмысленно и беспощадно городить сложные решения частных случаев

[zx-kit]

Никто никогда тайломап не двигает, делается карта 2 на 2 экрана и закольцовывается. Прекращайте уже, правда. Zst прочитайте пожалуйста про любой спрайтовый акселератор со слоями, про тот же tsconf, там на самом деле все просто и удобно. У него конечно есть ограничения наложенные целевой платформой, но структура и подход правильные. И наконец то надо определится блиттер или спрайты.

Почитал про устройство экранов в TSconf и NES. И там и там тайлы размером 8х8 точек и тайловая карта 64х64 клетки. Прокрутка без копирования, аппаратная. Но при движении вправо дальше двух экранов надо постоянно подрисовывать справа от экрана новый столбик. Предлагаю для упрощения написания игр выделить под тайловую карту большую площадь 256х256 клеток. Каждой клетке будет соответствовать тайл также размером 8х8, описываемый двумя байтами. Тогда при движении мы можем просто указывать координаты окна в тайловой карте в клетках и дополнительное смещение в точках.

---------- Post added at 12:58 ---------- Previous post was at 12:55 ----------

Т.к. у меня нет реального спектрума, сделал простенький zx-spectrum c 128K ОЗУ, 32К ПЗУ, Z80 на 3.5МГц, AY и DivMMC 128K + SD, добавил ещё и загрузку с реального магнитофона. Всё ОЗУ и ПЗУ разместил во внутренней памяти камня - M10K, что дает возможность пока полностью использовать SDRAM для видео карты. Видео выход VGA 640x480@60Hz (ZX-Spectrum screen x2 = H:32+256+32; V=24+192+24). Конфигурация ZX128K написана для DE1-SoC, решил использовать её, т.к. плата максимально подходит для разработки и отладки, на борту есть GPIO, можно вывести ZXBus/NemoBus и попробовать как всё будет работать с разными платками, но платок у меня тоже нет. HPS (Dual-core ARM CortexA9 + 1GB DDR3) сейчас не используется, но может быть использован для софтовой эмуляции различного спектрумовского железа, тут я пока ещё не разбирался.
Теперь можно двигаться дальше с разработкой и отладкой модуля графической карты.

Что дальше ? Надо изменить настройки SDRAM ?

[Valen]

Предлагаю для упрощения написания игр выделить под тайловую карту большую площадь 256х256 клеток.

Можно и столько. (в 2 раза меньше тоже нормально будет)
Ведь тайловая карта будет в памяти видео-карты ?

Тогда при движении мы можем просто указывать координаты окна в тайловой карте в клетках и дополнительное смещение в точках.

Да, но всё равно,
нужно сделать закольцовывание.

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

[zx-kit]

Можно и столько. (в 2 раза меньше тоже нормально будет)
Ведь тайловая карта будет в памяти видео-карты ?

Да, но всё равно,
нужно сделать закольцовывание.

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

Давайте упростим еще и увеличим размеры тайловой карты до 1024 на 1024. Хватит на 25 экранов по-горизонтали и 34 по-вертикали. Памяти пока хвватает. Можно будет двигать фон хоть влево, хоть вниз, хоть нарезать на отдельные локации.

Теперь у нас подготовлена карта для простого аппаратного скроллинга тип Денди. Задаем окно в карте тайлов для вывода на экран. Копируем в буфер экрана с помощью блиттера, добавляем сверху спрайты и тайлы переднего фона.

Спрайты можно копировать в буфер экрана с помощью командного файла с упрощенной структурой:
Y1,X1,N1, Y2,X2,N2, Y3,X3,N3, FFFF.

[Valen]

Давайте упростим еще и увеличим размеры тайловой карты до 1024 на 1024. Хватит на 25 экранов по-горизонтали и 34 по-вертикали. Памяти пока хвватает. Можно будет двигать фон хоть влево, хоть вниз, хоть нарезать на отдельные локации.

Добавить бы ещё закольцовывание.
Там логика простая.

Если, координата текущего печатаемого тайла (X, Y), выходит за пределы тайловой карты,
обнулить X и/или Y.

Как-то так:
Если X > TILE_MAP_WIDTH - 1, то X=0
Если Y > TILE_MAP_HEIGHT - 1, то Y=0

TILE_MAP_WIDTH, TILE_MAP_HEIGHT - размер тайловой карты (в тайлах)

[zx-kit]

Добавить бы ещё закольцовывание.
Там логика простая.

ОК.

Команды инициализации SDRAM после включения питания для тактовой частоты до 133 MHz в режиме 3-3-3 с пакетным режимом чтения и записи по 8 точек (BL=8):

• NOP около 14000 тактов
• PRECHARGE ALL (A10=1)
• NOP 3 такта
• AUTOREFRESH
• NOP 9 тактов
• AUTOREFRESH
• NOP 9 тактов
• LOAD MODE REGISTER (BA1=0, BA0=0, A[12...0] = 000 0 00 011 0 011)
• NOP 2 такта

[CodeMaster]

Можно будет двигать фон хоть влево, хоть вниз

А двигаться он будет попиксельно или кратно 8-ми?

Памяти пока хвватает.

А игры будут только "бродилки/леталки", расширятся функционал не будет? Поддержка 3D движков? Или для этого памяти много не потребуется?

[Smalovsky]

ʁɔɯиҺʎvоu ɐɯdɐʞ ʁɐнɔǝdǝɯни

[Alex Rider]

Ok, я согласен, что сделать удобно для адаптации всех игр не получится - какие-то придется переписать основательно. Но господа, не забываем одну вещь: сделать новую хорошую игру трудно! Для этого нужны таланты геймдизайнера, художника, музыканта, программиста - сейчас командной работы в этой области почти нет. А вот для переделки игры нужны в основном только программерские способности, ну результат с текущей графикой можно предложить художнику для редизайна. Это сильно проще.

2. Подсчитали все координаты обьектов.
3. Сделали проверку на столкновение и скорректировали результаты.
4. Отрисовали фон и объекты по вычисленным координатам

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

Увы, чего только нет в старых играх для экономии тактов. В том числе, и определение столкновений и даже обработка логики игры во время отрисовки. А про использование экранных атрибутов и графики тайлов в качестве аркадных атрибутов писал даже "Инфорком" в своей серии про графику.