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

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

Цитата:

---

Сообщение от Smalovsky

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

---

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

Цитата:

---

Сообщение от krt17

Никто никогда тайломап не двигает, делается карта 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 ----------

Цитата:

---

Сообщение от MVV

Т.к. у меня нет реального спектрума, сделал простенький 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 ?

Цитата:

---

Сообщение от zst

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

---

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

Цитата:

---

Сообщение от zst

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

---

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

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

Цитата:

---

Сообщение от Valen

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

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

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

---

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

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

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

Цитата:

---

Сообщение от zst

Давайте упростим еще и увеличим размеры тайловой карты до 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 - размер тайловой карты (в тайлах)

Цитата:

---

Сообщение от Valen

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

---

ОК.

Команды инициализации 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 такта

Цитата:

---

Сообщение от zst

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

---

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

Цитата:

---

Сообщение от zst

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

---

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

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

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

Цитата:

---

Сообщение от Smalovsky

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

---

Цитата:

---

Сообщение от Lethargeek

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

---

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

Цитата:

---

Сообщение от CodeMaster

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

---

Имея карту тайлов, в которой описан фон, можно передвигать окно плавно по 1 пикселу или на целый экрана. Все зависит от типа игры.

Цитата:

---

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

---

Игры будут такие же, какие были на ZX Spectrum, только более быстрые и плавные. 3D пока не планируется.

---------- Post added at 08:21 ---------- Previous post was at 08:11 ----------

Цитата:

---

Сообщение от Alex Rider

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


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

---

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

http://s015.radikal.ru/i333/1507/0b/f9351283bed8t.jpg http://s017.radikal.ru/i427/1507/99/82b378d8893ct.jpg http://s017.radikal.ru/i401/1507/91/325eeb06103ft.jpg http://s020.radikal.ru/i719/1507/3e/6e6536f5d9act.jpg http://s017.radikal.ru/i406/1507/d1/5ee348a9829bt.jpg

Давайте посмотрим, что общего на приведенных картинках?
Экран делится на статическую часть и динамическую. Нам надо для построения использовать 2 экрана. Назовем их S_SCREEN1 и D_SCREEN1. При выводе на VGA часть изображения будет браться с S_SCREEN1, а другая с D_SCREEN1. Учитывая то, что на одной паре экранов мы строим изображение, а другая в это время отображается нам надо иметь 4 буфера экрана размером по 512х256 точек (128K x 16) каждый.

Цитата:

---

Сообщение от zst

3D пока не планируется.

---

Может это, вместе с графичискими примитивами, было бы интересно для развития.

Цитата:

---

Сообщение от zst

Игры будут такие же, какие были на ZX Spectrum, только более быстрые и плавные.

---

Просто, в таком случае, карта 1024 на 1024 экрана это лишнее, обычно они были вытянутыми. ИМХО 32х1024 или 1024 на 32 будет достаточно. С закольцовкой её можно "растянуть" практически до бесконечности (правда не для линейный карт типа R-Type, если не предусмотреть возможности сдвига одного измерения при переходе границы), а память под будущие апгрейды освободится.

Цитата:

---

Сообщение от krt17

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

---

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

---------- Post added at 08:12 ---------- Previous post was at 08:08 ----------

Цитата:

---

Сообщение от zst

Учитывая то, что на одной паре экранов мы строим изображение, а другая в это время отображается нам надо иметь 4 буфера экрана размером по 512х256 точек (128K x 16) каждый.

---

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

---------- Post added at 08:23 ---------- Previous post was at 08:12 ----------

Цитата:

---

Сообщение от zst

Переделать игру - это будет целое искусство.

---

впечатление, что это главная цель проекта :D

Цитата:

---

Сообщение от zst

Но мы можем кое-что предусмотреть.

---

а предусмотреть, чтобы для переделки в принципе НЕ требовался "искусник"?

Цитата:

---

Сообщение от CodeMaster

Может это, вместе с графичискими примитивами, было бы интересно для развития.

---

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

Цитата:

---

Просто, в таком случае, карта 1024 на 1024 экрана это лишнее, обычно они были вытянутыми. ИМХО 32х1024 или 1024 на 32 будет достаточно. С закольцовкой её можно "растянуть" практически до бесконечности (правда не для линейный карт типа R-Type, если не предусмотреть возможности сдвига одного измерения при переходе границы), а память под будущие апгрейды освободится.

---

Надеюсь появятся и новые игры, которым эти возможности могут пригодиться. Например, разделить эту область на две карты тайлов.
http://s018.radikal.ru/i526/1507/98/d100ca4d89cet.jpg
Когда я писал игру FUTURE TANK у меня было две карты: MAP2D и MAP3D. На карту 2D я распаковывал уровень. Там было два вида тайлов - дорога и препятствия. Потом специальная процедура строила программно вокруг дорог стены с помощью разных спрайтов и заполняла карту 3D. По 3D карте заполнялся буфер экрана в игре, а по 2D я определял, куда можно ехать, куда нельзя, где лежат предметы.

---------- Post added at 12:52 ---------- Previous post was at 12:49 ----------

Цитата:

---

Сообщение от Lethargeek

а предусмотреть, чтобы для переделки в принципе НЕ требовался "искусник"?

---

Хорошо бы остановить игру, добавить несколько POKES и заработало по новому. Пока не знаю, как это сделать...

Цитата:

---

Сообщение от zst

и заполняла карту 3D

---

В смысле изометрию или где там 3D? Под 3D я имел ввиду, что-то типа Wolf 48K

Цитата:

---

Сообщение от zst

Хорошо бы остановить игру, добавить несколько POKES и заработало по новому. Пока не знаю, как это сделать...

---

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

Цитата:

---

Сообщение от zst

http://s018.radikal.ru/i526/1507/98/d100ca4d89cet.jpg
Когда я писал игру FUTURE TANK

---

таки да. а где игра то?

Не ссорьтесь. gg all.
Может для спекки и нужен гибрид.

Цитата:

---

Сообщение от Alex Rider

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

---

Видишь ли, "проще", "легче", "сложнее" - понятия субъективные. Что кому-то сделать просто, второй не сможет, третьему же лень возиться или нет времени. Таким образом, сделать переделку простой для всех (или максимально к тому приблизиться) можно лишь одним способом: дать возможность каждому самому определять объём и сложность работ. Чтоб игру можно было переделывать постепенно, независимо корректируя процедурки, переделывая графику по частям. Чтоб результат был рабочим и играбельным на любой стадии, чтобы можно было бросить в любой момент, и все равно выглядел бы лучше оригинала. Сам собой напрашивается вывод, что обеспечить это можно только в том случае, когда старая и новая графика одновременно сосуществуют в одном экране. Что возможно, если старая графика есть одно из состояний новой видеопамяти, а вывод в эту память старыми процедурами перехватывается и обрабатывается девайсом так, чтобы видимых отличий не возникало (если мы, конечно, их не хотим). Ну, как эмулятор спектрума на пц, но с возможностью рисовать без цветовых ограничений на пц-экране из спектрумовской программы, с ускорением (средствами того же эмулятора) или без.

Цитата:

---

Сообщение от Alex Rider

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

---

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

Цитата:

---

Сообщение от Lethargeek

Таким образом, сделать переделку простой для всех (или максимально к тому приблизиться) можно лишь одним способом: дать возможность каждому самому определять объём и сложность работ. Чтоб игру можно было переделывать постепенно, независимо корректируя процедурки, переделывая графику по частям. Чтоб результат был рабочим и играбельным на любой стадии, чтобы можно было бросить в любой момент, и все равно выглядел бы лучше оригинала.

---

Да я не против! Мой пост как раз и был к тому, что, если сделать карту только для новых игр, игр с поддержкой этой карты будет чуть меньше, чем одна. Я как раз-таки за то, чтобы карта максиамльно способствовала переделкам, но сокрушаюсь тут, что сделать одинаково удобно для всех игр не получится, игры все равно придется курочить. Но не дай боже, что для того, чтобы при включении карты чтобы хоть что-то похожее на старую игру увидеть, надо сразу же переписать половину игры.

Цитата:

---

Сообщение от Lethargeek

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

---

В новых - не надо, но поддержка тайломапов в памяти Спека была бы неплоха для адаптации. Хотя, может быть, я и не прав. В любом случае, если в играх изменить побайтный рендер тайломапа в экран 6912 на потайловый вывод его же в видеокарту (по любому разумному протоколу), скорость игры вырастет заметно. А привязка к конкретному формату этих самых тайломапов в памяти Спека может выйти боком.

Давайте пока отложим способы формирования сцены игры в буфере экрана. Надо время все обдумать. Наверно найдем приемлемый вариант. А пока спроектируем вывод из буфера экрана в регистр RGB. Для начала будем считать, что у нас один буфер экрана с картинкой 320х240 точек по 15 бит на цвет. Потом доработаем для 4х буферов с врезанием экрана с динамической графикой в экран со статической графикой.

Для хранения информации о цвете точек в строке организуем во внутренней памяти FPGA буфер VGA размером 320 ячеек по 15 бит. Из SDRAM будем читать данные пакетами по 8 точек (1 точка за такт) с паузами (по 6 и более тактов) и записывать в буфер VGA. После записи каждой точки в буфер VGA счетчик записи увеличивается на 1. Как только сделано 320 записей - буфер полон. Больше читать из буфера экрана не надо.

Для адресации в буфере VGA во время чтения используем счетчик чтения. Так как читать из буфера VGA можно только тогда, когда он свободен от записи из SDRAM - нужно добавить между буфером VGA и регистром RGB небольшой буфер FIFO. Из регистра RGB будем отправлять данные о цвете точки через HDMI или аналоговые ЦАПы типа R-2R на монитор. Это уже будет зависеть от реализации конкретной видеокарты или девборды. В остальном, кроме типа выхода на монитор, новый видеорежим должен работать одинаково на всех устройствах.

Во время строчного синхроимпульса VGA будем сбрасывать счетчики записи и чтения из буфера VGA, а также проводить регенерацию SDRAM. Достаточно сделать 3 цикла AUTO REFRESH в начале каждой строки VGA. Затем, во время левого бордера в строке начинаем заполнение буфера VGA данными о цвете точек из буфера экрана в SDRAM. К моменту вывода видимой части строки его начало уже будет заполнено.

Так как для экрана 320х240 каждая вторая строка VGA в режиме 640x480@60Hz дублируется, то буфер загружать надо только 1 раз на 2 строки. В начале второй строки нужно сделать только 3 цикла AUTO REFRESH, а остальное время доступ к SDRAM будет в основном у блиттера. Аналогично нужно вывести все 240 строк изображения, сформированного в буфере экрана. Во время бордера в кадре VGA данные из SDRAM читать не надо.

Вот и все. Для простоты частоту точек VGA выбрать 25 MHz, а FGPA и SDRAM 125 MHz.

Цитата:

---

Сообщение от zst

А пока спроектируем вывод из буфера экрана в регистр RGB.

---

Это уже не моя компетенция, но все же: оно будет нормально, без искажений показывать обычный спектрумовский 6912, если карту не активировать после сброса/включения питания, а VGA-монитор подключить только к карте? Какие частоты развертки будут поддерживаться?

Цитата:

---

Сообщение от zst

Во время бордера в кадре VGA данные из SDRAM читать не надо.

---

15с-BORDER по #fe сделать получится?

Цитата:

---

Сообщение от Alex Rider

Это уже не моя компетенция, но все же: оно будет нормально, без искажений показывать обычный спектрумовский 6912, если карту не активировать после сброса/включения питания, а VGA-монитор подключить только к карте? Какие частоты развертки будут поддерживаться?

15с-BORDER по #fe сделать получится?

---

Мы пришли к выводу, что после сброса работает стандартный режим 256х192 15 цветов с бордером. Вывод на SCART 50 Гц или на монитор VGA 640х480@60Hz без геометрических искажений. INT стандартный 50 Гц. Возможно получится и 50 Гц VGA.

После включения нового режима 320х240 32K бордера уже нет так как экран занимает всю видимую часть на мониторе VGA 640х480@60Hz. INT новый 60 Гц для уменьшения мерцаний и совпадения с частотой развертки VGA.

Возможно сделаем, как вы просили, возможность включения вывода стандартного режима по-новому в центре экрана для упрощения постепенного перекрашивания игр. При этом бордер будет как раньше или как статическая часть экрана 320х240.

Полностью совместить 50 и 60 Гц не получается, приходится выбирать приемлемый и достаточно хороший вариант вывода.

Цитата:

---

Сообщение от zst

Возможно получится и 50 Гц VGA.

---

а почему не получится ? - сделать то его не сложно просто не все мониторы поддерживают 50 Гц - мой Асус 22'' например минимум 56 Гц поддерживает, я даже спецом для спековских дел купил CRT 17'' )

Цитата:

---

Сообщение от zst

Полностью совместить 50 и 60 Гц не получается, приходится выбирать приемлемый и достаточно хороший вариант вывода.

---

А конвертировать на лету, как в китайских конвертерах SCART to HDMI — не судьба?

Мы уже обсуждали кадровые частоты ранее. Для старого режима 50 Гц или 60 Гц, для нового 640х480@60Hz.
Эмулятор UNREAL выводит картинку в режиме 640х480@60Hz, любой монитор и телевизор с VGA входом также поддерживает этот режим. Это стандарт. Поэтому новый режим будет одинаково отображаться на любом экране. Разве что у широкоформатных по бокам будет лишнее затемнено.

Надо блиттер делать. А сначала вывести состояние SDRAM на экран, потом добавить рисование точками. Работы много. а мы опять спорим про частоты.

Цитата:

---

Сообщение от MVV

Я сейчас занимаюсь разработкой основного режима 640х480@60Hz 24bpp, на его базе: 640x480@60Hz 24bpp/15bpp/8bpp, 320x240@60Hz 24bpp/15bpp/8bpp.
На данный момент работает базовый режим 640х480@60Hz 24bpp и ZX-Spectrum screen x2 = H:32+256+32; V=24+192+24 с возможностью наложения.

---

ОК. На какой частоте работает SDRAM и FPGA? Можешь сделать так, чтобы моя тестовая программа рисовала цветные полоски? Для этого надо реализовать команду рисования по точкам. А до этого пакетный режим SDRAM по 8 точек на частоте 125 MHz (для упрощения вывода на VGA)

Цитата:

---

Сообщение от zst

Потом доработаем для 4х буферов с врезанием экрана с динамической графикой в экран со статической графикой.

---

Это аппрататное врезание статического и динамического экрана ?
Думаю что не нужно, трата логики.
Блиттер успеет.

Цитата:

---

Сообщение от Valen

Это аппрататное врезание статического и динамического экрана ?
Думаю что не нужно, трата логики.
Блиттер успеет.

---

Не все можно сделать с помощью денди-скроллов. Надо и неподвижную информацию выводить.

Цитата:

---

Сообщение от MVV

Добавил палитру, получается 4-ре страницы. Как лучше сделать обращение к палитре со стороны ЦП и переключение страниц, через порта? Тогда нужно 3-ри развёрнутых порта типа 0xnnD0, 0xnnD1, 0xnnD2, где nn=0-255. Или отображать палитру на память, это 3К (4-ре страницы). Формат записи тогда какой, страница палитры 0: +0 R, +1 G, +2 B ... +253 R, +254 G, +255 B, страница палитры 1: +256 R, +257 G, +258 B ... +509 R, +510 G, +511 B ... ?

---

В блоке адресов регистров выдели два регистра. 1 регистр - установка номера цвета/начальный адрес для загрузки данных. 2 регистр - данные. Записывать в регистр данных последовательно R0,G0,B0, R1,G1,B1. Видеокарта сама увеличивает адреса, начиная с загруженного в регистр 1.

00 MODE - режим графики: 1 = 256х192 32K, 2 = 320х240 32K, 0 - стандартный 256х192 с атрибутами
01 ADDR_SCR1 - адрес экрана 1
02 ADDR_SCR2 - адрес экрана 2
03 CLEAR - закрасить экран цветом COLOUR
04 PLOT - нарисовать точку цветом COLOUR по координатам Y, X с предварительным смещением в качестве параметра: 0 = без смещения
05 PL1_ADDR - начальный номер цвета/адрес в палитре для загрузки данных
06 PL1_DATA - последовательные данные цветов RGB в палитре
07 PL2_ADDR - начальный номер цвета/адрес в палитре для загрузки данных
08 PL2_DATA - последовательные данные цветов RGB в палитре
09 PL3_ADDR - начальный номер цвета/адрес в палитре для загрузки данных
0A PL3_DATA - последовательные данные цветов RGB в палитре
0B PL4_ADDR - начальный номер цвета/адрес в палитре для загрузки данных
0C PL4_DATA - последовательные данные цветов RGB в палитре
0D PL_SELECT - выбор палитры 1-4

Цитата:

---

Сообщение от zst

Возможно сделаем, как вы просили, возможность включения вывода стандартного режима по-новому в центре экрана для упрощения постепенного перекрашивания игр. При этом бордер будет как раньше или как статическая часть экрана 320х240.

---

Да, это обязательно надо. Мало того, большинство игр не получится переделать под другое разрешение экрана (без переписывания игры заново). Надо сделать режим 256x192 с новыми фишками - палитрами, прозрачностью и прочими запланированными плюшками.

---------- Post added at 02:14 ---------- Previous post was at 02:12 ----------

Цитата:

---

Сообщение от zst

0D PL_SELECT - выбор палитры 1-4

---

На всякий, если не сложно - а можно сделать каждому слою (и "прсевдслою", на который выводится векторная графика) свою палитру?

Я так понял, MVV решил добавить новые режимы 8 битов на точку с палитрой. Палитра будет загружаться при смене уровня или когда надо задать эффект плавного затемнения. MVV, как планируешь использовать палитру и где ее указывать ?

А зачем в векторной графике палитра ? Можно ведь указать для точки любой цвет из 32K. В буфере экрана все точки представлены как цвета из 32К.

Векторную графику в режимах 320х240 и 256х192 применять затруднительно - точки слишком крупные. Если только в режиме 640х480.

Цитата:

---

Сообщение от zst

как планируешь использовать палитру и где ее указывать ?

---

Сейчас доступно 4-ре палитры. Размер одной страницы палитры 768 байт. Доступ к палитре IN/OUT через три порта: #iiBF (Red), #iiBE (Green), #iiBD (Blue), где ii=индекс интенсивности цвета в одной из 4-х страниц палитры от 0 по 255. Порт выбора страницы палитры #01BC, биты 1..0=00-страница 0, 01-страница 1...
Как-то-так, адреса портов вымышленные, использую исключительно для отладки в конфигурации DE1-SoC:ZX128K.
Пример:

Код:

---

; Инициализация палитры 24bpp
        LD BC,#00BD        ; Palette=Blue, Address=0
L1        OUT (C),B
        DJNZ L1
        INC C
L2        OUT (C),B
        DJNZ L2
        INC C
L3        OUT (C),B
        DJNZ L3
        RET

; Чтение палитры 24bpp
        LD HL,addr
        LD BC,#00BD        ; Palette=Blue, Address=0
        INIR
        INC C
        INIR
        INC C
        INIR
        RET

; Запись палитры 24bpp
        LD HL,addr
        LD BC,#00BD        ; Palette=Blue, Address=0
        OTIR
        INC C
        OTIR
        INC C
        OTIR
        RET

---

Параллельно с графической картой ещё делаю конфигурацию для DE1-SoC и ReVerSE-U16, планируется переход на NextZ80. Конфигурация получит два процессора с максимальной частотой 42МГц c 16К+16K L1 и 1К L2 кэшем. Быстродействия и объёма памяти вполне должно хватить для нового видео режима 640x480@60Hz 8bpp/15bpp/24bpp. Было-бы правильнее сделать совместимость графической системы с zx-evo, но есть проблема, команда ts-labs неохотно идет на встречу, оно и понятно, zx-evo себя полностью исчерпал в аппаратном плане, а вести работу над конфигурацией на других платах никто из них не будет. Да нас рать, есть возможность и желание сделать лучше, то почему-бы и не сделать.

Цитата:

---

Сообщение от MVV

Параллельно с графической картой ещё делаю конфигурацию для DE1-SoC и ReVerSE-U16, планируется переход на NextZ80

---

А исходный код доступен? Хотелось бы на своей плате запустить

Цитата:

---

Сообщение от s_kosorev

А исходный код доступен? Хотелось бы на своей плате запустить

---

У меня сейчас наброски для DE1-SoC, просто удобней вести разработку. Попробуй запустить ZX128K, на его базе и делаю. Если успею, вечером попробую собрать новые рабочие модули и выложить.

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

Mode 0. Стандартный режим ZX SPECTRUM после сброса. 256х192 точек. Точка может быть двух цветов из 15, заданных с помощью атрибута. fINT=50 Hz. Предположильный способ формирования изображения - каждые 20 mS данные из экранной области ZX Spectrum и состояние BORDER построчно записываются (включая цвет BORDER-a) в буфер экрана. Из буфера экрана с частотой 50 или 60 Гц цвета выводятся на видеоустройство (телевизор, монитор или экран PC в эмуляторе).

Mode 1. Аналог режима 0 с дополнительными возможностями для устранения клешинга атрибутов 256х192 точек + доп возможности. Точка может быть двух цветов из 15, заданных с помощью атрибута. fINT=50 Hz. Предположильный способ формирования изображения - каждые 20 mS данные из экранной области ZX Spectrum и состояние BORDER построчно записываются (включая цвет BORDER-a) в буфер экрана. Из буфера экрана с частотой 50 или 60 Гц цвета выводятся на видеоустройстов (телевизор, монитор или экран PC в эмуляторе).

Mode 2. 320х240 точек. Точка может быть любым из 32768 цветов или прозрачной. fINT=60 Hz. Экран может состоять из статической и динамической частей. В динамической части возможен аппаратный скроллинг экрана и вывод изображения из карты тайлов 1024х1024 тайла размером по 8х8 точек. Предположильный способ формирования изображения. Фон строится из карты тайлов. Программист указывает координаты в карте тайлов для копирования в буфер экрана. Если в тайле фона точка прозрачного цвета - то будет изображен цвет фона (нижнего плана). Далее выполняются командные буферы, куда Z80 записал номера и координаты спрайтов для вывода поверх фона в буфер экрана. Сверху возможно рисование линий аппаратными точками заданным цветом. Из буфера экрана с частотой 60 Гц цвета выводятся на видеоустройство (телевизор, монитор или экран PC в эмуляторе).Два буфера экрана - на одном строим изображение, со второго изображение в этот момент выводится на видеоустройство.

Mode 3. 640х480 точек. Похож на режим 2, только точек в два раза больше по-вертикали и по-горизонтали.

MVV, какие режимы ты предлагаешь добавить ?

Цитата:

---

Сообщение от zst

какие режимы ты предлагаешь добавить ?

---

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

А получится ли малой кровью в Mode1 добавить поддержку ULA+ так, чтобы не переделывать игры?

Цитата:

---

Сообщение от bigral

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

---

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

Очень много для этого сделано в TSconf. В TSconf есть тайлы 8х8 как в Денди, отображение тайлов из карты и аппаратный скроллинг. Плюс там увеличено количество возможных тайлов по сравнению с 256 у Денди. Также в TSconf, по сравнению с Денди увеличено количество и размер спрайтов. У Денди 64 спрайта размером 8х8, в TSconf 85 размером до 64х64.

Но в TSconf есть и некоторые недостатки. Изображение строится на лету при выводе на монитор. Спрайты аппаратные. Это приводит к некоторым ограничениям и сложным преобразованиям. У Денди при выводе больше 8 спрайтов в строке остальные начинают мерцать или пропадают. Не будет ли такого же тут ? Карта тайлов есть, но как в Денди размером 64х64. Желательно увеличить до 1024х1024, чтобы программисту не надо было заниматься лишней работой при скроллинге экрана. Наличие палитры ограничивает количество возможных цветов. Такая ситуация может возникнуть, если надо добавить картинку с другой палитрой.

Когда жестко задано количество слоев или спрайтов - это может затруднить формирование изображения. В TSconf нельзя рисовать точки и линии поверх тайлов и спрайтов. Лучше предоставить программисту возможность накладывать требуемое количество тайлов, спрайтов и линий в буфер экрана с количеством цветов 32К, а затем выводить на видеоустройство. Также затруднительно выводить неподвижую информацию.

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

---------- Post added at 03:21 ---------- Previous post was at 03:13 ----------

Цитата:

---

Сообщение от Alex Rider

А получится ли малой кровью в Mode1 добавить поддержку ULA+ так, чтобы не переделывать игры?

---

Если для формирования изображения мы читаем данные из стандартного экрана и попиксельно записываем изображение в буфер экрана, то при этом стандартные 15 цветов преобразовываются в соответствующие цвета 32К. При этом можно подменить стандартную палитру на ULA+. Немного сложнее, но думаю возможно. Но это ближе к режиму 0.

В режиме 1 надо будет сделать возможность устранить клешинг. Он будет выглядеть также как 0, но формироваться по-другому. Надо еще продумать. Пока мне видится это так:

Цвет каждой клетки размером 8х8 точек определяется двумя атрибутами. При записи в черно-белую область экрана или область атрибутов включается стандартный цвет из первого атрибута. При записи в определенные регистры видеокарты можно включить второй атрибут. Точки могут быть трех цветов: PAPER2, INK2 или прозрачными. Если прозрачные, то сквозь них видны точки 1 атрибута. Так можно нарисовать Диззи на переднем плане. Как только будет запись в черно-белую область экрана или область атрибутов включается стандартный цвет из первого атрибута.

Подумайте, как проще сделать вывод спрайта поверх фона без клешинга.