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

[zx_]

за юлу плюс обеими руками за
на рассыпухе
к ULA + барсики есть, игрушки есть

ПДП есть схема у велесофт, ничего сложного
только где сам чип брать

Чорный Кот гдето в своих эмпиреях , к простым смертным не спускается

[Advertiser]

[s_kosorev]

и зачем для какой то унылой ULA+ делать видеокарту? любители ЛА3 не поймут что такое FPGA

[Lethargeek]

На что там реагировать надо? Я привел пример, как можно заполнить экран для игры Диззи по той картинке.

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

А вам почему-то не понравилась жесткая сетка и фиксированный размер. C чего это они жесткие? Как раз наоборот - мы их можем выбирать. Какие тайлы были, такой размер и указан. Будут другие размеры - будет другая сетка. Мы сами выбираем размер тайлов и спрайтов при проектировании игры. Но если выбрали 8х8, значит так надо было. Что тут не так ?

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

Ну а насчет тайлов разного размера - это как-то странно, как ими заполнить экран без промежутков ?

"как-то странно" заполнять экран непременно "без промежутков", когда в играх (втч Диззи) дофига экранов полупустых
я ж сказал - список пар "координаты, номер объекта" (и по номеру из массива прочие параметры взять)
для объектов одинакового размера, как ты хотел, можно тупо сделать сразу массив адресов изображений
остальные все параметры одинаковы, а экранный адрес в цикле меняешь сам

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

да размер тут совершенно же ни при чём, отрисовка - по порядку перекрытия у объектов

Язык сломал писать все в множественном числе - перехожу на ты.

да здесь на форуме всегда народ общался "на ты"

Печатать строку тайлов лучше одинакового размера (для данной полоски), при этом карта сама сможет определить адрес начала следующего спрайта в буфере спрайтов и в буфере экрана. Это же логично. Строка из спрайтов разного размера - это уже не строка, а неизвестно что.

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

Размер спрайтов настраивается, координаты начала строки спрайтов можно задать. Этого хватит, чтобы напечатать экран, какой желает программист.

нет, не хватит - ну, вот я, например, желаю кучу перекрывающихся слоёв (и даже независимых отдельных объектов)

---------- Post added at 02:24 ---------- Previous post was at 02:20 ----------

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

это можно делать в обычной памяти, а пассивные девайсы проще присобачить к любому спектруму

Разница в том, что кидать в порт байт за байтом в цикле каждый раз когда мне это нужно в итоге будет геморно и не удобно. зачем создавать себе проблему?

где проблема, вызвал простенькую процедуру, она кидает, времени на это уйдёт немного

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

"мелкий" доступ по одному объекту (или даже частичному параметру) тоже нужен (а точнее даже - необходим!)
а ресурсы железяки небесконечны, так что - только в качестве необязательной примочки, а не основы

---------- Post added at 02:25 ---------- Previous post was at 02:24 ----------

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

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

Простейший вариант, писать процессором не в порты а в этот буфер, все!

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

---------- Post added at 02:28 ---------- Previous post was at 02:25 ----------

Глянь какие сигналы на ZXBus ещё нужны. Может RTC(часы на бордюр) ещё добавить? Ethernet или USB контроллер, PS/2 keyboard?

издиваишси? ну при чем тут видеокарта
wait проца как защиту от переполнения буфера
+ хорошо бы строчное прерывание

[zx-kit]

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

Размер тайлов выбирает разработчик игры и может изменить в любой момент

"как-то странно" заполнять экран непременно "без промежутков", когда в играх (втч Диззи) дофига экранов полупустых

Промежутки после перехода в другое место может потребоваться заполнять черным тайлом, чтобы затереть предыдущую картинку (на этом месте в предыдущей картинке могло быть дерево или другой объект). Если наносим уже второй слой (этой же картинки) также построчно - можно использовать нулевой прозрачный спрайт. Или указывать координаты для каждого одиночного тайла. Можно конечно заполнить экран черным цветом, а потом рисовать одиночные объекты. Это выбирает разработчик игры - как ему удобно, так и заполняет. Новый графический режим только ускоряет вывод тайлов и спрайтов.

я ж сказал - список пар "координаты, номер объекта" (и по номеру из массива прочие параметры взять)
для объектов одинакового размера, как ты хотел, можно тупо сделать сразу массив адресов изображений
остальные все параметры одинаковы, а экранный адрес в цикле меняешь сам

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

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

нет, не хватит - ну, вот я, например, желаю кучу перекрывающихся слоёв (и даже независимых отдельных объектов)

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

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

---------- Post added at 08:05 ---------- Previous post was at 06:58 ----------

Лучше бы рассказали как на ленинграде простым смертным ULA+ сделать. Реально полезно и нужно, сделали бы 50%+ народу, и игр полно и поддержка в коде простая. А то придумаете видеокарту которой по факту спектрум как бы и не к чему, спартан там пожирнее 16 метров все дела. Ретро платформа же, дядьки, опомнитесь.

Посмотрите там, может поможет. ULA + это всего лишь палитра. Она не облегчает написание игр. Мы хотим при той же графике упростить и ускорить построение изображений.

[s_kosorev]

Размер тайлов выбирает разработчик игры и может изменить в любой момент

а если тайлы шестигранные? есть же куча игрушек где они именно такие

---------- Post added at 07:47 ---------- Previous post was at 07:31 ----------

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

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

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

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

---------- Post added at 07:49 ---------- Previous post was at 07:47 ----------

экран 320х240 при тайле 8х8 это надо карте подать 40х30=1200 комнд, а если слове 3-4? ну блин тоже же глупо, проще такие тривиальные вещи как вывод мелких тайлов в цикле, обучить карту делать через КА

[zx-kit]

а если тайлы шестигранные? есть же куча игрушек где они именно такие

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

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


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

---------- Post added at 07:49 ---------- Previous post was at 07:47 ----------

экран 320х240 при тайле 8х8 это надо карте подать 40х30=1200 комнд, а если слове 3-4? ну блин тоже же глупо, проще такие тривиальные вещи как вывод мелких тайлов в цикле, обучить карту делать через КА

Можно для неизменяемой части экрана создать описание в виде строки данных типа SIZE, 8, 8, SPR_ADDR, 1, 2, PRINT, AT, X, Y, 1, 2, 3, 4, 5, ENTER, PRINT, 3, 4, 5, 6, 7, AT, Y2, X2, SPR_ADDR, 7, 8, SIZE, 20, 20, PRINT, 1, ... END.

Можно описать так 15 экранов и разместь в SD-RAM. Тогда при переходе Диззи в очередное место передавать видеокарте адрес описания фона этого места и команду типа DRAW_LOCATION. После этого сразу команды печати спрайтов объектов.

[s_kosorev]

ясно, сторонники костылей

---------- Post added at 13:51 ---------- Previous post was at 13:36 ----------

Можно описать так 15 экранов и разместь в SD-RAM

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

[MVV]

предлагаю параллельно со схемой видеокарты начать совместно разработку режима "METEOR" для ReVeRse.

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

От SCART, на мой взгляд рано отказываться. Много старой техники. И режим 50 Гц не все мониторы показывают. 15 бит также позволяет сделать копирование в два раза быстрее, чем 24 бита при достаточно хорошем качестве изображения.

Для VGA не хватает выводов, разве что 6bpp получится (решается простым переходником HDMI2VGA), выхлоп переходника можно на шурупы, чтобы карта не выпадала и всё хорошо.
Будет 60Гц как у нормальных людей, а 50Гц смотреть и фапать через SCART или S-Video с выхода видео компа, он то у нас будет свободный, я планирую TV подключить двумя шнурками VGA/SCART комп и HDMI для DivGPU или exGPU или как там по понятней карту назвать...

Чтобы была большая скорость нужна FT2232H. Она дороговатая. Лучше использовать внешний программатор с ней, чем устанавливать на карту. Хотя, может лучше иметь встроенный программатор и порт связи через один шнурок USB. Так сделано в MARSOHOD2.

Большая скорость кого/чего? Во первых плохое соотношение цены и функционала. Уже лучше VNC2, дешевле и в разы для этого случая лучше.
Добавил в схему CP2104, раз нужна возможность отладки и загрузки обновлений или обмен данными с PC (USB-UART).

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

[Lethargeek]

Размер тайлов выбирает разработчик игры и может изменить в любой момент

зачем ты вообще принуждаешь разработчика выбирать какой-то общий (пусть даже на время) размер?

Промежутки после перехода в другое место может потребоваться заполнять черным тайлом, чтобы затереть предыдущую картинку (на этом месте в предыдущей картинке могло быть дерево или другой объект). Если наносим уже второй слой (этой же картинки) также построчно - можно использовать нулевой прозрачный спрайт. Или указывать координаты для каждого одиночного тайла. Можно конечно заполнить экран черным цветом, а потом рисовать одиночные объекты. Это выбирает разработчик игры - как ему удобно, так и заполняет. Новый графический режим только ускоряет вывод тайлов и спрайтов.

ускорять и делать удобным нужно вывод ЛЮБЫХ объектов в ЛЮБОМ порядке
а ты хочешь один частный случай в ущерб другому - нинада так делать!

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

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

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

это как "быстрый" бег в грязи по колено вместо "медленной" ходьбы по дороге

Согласитесь, если тайлы идут друг за другом,

а зачем им друг за другом идти так часто, чтобы обращать на это внимание?

то координаты следующего тайла на экране может вычислять сама видеокарта. Если же указывать их для каждого тайла в строке - это замедлит вывод.

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

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

нифига не проще и не быстрее, а ты снова "улучшаешь" частный случай в ущерб ВСЕМУ!
а если вывод не в экран, а в буфер прямоугольный, а потом уже его на экран?
а если крупные объекты для начала конструируются из мелких, а после вывод?
а если у разраба более трёхсот объектов разных размеров?
или вовсе нарезаемых из большой картинки как ему нужно
как их напечатать по номерам?

Как выводить тайлы на экран построчно, столбиками или указывая координаты каждого - это выбор разработчика игры. Режим должен поддерживать все три вида печати. Это сделано для обеспечения скорости и гибкости построения экрана.

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

---------- Post added at 18:36 ---------- Previous post was at 18:27 ----------

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

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

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

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

экран 320х240 при тайле 8х8 это надо карте подать 40х30=1200 комнд, а если слове 3-4? ну блин тоже же глупо, проще такие тривиальные вещи как вывод мелких тайлов в цикле, обучить карту делать через КА

повторю, проще и быстрей не мельчить, и вообще отказываться от тайлов

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

или так только всё же лучше прямоугольником

[s_kosorev]

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

Ну так разработчик игры сам формат ему удобный и придумает, потом просто "шейдер" реализует и вуаля, процессор свободен, карта варится в своем соку, рисуя все что надо