Просмотр полной версии : Быстрая видеокарта "METEOR-2013"
Видеокарта "METEOR" предназначена для устранения клешинга атрибутов в старых играх для "ZX Spectrum".
Про завершение разработки видеокарты читайте в новой теме METEOR-2020 (https://zx-pk.ru/threads/31241-videokarta-quot-meteor-2020-quot-dlya-ustraneniya-kleshinga.html).
http://s016.radikal.ru/i337/1509/95/fe827124ba82t.jpg (http://s016.radikal.ru/i337/1509/95/fe827124ba82.jpg) http://s020.radikal.ru/i723/1509/a6/5d22094b554bt.jpg (http://s020.radikal.ru/i723/1509/a6/5d22094b554b.jpg) http://s019.radikal.ru/i630/1509/fc/64dd91c0bd18t.jpg (http://s019.radikal.ru/i630/1509/fc/64dd91c0bd18.jpg)
Идея такая - делаем новый комп, заточенный под графику. Он кроме стандартного режима графики будет иметь дополнительный. Оба на частоте 3.5 MHz. В новом режиме мы сначала, используя байт маски, рисуем черный силуэт спрайта. Маска меняет цвет точек выборочно. Потом, используя байт спрайта, рисуем контур спрайта выбранным цветом. Тоже цвет точек меняется выборочно. Этот режим для раскрашивания старых игр.
Если для новых или портирования с других компьютеров, то лучше сделать буфер для подготовки следующего кадра игры с адреса 0000H вместо ПЗУ. При этом адресацию надо сделать линейную как в Орионе и Специалисте. Это позволит рисовать спрайты блочными командами. Спрайты располагать также с линейной адресацией. Тогда первый столбик спрайта шириной 8 точек мы сможем нарисовать сверху-вниз командой LDIR, затем переместить адреса HL и DE вправо с помощью команд INC H, INC D и рисовать второй столбик снизу-вверх командой LDDR.
Ну и скорость для новых игр можно переключить на TURBO 14 MHz.
ПРИНЦИП УСТРАНЕНИЯ КЛЕШИНГА И ДОРАБОТКИ СТАРЫХ ИГР:
Параллельно стандартной памяти 48К добавляется графическая память. В графическую память запись идет сразу по 8 байтов. Каждый байт соответствует биту в основной памяти. В стандартном режиме графики в старшие 7 битов записываются единицы, а в младший - соответствующий бит как в стандартную память.
Фон рисуется как обычно в хороших цветных играх в буфер. В разных играх буфер разного размера и по разным адресам. Как только фон нарисован - копию буфера аппаратно сохраняем в дополнительном буфере.
После этого включаем новый режим рисования цветом PAPER. Подпрограмма вывода спрайта немного дорабатывается. Маска спрайта читается и просто пишется в буфер без команды AND. При этом вместо нулевых битов записывается 4 бита цвета PAPER в соответствующий байт новой памяти. В старшие биты записывается 0000.
После этого включаем новый режим рисования цветом INK. Подпрограмма вывода спрайта немного дорабатывается. Байт спрайта читается и просто пишется в буфер без команды OR. При этом вместо единичных битов записывается 4 бита цвета INK в соответствующий байт новой памяти. В старшие биты записывается 0000.
Далее готовая картинка копируется аппаратно из буфера в экраную область.
При выводе на телевизор читается байт из графической памяти. Если старшие биты 1111111 - цвет в старом режиме. Значит надо прочитать атрибут из стандартного экрана и цвет получить из него. Если старшие биты не 1111111 - цвет точки брать из четырех младших битов графической памяти.
Перед подготовкой следующего кадра игры аппаратно восстанавливается фон в буфере из ранее сохраненной копии. Это делается для того, чтобы стереть спрайты на старых местах. Затем рисуются новые спрайты.
Таким образом можно перекрасить старые игры и устранить клешинг.
Время копирования буфера 256х192 точки составит около 1 мс. Это позволит обойтись без второго экрана. Рисуем в буфере и быстро копируем на экран.
Для адресования новых портов видеокарты Метеор надо будет сделать параллельную страницу портов, которая будет подключаться записью числа в порт FF. Тогда можно будет новых портов сделать сколько угодно.
В Орионе и Специалисте был медленный проц. Если использовать статику, то можно сделать Z80 на 14 MHz.
Для сохранения ретро цвета остаются как в ZX Spectrum.
ПРИНЦИП РАСКРАШИВАНИЯ СТАРЫХ ИГР:
Как устранить клешинг я придумал, но спрайты могут получиться только одного цвета. Как же дорабатывать игры, чтобы была возможность каждый спрайт рисовать своим цветом ?
Для начала в конце подпрограммы вывода спрайта можно записать в порт атрибута PAPER = 0, INK = 7, BRIGHT = 1. Тогда все спрайты, для которых не выбраны индивидуальные цвета будут рисоваться без клешинга ярко-белым цветом. Потом некоторые спрайты можно перекрасить, если захочется.
Нужно найти место в программе, где рисуется каждый тип спрайтов. Например, пчелы, летучие мыши и т.д. Скорее всего они рисуются одной подпрограммой, но перед ее вызовом для каждого типа спрайта указывается адрес начала его блока спрайтов. Скорее всего эта команда имеет длину 3 байта. Вместо нее написать команду перехода на дополнительные команды настроики цвета спрайта, а в конце написать ту команду, которую мы затерли и команду перехода назад к следующей команде.
Команды выбора цвета спрайта - это запись атрибута в порт атрибута. Надо будет для каждого объекта сделать свою команду записи атрибута со своими цветами PAPER и INK. Если объектов много, то надо где-то найти свободное место в игре для модернизации. Или придется в компьютер МETEOR-2020 добавить возможность включать блок ОЗУ вместо ПЗУ на время рисования спрайтов.
Если загружать в теневое ОЗУ блок команд для модернизации игры, то это можно использовать как типовое решение во всех играх и не искать свободное место в игре.
ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ:
Z80 на частоте 3.5 / 14 MHz.
Разрешение 256х192 точек.
Стандартные 15 ZX цветов.
Видеовыход: цифровой 4 бита RGBI c TV разверткой.
INT 50 Hz сразу после отображения последней строки окна 256х192.
Параллельная память графики 1 байт на 1 точку.
Рисование сразу по 8 точек. В стандартном режиме - одновременно, в новых режимах рисование точек выборочно.
Режимы рисования: стандартный, цветом PAPER (нулевыми битами), цветом INK (единичными битами), обоими цветами PAPER и INK (и нулями и единицами как раньше).
Аппаратное копирование блоков памяти в параллельной памяти. Время копирования буфера на экран около 1 мс.
Линейный буфер для рисования следующего кадра с адреса 0000H.
Вики о метеорите "Челябинск" (https://ru.wikipedia.org/wiki/%D0%A7%D0%B5%D0%BB%D1%8F%D0%B1%D0%B8%D0%BD%D1%81%D 0%BA_%28%D0%BC%D0%B5%D1%82%D0%B5%D0%BE%D1%80%D0%B8 %D1%82%29)
Про завершение разработки видеокарты читайте в новой теме METEOR-2020 (https://zx-pk.ru/threads/31241-videokarta-quot-meteor-2020-quot-dlya-ustraneniya-kleshinga.html).
zst, я бы всё-таки удалил, из спецификации, все слова "тайл", "тайлы".
(чтобы непонятки не вызывали )
У вас все данные в ОЗУ спрайтов видео-карты, это спрайты.
Также, написать - планируется видео-режим 320x200 (или 320x240),
полно-экранный.
Alex Rider
15.06.2013, 17:18
4000 - координата Y копирования спрайта (строка экрана)
4001 - младший байт координаты X копирования спрайта (столбец экрана)
Это предполагает, что координаты спрайтов всегда положительны, так? Если надо "выдвинуть" спрайт из-за границ экрана или "задвинуть" его, придется делать цикл на основном Z80 и передавать видеокарте область спрайта, подлежащего отрисовке? Может, сделать y 2-байтной и аппаратное клиппирование спрайтов?
---------- Post added at 17:18 ---------- Previous post was at 17:16 ----------
Примитивы кроме точек не планируются?
Это предполагает, что координаты спрайтов всегда положительны, так? Если надо "выдвинуть" спрайт из-за границ экрана или "задвинуть" его, придется делать цикл на основном Z80 и передавать видеокарте область спрайта, подлежащего отрисовке? Может, сделать y 2-байтной и аппаратное клиппирование спрайтов?
Для изображения (копирования на экран) части спрайта возле границ экрана предназначены следующие параметры:
4003 - начальная копируемая строка спрайта (обычно 0)
4004 - конечная копируемая строка спрайта (обычно 15)
...
начальный копируемый столбец спрайта (обычно 0)
конечный копируемый столбец спрайта (обычно 15)
При этом на экран копируется нужная часть спрайта. Какую часть копировать решает Z80.
Примитивы кроме точек не планируются?
Пока нет.
introspec
15.06.2013, 18:10
Включается новый режим на раз-два-три. В левый верхний атрибут стандартного экрана поочередно записываются числа 1, 2, 3.
Т.е., получается, есть риск запустить эту карту стандартной атрибутной гасилкой (ок, не гасилкой, а зажигалкой). Шутка про раз-два-три смешная, но смешно будет не всем. Включите хотя бы бит мерцания (129, 130, 131), тогда шансы напороться на существующий код резко снизятся.
Ну или, если очень хочется чисел попроще, сделайте запуск по "-3, -2, -1" :)
Alex Rider
15.06.2013, 18:24
Шутка про раз-два-три смешная
А еще там могут быть индикаторы дем, отладочные индикаторы... Лучше все-таки порт. И, да, железка серьезная, механизм надежного детекта бы сделать...
а можно ли будет дать задания такой видеокарте на автономные расчеты / быструю математику и/или быстрое перемещение блоков данных?
+ аппаратный вывод чанков 4*4, 2*2
Т.е., получается, есть риск запустить эту карту стандартной атрибутной гасилкой (ок, не гасилкой, а зажигалкой). Шутка про раз-два-три смешная, но смешно будет не всем. Включите хотя бы бит мерцания (129, 130, 131), тогда шансы напороться на существующий код резко снизятся.
Ну или, если очень хочется чисел попроще, сделайте запуск по "-3, -2, -1" :)
Вероятность, что в один и тот же байт атрибутов подряд будут записаны три идущих подряд числа очень мала. Конечно лучше использовать значения с включенным мерцанием, так как его почти не используют. Спасибо за подсказку. От записи в порты лучше воздержаться.
а можно ли будет дать задания такой видеокарте на автономные расчеты / быструю математику и/или быстрое перемещение блоков данных?
Это тебе надо NeoGS.
introspec
15.06.2013, 18:39
Вероятность, что в один и тот же байт атрибутов подряд будут записаны три идущих подряд числа очень мала.
Я не в порядке поспорить, а в порядке проговорить: я ещё не писал программы, в которой я бы этого не делал. И, уверен, то же самое могут сказать многие другие программисты. Или вы имеете в виду, что если мы записали 1 во все 768 атрибутов, 2 во все 768 атрибутов, а потом 3 во все 768 атрибутов, то карта уже не запустится?
С включённым битом мерцания риск почти нулевой. Я бы даже сказал, что если кто-то делал (делает?) атрибутные вещи такого рода с включённым мерцанием - их программа заслуживает самого жестокого глюка в любом случае.
а можно ли будет дать задания такой видеокарте на автономные расчеты / быструю математику и/или быстрое перемещение блоков данных?
+ аппаратный вывод чанков 4*4, 2*2
Видеокарта получается итак достаточно хорошая. Надо реализовать сначала задуманное. Быстрое перемещение пока будет в пределах памяти видеокарты. Пока в одну сторону - из памяти спрайтов в память экрана. Про чанки мне нужно почитать, пока не могу ответить. Но, теоретически, размеры спрайтов могут быть произвольного размера от 1 до 256. Для начала нужно сделать размером 16х16 точек.
Пока хорошо бы найти спрайты для отладки движения по экрану и составить процедуру теста для Z80.
Реквестирую, ещё чтобы был на борту пал-кодер, с обычным композитным видео-выходом (тюльпан).
(SCART не у всех то есть.)
Кто хочет сэкономить - просто не впаивает детали пал-кодера.
Будет FPGA или CPLD ?
Вот точно помню, разговаривал я с ZEK, именно на тему, как сделать такую видео-карту (на zx bus),
максимально работоспособной на разных рассыпушных клонах спектрума.
Он там даже список правил приводил, если ZEK таки вспомнит, неплохо было бы написать тут.
отлично,уже 3 видеокарты будут .Я так понимаю эта видеокарта не совместима с остальными?
основной упор делался на графику MSX?
отлично,уже 3 видеокарты будут .Я так понимаю эта видеокарта не совместима с остальными?
основной упор делался на графику MSX?
Основная цель - сделать простое и максимально быстрое построение экрана для игр. На графику MSX2 я не нацеливался. Изображения должны быть похожи на обычную графику для ZX SPECTRUM. Просто у нее 256 цветов. Сделать такие же цвета. Возможно под такой набор найдется редактор спрайтов. Почти такие же цвета в палитре ULAplus.
Основная цель - сделать простое и максимально быстрое построение экрана для игр.
Тогда надо делать тайловый фон со скроллерами, несколько слоев и аппаратные спрайты. Ну и палитра обязательно.
Реквестирую, ещё чтобы был на борту пал-кодер, с обычным композитным видео-выходом (тюльпан).
(SCART не у всех то есть.)
Кто хочет сэкономить - просто не впаивает детали пал-кодера.
Пока предполагается, что PAL-кодер от CHRV или китайский видеоконвертер VGA для вывода на монитор. Хотя можно сделать как в SPECCY2010 на резисторах, но знаний на это у меня, скорее всего не хватит. Резисторы предусмотреть можно попробовать.
Будет FPGA или CPLD ?
Скорее всего FPGA, так как память желательно разогнать до 56 МГц с помощью PLL. Также будет запас на хотелки типа выходов PAL, S-VIDEO и VGA.
Вот точно помню, разговаривал я с ZEK, именно на тему, как сделать такую видео-карту (на zx bus),
максимально работоспособной на разных рассыпушных клонах спектрума.
Он там даже список правил приводил, если ZEK таки вспомнит, неплохо было бы написать тут.
Главное - не использовать порты. И частота кварца в клоне для тактирования видеокарты через ZX-BUS должна быть ровно 14 МГц. INT возможно надо будет подавать с видеокарты для синхронизации Z80 с экраном.
---------- Post added at 20:21 ---------- Previous post was at 20:19 ----------
Тогда надо делать тайловый фон со скроллерами, несколько слоев и аппаратные спрайты. Ну и палитра обязательно.
Фактически на втором слое (на заднем плане) изображение строится из тайлов. Но называем мы их тоже спрайтами. Вместо скроллера используются новые координаты. Для эффекта движения фона каждый новый кадр надо заполнять в новом месте со сдвигом координат от предыдущего положения на 1,2 или 4 точки. Если сделать все быстро, то вместо аппаратных спрайтов достаточно будет и блиттера. Отказ от аппаратных спрайтов позволит разнообразить графику прямым построением линий на экране, возможно в будущем появится поддержка рисования линий для игр типа WARCRAFT2 и DUNE2.
Можно конечно подумать о палитре BMP. Там 256 цветов преобразуются в палитру 3х6 бит. Но эта палитра занимает около 256 х 3 байтов и требует 18 бит на формирователь RGB.
Но эта палитра занимает около 256 х 3 байтов и требует 18 бит на формирователь RGB.
Думаю, что палитры в 12 бит (4096 цветов), должно вполне хватить.
(Так сделано в v6z80p, схему видео выхода можно посмотреть (https://sourceforge.net/p/v6z80p/code/HEAD/tree/trunk/Documentation/PCB related/V6Z80P (Original PCB) Specifics/Peripheral_circuits/v6z80p_audio_video.png))
Фактически на втором слое (на заднем плане) изображение строится из тайлов. Но называем мы их тоже спрайтами. Вместо скроллера используются новые координаты. Для эффекта движения фона каждый новый кадр надо заполнять в новом месте со сдвигом координат от предыдущего положения на 1,2 или 4 точки. Если сделать все быстро, то вместо аппаратных спрайтов достаточно будет и блиттера.
То есть бессмысленное копирование каждый кадр. Еще и немощный Z80 напрягать управлением блиттером. На маленьких размерах тайлов эффективность блиттера будет стремиться к нулю. Какой fps будет в игре такого типа http://rghost.ru/46777440 ?
Реквестирую, ещё чтобы был на борту пал-кодер, с обычным композитным видео-выходом (тюльпан).
(SCART не у всех то есть.)
На теликах 2012-2013гг уже далеко не везде есть низкочастотный PAL/SECAM-вход. А вот SCART есть у всех. Убрали тюльпан и S-Video((. Я смотрел много моделей телевизоров, редко где остался тюльпан. Сейчас везде стоит композитный вход YPbPr
introspec
15.06.2013, 20:06
Какой fps будет в игре такого типа http://rghost.ru/46777440 ?
Ух ты, игра очень хорошо знакомого типа! :)
То есть бессмысленное копирование каждый кадр. Еще и немощный Z80 напрягать управлением блиттером. На маленьких размерах тайлов эффективность блиттера будет стремиться к нулю. Какой fps будет в игре такого типа http://rghost.ru/46777440 ?
Можно прикинуть сдвиг всего экрана на 1 точку. 256 х 192 байт /56 МГц = 878 мкс.
Для управления мелкими объектами надо оптимизировать интерфейс с Z80.
Можно прикинуть сдвиг всего экрана на 1 точку. 256 х 192 байт /56 МГц = 878 мкс.
Т.е. блитер будет работать на 56 МГц ?
И память на 56 ?
Но ведь блитер,
при записи в экранную ОЗУ, делит время со сканером 7МГц (тот кто постоянно обновляет экран).
Получается, чтобы блитер мог записывать на 56МГц,
экранное ОЗУ должно работать на 56 + 7 ?
Т.е. блитер будет работать на 56 МГц ?
И память на 56 ?
Но ведь блитер,
при записи в экранную ОЗУ, делит время со сканером 7МГц (тот кто постоянно обновляет экран).
Получается, чтобы блитер мог записывать на 56МГц,
экранное ОЗУ должно работать на 56 + 7 ?
Шина данных будет 16 бит, то есть скорость увеличится еще в 2 раза.
Добавил в параметры цвет BORDERa.
Шина данных будет 16 бит, то есть скорость увеличится еще в 2 раза.
Т.е. реальная пропускная способность блитера 56МГц,
это около 56 Мегабайт/сек ?
Т.е. реальная пропускная способность блитера 56МГц,
это около 56 Мегабайт/сек ?
Он будет пытаться работать со скоростью 112 Мбайт в секунду, но его иногда будут отвлекать сканер для вывода на телевизор и Z80 с загрузкой команд команд. То есть скорость будет около 56 Мбайт в секунду.
Теоретически можно еще немного ускорить работу. 14 МГц * 4 = 56 МГц, 14 МГц * 6 = 84 МГц, 14 МГц * 8 = 112 МГц. Но больше 100 МГц память работать не сможет.
---------- Post added at 22:29 ---------- Previous post was at 21:40 ----------
Я не в порядке поспорить, а в порядке проговорить: я ещё не писал программы, в которой я бы этого не делал. И, уверен, то же самое могут сказать многие другие программисты. Или вы имеете в виду, что если мы записали 1 во все 768 атрибутов, 2 во все 768 атрибутов, а потом 3 во все 768 атрибутов, то карта уже не запустится?
С включённым битом мерцания риск почти нулевой. Я бы даже сказал, что если кто-то делал (делает?) атрибутные вещи такого рода с включённым мерцанием - их программа заслуживает самого жестокого глюка в любом случае.
Скорее всего вы пишете 1,2,3 не сразу в первый атрибут, а сначала 1 во второй и т.д. Вы ведь не пишите команды типа:
LD #5800,1
LD #5800,2
LD #5800,3
Если запись была в другой адрес, или следующее число не равно ожидаемому в последовательности - автомат включения нового режима должен сбрасываться в исходное состояние. Но я исправил числа на рекомендуемые вами.
Но больше 100 МГц память работать не сможет.
56МГц вполне нормальная частота,
100МГц я думаю будет перебор (помехи и т.п.)
Alex Rider
15.06.2013, 22:30
От записи в порты лучше воздержаться.
А почему?
И частота с клона должна быть ровно 14 МГц.
То есть, машины с 3,5 Мгц и 7 Мгц идут лесом?
Скорее всего вы пишете 1,2,3 не сразу в первый атрибут, а сначала 1 во второй и т.д. Вы ведь не пишите команды типа:
LD #5800,1
LD #5800,2
LD #5800,3
Так может сделать даже загрузчик с ленты и диска. Например, если активен экран 1 128-х машин, а 5-я страница используется под данные (или переменные программы). Еще так может сделать заглючившая отлаживаемая программа. Или незаглючившая, если я хочу посмотреть счет в некоторых переменных визуально, и не хочу писать вывод цифер. Просто вообще переключение видеорежимов при записи ключа в память (тем более, такого простого) - не айс. Порты надежнее.
Хочется еще уметь делать гарантированный детект девайса и возвращать его в режим 6912. Зачем нужен детект - чтобы писать отциональный софт под него. Зачем нужен возврат в 6912 - чтобы можно было не всю игру переделать под устройство, а оставить, например, классическое 6912-меню или межуровневую заставку.
То есть, машины с 3,5 Мгц и 7 Мгц идут лесом?
Имелась ввиду частота кварца в компьютере, которая выводится на шину ZX-BUS для тактирования видеокарты, исправил - частота кварца в клоне должна быть ровно 14 МГц. Нам ведь надо на телевизор сигнал кратно этой частоте формировать. А если будет 16 МГц, как у некоторых клонов, то синхронизации не будет.
Так может сделать даже загрузчик с ленты и диска. Например, если активен экран 1 128-х машин, а 5-я страница используется под данные (или переменные программы). Еще так может сделать заглючившая отлаживаемая программа. Или незаглючившая, если я хочу посмотреть счет в некоторых переменных визуально, и не хочу писать вывод цифер. Просто вообще переключение видеорежимов при записи ключа в память (тем более, такого простого) - не айс. Порты надежнее.
Лучше порты не занимать - их итак свободных не осталось. Почти нет программ, которые запишут подряд в одну ячейку по адресу атрибутов три нужных байта. Это бессмысленно, так как человек не успеет заметить такое быстрое изменение цвета. Да и сканер при выводе на TV сможет прочитать только один из трех в заданный момент.
Хочется еще уметь делать гарантированный детект девайса и возвращать его в режим 6912. Зачем нужен детект - чтобы писать отциональный софт под него. Зачем нужен возврат в 6912 - чтобы можно было не всю игру переделать под устройство, а оставить, например, классическое 6912-меню или межуровневую заставку.
Возврат к стандартному экрану можно сделать при записи другой последовательности байтов в эту же ячейку. Чтение из видеокарты не планировалось, чтобы не конфликтовать с памятью и портами компьютера. В крайнем случае через порт #FF, так как он будет формироваться видеокартой только для стандартного экрана ZX SPECTRUM.
Alex Rider
15.06.2013, 23:07
Лучше порты не занимать - их итак свободных не осталось.
Не знаю... Как-то не по уму оно, через память. Спонтанная мысль: может, через последоватетельность хитрых out'ов в #7ffd при включенном экране-1 (+ память)? Если через ZX-BUS можно "заблокировать" блокировку #7ffd, было бы вообше рульно, например, карта переходит в нужный видеорежим если при включенном экране-1 блокируется порт #7ffd. :)
Кстати, видеокарта должна стать единственным видеовыходом компа же, так? Значит, второй экран 128-го будет тоже на ней?
Чтение из видеокарты не планировалось, чтобы не конфликтовать с памятью и портами компьютера. В крайнем случае через порт #FF, так как он будет формироваться видеокартой только для стандартного экрана ZX SPECTRUM.
В принципе,
можно и обойтись без чтения z80 из ОЗУ видео-карты.
Так что это не смертельно.
Но некие статусные биты, z80 должен уметь читать.
Например,
бит занятости блитера (занят/не занят)
(Т.к. выдавать новую команду блитеру, можно будет только тогда, когда блитер не занят.)
crazy_bender/ex-PLACEBO
15.06.2013, 23:46
извините что влез в вашу беседу. но почему бы разработчику не посмотреть то уже было сделано? а именно описание VIC-II на C64? там есть и прерывание по определенной линии растра и 8 аппаратных спрайтов и тд. всегда можно взять готовое и улучшить
На теликах 2012-2013гг уже далеко не везде есть низкочастотный PAL/SECAM-вход. А вот SCART есть у всех. Убрали тюльпан и S-Video((. Я смотрел много моделей телевизоров, редко где остался тюльпан. Сейчас везде стоит композитный вход YPbPr
Я тоже считаю, что лучше ограничиться выходом SCART, ну может VGA. А YPbPr легко сделать ?
Мне в концепциях предложили увеличить количество слоев экрана и сделать аппаратные спрайты и скроллинг всего экрана.
Это навело меня на более эффективный и удобный способ построения экрана. Можно сделать, наоборот, всего один слой, но два экрана как ZX128. На одном экране будем строить изображение игровой ситуации. А второй экран в это время отображает текущее состояние игры. По прерыванию экраны меняются местами с помощью соответствующей команды.
Для реализации графики всего на одном слое достаточно реализовать аппаратное копирование спрайтов с учетом прозрачного цвета. Если цвет точки спрайта при копировании не прозрачный - записать на экран этот цвет. Если же данная точка в спрайте прозрачная - ничего не делать и переходить к копированию следующей.
Тогда мы просто путем копирования создаем фон, на него поочередно копируем все остальные спрайты, начиная с дальнего. Таким образом передние объекты будут правильно загораживать дальних. И это призойдет само сабой без манипуляции слоями.
Это позволит создавать даже игры типа DOOM2 с объектами на разных планах используя всего один слой и не задумываясь, как нам накладывать загораживающие друг друга объекты.
Для реализации графики всего на одном слое достаточно реализовать аппаратное копирование спрайтов с учетом прозрачного цвета. Если цвет точки спрайта при копировании не прозрачный - записать на экран этот цвет. Если же данная точка в спрайте прозрачная - ничего не делать и переходить к копированию следующей.
Так это и есть, алгоритм классического блитера.
2 экрана (теневой и активный) и
сам копировщик прозрачных спрайтов.
56 МБайт/сек это 1,1 мегабайта во фрейм
Один экран 320x240x8, это 77КБ.
Т.е. за фрейм можно накидать/наложить около 12 экранов (слоёв).
Блин, люди, вы всё таки не забывайте что вы Спектрум улучшаете. А то вы сейчас монстра создадите, который и близко о Спектруме напоминать не будет. Крутых безликих компов и так навалом, стоит ли плодить еще один безликий? Сумеете ли вы сочетать крутую производительность в графике со Спектрумовской индивидуальностью?
В 90-х годах была идея подключать спектрум к Денди через слот вместо катриджа и использовать Деньдю как графическую карту и тема эта вызвала жуткий холивар и в конце концов захирела. Смотрите не наступите на те же грабли.
NovaStorm
16.06.2013, 22:49
>и в конце концов захирела
Да щязз, см. AMD HUMA/HSA - писк сезона =)
Немного о компрессии спрайтов.
После прочтения про рисование тайлов к играм (http://gas13.ru/v3/tutorials/ru_sywtbapa_de-mystifying_greats_1.php) сделал вывод, что не следует гнаться за цветастостью и использовать более 4 оттенков в одном спрайте для фона. Тогда на цвет каждой точки достаточно двух битов вместо восьми. Упакованный спрайт для фона травы, земли, стен и т.п. размером 16 х 16 точек будет содержать не 256 байтов, а только 64. Плюс 4 байта на таблицу цветов для этого спрайта. Итого экономим 256 - 68 = 188 байтов. Ужимаем почти в 3.8 раза.
Если взять спрайт размером 8 х 8 точек с двумя цветами в спрайте, то при стандартных цветах ZX SPECTRUM на это уйдет 9 байтов.
Сжатые спрайты перед записью в буфер видеокарты распаковываем в представление 256 цветов на точку.
Таким образом, для начала можно использовать стандартные цвета без увеличения объема памяти игры. А если в игре кроме этого были еще и заранее сдвинутые спрайты для ускорения скроллинга экрана, то занимаемая игрой память будет еще меньше.
Пока разрабатывается и изготавливается железо полезно было бы прикинуть, на чем можно было бы протестировать собранную видеокарту и какая программа подойдет для рисования спрайтов с данной палитрой цветов (256 оттенков как в MSX2).
После прочтения про рисование тайлов к играм (http://gas13.ru/v3/tutorials/ru_sywt...g_greats_1.php) сделал вывод, что не следует гнаться за цветастостью и использовать более 4 оттенков в одном спрайте для фона.
Вообще-то на местах стыка травы и деревьев в одном тайле там 7 оттенков. Если использовать только 4 краски на тайл, то будет МАКСИМУМ (если художник гений) вот так:
http://xboxlivemedia.ign.com/xboxlive/image/article/114/1141028/retro-city-rampage-20101220110718736-000.jpg
Вообще-то на местах стыка травы и деревьев в одном тайле там 7 оттенков.
Значит компрессор должен считать количество оттенков в спрайте и использовать соответствующий способ компрессии для каждого спрайта. 7 оттенков (от 5 до 16) укладывается в 4 бита. Компрессия будет примерно в 1.5-2 раза. Для универсальной распаковки в 256 цветов блок каждого упакованного спрайта должен содержать параметры: количество N оттенков в спрайте, таблица оттенков (N байтов), затем соответствующее способу компрессии количество байтов данных.
Зачем?
Если вы про компрессию спрайтов - для уменьшения размера игры при загрузке.
Почему этим должна заниматься видеокарта?
Если вы про компрессию спрайтов - для уменьшения размера игры при загрузке.
Зачем вообще компрессировать? Сэкономить мегабайт на восьмигиговой карточке? Для справки: игра Project Robo в сжатом виде занимает 440К и грузится 18 секунд, в несжатом виде занимает 1,5 мегабайта и грузится 3 секунды. Что лучше?
Зачем вообще компрессировать? Сэкономить мегабайт на восьмигиговой карточке? Для справки: игра Project Robo в сжатом виде занимает 440К и грузится 18 секунд, в несжатом виде занимает 1,5 мегабайта и грузится 3 секунды. Что лучше?
Компрессия может понадобиться чтобы игра влезла на диск TR-DOS. Хотя спрайты займут не более 512К. На код останется не более 640 - 512 = 128К. Пока хватает памяти в этих пределах - можно и не сжимать.
Подскажите как продемонстрировать скорость/возможности видеокарты - нужен тест.
Alex Rider
18.06.2013, 23:10
Подскажите как продемонстрировать скорость/возможности видеокарты - нужен тест.
Нужно описание теста или реализация? Не представляю как сделать реализацию в отсутствии железа и эмуляции.
Нужно описание теста или реализация? Не представляю как сделать реализацию в отсутствии железа и эмуляции.
Для начала описание теста. Потом надо начать его реализовывать и на ходу уточнять интерфейс для повышения удобства программирования.
cherkasy
19.06.2013, 01:15
как реализована совместимость с оригинальными спеками ?
как реализована совместимость с оригинальными спеками ?
Вы имеете ввиду аппаратное подключение к краевому разъему или времянки оригинального Спектрума ?
Если аппаратно, то видеокарта планируется в слот ZX-BUS, на котором должна быть частота 14 МГц. А у оригинального Спека и ZXEvо, как тут написали, этого нет. Можно сделать дополнительный генератор 14 или 56 МГц на плате видеокарты.
Для реализации времянок оригинального Спектрума, как в LENINGRAD-2012, потребуется подача с видеокарты через ZX-BUS нового тактового сигнала на Z80. Для этого на плате предусмотрена перемычка. Если не подавать, то тактовые на Z80 будут идти с материнской платы.
Также предусмотрены вилки для подключения тумблеров или перемычек для управления следующими режимами:
1. CONTENDED MEMORY - ON/OFF
2. PORT FF - 0N/OFF
3. SCAN - ZX SPECTRUM (50 Hz) / PENTAGON-128 (48 Hz)
Alex Rider
19.06.2013, 11:24
Для начала описание теста.
Можешь сделать заготовку спецификации и положить ее в первое сообщение? А то вычитывать весь тред с целью понять что оно вообще должно уметь, утомительно. Да и мысли менялись уже. Для начала тест №1:
1. Определение наличия карточки.
2. Включение дополнительного видеорежима.
3. Очистка указанным цветом (из палитры?) и отображение нулевого экрана.
4. Установка цвета бордера (из палитры?).
5. Очистка и отображение первого экрана.
6. Возвращение режима 6912.
Проверяется:
1. Отправка команд в карточку и ожидание их приема.
2. Включение и выключение видеорежима.
3. Очистка экранной памяти заданным цветом.
4. Возможность показа обоих двух экранов.
5. Возврат к режиму 6912.
6. Работа бордера.
7. Детект карточки.
Отсебятина тут:
1. Очистка цветом - это я сам придумал, но видеокарта ведь все равно должна показывать какой-то цвет на месте, где нет тайла фона и точек спрайта.
2. Возврат в 6912 - это все-таки надо. К примеру, товарищи, программирующие на реале, это сильно заценят.
3. Детект карточки. Все-таки, хорошо бы, чтобы он был.
Вопросов по реализации также хватает:
1. Как передаются команды в карточку?
2. Как пользоваться переключением экранов? Классика, 7ffd?
3. Как задавать цвет бордюра?
4. Какая палитра будет после сброса карты? (предлагается - стандартная спековская, отображенная на все цвета с повторением через 16).
5. Как узнать когда команда выполнилась и выполнилась ли она.
6. Как узнать если карточка вообще?
7. Какие видеорежимы и с какой глубиной цвета будут реализованы? Будет ли поллитра.
P.S. Есть столь же детальные задумки для еще пары тестов. Первая пока на пробу.
Для управления видеокартой «METEOR-2013», которая предназначена для ускорения графики в
ZX SPECTRUM-совместимых компьютерах, разработаны простые и эффективные команды типа PRINT, PLOT, DRAW, POKE, PAPER, INK, BORDER, похожие по назначению на соответствующие команды BASICa.
Для указания места вывода на экран используются координаты X и Y. Спрайты загружаются
в память видеокарты и не занимают места в основной памяти компьютера. Во время игры с помощью соответствующих команд видеокарты спрайты копируются по номерам в указанные координаты экрана.
Спрайты можно накладывать друг на друга с использованием прозрачного цвета фона спрайта.
В одной игре можно использовать спрайты нескольких размеров. Имеется возможность задавать границы окна для печати спрайтов. При печати части спрайтов, выходящие за границы окна, обрезаются. Поверх спрайтов можно рисовать нужным цветом точками и линиями.
Параметры новых режимов - 256х192 и 320х240 точек, 255 цветов с палитрой + «прозрачный» цвет.
Два экрана - теневой и отображаемый. Координаты (0,0) в левом верхнем углу экрана.
Палитра - 3х6 бит (как BMP 256), размещена во внутренней памяти FPGA 256 * 18 бит.
Для команд работы с видеокартой «METEOR-2013» выделены адреса 5800H-58FFH в области атрибутов стандартного экрана ZX-SPECTRUM. Команда определяется по адресу, а данные, которые записывает Z80 по этому адресу, используются как параметры для этой команды. Команды в видеокарте накапливаются в буфере для исключения ожидания Z80 при выполнении сложных команд. Видеокарта затем выполняет накопленные команды из буфера.
История оптимизации команд для работы с видеокартой:
130714-05 - глобальная оптимизация команд с целью ускорения заполнения экрана спрайтами
130711-01 - убраны команды задания границ копирования части спрайтов. Добавлены команды рисования точки
130707-01 - добавлены команды управления курсором.
130630-01 - координаты курсора на экране теперь могут быть отрицательными для автоматического обрезания спрайта при выходе за границу экрана. Координата Y теперь тоже состоит из старшего и младшего байта.
130629-02 - вместо команды установки младшего байта номера спрайта с копированием спрайта добавлены команты PRINT_AUTOINC_X, PRINT_AUTOINC_Y для печати спрайта с автоинкрементом координат.
130629-01 - Уточнение имен команд
130628 - В ходе написания примера работы с видеокартой уточнены названия команд и т.п. Также удобнее по одному адресу записывать номер команды, а по другому - значение этого параметра. Потом ПЛИС сможет записывать оба байта одним словом в буфер FIFO.
130624 - добавлен адрес спрайта с номером 0
130622 - вместо HL для адресации команд и данных теперь применятеся индексная адресация с IY
130621 - предложен буфер команд в FPGA для того чтобы не нужно было ждать готовности видеокарты. Запись команд и данных по адресу в HL.
Включается новый режим так - в левый верхний атрибут стандартного экрана поочередно записываются числа 129, 130, 131:
ложных срабатываний от фейдеров не будет?
ложных срабатываний от фейдеров не будет?
Нет, так как в них между приведенными командами записи есть другие команды, что сбрасывает автомат включения.
LD HL, #5800
LD (HL),131
LD (HL),131
LD (HL),131
А вот такое включение тоже будет работать ?
ld iy,#5800
ld (iy),131
ld iy,#5800
ld (iy),131
ld iy,#5800
ld (iy),131
Или нужно строго как у вас.
А вот такое включение тоже будет работать ?
ld iy,#5800
ld (iy),131
ld iy,#5800
ld (iy),131
ld iy,#5800
ld (iy),131
Или нужно строго как у вас.
Так тоже можно. Главное, чтобы запись была подряд по указанному адресу в ОЗУ три раза подряд и с нужными значениями.
Я прикинул, что удобнее задать как у вас базовый адрес команд в IY, а для записи команд и параметров использовать индексную адресацию. Это освободит регистровую пару HL для более важных операций в игре.
Обновил систему команд для индексной адресации -- http://www.zx.pk.ru/showpost.php?p=610738&postcount=50
================================================== ==============
ПРИНЦИПЫ ПЕРЕКЛЮЧЕНИЯ ЭКРАНОВ.
В видеокарте предусмотрено два экрана - отображаемый и рабочий.
Команда выбора экрана:
LD (IY+1), NUM_SCR
LD (IY+1), число (обычно поочередно, каждое прерывание менять 1 и 2)
Бит D0 числа показывает видеокарте какой экран отображать на TV.
Бит D1 числа показывает видеокарте какой экран рабочий.
Текущее состояние нужно хранить в одной из ячеек ОЗУ. Каждое прерываение инвертировать два младших бита, сохранять новое значение и отправлять в видеокарту команду выбора экрана.
Теоретически, можно сделать установку так, что редактируется и отображается один и тот же экран. Тогда его не надо будет переключать. Чтобы для рисования изображения без мельканий с использований только одного экрана было достаточно много времени желательно изменить положение INT. Предлагается в новых режимах сигнал INT формировать в момент сразу после отображения правой нижней точки экрана. Это позволит построить новый экран пока на TV отображается кадровый BORDER.
карта клевая, только есть минус - спек получается нелепым довеском к ней, так как её вычислительных мозностей и ресурсов в принципе хватит что бы подрубить джостик и сделать денди как я понимаю
LD (IY+1), SIZE_X ; размер спрайта по-горизонтали (обычно 16)
LD (IY+1), число
Т.е. например, чтобы установить размер спрайта по горизонтали 16 точек,
нужно сделать так:
LD (IY+1), SIZE_X
LD (IY+1), 16
А само значение константы SIZE_X какое ?
---------- Post added at 17:21 ---------- Previous post was at 17:19 ----------
Я прикинул, что удобнее задать как у вас базовый адрес команд в IY
Это мне такое sdcc сгенерировал с IY.
А вообще, тут уж как программер захочет, хоть через HL, хоть через IY.
---------- Post added at 17:25 ---------- Previous post was at 17:21 ----------
предложен буфер команд в FPGA для того чтобы не нужно было ждать
готовности видеокарты
А длина его какая ?
Он может переполниться ?
Точнее можно сказать так. Направление (концепция) разработки хорошая, но не сказать что отличная. Рано говорить об отличной. Но что хочется пожелать, и попросить. Вернее будет, попросить. Разместить блок - схему этой видеокарточки. Или, если есть, принципиальную схему. Я уже написал, что возможно, (я только полагаю!), что некий опытный образец есть. Если все-таки он есть, то может быть не стоит делать из этого секретную разработку. Таких разработок предостаточно. Все равно без прошивки это просто "железо". Но если все-таки и прошивку возможно разместить, то это было бы неплохо. Такая карточка в любом случае будет дорабатываться и изменятся. Пример тому тот же ZX Evo. От первого прототипа "A" ревизия "C" значительно изменилась. И все-таки, если видеокарточка будет как второй компьютер, на первых порах, "это не есть плохо!", думаю, что в будущем она станет компактнее. И здесь примеров достаточно.
Опытного образца пока нет, но детали для него уже выбраны и заказаны.
Блок-схема видеокарты "METEOR-2013"
http://s61.radikal.ru/i172/1306/be/12bca1b9f08at.jpg (http://s61.radikal.ru/i172/1306/be/12bca1b9f08a.png)
---------- Post added at 20:21 ---------- Previous post was at 20:17 ----------
Т.е. например, чтобы установить размер спрайта по горизонтали 16 точек,
нужно сделать так:
LD (IY+1), SIZE_X
LD (IY+1), 16
А само значение константы SIZE_X какое ?
Когда интерфейс будет проработан достаточно оптимально - перепишем все команды и пронумеруем от 0 до N.
А длина его какая ?
Он может переполниться ?
Сколько влезет в FPGA. В обычных случаях Z80 не будет успевать перегружать FPGA.
zst, по схеме:
Предлагаю поставить генератор на одной 3.3в м/с вместо 555LN1+кварц.
Сигналы /OE на м/с памяти, возможно, не нужны - при понижении WE вывод автоматически отключается, а шины у памятей отдельная и мешать другим ус-вам не будут.
vlad, в ipvc нет слоев. Слои я отдельно пробовал делать. Концепция похожая, да.
IanPo, так у тебя уже все вроде здесь IPVC - графический контроллер для ZX-BUS (http://zx.pk.ru/showthread.php?t=15176) получилось, у zst вроде как, такая же концепция вырисовывается?
в ipvc нет слоев. Слои я отдельно пробовал делать. Концепция похожая, да.
Так может получится доделать начатое?
zst раз уж решил взять CycloneII EP2C5Q208 то надеюсь, что будет возможность на будущее установить EP2C8Q208?
На мой взгляд, лучше поставить 3-ри SRAM 512K x 8бит вместо двух по 16бит, скорости и так хватит для 256 цветов, а вот возможностей в разы больше появится (вместо 3-ей SRAM возможно лучше поставить SDRAM для подкачки видео строк или использовать как буфер для различного вида видео данных).
Попробовал сделать пробные наброски схемы на EP4CE6E22 + 2-ве SRAM 512Kx8 в связке с EPM3064AT100. Пока вроде все получилось.
При разработке ReVerSE II наткнулся на эти статьи, может пригодятся:
Генерация видео сигнала "Generating NTSC composite video with an FPGA and two resistors" (http://excamera.com/sphinx/fpga-ntsc.html)
Генерация аудио сигнала "PWM (Pulse Width Modulation)" (http://www.fpga4fun.com/PWM_DAC_1.html)
HDMI "HDMI Output" (http://www.youtube.com/watch?v=hkOZifLUp8s)
НОМЕР СПРАЙТА В ОЗУ СПРАЙТОВ
LD (IY+1), HN ; старший байт номера спрайта
LD (IY+1), число
LD (IY+1), LN ; младший байт номера спрайта
LD (IY+1), число
Всё таки думаю,
что в обычной программе, спрайты будут самых разных размеров,
(т.е. по номеру спрайта уже нельзя будет вычислить, его адрес )
поэтому тут нужен просто 3-байтовый адрес спрайт-памяти.
Планируете ли выложить все фалы проекта (или некоторые части) в открытый доступ ?
Alex Rider
23.06.2013, 19:30
поэтому тут нужен просто 3-байтовый адрес спрайт-памяти.
Гораздо удобнее было бы адресовать спрайты по номеру! Не надо этой арифметики! Карте не врщвращает в Спектрум никаких данных - адрес (3-хбайтовый) придется считать в загрузчике, хранить в программе и передавать каждый раз в карту. Зачем?
zst, по схеме:
Предлагаю поставить генератор на одной 3.3в м/с вместо 555LN1+кварц.
А чем такой генератор лучше ? И какую лучше частоту: 14, 56, 84 или какую другую ? К какому входу FPGA лучше подключать? Вообще-то планировалось брать 14 МГц с материнской платы компьютера. Но у некоторых компьютеров ее нет на разъеме.
zst раз уж решил взять CycloneII EP2C5Q208 то надеюсь, что будет возможность на будущее установить EP2C8Q208?
Только если останется 6 лишних выводов.
На мой взгляд, лучше поставить 3-ри SRAM 512K x 8бит вместо двух по 16бит, скорости и так хватит для 256 цветов, а вот возможностей в разы больше появится (вместо 3-ей SRAM возможно лучше поставить SDRAM для подкачки видео строк или использовать как буфер для различного вида видео данных).
Пока от лишних наворотов я отказался. Цель - максимально ускорить работу копирования спрайтов в область экрана.
Попробовал сделать пробные наброски схемы на EP4CE6E22 + 2-ве SRAM 512Kx8 в связке с EPM3064AT100. Пока вроде все получилось.
При разработке ReVerSE II
Хорошо бы пока сделать новый графический режим в соответствии с указанным набором команд для тех компьютеров на FPGA, где это возможно - Speccy2010 и ReVerSE. Как вы считаете - это возможно ?
наткнулся на эти статьи, может пригодятся:
Генерация видео сигнала "Generating NTSC composite video with an FPGA and two resistors" (http://excamera.com/sphinx/fpga-ntsc.html)
Генерация аудио сигнала "PWM (Pulse Width Modulation)" (http://www.fpga4fun.com/PWM_DAC_1.html)
HDMI "HDMI Output" (http://www.youtube.com/watch?v=hkOZifLUp8s)
Спасибо. Хорошо бы почитать теорию, по видеоролику догадаться трудновато. Думаю, раз есть FPGA, может предусмотреть переключаемый видеовыход, как в Speccy2010 - SCART/VGA/S-VIDEO/COMPOSITE/HDMI ? Хотя бы предусмотреть на будущее возможность подпайки через разъем дополнительных разъемов.
Всё таки думаю,
что в обычной программе, спрайты будут самых разных размеров,
(т.е. по номеру спрайта уже нельзя будет вычислить, его адрес )
поэтому тут нужен просто 3-байтовый адрес спрайт-памяти.
Может лучше стандартизировать размер для хранения спрайтов 16 х 16 точек ? Тогда рассчитывать адрес в FPGA проще. Указанием начальной и конечной строки/столбца спрайта можно уменьшать до нужного размера. А если нужно изобразить больший объект - то составлять их из нескольких спрайтов. Лишние пикселы закрашивать прозрачным цветом.
Планируете ли выложить все фалы проекта (или некоторые части) в открытый доступ ?
Можно будет выложить исходники прошивки в этой теме или на GOOGLECODE.
Гораздо удобнее было бы адресовать спрайты по номеру! Не надо этой арифметики! Карте не врщвращает в Спектрум никаких данных - адрес (3-хбайтовый) придется считать в загрузчике, хранить в программе и передавать каждый раз в карту. Зачем?
Может хранить спрайты одинаковых размеров в наборах до 256 спрайтов в наборе ? Тогда на каждый набор нужно видеокарте указывать размеры спрайта и количество спрайтов в наборе. Возможно также начальный адрес каждого набора. Тогда при копировании на экран достаточно будет указать номер набора и номер спрайта. Остальные данные по началу блока и размерам спрайта указать при загрузке.
Возможно FPGA сможет сама вычислять начала каждого спрайта по номеру набора и спрайта. Тогда нужно спроектировать достаточное количество наборов и выделить для этого соответствующие команды и параметры.
Alex Rider, если спрайты разного размера (пуля и танк, например), то надо иметь таблицу адресов начал спрайтов.
zst, генератор просто меньше по габаритам, меньше элементов. Если будет генерация от ZXBUS, то его вообще можно не ставить (на выбор юзера). 14 МГц достаточно, подавать на PLL вход Циклона(можно посмотреть в даташите или Квартусе). С помощью ФАПЧ можно получить 56 МГц или 84.
А чем такой генератор лучше ? И какую лучше частоту: 14, 56, 84 или какую другую ? К какому входу FPGA лучше подключать? Вообще-то планировалось брать 14 МГц с материнской платы компьютера. Но у некоторых компьютеров ее нет на разъеме.
Сделай пока возможность его установки. А какой именно частоты зависит от того какие видео режимы планируешь, экспериментально можешь попробовать подобрать в MegaWizard (ALTPLL).
Только если останется 6 лишних выводов.
Должны остаться, :) иначе не будет куда развивать конфигурацию.
Пока от лишних наворотов я отказался. Цель - максимально ускорить работу копирования спрайтов в область экрана.
Наворотами это думаю назвать сложно, корки контроллера SDRAM есть. Перенос данных от спека в видео ускоритель возможно, при наличии простого DMA на счетчиках.
Думаю, раз есть FPGA, может предусмотреть переключаемый видеовыход, как в Speccy2010 - SCART/VGA/S-VIDEO/COMPOSITE/HDMI ? Хотя бы предусмотреть на будущее возможность подпайки через разъем дополнительных разъемов.
Все закладывать не имеет смысла, т.к. реально использоваться будет всего один видео выход. Но как базовый, я бы распаял VGA, остальное пусть подрубается в интерфейс.
Хорошо бы пока сделать новый графический режим в соответствии с указанным набором команд для тех компьютеров на FPGA, где это возможно - Speccy2010 и ReVerSE. Как вы считаете - это возможно ?
Возможно, но на данных бордах есть ряд архитектурных ограничений.
Alex Rider
23.06.2013, 23:27
Может хранить спрайты одинаковых размеров в наборах до 256 спрайтов в наборе ? Тогда на каждый набор нужно видеокарте указывать размеры спрайта и количество спрайтов в наборе. Возможно также начальный адрес каждого набора. Тогда при копировании на экран достаточно будет указать номер набора и номер спрайта. Остальные данные по началу блока и размерам спрайта указать при загрузке.
Возможно FPGA сможет сама вычислять начала каждого спрайта по номеру набора и спрайта. Тогда нужно спроектировать достаточное количество наборов и выделить для этого соответствующие команды и параметры.
Alex Rider, если спрайты разного размера (пуля и танк, например), то надо иметь таблицу адресов начал спрайтов.
Эм... А вот я не пойму ни разу. А нельзя ли разве просто сначала грузить спрайты разных размеров вперемешку, а потом выводить их по номеру (возможно, 2-хбайтному)? И не заморачиваться наборами - наборы не нужны при программировании со стороны Спектрума.
Может лучше стандартизировать размер для хранения спрайтов 16 х 16 точек ? Тогда рассчитывать адрес в FPGA проще. Указанием начальной и конечной строки/столбца спрайта можно уменьшать до нужного размера. А если нужно изобразить больший объект - то составлять их из нескольких спрайтов. Лишние пикселы закрашивать прозрачным цветом.
Вот это не надо совсем. Спрайты должны быть произвольного размера (ну да, с каким-то разумным верхним ограничением). Потому что железка на карточке в 100500 раз мощнее Z80, а вы хотите на Z80 переложить вот эту вот аппликацию, склеивание спрайтов из кусков. Да еще и проверку того, чтобы вышедшие за пределы экрана куски с другой стороны не поперли. Сделайте простую для программистов штуку - это сильно повысит шансы того, что кто-то что-то под нее напишет.
upd: а номер спрайта обязан быть 2-х байтным. Потому что первым делом я бы загрузил в видеокарту 256 спрайтов букв.
Может лучше стандартизировать размер для хранения спрайтов 16 х 16 точек ? Тогда рассчитывать адрес в FPGA проще. Указанием начальной и конечной строки/столбца спрайта можно уменьшать до нужного размера.
Не, это уже лишнее.
Вот сейчас у вас, по проекту, это нормальный классический блитер.
Копирующий спрайты размером до 255x255.
Деление же на блоки по 16x16, просто надуманный момент.
Незачем усложнять жизнь программеру и заставлять его составлять объект из неких кусков 16x16.
Вот каких размеров спрайт нужен, вот таким он и будет.
Ну и нужно сделать, чтобы можно было задавать адрес спрайта, в двух вариантах:
- по 3-ёх байтовому адресу в спрайт памяти
- по 2-ух байтовому номеру (если кодер очень хочет сэкономить)
Т.е. какой именно вариант будет удобен кодеру, такой он и и будет использовать.
---------- Post added at 22:59 ---------- Previous post was at 22:46 ----------
а номер спрайта обязан быть 2-х байтным
Alex Rider, если спрайты разного размера (пуля и танк, например), то надо иметь таблицу адресов начал спрайтов.
Верно IanPo говорит.
Думаю, раз есть FPGA, может предусмотреть переключаемый видеовыход, как в Speccy2010 - SCART/VGA/S-VIDEO/COMPOSITE/HDMI ? Хотя бы предусмотреть на будущее возможность подпайки через разъем дополнительных разъемов.
Всенепременно. Хотя бы VGA был бы, иначе полезность карты сводится на нет, если к ней еще скандаблеры цеплять...
Эм... А вот я не пойму ни разу. А нельзя ли разве просто сначала грузить спрайты разных размеров вперемешку, а потом выводить их по номеру (возможно, 2-хбайтному)? И не заморачиваться наборами - наборы не нужны при программировании со стороны Спектрума.
Вот это не надо совсем. Спрайты должны быть произвольного размера Сделайте простую для программистов штуку - это сильно повысит шансы того, что кто-то что-то под нее напишет.
upd: а номер спрайта обязан быть 2-х байтным. Потому что первым делом я бы загрузил в видеокарту 256 спрайтов букв.
Согласен, нужно предоставить программисту возможность использовать спрайты разных размеров. Для этого я и предложил идею наборов. Их еще можно назвать банками, блоками и т.п. Важно то, что в банке спрайты одинакового размера. Для простоты нумерации одним байтом количество спрайтов в банке может быть от 1 до 256. Это обеспечит легкость указания спрайта одним байтом.
Например шрифт в кодировке WINDOWS-1251. Рисуем 256 символов размером 8 х 8 точек или другого размера. Это будет банк спрайтов номер 1. Чтобы изобразить текст сначал выбираем банк спрайтов номер 1 с символами. Потом уже используем однобайтный номер спрайта/ символа в банке. Мне кажется это проще, чем каждый раз указывать по два байта.
Второй банк спрайтов может содержать тайлы травы, деревьев, земли и т.п. Он уже может содержать от 1 до 256 спрайтов размером, например, 12 х 12 точек. Это будет банк спрайтов номер 2. Тогда для изображения фона нужно установить текущим банк номер 2 и уже работать с однобайтовым номером спрайта. Это тоже проще, чем каждый раз писать по два байта.
Фактически, старший байт номера спрайта - это номер банка. Банков спрайтов может быть, например, 16. Один для букв, другой для фона, третий для главного героя, четвертый - враги, пятый - пули, шестой взрывы и т.п. Каждый банк нужно описать следующими параметрами: адрес начала, размер спрайта по-горизонтали, размер спрайта по-вертикали. Не обязательно в банке рисовать все 256 спрайтов - только необходимое количество. Адрес следующего банка указывать на следующий байт после последнего байта предыдущего банка.
Alex Rider
24.06.2013, 05:22
Верно IanPo говорит.
Таблица смещений спрайтов не обязательна ни в каком случае. В карточку я могу загрузить спрайты известным в известном мне порядке и рисовать их на экране по номеру - это удобно, исключает указательную арифметику в памяти видеокарты. Оставить прямую адресацию в видеократе стоит, да. Даже без видеокарты при выводе на экран 6912 можно обойтись без таблицы смещений спрайтов если хранить перед каждым спрайтом его размеры.
---------- Post added at 05:22 ---------- Previous post was at 05:19 ----------
Для этого я и предложил идею наборов. Их еще можно назвать банками, блоками и т.п.
Так можно, да. Фактически, номер спрайта всен равно останется 2-хбайтным, только нумерация не сквозная. А как теперь сопоставить загруженный в карточку спрайт и его номер?
Таблица смещений спрайтов не обязательна ни в каком случае. В карточку я могу загрузить спрайты известным в известном мне порядке и рисовать их на экране по номеру - это удобно, исключает указательную арифметику в памяти видеокарты. Оставить прямую адресацию в видеократе стоит, да. Даже без видеокарты при выводе на экран 6912 можно обойтись без таблицы смещений спрайтов если хранить перед каждым спрайтом его размеры.Смещение для каждого спрайта указывать не надо - только адрес начала банка. Это можно сделать при загрузке спрайтов в видеокарту.
Так можно, да. Фактически, номер спрайта всен равно останется 2-хбайтным, только нумерация не сквозная. А как теперь сопоставить загруженный в карточку спрайт и его номер?
На мой взгляд, удобнее хранить спрайты одинакового размера в одном банке. Это позволит видеокарточке самой рассчитывать адрес начала нужного спрайта по номеру. Для этого видеокарта возьмет адрес начала банка и прибавит к нему смещение (номер спрайта * ширина спрайта * высота спрайта). Программисту остается передать видеокарте номер банка и номер спрайта в этом банке.
Вопрос к программистам - что представляет из себя карта уровня для игр типа R-TYPE на логическом уровне ? Достаточно ли 256 спрайтов для такой игры ? Или нужно несколько банков спрайтов по 256 ?
Для этого я и предложил идею наборов. Их еще можно назвать банками, блоками и т.п.
Да, нормальная идея.
Только, оставить выбор за кодером, какой метод использовать,
описанные вами банки или
3-ёх байтовый адрес.
Т.е. нужно реализовать в карте оба метода.
(начать с более простого)
---------- Post added at 15:11 ---------- Previous post was at 14:59 ----------
Номер спрайта, можно сделать 2 байтовым.
Но, по умолчанию, старший байт равен нулю.
Тогда, кодер может установить:
- только младший байт номера спрайта
(если 256 номеров спрайтов достаточно)
или
- младший и старший байты номера спрайта
(если 256 номеров спрайтов не достаточно)
---------- Post added at 15:15 ---------- Previous post was at 15:11 ----------
Достаточно ли 256 спрайтов для такой игры ?
Вот, по предложенному мной простому методу,
если 256 не достаточно,
то кодер просто будет юзать 2-ух байтовый номер спрайта.
Да, нормальная идея.
Только, оставить выбор за кодером, какой метод использовать,
описанные вами банки или
3-ёх байтовый адрес.
Т.е. нужно реализовать в карте оба метода.
(начать с более простого)
[/COLOR]Номер спрайта, можно сделать 2 байтовым.
Но, по умолчанию, старший байт равен нулю.
Тогда, кодер может установить:
- только младший байт номера спрайта
(если 256 номеров спрайтов достаточно)
или
- младший и старший байты номера спрайта
(если 256 номеров спрайтов не достаточно)
Вот, по предложенному мной простому методу,
если 256 не достаточно,
то кодер просто будет юзать 2-ух байтовый номер спрайта.
Вы согласны, что спрайты в банке должны быть одинакового размера ?
Старший байт номера спрайта - это номер банка.
Чтобы видеокарта могла найти спрайт по номеру она должна знать начало банка и размеры спрайтов в этом банке.
Если указывать при копировании трехбайтный адрес спрайта, тогда нужно будет каждый раз указывать и размер спрайта, если будут использоваться спрайты разных размеров. А при обращении по номеру банка и спрайта размер спрайтов будет читаться из параметров банка. Как их увязать между собой.
Как вариант можно не делить всю область на банки и не сохранять их параметры. Тогда нужно каждый раз при смене размера используемого спрайта задавать текущий размер и указывать адрес начала спрайтов данного размера. Тогда нет ограничений на количество банков и не надо сохранять в видеокарте их параметры.
FPGA может аппаратно умножать числа по 18 битов. Это можно использовать для вычисления смещения спрайта в банке.
Запутаться можно уже...
Давайте о банках и спрайтах еще обдумаем хорошенько. Еще нужно обдумать о поведении блиттера на границах экрана. Например, как изображать спрайт летящего справа-налево объекта ?
Вы согласны, что спрайты в банке должны быть одинакового размера ?
Да, конечно.
Чтобы видеокарта могла найти спрайт по номеру она должна знать начало банка и размеры спрайтов в этом банке.
Верно.
Смотрите, можно проще, прям без "банков", вот так:
- установил начало области (3 байта адрес спрайт памяти)
- установил размер спрайтов области (2 байта)
- копирую спрайт по номеру спрайта (номер спрайта: 1 или 2 байта)
- ...
Т.е. всё тоже самое, что вы говорили, только понятия "банка", мы не вводим. А просто при необходимости, подаются команды установки "начала области" и "размера спрайтов области" (вместо переключения банков).
По моему так по-проще будет.
Смотрите, можно проще, прям без "банков", вот так:
- установил начало области (3 байта адрес спрайт памяти)
- установил размер спрайтов области (2 байта)
- копирую спрайт по номеру спрайта (номер спрайта: 1 или 2 байта)
Т.е. всё тоже самое, что вы говорили, только понятия "банка", мы не вводим. А просто при необходимости, подаются команды "установки начала области" и "размера спрайтов области" (вместо переключения банков).
По моему так по-проще будет.
Хорошо. давайте остановимся на этом варианте.
На нормальных видеоконтроллерах спрайты лежат в виде битмапа шириной 512 и не требуют никакого умножения. Тслабсу это было внедрено в мосх ещё два года назад, он понял сразу.
На нормальных видеоконтроллерах спрайты лежат в виде битмапа шириной 512 и не требуют никакого умножения. Тслабсу это было внедрено в мосх ещё два года назад, он понял сразу.
Вроде решили, что не стоит ограничивать полет фантазии программиста размерами спрайта 16 х 16 точек или каким-либо другим. Пусть он сам выбирает размер, например 6х8 точек для букв. А для произвольного размера нужно умножение при определении по номеру адреса начала спрайта .
В команды добавлено:
АДРЕС НАЧАЛА ОБЛАСТИ СПРАЙТОВ
LD (IY+1), SPR0_ADDR0 ; младший байт адреса
LD (IY+1), число
LD (IY+1), SPR0_ADDR1 ; средний байт адреса
LD (IY+1), число
LD (IY+1), SPR0_ADDR2 ; старший байт адреса
LD (IY+1), число
РАЗМЕР СПРАЙТОВ В ОБЛАСТИ
LD (IY+1), SIZE_X ; размер спрайта по-горизонтали (обычно 16)
LD (IY+1), число
LD (IY+1), SIZE_Y ; размер спрайта по-вертикали (обычно 16)
LD (IY+1), число
Вроде решили, что не стоит ограничивать полет фантации программиста размерами спрайта 16 х 16 точек или каким-либо другим.
При чём тут размер спрайта?
А для произвольного размера нужно умножения для определения начала спрайта по номеру.
Если все спрайты одного размера - то это не "произвольный размер".
И умножение не нужно. Вообще. Ни для начала спрайта, ни для середины спрайта.
При чём тут размер спрайта?
Тогда объясните поподробнее, что вы имели ввиду.
Пользователь задаёт координаты левого верхнего угла спрайта в битмапе и размер этого спрайта. Первая строка спрайта берётся по адресу base+256*Y+X. Следующая строка спрайта берётся по адресу +256. И так далее.
Пользователь задаёт координаты левого верхнего угла спрайта в битмапе и размер этого спрайта. Первая строка спрайта берётся по адресу base+256*Y+X. Следующая строка спрайта берётся по адресу +256. И так далее.
То есть в первом отрезке памяти длиной 256 байтов размещены первые строки спрайтов нескольких спрайтов (256/SIZE_X) , в следующих 256 байтов - вторые строки этих же спрайтов и т.д.?
При произвольном размере спрайтов каждый конкретный спрайт может начинаться с любой строки.
При произвольном размере спрайтов каждый конкретный спрайт может начинаться с любой строки.
Уточню еще. Мы до этого обсуждали, как определить адрес начала спрайта в ОЗУ спрайтов по его номеру. Для этого предлагалась формула: BASE + N * SIZE_X * SIZE_Y.
А вы вроде говорите про адрес на экране? У нас адрес начала первого столбца спрайта в ОЗУ экрана задается по формуле: 256 * X + Y, второго столбца 256 * (X+1) + Y и т.д. Копируются спрайты на экран столбиками слева-направо, в столбике точки копируются сверху-вниз.
Я говорю про адрес в битмапе спрайтов.
А не проще ли просто взять доку на V9990 или спрайты тслабса (№2) и повторить, как там сделано? Зачем нам ещё одна ветка без софта? Программистов на платформе и там можно по пальцам пересчитать - зачем дальше дробить платформу? Или у существующих веток фатальный недостаток "сделано не мной"?
Я говорю про адрес в битмапе спрайтов.
А не проще ли просто взять доку на V9990 или спрайты тслабса (№2) и повторить, как там сделано? Зачем нам ещё одна ветка без софта? Программистов на платформе и там можно по пальцам пересчитать - зачем дальше дробить платформу? Или у существующих веток фатальный недостаток "сделано не мной"?
Мы делаем максимально быстрый и удобный вариант для программирования игр. Спрайты хранятся в ОЗУ видеокарты. Никаких 3D и т.п. наворотов. Цветов 256. Вы нам подсказывайте как лучше в этих рамках.
Кто конкретно будет писать эти несовместимые игры?
Кто конкретно будет писать эти несовместимые игры?
Если писать будет легко и скорость будет большая, писать смогут многие. Тогда игра будет лучшего качества, по сравнению с играми, которые писать трудно. К тому же предлагаемый режим можно реализовать в клонах на FPGA.
Прошу дать прямые ссылки для ознакомления с указанными выше режимами.
http://alonecoder.nedopc.com/zx/books/V9990RUS.rar
http://tslabs.info/forum/viewtopic.php?f=6&t=178 (начало, а продолжения, похоже, не будет - дальше спрашивать тслабса)
Обе системы уже реализованы и имеют софт. На клонах с FPGA/CPLD, скорее всего, будет только вторая, но с АТМ портами, ибо другой вариант поддержки её и АТМ одновременно не влезает в ZX Evo. Сейчас эту проблему DDp решил переключением прошивок, но это, во-первых, не универсальное решение с точки зрения разного железа, а во-вторых, полностью неприемлемое решение с точки зрения ОС.
http://alonecoder.nedopc.com/zx/books/V9990RUS.rar
http://tslabs.info/forum/viewtopic.php?f=6&t=178 (начало, а продолжения, похоже, не будет - дальше спрашивать тслабса)
Обе системы уже реализованы и имеют софт. На клонах с FPGA/CPLD, скорее всего, будет только вторая, но с АТМ портами, ибо другой вариант поддержки её и АТМ одновременно не влезает в ZX Evo. Сейчас эту проблему DDp решил переключением прошивок, но это, во-первых, не универсальное решение с точки зрения разного железа, а во-вторых, полностью неприемлемое решение с точки зрения ОС.
Почитал у TSLABA - кто такое ослит ? Сделайте простые режимы с одним слоем. Конечно игр не дождетесь под такое сложное программирование. Мы тут придумали достаточно элегантное программирование игр без лишних сложностей. Такое бы на ZXEvo сделать - сразу бы стало игра в 10 раз больше.
Если писать будет легко и скорость будет большая, писать смогут многие.
Никаких "многих" нет. Во всём СНГ осталось только 6 разработчиков игр под ZX.
Кто конкретно будет писать эти несовместимые игры?
Хватит тут флудить.
Ветка, конкретно по техническим вопросам.
Если нечего сказать, флудить незачем.
И не путай человека, тс-лабсом, у которого аппаратные спрайты.
Здесь же, человек выбрал блитер.
Не путай тёплое с мягким...
Давайте продолжим обсуждение.
Было предложение сделать координаты X и Y по два байта. Если X от 0 до 255 (319), а Y от 0 до 191 (239) - точку спрайта копировать на экран. Иначе - нет, эта точка за границами экрана.
Тогда для изображения части спрайта у левой границы экрана нужно...
Ветка, конкретно по техническим вопросам.
Ветка конкретно по расколу платформы. Любые просьбы о совместимости автор отметает.
Если нечего сказать, флудить незачем.
Я сказал по технической части больше, чем любой другой в этой теме. И я не хрен с горы.
Здесь же, человек выбрал блитер.
Для таких решений нужна серьёзная аргументация.
И да, в V9990 блиттер есть. Как насчёт совместимости?
Ветка конкретно по расколу платформы. Любые просьбы о совместимости автор отметает.
Совместимость с огромным количеством программ для ZX SPECTRUM остается, даже более, чем в других клонах. Добавляется совместимость с демами Pentagon-128.
Я сказал по технической части больше, чем любой другой в этой теме. И я не хрен с горы.
Ваши замечания ценны, но вы уперлись в АТМ и несколько игр для него. Возможно на тот момент это было единственно верное расширение графики. Но на данный момент, можно уже и сменить свое мнение. Давайте вернемся к первоисточнику - ZX SPECTRUM и начнем заново, а не будем повторять тупиковые ветви по развитию железа.
Мы предлагаем новую графику без портов, без страниц и т.п. сложностей. Обычные координаты на экране и номера спрайтов. Вы что не видите ни одного достоинства? Например, спрайты могут быть произвольного размера, а не 16 х 16.
Для таких решений нужна серьёзная аргументация.
И да, в V9990 блиттер есть. Как насчёт совместимости?
Посмотрел бегло. Там спрайты фиксированного размера 16 х 16. Мы же предлагаем выбор в размере спрайтов, 256 цветов без палитры, один слой, на котором можно наложить несколько объектов.
Почему вы все критикуете. Давайте сделаем НОВЫЙ РЕЖИМ без оглядки на предыдущие разработки.
Кроме этого, старые расширения графики можно добавить ПОТОМ.
Мы предлагаем новую графику без портов, без страниц и т.п. сложностей. Обычные координаты на экране и номера спрайтов. Вы что не видите ни одного достоинства?
Пока достоинств не видно. Как будет выглядеть движок для R-TYPE? Там два слоя фона со скроллингом.
256 цветов без палитры
Можно сразу закапывать. Палитра нужна, и минимум 12 бит.
Давайте вернемся к первоисточнику - ZX SPECTRUM и начнем заново, а не будем повторять тупиковые ветви по развитию железа.
От 128К тоже откажемся, он тоже тупиковый - в Enterprise и Sam Coupe не поддерживается.
Посмотрел бегло. Там спрайты фиксированного размера 16 х 16.
В блиттере V9990 они там любого размера, причём с кучей режимов наложения.
Давайте сделаем НОВЫЙ РЕЖИМ без оглядки на предыдущие разработки.
Спасибо, уже имел опыт.
Пока достоинств не видно. Как будет выглядеть движок для R-TYPE? Там два слоя фона со скроллингом.
По программированию игр вам виднее. Как хранится уровень в памяти, я только предполагаю. Я видел только карту без монстров в виде копий экрана (ftp://ftp.worldofspectrum.org/pub/sinclair/games-maps/r/R-Type_4.png). Можно предположить, что там спрайты фона размером 8 х 64 точек. Для экономии многие спрайты имеют зеркальную копию.
В первом уровне около 13 экранов ZX SPECTRUM. Видимо есть карта уровня, где указаны номера спрайтов фона. При движении мы получаем карту экрана, где указаны спрайты, которые нужно изобразить и смещение левого спрайта относительно границы экрана.
Для нового режима мы можем загрузить те же спрайты в ОЗУ видеокарты, преобразовывая на ходу их 256-ти цветные. По номерам спрайтов карты экрана мы копируем соответствующие спрайты из ОЗУ спрайтов в ОЗУ экрана. Видеокарте при этом передаем адрес области спрайтов, размер спрайта, номер спрайта и координаты спрайтна на экране. Это нужно делать после прерывания. В результате получаем плавный скроллинг фона.
Поверх фона копируем движущиеся объекты таким же образом, как и спрайты фона. При этом не надо заботиться о клэшинге атрибутов, так как вокруг спрайтов используется прозрачный цвет. Объекты правильно перекрывают друг друга без всяких усилий со стороны программиста. Количество наложенных на одно место объектов не ограничено количеством слоев. Слой всего один. Работаем только с координатами на экране и номерами спрайтов. Нет необходимости в управлении портами и страницами. Чтобы устранить мелькания экрана, можно использовать два экрана, как в ZX SPECTRUM 128 К - на одном готовим изображение, а другой вы это время показываем.
Можно сразу закапывать. Палитра нужна, и минимум 12 бит.
Можно сделать и по 8 бит на каждый канал цвета, как в Speccy2010. Мы то будет работать с 8 битами на точку. Что это изменит ?
Ну что, есть в этом что-то разумное ?
zst
Видеокарте при этом передаем адрес области спрайтов, размер спрайта, номер спрайта и координаты спрайтна на экране.
Мне непонятно, как рассчитывать адрес начала спрайта номер такой-то, если будут области с разными размерами (банки) спрайтов. А если этих банков будет 100 ?
Идея alone c расположением всех картинок в одну шириной 256 мне нравится, т.к. удобно в редакторе рисовать сразу все спрайты.
Без палитры вообще жуть будет, тем более, ее на внутреннем ОЗУ Циклона сделать несложно.
Для нового режима мы можем загрузить те же спрайты в ОЗУ видеокарты, преобразовывая на ходу их 256-ти цветные. По номерам спрайтов карты экрана мы копируем соответствующие спрайты из ОЗУ спрайтов в ОЗУ экрана. Видеокарте при этом передаем адрес области спрайтов, размер спрайта, номер спрайта и координаты спрайтна на экране. Это нужно делать после прерывания. В результате получаем плавный скроллинг фона.
Тайлы там скорее всего 16х16. То есть для получения плавного скроллинга, надо каждый кадр пересчитывать данные для 204 спрайтов только для одного слоя фона. И это на Z80 3,5 МГц. Не сказал бы что это проще и быстрее, чем на тайловом VDP. Там для скроллинга надо каждый инт менять только TileXOffset, и раз в 16 кадров дорисовывать столбик из 10 тайлов. Процессорного времени это займет намного меньше.
zst
Мне непонятно, как рассчитывать адрес начала спрайта номер такой-то, если будут области с разными размерами (банки) спрайтов. А если этих банков будет 100 ?
Мы решили, что при переходе к области спрайтов с другими размерами мы сообщаем видеокарте размер спрайтов в этой области и начало области. Дальше ко всем спайтам в этой области можно обращаться по номеру. Адрес спрайта при копировании будет рассчитывать сама видеокарта.
Идея alone c расположением всех картинок в одну шириной 256 мне нравится, т.к. удобно в редакторе рисовать сразу все спрайты.
Так сделано в V9990, но это для фиксированного размера спрайтов 16 х 16 точек. Нам же это будет только ограничивать фантазию при разработке игр.
Без палитры вообще жуть будет, тем более, ее на внутреннем ОЗУ Циклона сделать несложно.
Вы, извиняюсь, не видите преимущества ОДНОВРЕМЕННОГО присутствия 256 цветов на экране по сравнению с оригинальными 15 с атрибутами или с 16 цветами из платры 256 ? Я думаю, что вы шутите.
А сделать палитру можно, но это не главное. У некоторых компьютеров всего 64 цвета, а какие рисунки получаются. Да и на 15 цветах тоже. Вам что надо для игры палитру BMP - по 6 битов на один канал ? Можно и такую сделать.
---------- Post added at 23:11 ---------- Previous post was at 22:59 ----------
Тайлы там скорее всего 16х16. То есть для получения плавного скроллинга, надо каждый кадр пересчитывать данные для 204 спрайтов только для одного слоя фона. И это на Z80 3,5 МГц.
Ну вы сгущаете краски. Нет такой проблемы, ведь в игре Z80 все успевает делать. А с новой видеокартой будет еще быстрее успевать. Там ведь не надо сдвигать каждый байт при движении экрана. Просто сдвигаем координаты каждого спрайта. Если бы такие простые вещи Z80 не успевал делать, то игр бы было очень мало.
Не сказал бы что это проще и быстрее, чем на тайловом VDP. Там для скроллинга надо каждый инт менять только TileXOffset, и раз в 16 кадров дорисовывать столбик из 10 тайлов. Процессорного времени это займет намного меньше.
Какая разница, если Z80 успеет за кадр вывести все координаты и номера спрайтов в видеокарту. При этом нет ограничений в скорости движений разных планов экрана. Кроме тайлов и спрайтов остается возможность наложить сверху на этот же экран цветные линии, как Элите.
shurik-ua
24.06.2013, 22:15
так как упор делается на спрайты вот полезная ссылка, так сказать на будущее -
вот например спрайты из игры BattleCity:
http://www.spriters-resource.com/nes/batcity/sheet/11756/
Ну вы сгущаете краски. Нет такой проблемы, ведь в игре Z80 все успевает делать.
Fps какой при этом?
Какая разница, если Z80 успеет за кадр вывести все координаты и номера спрайтов в видеокарту.
Не успеет он за кадр.
Вы, извиняюсь, не видите преимущества ОДНОВРЕМЕННОГО присутствия 256 цветов на экране по сравнению с оригинальными 15 с атрибутами или с 16 цветами из платры 256 ?
Чтобы наглядно представить нужность палитры, можно сделать следующее: в фотошопе (или подобном граф.редакторе) открыть полноцветную картинку, уменьшить для наглядности ее разрешение, и выбрать режим индексированных цветов - системную (фиксированные 256 цветов) палитру, а потом локальную, когда необходимые 256 оттенков именно для этого изображения будут выбраны из всей доступной палитры. Разница будет видна сразу. Что толку от этих 256 цветов, если в них может не оказаться и трети нужных в определенных условиях оттенков.
Чтобы наглядно представить нужность палитры, можно сделать следующее
Кроме этого есть еще fade in, fade out.
Fps какой при этом?
Не успеет он за кадр.
Надо кусок кода по подобной игре для расчетов.
zst
Мы решили, что при переходе к области спрайтов с другими размерами мы сообщаем видеокарте размер спрайтов в этой области и начало области.
Т.е. держать в ОЗУ Спека таблицу начал областей спрайтов. Что не есть хорошо.
Так сделано в V9990, но это для фиксированного размера спрайтов 16 х 16 точек.
Сочетаний любых размеров, в том-то и дело.
Вы, извиняюсь, не видите преимущества ОДНОВРЕМЕННОГО присутствия 256 цветов на экране по сравнению с оригинальными 15 с атрибутами или с 16 цветами из платры 256 ? Я думаю, что вы шутите.
С палитрами вы не сталкивались, ясно. Даже 16-цветная палитра 5+5+5 выглядит лучше 256 цветов. Достаточно посмотреть на невыразительные цвета Sam Coupe.
На нормальных видеоконтроллерах спрайты лежат в виде битмапа шириной 512 и не требуют никакого умножения. Тслабсу это было внедрено в мосх ещё два года назад, он понял сразу.
Хе. Не сразу, но плюсанул. Алсо, в таком формате очень удобно использовать прямоугольную ДМА, скроллеры, рисовать графику опять же художникам удобно. Почему же в большинстве игр на пэцэ спрайты лежат на большом прямоугольном битмапе?..
Мы делаем максимально быстрый и удобный вариант для программирования игр. Спрайты хранятся в ОЗУ видеокарты. Никаких 3D и т.п. наворотов. Цветов 256. Вы нам подсказывайте как лучше в этих рамках.
Вы определитесь какие у вас рамки.
Для нищебродских систем типа пентевы концепт движка тсконфы если не оптимальный, то уж один из самых оптимальных. Это уровень амиги/сеги.
А вот для вундервафли с 56мгц срам шинами (почему кстати не 100?) - это полное убожество. Для такого размаха можно сделать в 10 раз больше наворотов. Со 100500 слоями, альфой, зумскейлами, чем угодно - я уже писал. Если продумать концепт, кодать под это будеть не сложнее создания презентации в паверпойнте.
А могу дать совет, который мне помог: сделай техническое демо для "сырого" дизайна на каком нибудь этапе его написания. Сразу поймешь, что лучше, а что хуже. Одно дело - теоретизировать, другое - влезть в шкуру кодера.
Обе системы уже реализованы и имеют софт.
Признавайтесь, кто перепрошил Алония? :rolleyes:
Почитал у TSLABA - кто такое ослит ?
У тслабса. Джек Воробей.
У меня МИНИМУМ того, что нужно для комофтного кодинга игрух со спрайтовыми наворотами 50фпс. Реализовано на железе из говна и палок. 7мгц 16 бит ДРАМ, ВЕСЬ спектрум в 2800 ЛЕ, асекс1.
Брать ц2 для дизайна и делать на нем унылое не пойми что - как минимум странно.
Добавляется совместимость с демами Pentagon-128.
А позвольте поинтересоваться, как будут отображаться мультиколорные фефекты?
Можно сразу закапывать. Палитра нужна, и минимум 12 бит.
Плюсую и перепощиваю. Без палитры нет НИ ОДНОГО движка 2Д графики. Или найди пруф противоположного.
И да, палитра нужна не для 15ц режима, но и ОБЯЗАТЕЛЬНО для 255ц.
Т.е. держать в ОЗУ Спека таблицу начал областей спрайтов. Что не есть хорошо.
Там 5 байт на одну область спрайтов.
3 - адрес начала области
2 - ширина и высота спрайтов в области
Очень много наверно...
Еще. Одним из весьма удачных дизайнов считаю V6Z80P.
И да, я понял, что делается не спрайтовый процессор, а блиттер. Так вот - определитесь с конечной целью, что вы хотите видеть на экране. Пока что я вижу обычный 2Д двиг, реализованный ОЧЕНЬ странно. У блиттеров другие применения.
Fps какой при этом?
Не успеет он за кадр.
Если вы говорите, что Z80 не успеет передать видеокарте за один фрейм все кооординаты и номера спрайтов фона, придется для фона сделать отдельный слой. Тогда его не перестраивать каждый раз, а добавлять новые спрайты с края экрана. Какие варианты управления тут есть? Можно сделать аппаратное копирование прямоугольной области в ОЗУ экрана для сдвига всего или части экрана на нужное количество пикселов. На частоте 56 или 84 МГц это делается быстро и небольшое количество данных от Z80 - он успеет за 1 фрейм дать команду сдвига.
И да, я понял, что делается не спрайтовый процессор, а блиттер. Так вот - определитесь с конечной целью, что вы хотите видеть на экране. Пока что я вижу обычный 2Д двиг, реализованный ОЧЕНЬ странно. У блиттеров другие применения.
Основная цель - сделать быстрый движок без 3D, и т.п. наворотов. Графика должна остаться похожей на ZX SPECTRUM. Но без клэшинга атрибутов, с плавным скроллингом отдельных областей экрана, а не только всего.
Также для программиста должна быть возможность выбрать размера спрайтов и даже несколько типоразмеров в игре. Управление спрайтами с помощью координат на экране и номеру спрайта. Минимум манипуляций с портами, страницами. Мы должны про них забыть. Максимум удобства и скорости для программиста.
Изображения должны накладываться друг на друга на один слой. Для ускорения скроллинга фона без постонного перестроения фона с помощью спрайтов добавить слой фона.
Спасибо насчет палитры - убедили, не помешает. Тем более ее легко поместить в самой FPGA. Думаю, вы поможете в ее реализации. Я сделаю на каждом канале RGB по 8 бит, как в SPECCY2010.
FPGA используется в минимально необходимых пределах - много ног, большая скорость, PLL, аппаратное умножение, буфер FIFO в ОЗУ для передачи команд из Z80. Нет цели нагрузить ее по максимуму.
Остальные режимы возможны, но ПОТОМ.
Палитру предлагаю 18 бит, по 6 на компоненту. Штуки памяти в ц2 как раз 18-битные.
ОК, пробую представить, как это все работает. Я так понимаю, используется дабл буфферинг? Синхронно с началом фрейма блиттер начинает строить изображение в теневой экранке, обрабатывая очередь объектов, которые надо вывести и копируя их в экранку из ОЗУ с графическими объектами?
Я так понимаю, используется дабл буфферинг?
Да.
Синхронно с началом фрейма блиттер начинает строить изображение в теневой экранке, обрабатывая очередь объектов, которые надо вывести и копируя их в экранку из ОЗУ с графическими объектами?
Верно.
Видяха должна эмулировать основное видео спека?
Как будут эмулироваться мультиколорные эффекты?
Видяха должна эмулировать основное видео спека?
Да,
это есть в спецификации автора (первый пост).
Про мультиколор, думаю, автор расскажет.
Ну, что такое "спецификация", это советую погуглить. Первый псто по этим признакам явно не детектится.
А насчет мультиколора, дада, ОЧЕНЬ интересно.
Мультиколор не нужен. Говорю как специалист по мультиколорам. Это изврат и онанизм. Да.
introspec
25.06.2013, 20:10
Мультиколор не нужен. Говорю как специалист по мультиколорам. Это изврат и онанизм. Да.
По-моему нужно ещё поредактировать немножко :)
И мастурдрочество.
Так же как POP HL: LDI и прочие вольфы.
introspec
25.06.2013, 22:41
И животноводство!
alone
Мультиколор не нужен.
Даже аппаратный ?
Alex Rider
26.06.2013, 01:40
А что мешает хранить в карточке спрайты последовательно вместе с их размерами, находить нужный спрайт по номеру независимо от его размера и размера предыдущих спрайтов и отказаться от команд установки размеров при выводе на экран? Можно использовать в карточке таблицу смещений загруженных спрайтов для ускорения поиска. Для меня это был бы самый лучший вариант. Плюс, сделать команды для вывода окна спрайта.
Коль ужо у вас блиттер, дык сделайте же дисплей лист сто раз задолбался повторять.
Код на микроязыке парсера, который он обрабатывает, начиная с начала фрейма, выгребает последовательно параметры каждого описанного там объекта, пинает соответствующий этому объекту обработчик, передавая ему параметры.
А чтоб милому слоупочному зетнику было удобно апдейтить массивы обжектов, располагать их по удобным адресам, а в конце массива команда а-ля джамп на следующий.
Блин, не делайте еще одно унылое поделие. Сделайте НОРМАЛЬНУЮ архитектуру.
---------- Post added at 04:28 ---------- Previous post was at 04:26 ----------
А, все время забываю спросить - сорцы изделия будут доступны?
Для изображения (копирования на экран) части спрайта возле границ экрана предназначены следующие параметры:
4003 - начальная копируемая строка спрайта (обычно 0)
4004 - конечная копируемая строка спрайта (обычно 15)
...
Вопрос: управление будет вестись по заданным адресам в пространстве памяти Z80? Т.е. т.н. экранная область ZX48 (начиная с #4000)? Хотелось бы уточнить этот момент, логично перехватывать обращения в новом режиме к карте не по физическим адресам в пространстве ZX48 (#4000-#5aff), а именно обращения к видеостраницам (5 и 7) причем с завязкой на бит 3 порта #7ffd. Т.е. чтоб при поднятом в 1 этом бите управление видеокартой велось бы через включенную страницу 7, чтоб видео память была так сказать теневой со стороны софта. А при опущенном в 0 бите 3 #7ffd управление велось бы через 5ю страницу с проекцией на #4000. таким образом можно высвободить все пространство 64 кб под код. Что не маловажно при написании программ на том же SDCC, язык C не предусматривает фрагментацию кода.
Вольфы работают без извратов. Можно даже под ось переделать.
---------- Post added at 13:18 ---------- Previous post was at 13:14 ----------
Даже аппаратный ?
Даже аппаратный. Я опубликовал схему аппаратного мультиколора в 2002 году и с тех пор только я и написал под неё софт. Один. Который и без неё прекрасно работает. Называется Hexagonal Filler.
Поэтому позже я доработал аппаратный мультиколор в цвет на точку а-ля АТМ.
shurik-ua
26.06.2013, 14:24
у меня была идея сделать сигнал наподобие IORQGE - только вместо IORQ завести MREQ, вот какие из этого возникают преимущества:
1.в начале включили какой то бит в каком то порту - после чего чтение опкодов и данных происходит по прежнему из памяти зетника, а вот вся запись в память ловится видюхой, и при этом в основную память ничего не пишется, отсюда вытекает что видеопамять можно нарезать по 64к.
2. вся память зетника отведена под код - нет видеобуфера в основной памяти.
можно сделать даже 2 бита под это со всеми комбинациями:
00 - резерв (либо нет записи вообще)
01 - запись только в видеопамять
10 - запись только в основную память (после сброса)
11 - пишем и туда и сюда.
короче маска сигнала MREQ получается ).
Что не маловажно при написании программ на том же SDCC, язык C не предусматривает фрагментацию кода.
а вот iar вроде бы имел поддержку страниц...
shurik-ua, V9990 спокойно ловит линейные и прямоугольные блоки данных по OUTI, причём с разными режимами наложения. Удобнее некуда.
---------- Post added at 13:28 ---------- Previous post was at 13:27 ----------
Если не будет конструктивных предложений и реально созданной команды разработчиков софта и железа (для новодела просто необходим один стандарт) все просто переедет в концепцию или останется невостребованным пылиться на полке
Вступай в NedoPC :)
а вот iar вроде бы имел поддержку страниц...
это хорошо, но я не совсем о поддержке страниц... а о фрагментации кода до #4000 и после, какой-то из современных компиляторов это умеет? если да, то вопрос отпадает.
С их стороны никаких предложений не было, а я не напрашиваюсь, т.к. даже сам технологически их обхожу.
Уже сделал прозрачную работу с TAP и TRD на винте и сетевую карту? :)
Лучше работать вместе. Новый софт должен работать на всём новом железе, а для этого оно должно быть совместимо.
о фрагментации кода до #4000 и после
До #4000 ПЗУ и отключать его не все клоны умеют.
Мне и прозрачной работы с SD с головой хватает
Так в ZX Evo она как раз прозрачная. И на чтение, и на запись. И не только #3d13. Автор Савелий.
Сетку на W5300 и расширитель уже давно можно прикрутить.
Под ZXINET уже есть софт в виде кросс-отладчика. Автор DimkaM. http://dlcorp.nedopc.com/viewtopic.php?f=42&t=1201
Он же пишет FTP и IRC под ту же карту.
Согласен, но без гонки или конкурсов все станет и потеряет здравый смысл.
Всё встанет, если каждый будет делать своё ни с чем не совместимое и растащит оставшихся программистов. Тогда платформе придёт конец.
---------- Post added at 14:24 ---------- Previous post was at 14:22 ----------
До #4000 ПЗУ и отключать его не все клоны умеют.
С ZX-BUS - все.
До #4000 ПЗУ и отключать его не все клоны умеют.
не все... но из имеющих шину NemoBUS большинство - П1.4, П2.2, Скорп, Кай, Феникс, Профи...
у меня была идея сделать сигнал наподобие IORQGE - только вместо IORQ завести MREQ
Посмотри на ширину ~WR в цикле ~MREQ.
---------- Post added at 15:51 ---------- Previous post was at 15:50 ----------
Так в ZX Evo она как раз прозрачная. И на чтение, и на запись. И не только #3d13. Автор Савелий.
Слушай кодер, где тебя научили так врать?
Там же ПЗУ трдоса перепахано на британский флаг. Какая "прозрачность"?
Старый софт работает с карточкой без переделок. Какая версия TR-DOS - программам пофиг, потому что они работают через известные точки.
И вообще, заруби себе на носу: заявы от кидал не принимаются. Когда сделаешь обещанное, тогда и сможешь пальцы гнуть.
Всё встанет, если каждый будет делать своё ни с чем не совместимое и растащит оставшихся программистов. Тогда платформе придёт конец.
Кодер, плати кодерам зарплату, тогда они будут кодать под то, что ты хочешь. А нет - так каждый будет кодать под то, что ему мило, и ты этого не изменишь.
---------- Post added at 16:01 ---------- Previous post was at 15:58 ----------
И вообще, заруби себе на носу: заявы от кидал не принимаются. Когда сделаешь обещанное, тогда и сможешь пальцы гнуть.
Ты опять таблеток объелся?
Я тебе предложил ГУМАНИТАРНУЮ ПОМОЩЬ, на нищей, унылой недоконфе. А твой Властелин LVD выпилил меня из SVN.
Иди прямо, прямо, там будет лес.
---------- Post added at 16:03 ---------- Previous post was at 16:01 ----------
А кстати, пофиксал быдлокодец изза которого у ЛВД не работали тайлы. Можешь запустить на своей, пожалованной с барского плеча ревА и пофапать.
Я тебе предложил ГУМАНИТАРНУЮ ПОМОЩЬ, на нищей, унылой недоконфе.
Вот и впили свою урезанную конфу в главный проект.
А твой Властелин LVD выпилил меня из SVN.
Для выполнения обещанного доступ к SVN не нужен. У тебя есть текущий транк (пока ещё текущий).
А кстати, пофиксал быдлокодец изза которого у ЛВД не работали тайлы.
Молодец, что имеешь самокритику.
Можешь запустить на своей, пожалованной с барского плеча ревА и пофапать.
Лично мне неинтересно прошивать неполноценную конфигурацию. Тут кто-то ещё бродил, у кого не работало - попроси его.
Впиливай сам. Верилог знаешь, сорцы где лежат - тоже.
----
Транк там будет "текущим" теперь уже по жизни. С чем и поздравляю.
----
Не прошивай. Продолжай изображать клоуна во всех топиках.
Для выполнения обещанного доступ к SVN не нужен. У тебя есть текущий транк (пока ещё текущий).
ваще красиво, продолжайте. точка невозврата скоро пройдецца...
Пример циклического сдвига экрана на 1 пиксел для игр типа R-TYPE с использованием новой видеокарты.
В примере предполагается, что карта уровня игры располагается в памяти и представляет из себя таблицу из 256 столбцов и 15 строк. В каждой ячейке таблицы лежит код спрайта. Для оценки скорости заполнения экрана размеры спрайтов можно задать 16х16. Экран 320x240 точек по 256 цветов.
Ничего не попутал с пожеланиями?
EGA и быстрая видеокарта это взаимоисключающие параграфы.
LD (IY+1),SET_LN ; передаем номер спрайта видеокарте
LD (IY+2),A ; при этом видеокарта копирует спрайт !
Т.е. сигнал к копированию, имеено установка младшего байта номера спрайта ?
(было "установка Y спрайта")
Т.е. сигнал к копированию, имеено установка младшего байта номера спрайта ?
(было "установка Y спрайта")
В ходе написания примера работы с видеокартой уточняются названия команд и т.п. Также оказалось удобнее по одному адресу записывать номер команды, а по другому - параметр. Потом FPGA сможет записывать оба байта одним словом в буфер FIFO.
Скоро доработаю пример от явных ошибок. Надо будет оценить скорость формирования одного экрана на реальном примере.
есть описание режимов EGA и VGA, которые могут быть приняты для разработки новой видеокарты.
Бред
Но если она понадобится, то проще то здесь найти.
Еще больше бред, тебе раздел уже сделали и всерано хламье по всем веткам тыкать продалжаеш
Отписался от топика. Во избежание.
Прочти книжку. Она и тебе понадобится, может быть не сейчас, но потом. ... Просто книжка может быть понадобится, и проще найти здесь будет, всего-то прочитав тему.
Добавил ссылку на книгу в первый пост - кому-нибудь пригодится.
Обновил команды для связи с видеокартой. Добавил ссылку в первый пост.
Дописал пример скроллинга сразу для экрана 320х240 точек 256 цветов. Добавил ссылку на пример в первый пост. Теперь надо подсчитать скорость выполнения одного обновления экрана с учетом процедуры скроллинга. Кто умеет быстро считать такты в программах ?
еперь надо подсчитать скорость выполнения одного обновления экрана с учетом процедуры скроллинга.
Может решить этот вопрос кардинально.
(в рамкам блитера)
Пусть ПЛИС всё это делает, по команде "нарисовать тайловую карту" ?
Может решить этот вопрос кардинально.
(в рамкам блитера)
Пусть ПЛИС всё это делает, по команде "нарисовать тайловую карту" ?
То есть копию карты загружать в видеокарту в виде таблицы с номерами спрайтов ?
Вроде тогда будет все хорошо, но игры будут однообразными с плавным, но ОДНОВРЕМЕННЫМ движением ВСЕГО экрана.
А программно у нас будет свобода выбора что, куда и с какой скоростью двигать или не двигать !
Мы можем написать для каждого участка свой алгоритм и шаг движения фона.
Вывел формулу для ориентировочного подсчета времени выполнения примера:
T=(NX+1)*(NY*115+300)+700,
где T - общее кол-во тактов Z80 на отрисовку фона,
NX - число спрайтов по-горизонтали
NY - число спрайтов по-вертикали.
Для режима 256х192 и спрайтов 16х16 T=17*(12*115+300)+700=29260 тактов
Для режима 320х240 и спрайтов 16х16 T=21*(15*115+300)+700=43225 тактов
В одном кадре 312*224=69888 тактов Z80.
Много это или мало? Программа отображения фона написана универсальной с произвольными размерами спрайтов. Ее можно оптимизировать по скорости, особенно для режима 256x192 точек. Кроме этого, мало в каких играх используется скроллинг всего экрана - есть еще и статичные участки.
Еще один аргумент в пользу однослойного строения экрана. Если делать второй слой для подвижных мелких объектов, то для их движения нужно будет сохранять координаты и размеры их местоположения на экране и каждый раз стирать их на старом месте. Только потом изображать на новом. А это требует дополнительного времени. Если же мы каждый кадр фон отрисовываем заново - он автоматически стирает эти мелкие объекты на старом месте. Останется только после отрисовки фона изобразить их поверх фона на новом месте.
То есть копию карты загружать в видеокарту в виде таблицы с номерами спрайтов ?
Да.
2 байта на тайл (спрайт).
Вроде тогда будет все хорошо, но игры будут однообразными с плавным, но ОДНОВРЕМЕННЫМ движением ВСЕГО экрана.
Неверно.
Никто ведь не заставляет программера юзать именно встроенную функцию построения тайловой карты !
Если чел хочет, что-либо иное, пожайлуйста, пусть составляет фон из обычных спрайтов КАК ему угодно (используя ваш же асм пример, как заготовку). Но это будет (не)много медленее, чем юзать встроенную ф-цию.
Т.е. мы хотим предоставить _быстрый_ типовой вариант построения тайловой карты, дальше уже сам кодер пусть решает, использовать его или нет.
---------- Post added at 15:59 ---------- Previous post was at 15:47 ----------
Для режима 320х240 и спрайтов 16х16 T=43225 тактов
Вот я и подумам про необходимость "быстрой команды ПЛИС"...
---------- Post added at 16:04 ---------- Previous post was at 15:59 ----------
Кроме этого, мало в каких играх используется скроллинг всего экрана
Это личное мнение.
Думаю, что нужно рассчитывать именно на скролл всего экрана,
ведь блитер будет позволять по скорости...
Если процедуру вывода столбика спрайтов развернуть из цикла в последовательность прямым указанием координат Y, то формула изменится:
Cтарая формула:
T=(NX+1)*(NY*115+300)+700,
где T - общее кол-во тактов Z80 на отрисовку фона,
NX - число спрайтов по-горизонтали
NY - число спрайтов по-вертикали.
Для режима 256х192 и спрайтов 16х16 T=17*(12*115+300)+700=29260 тактов
Для режима 320х240 и спрайтов 16х16 T=21*(15*115+300)+700=43225 тактов
В одном кадре 312*224=69888 тактов Z80.
Формула с первым ускорением:
T=(NX+1)*(NY*87+300)+700,
Для режима 256х192 и спрайтов 16х16 T=17*(12*87+300)+700=23548 тактов
Для режима 320х240 и спрайтов 16х16 T=21*(15*87+300)+700=34405 тактов
Следующим шагом может быть автоинкремент координат по X или Y по размерам спрайта.
При автоинкременте по Y формула будет такой:
T=(NX+1)*(NY*49+338)+700
Для режима 256х192 и спрайтов 16х16 T=17*(12*49+338)+700=16442 тактов
Для режима 320х240 и спрайтов 16х16 T=21*(15*49+338)+700=23233 тактов
Добавил в интерфейс с видеокартой команды:
ПЕЧАТЬ СПРАЙТА НА ЭКРАН С АВТОИНКРЕМЕНТОМ
LD (IY+1), PRINT_AUTOINC_X ; печать спрайта с автоинкрементом координаты X на ширину спрайта
LD (IY+2), число ; младший байт номера спрайта
LD (IY+1), PRINT_AUTOINC_Y ; печать спрайта с автоинкрементом координаты Y на высоту спрайта
LD (IY+2), число ; младший байт номера спрайта
Данные команды позволят быстро и легко заполнять фон спрайтами. PRINT_AUTOINC_X можно будет использовать для печати текста.
Получается, что у нас теперь есть что-то, напоминающее курсор. Печать ведется в позицию курсора, а затем курсор перемещается дальше. Возможно понадобятся команды перемещения курсора в разных направлениях кратно размерам спрайта...
Теперь давайте продумаем, как печатать спрайты на границах экрана? Как сделать удобный способ с обрезанием спрайта вне границ экрана ? Также предусмотреть способ произвольно выбирать окно, в котором мы будем печатать спрайты.
Может есть смысл, вообще отказаться от установки начальных/конечных рядов/столбцов спрайта ?
Т.е. пусть это высчитывает плис, по координатам и размерам спрайта,
учитывая "окно отсечения".
Ну и добавить команду установки "окна отсечения".
Если, спрайт частично выходит за границы "окна отсечения", то плис сама просчитывает какой кусок спрайта входит в "окно отсечения" и рисует этот кусок.
Может есть смысл, вообще отказаться от установки начальных/конечных рядов/столбцов спрайта ?
Пока оставим, ведь иногда нужно изобразить часть спрайта. Например, в игре FLYING SHARK танки могут выезжать из под укрытий.
Т.е. пусть это высчитывает плис, по координатам и размерам спрайта,
учитывая "окно отсечения".
Ну и добавить команду установки "окна отсечения".
Если, спрайт частично выходит за границы "окна отсечения", то плис сама просчитывает какой кусок спрайта входит в "окно отсечения" и рисует этот кусок.
Согласен, это облегчит программирование, но как указать видеокарте координаты за рабочим окном или всем экраном? Также хорошо бы посмотреть типовой фрагмент кода для Z80 при уходе движущегося объекта за границы экрана. Тогда уже это можно будет привязать к ПЛИС. Ей то это будет не трудно обрезать.
Нужно выбрать в каком виде нужно задавать координаты. Если крайний левый пиксел экрана имеет значение 0, а для режими 320х240, координата задается двумя байтами. А объект пытается выехать на 1 пиксел за левую границу. В каком формате программе будет указывать эти отрицательные координаты? Ну и как их ПЛИС проще обрабатывать тоже нужно учесть.
Для ПЛИС будет удобнее, чтобы координаты шли так: FFFE, FFFF, 0000, 0001... для режима 320х240
Для режима 256х192: FE, FF, 00, 01, но для отрицательных координат все-равно придется задавать координаты двумя байтами?
ПЛИС может загрузить координату FFFE в счетчик копирования, а затем циклически увеличивать. Если координаты не входят в диапазон 0-320, то при копировании не записывать данные в ОЗУ экрана.
На координату Y тоже надо будет два байта..
Новая версия примера с учетом новых команд печати с автоинкрементом по X и автоматической обрезкой спрайтов на границах экрана.
Примерная длительность заполнения фона при скроллинге для экрана размером 320х240 точек = 18973 такта Z80 из 69888 в кадре (27%).
Во втором варианте заменил индексную адресацию в командах печати спрайта на более быструю. Время уменьшилось до 13303 тактов (19%). И это еще не предел. Таким образом, по этому способу у нас получилось достаточно быстрое заполнение фона плюс гибкость в выборе способа реализации скроллинга.
Основная цель - сделать быстрый движок без 3D, и т.п. наворотов. Графика должна остаться похожей на ZX SPECTRUM. Но без клэшинга атрибутов, с плавным скроллингом отдельных областей экрана, а не только всего.
Это уже Амига будет. В чем похожесть? В разрешении экрана? Так у Nintendo DS тоже 256х192.
ZX SPECTRUM = клэшинг
В чем похожесть? В разрешении экрана?
Да, в размере точек,а также клавиатура, джойстик, ПЗУ, TR-DOS, YAMAHA, Z80, объем памяти. Мы немного усовершенствуем.
ZX SPECTRUM = клэшинг
Браво! С-64 и MSX = ZX SPECTRUM!
Хотите много игр - делайте редактор игр, а архитектура блиттера тут вторична.
Недопраграммистов больше чем программистов.
Крутой программист может круто запрограмить, но как правило несостоятелен как геймдизайнер. А геймдизанер вполне может освоить создание игры на Бейсико подобном языке или в визуальном редакторе.
Половина, если не больше выпускаемых ныне игр делаются в редакторе игр, либо в его подобие собственного производства.
---------- Post added at 21:21 ---------- Previous post was at 21:19 ----------
Браво! С-64 и MSX = ZX SPECTRUM!
Посмотри в гугле визуальные мемы на тему Спектрума.
Там везде обыгрывается клэшинг. Технически он есть на многих платформах, но визитной карточкой стал именно для Спектрума.
Крутой программист может круто запрограмить, но как правило несостоятелен как геймдизайнер. А геймдизанер вполне может освоить создание игры на Бейсико подобном языке или в визуальном редакторе.
Вот видите. Вся прелесть в ZX SPECTRUM - простые устройства ввода типа клавиатуры и мыши, магнитофона, звука. Но - очень сложный экран, который был разработан для вывода текста. Поэтому хорошие игры могли написать несколько человек вместе с крутым программером. Один человек, не мог реализовать свою идею. Сейчас, когда коммерческой выгоды в написании игр нет - крутых программеров не заманишь на проект игры. А обычный человек, если у него есть энтузиазм - сможет многое.
А обычный человек, если у него есть энтузиазм - сможет многое.
Обычному человеку сегодня 30-35 лет, Если он за это время не освоил Ассемблер, то и дальше этого скорее всего не случится.
Поэтому и важно средство разработки, позволяющее максимально абстрагироваться от всех технических заморочек и сосредоточится на самой игре.
---------- Post added at 22:55 ---------- Previous post was at 22:51 ----------
И вот в этом контексте совершенно не важно как там ваш блиттер работает, потому что для юзера будут существовать в виде абстракций "спрайт", "область скролирования" и т.п.
Даже если все спрайты технически будут 16х16 это не страшно, редактор из них склеит спрайт нужного размера.
Согласен, это облегчит программирование, но как указать видеокарте координаты за рабочим окном или всем экраном?
Да,
ввести отрицательные координаты.
(координаты спрайта X и Y 2-байтовые)
Нужно выбрать в каком виде нужно задавать координаты. Если крайний левый пиксел экрана имеет значение 0, а для режими 320х240, координата задается двумя байтами. А объект пытается выехать на 1 пиксел за левую границу. В каком формате программе будет указывать эти отрицательные координаты?
тогда X координата объекта, будет -1
(0xFFFF)
---------- Post added at 18:47 ---------- Previous post was at 18:43 ----------
Для ПЛИС будет удобнее, чтобы координаты шли так: FFFE, FFFF, 0000, 0001...
Да.
(так и z80 считает.)
---------- Post added at 18:49 ---------- Previous post was at 18:48 ----------
Для режима 256х192: FE, FF, 00, 01, но для отрицательных координат все-равно придется задавать координаты двумя байтами?
Да, двумя байтами.
---------- Post added at 19:04 ---------- Previous post was at 18:49 ----------
ПЛИС может загрузить координату FFFE в счетчик копирования, а затем циклически увеличивать. Если координаты не входят в диапазон 0-320, то при копировании не записывать данные в ОЗУ экрана.
Да, вполне рабочий алгоритм.
Только в идеале, хотелось, чтобы пропущенные точки (байты),
не попадающие в окно,
даже не читались из спрайт-памяти (для скорости).
Добавил в список команд:
КОМАНДЫ УПРАВЛЕНИЯ КУРСОРОМ. РАЗМЕР КУРСОРА РАВЕН ТЕКУЩЕМУ РАЗМЕРУ СПРАЙТА.
LD (IY+1), CURSOR_RESTORE_X ; восcтановление координаты X
LD (IY+2), число ; (обычно 1)
LD (IY+1), CURSOR_RESTORE_Y ; восстановление координаты Y
LD (IY+2), число ; (обычно 1)
LD (IY+1), CURSOR_LEFT ; курсор влево
LD (IY+2), число ; (обычно 1)
LD (IY+1), CURSOR_RIGHT ; курсор вправо
LD (IY+2), число ; (обычно 1)
LD (IY+1), CURSOR_DOWN ; курсор вниз
LD (IY+2), число ; (обычно 1)
LD (IY+1), CURSOR_UP ; курсор вверх
LD (IY+2), число ; (обычно 1)
Эти команды можно будет использовать при заполнении фона и печати текста. После печати спрайтов в строке команда CURSOR_RESTORE_X восстановит координату X первого спрайта в строке. После этого для перехода к началу следующей строки можно использовать команду CURSOR_DOWN,
---------- Post added at 14:15 ---------- Previous post was at 14:09 ----------
Обычному человеку сегодня 30-35 лет, Если он за это время не освоил Ассемблер, то и дальше этого скорее всего не случится.
Поэтому и важно средство разработки, позволяющее максимально абстрагироваться от всех технических заморочек и сосредоточится на самой игре.
Мы делаем простые команды для работы с графикой. Для динамичных игр для ZX SPECTRUM скорее всего ассемблер потребуется. Для простых игр среда разработки может быть полезна.
---------- Post added at 14:17 ---------- Previous post was at 14:15 ----------
Да, вполне рабочий алгоритм.
Только в идеале, хотелось, чтобы пропущенные точки (байты),
не попадающие в окно, даже не читались из спрайт-памяти (для скорости).
Это не так просто - надо думать.
sergio78
10.07.2013, 17:17
Поэтому и важно средство разработки, позволяющее максимально абстрагироваться от всех технических заморочек и сосредоточится на самой игре
А разве кто то, что то ещё будет писать, особенно под эту видеокарту?:v2_dizzy_tired2: по моему, главный смысл всех подобных начинаний, это вид спорта по изготовлению какой то железки, которой просто раньше не было.:v2_wink2:
А разве кто то, что то ещё будет писать, особенно под эту видеокарту?
Под карту нет.
А под среду разработки, которая автоматом экспортирует игру в HTML5, в которую можно будет играть хоть на айфоне, хоть на андроиде, хоть вконтакте - вполне возможно.
А разве кто то, что то ещё будет писать, особенно под эту видеокарту?:v2_dizzy_tired2: по моему, главный смысл всех подобных начинаний, это вид спорта по изготовлению какой то железки, которой просто раньше не было.:v2_wink2:
Да! Проработанные команды можно будет интегрировать также и в компьютеры на базе FPGA: ZXEvolution, ReVerSe и Speccy2010. Для других клонов с ZX-BUS - релизовать на отдельной видеокарте.
alone, кто на ваш взляд смог бы написать игру для новой видеокарты ?
Может есть смысл, вообще отказаться от установки начальных/конечных рядов/столбцов спрайта ?
Убрал команды задания границ спрайта. Добавил команды рисования точки:
КОМАНДЫ ДЛЯ РИСОВАНИЯ ТОЧКИ
ДЛЯ РИСОВАНИЯ ТОЧКИ ИСПОЛЬЗУЮТСЯ ТЕКУЩИЕ КООРДИНАТЫ КУРСОРА НА ЭКРАНЕ И ЦВЕТ INK. ПАРАМЕТР КОМАНДЫ PLOT МОЖЕТ СМЕЩАТЬ КУРСОР ПЕРЕД РИСОВАНИЕМ ТОЧКИ.
LD (IY+1), INK
LD (IY+2), число ; цвет, которым будут рисоваться точки
LD (IY+1), PLOT ; рисовать точку, заданную координатами курсора
LD (IY+2), СМЕЩЕНИЕ
ПАРАМЕТР СМЕЩЕНИЕ ПЕРЕД РИСОВАНИЕМ ТОЧКИ ИЗМЕНЯЕТ ПОЛОЖЕНИЕ КУРСОРА:
биты D1 и D0 задают смещение курсора по-вертикали (координата Y):
00 - без смещения, 01 - на одну точку вниз, 11 - на одну точку вверх.
биты D3 и D2 задают смещение по-горизонтали (координата X):
00 - без смещения, 01 - на одну точку вправо, 11 - на одну точку влево.
Таким образом, перед рисованием точки можно изменить координаты курсора в восьми направлениях. После этого новые координаты курсора становятся текущими.
ДАВАЙТЕ ПОДВЕДЕМ ИТОГИ ПРОЕКТИРОВАНИЯ ВИДЕОКАРТЫ "METEOR-2013" :
Параметры новых режимов - 256х192 и 320х240 точек, 256 цветов с палитрой. Два экрана - теневой и отображаемый.
Палитра - 3х6 бит (как BMP 256), разместить во внутренней памяти FPGA 256 * 18 бит.
ЦАП - по 8 бит на каналы R,G,B (как в SPECCY2010).
Система команд для управления видеокартой - разработана.
Для рисования используем только координаты на экране и номер спрайта, никаких портов.
Способ рисования - печать спрайтов с помощью блиттера и линиями по точкам. Спрайты лежат в памяти видеокарты.
Способ включения и выключения новых режимов - через адрес первого атрибута стандартного экрана, подробнее описано в списке команд видеокарты (http://www.zx.pk.ru/showpost.php?p=610738&postcount=50).
Пример на ассемблере для заполнения фона игры - разработан.
Скорость заполения фона спрайтами - прикинута (для режима 320х240 время заполнения ~ 1/5 времени отображения кадра).
Микросхемы - выбраны (FPGA EP2C5Q208, 2 шт SRAM 256К * 16бит, конфПЗУ, стабилизаторы +3.3V и +1.25V).
Видеовыход - на плате разъем VGA с выходом на корпус. SCART - через гребенки или VGA разъем, выбор джамперами.
Тактовый сигнал - 14 МГц с разъема ZX-BUS с умножением внутри FPGA до 14*7=98 МГц.
Предусмотреть на плате возможность установки отдельного генератора на 98 МГц.
Детали для опытного образца - приобретены.
ТЕПЕРЬ ПЕРЕЧИСЛИМ, ЧТО ОСТАЛОСЬ СДЕЛАТЬ:
Уточнить габариты платы - предлагаю расстояние от края ZX-BUS до торца платы (задней стенки корпуса) расстояние 47,62 мм (как у NeoGS).
Развести и заказать плату для опытного образца.
Где разместить джамперы выбора режимов видеокарты - предлагаю угловые DIP-SWITCH-и на плате возле VGA разъема.
Выбрать язык проектирования прошивки FPGA - предлагаю Verilog. За основу предлагаю взять прошивку видеокарты ZEKа http://zx.pk.ru/showpost.php?p=184179&postcount=29), если он не против (там есть и режим АТМ).
Написать прошивку для FPGA.
Выбрать количество игр и типы для тестирования видеокарты. Предлагаю 10 штук разных жанров.
На основе чего разрабатывать игры. Предлагаю избегать делать клонов с других платформ.
Одна из возможных игр - "FUTURE TANK" (http://www.zx.pk.ru/showpost.php?p=350072&postcount=64).
http://s019.radikal.ru/i643/1307/87/91cccb79b336t.jpg (http://s019.radikal.ru/i643/1307/87/91cccb79b336.jpg)
Основу заставки к игре нарисовал Slesar. Вместо землетрясения можно использовать падение метеорита.
Выбрать среду разработки игр, ассемблер и эмулятор (пригодилась бы помощь от ZXMAK2).
Сделать рабочий комплект с настройкой для общего использования.
Разработать новые игры для демонстрации работы видеокарты.
Подсчитать количество видеокарт для разработчиков.
Выбрать программу для рисования спрайтов.
В каком формате сохранять спрайты и как их переносить на ZX.
Способ программирования FPGA - предлагаю через JTAG записывать в копфПЗУ (http://www.zx.pk.ru/showpost.php?p=179221&postcount=38).
Программатор для FPGA.
Возможность реализации команд нового режима в клонах на FPGA.
Способ согласования FPGA с ZX-BUS - можно через 74LVC245AD или через резисторы 100 Ом и диоды на +3.3V внутри FPGA.
---------- Post added at 22:40 ---------- Previous post was at 20:57 ----------
Надо уточнить удобное для игр расположение начала координат экрана (Y=0, X=0) - предлагаю оставить в левом верхнем углу.
shurik-ua
12.07.2013, 22:00
Дизю запилить надо по любому ))
даже бейсика должно хватить )
Alex Rider
13.07.2013, 04:42
Еще в "осталось" надо сделать поддержку этой карты в Unreal Spectrum. Ибо отладка.
Еще в "осталось" надо сделать поддержку этой карты в Unreal Spectrum. Ибо отладка.
Я вот подумал про отладку прошивок FPGA и игр. Можно встроить в видеокарту программатор для FPGA на базе FT2232HL. Это несколько увеличит стоимость видеокарты, но упростит прошивку через USB без открывания корпуса. У FT2232HL два канала и много вариантов работы.
Хорошо бы свободный от JTAG канал использовать для загрузки тестовых программ в Z80 через USB и видеокарту. Для этого выделить определенные порты, например, как у Z-CONTROLER. На PC нужна будет программа для передачи блоков данных в Z80. А в ПЗУ вместо GLUK/HE GLUK написать загрузчик данных из видеокарты.
Тогда, если бы появилась программа передачи данных из PC в ZX, с ее помощью можно было бы быстро загружать различные тестовые программы для отладки видеокарты... Это конечно мечты, но это бы ускорило и облегчило отладку игр и видеокарты. Подобное предложение было и от ZXMAK (http://www.zx.pk.ru/showpost.php?p=606464&postcount=308).
Конечно, в окончательном серийном варианте лишние микросхемы можно не запаивать и отключить дополнительные порты в FPGA, чтобы не ухудшать совместимость видеокарты с остальным железом.
---------- Post added at 11:33 ---------- Previous post was at 09:53 ----------
КОНЦЕПЦИЯ ЗАГРУЗЧИКА ДАННЫХ ИЗ PC НА ZX ДЛЯ ОТЛАДКИ ИГР
На PC мы создаем файлы игры в различных программах - спрайты в редакторе спрайтов, звук - в звуковом редакторе, коды - в компиляторе.
Представим, что у нас есть программа, которая может передавать файлы через USB-UART или другой подходящий интерфейс в FPGA.
Загрузчик в ПЗУ ZX может загружать из сплошного потока данные порциями по 256 байтов с проверкой контрольной суммы и возможностью приостановки приема данных. Сначала загружается LOADER размером 256 байт. В нем программа в кодах, загружающая остальные блоки игры в нужные места, например, спрайты в видеокарту "METEOR-2013".
На PC мы создаем bat-файл, в котором несколько раз запускается программа передачи данных на ZX с именами и местом расположения каждого файла игры.
После сброса Z80 загружает LOADER игры, который загружает остальные блоки, а потом запускает игру с нужного адреса. Скорость загрузки может быть достаточно быстрой, даже если загружать спрайты размером 512 Кб в видеокарту.
Не обязательно USB-загрузчик размещать в ПЗУ. Можно его загружать с любого носителя, имеющегося на компьютере. А дальше он загрузит LOADER игры.
Я вот подумал про отладку прошивок FPGA и игр. Можно встроить в видеокарту программатор для FPGA на базе FT2232HL. Это несколько увеличит стоимость видеокарты, но упростит прошивку через USB без открывания корпуса. У FT2232HL два канала и много вариантов работы.
Это сто процентов нужно.
Я так понял, что можно будет пере-прошить FPGA видео-карты, просто подключив её к PC, через USB кабель.
Верно ?
(Я думал предложить вариант, чтобы добавить EEPROM и микроконтроллер для пере-прошивки FPGA, но ваш вариант c USB , думаю лучше.)
Это сто процентов нужно.
Я так понял, что можно будет пере-прошить FPGA видео-карты, просто подключив её к PC, через USB кабель.
Верно ?
Если все заработает - да. Разъем USB-B разместить рядом с разъемом VGA и оба, а также DIP-SWITCH будут торчать наружу из корпуса.
---------- Post added at 17:43 ---------- Previous post was at 17:39 ----------
Конечно лучше (еще немного и карта заменит собой V6Z80P), можно еще этой картой управлять видео картой на PC (да что там - самим PC), тем самым делать очень быстрые в высоком разрешении 3D игры. Программатор USB планируете взять от сюда (http://marsohod.org/index.php/ourblog/11-blog/170-mbfdti#comment-2982)?
А что делать! LPT в компьютерах уже почти нет. А через USB можно прошивать FPGA с ноутбука. Пока такой программатор встречал только на сайте марсохода. Но у них уже вторая версия есть (http://marsohod.org/index.php/prodmbftdi), которая работает с QUARTUS-ом через драйвер и позволяет прошивать и конфПЗУ. Пока сам не проверял - но должен подойти для наших целей. Vlad, как вы считаете, как лучше подключить FT2232HL к FPGA для возможности обмена с PC? Хотя можно программатор не встраивать в видеокарту, а покупать на сайте марсохода. Но для обмена данными с PC потребуется отдельная платка с ПЛИС, а в видеокарте уже есть FPGA. Для загрузки данных с PC на ZX через UART, наверно достаточно двух сигналов ?
Неактуальное решение, если только не требуется скорость обмена более 25 Мбайт/с. Хотя разработчику виднее. Статей валом (http://www.kit-e.ru/assets/files/pdf/2010_08_90.pdf). Не думаю, что прошивки будут так часто обновляться, а для отладки достаточно простого UART. Я бы не заморачивался с FPGA, искал бы решение в DSP, уже имеющем встроенный графический ускоритель надлежащего уровня.
Нам нужно загружать данные с PC для отладки программ, так как у нас нет другого отладчика и эмулятора. Готовое решение графического ускорителя не подойдет - нам нужны именно те команды, которые выбраны...
В FT2232HL тоже есть UART. По одному сигналу TX данные будут последовательно передаваться в FPGA, а другой сигнал с FPGA будет тормозить передачу при заполнения буфера. Из буфера Z80 будет читать данные по мере необходимости.
Поддержка для развития проекта "zst" есть.
Спасибо за помощь в реализации проекта быстрой видекарты для ZX-SPECTRUM.
Для управления видеокартой «METEOR-2013», которая предназначена для ускорения графики в
ZX SPECTRUM-совместимых компьютерах, разработаны простые и эффективные команды типа PRINT, PLOT, DRAW, POKE, PAPER, INK, BORDER, похожие по назначению на соответствующие команды BASICa.
Для указания места вывода на экран используются координаты X и Y. Спрайты загружаются
в память видеокарты и не занимают места в основной памяти компьютера. Во время игры с помощью соответствующих команд видеокарты спрайты копируются по номерам в указанные координаты экрана.
Спрайты можно накладывать друг на друга с использованием прозрачного цвета фона спрайта.
В одной игре можно использовать спрайты нескольких размеров. Имеется возможность задавать границы окна для печати спрайтов. При печати части спрайтов, выходящие за границы окна, обрезаются. Поверх спрайтов можно рисовать нужным цветом точками и линиями.
Параметры новых режимов - 256х192 и 320х240 точек, 255 цветов с палитрой + «прозрачный» цвет.
Два экрана - теневой и отображаемый. Координаты (0,0) в левом верхнем углу экрана.
Палитра - 3х6 бит (как BMP 256), размещена во внутренней памяти FPGA 256 * 18 бит.
Для команд работы с видеокартой «METEOR-2013» выделены адреса 5800H-58FFH в области атрибутов стандартного экрана ZX-SPECTRUM. Команда определяется по адресу, а данные, которые записывает Z80 по этому адресу, используются как параметры для этой команды. Команды в видеокарте накапливаются в буфере для исключения ожидания Z80 при выполнении сложных команд. Видеокарта затем выполняет накопленные команды из буфера.
Обновленые команды: http://www.zx.pk.ru/showpost.php?p=610738&postcount=50
Серьёзный подход к проекту! я бы заказал экземплярчик ;)
На оригинальном +2 будет работать?
Серьёзный подход к проекту! я бы заказал экземплярчик ;)
На оригинальном +2 будет работать?
Спасибо. Как карта будет готова - проверим и на +2.
Скроллинг фона на 1 точку влево с помощью видеокарты "METEOR-2013"
Экран размером 320 х 240 точек, 256 цветов на точку. -
Спрайты фона размером 16 х 16 точек, карта уровня размером 15 х 256 спрайтов .
Время выполнения около 6851 тактов Z80 = 9.8 % от 69888 тактов в кадре TV.
Для отладки работы видеокарты быстрее загружать спрайты сразу с PC в память спрайтов видеокарты, а 48К программы в память ZX SPECTRUM. Прикинул, что в FPGA можно реализовать преобразователь последовательного кода из UART в параллельный для Z80 и ОЗУ. Как и писал раньше, на PC нужна простая программа, пересылающая файл на ZX через UART (USB-UART2 на FT2232HL). Скорость взять максимально возможную. Поток данных приостанавливать с помощью сигнала CTS высокого уровня.
Можно сделать такой алгоритм при чтении данных в Z80:
1. FPGA принимает байт с PC и устанавливает CTS=1.
2. После того, как Z80 прочитает байт, CTS=0
И т.д.
FT2232HL имеет буфер FIFO UART размером 4К. Так, что остановок не будет.
На Z80 сделать загрузчик в ПЗУ, который после сброса ожидает начала передачи с PC (по аналогии с пилот-сигналом с магнитофона). Также предусмотреть механизм очистки буфер FIFO, если например, прекратили играть в текущую игру на 3 уровне и захотим загрузить другую. Тогда остальные уровни игры нужно быстро прочитать для очистки буфере.
Для загрузки отладочных данных в память ZX нужно выбрать несколько свободных адресов для связи с FPGA.
В принципе, можно сразу в ОЗУ экрана загрузить и заставку к игре, чтобы не тратить время Z80 на повторную пересылку и не тратить на это память спрайтов.
Окончательную версию игры сделать с загрузкой с обычных носителей.
Последовательность загрузки блоков игры:
1. Загрузка палитры для заставки в память палитры в FPGA.
2. Загрузка заставки к игре в ОЗУ экрана.
3. Загрузка спрайтов к игре в ОЗУ спрайтов.
4. Загрузка карты уровня, звуков, кода управления игрой в ОЗУ ZX.
5. Ожидание нажатия кнопки.
6. Очистка экрана.
7. Загрузка палитры спрайтов в память палитры в FPGA.
8. Запуск основного цикла 1 уровня игры.
doorsfan
22.07.2013, 10:48
будете делать совместимость с TSL-Pentevo?
будете делать совместимость с TSL-Pentevo?
Нужно выбрать порты ввода-вывода для USB-загрузчика, чтобы не конфликтовал с существующими компьютерами и контроллерами.
Пока читаю про режимы FT2232HL, Больше всего подходит режим FAST SERIAL. Там полный контроль за потоком данных с помощью приостановки тактовых импульсов. В FGPA загружать c PC в последовательном виде. И можно загружать данные из FGPA в ZX в параллельном виде командами типа INI. Почитал про ее программирование на PC. Попробовал подключить бибилиотеку FTD2xx к QT и выполнять простейшие функции пока с помощью платы USB-UART.
Будут ли доступны исходники проекта, а именно:
1. HDL и firmware (если таковой есть),
2. Файлы P-CAD (или другого CAD, в котором создается плата) - схема и печатная плата?
Будут ли доступны исходники проекта, а именно:
1. HDL и firmware (если таковой есть),
2. Файлы P-CAD (или другого CAD, в котором создается плата) - схема и печатная плата?
А вы для чего спрашиваете ? Хотите помочь или опять назвать барыгой и сделать более дешевый аналог ? Для вас и еще нескольких разработчиков планируется собранный вариант видеокарты бесплатно. Лишь бы польза была для общего дела. Из общей выручки за другие конструкторы (http://www.zx.pk.ru/showpost.php?p=616863&postcount=57).
Ладно, хватит придираться друг к другу. Насколько я понимаю, вы очень умный человек. И вы можете встроить данную видеокарту в FPGA ZXEvo. И вам это раз плюнуть. Дня на два. Попробуйте. Это помогло бы в отладке команд, пока моя видоекатра не сделана. Пусть у людей будет выбор.
doorsfan
23.07.2013, 19:00
zst, я ж потому и задавал вам вопрос, на который, отквоченный, ответа не было. у ТСЛ ведь концепция видеоускорителя завершена, АПИ не меняется.
zst, я ж потому и задавал вам вопрос, на который, отквоченный, ответа не было. у ТСЛ ведь концепция видеоускорителя завершена, АПИ не меняется.
Можно ведь, как вариант и мою сделать. В другой прошивке. Если вставить мою видеокарту в ZXEvo, то его видеоускорителя уже не будет видно на экране. Какой тогда смысл ставить ? Дайте ссылку на последнюю версию команд его видеокарты. И есть ли программы, ее использующие ? Читал, что недавно он добавил блиттер (http://www.zx.pk.ru/showpost.php?p=612056&postcount=51). Но ссылки на описание не было.
Как вы считаете, а с какой видеокартой легче игры писать ? У которой много режимов и управление через порты или у которой два режима - оригинальный и быстрый и управление с помощью координат на экране и номеров спрайтов.
Если надо 256 цветов для ZXEvo - можно сделать модуль-переходник из регистров и резисторов. Из 6 битов цвета надо получить 9, по три бита на каждый канал цветности. Кому надо сможет сам спаять. А TSL поддержит в прошивке.
Я задаю вопрос потому, что наслышан, что аффтар сорцы прячет под любыми предлогами, а считаю что софт на спеке должен быть открытым априори. И это мое дело зачем нужны сорцы - найти багу, поучиться чему-нибудь, отбранчить свою версию, да что угодно.
Если аффтар боится, что его разработки украдут и начнут продавать, на этот случай всегда найдутся люди, которые помогут в создании вечной славы плагиаторам, я буду первым из них в списке. Так что волноваться не о чем.
Мои сорцы открыты абсолютно все. Другой вопрос - нужны ли мои *****коды кому-нибудь. Но я их не прячу.
А еще очень порадовала надпись у аффтара на его сайте о том, что Виндовс у него лицензионный. И сразу вопрос: а Quartus и P-CAD у него тоже лицензионные?..
А вы для чего спрашиваете
Я бы задал встречный вопрос: а почему вы свои сорцы не показываете?
Я бы задал встречный вопрос: а почему вы свои сорцы не показываете?
да, вдруг там закладки вражеские и все юзеры под колпаком... %)
Я с трудом допускаю мысль, что там тыряный код (у кого его тырять?) Тем более непонятно...
TSL, про лиц. софт zst:
При разработке использовались
бесплатная система проектирования печатных плат KiCAD
и лицензионные программы Sprint Layout 6.0
А Квартус Web edition бесплатный, надо полагать.
Квартус въэб ыдышын не генерит бинарник, есличо...
TSL, как не генерит? Я преобразовывал прошивку в sof или какой-то pof у себя( на версии 9 и 11 вроде). Потом с флешки контроллером его грузил по Passive Serial в ПЛИС. Это не бинарник ?
Ай ай. Реквестирую лог фиттера.
Делает, с DE1 той же идет диск и там WebEdition на сайте регишся и он лицензию на полгода по сетевой дает, но блин не знаю как сейчас, раньше было один раз из пяти запросов высылал лицуху и то через пару дней, забил на честность пошел на рутрекер, WebEdition не умеет инкрементальный синтез, юзает одно ядро, умеет только чаморошные чипы (куда входят циклон 1,2, ацексы всякие и максы) это раньше так было, как сейчас хз
В лицуху WebEdition даже лицензия на получасовой Nios входит (в смысле работает полчаса потом клок стопает)
Я задаю вопрос потому, что наслышан, что аффтар сорцы прячет под любыми предлогами, а считаю что софт на спеке должен быть открытым априори. И это мое дело зачем нужны сорцы - найти багу, поучиться чему-нибудь, отбранчить свою версию, да что угодно.
Если аффтар боится, что его разработки украдут и начнут продавать, на этот случай всегда найдутся люди, которые помогут в создании вечной славы плагиаторам, я буду первым из них в списке. Так что волноваться не о чем.
Мои сорцы открыты абсолютно все. Другой вопрос - нужны ли мои *****коды кому-нибудь. Но я их не прячу.
А еще очень порадовала надпись у аффтара на его сайте о том, что Виндовс у него лицензионный. И сразу вопрос: а Quartus и P-CAD у него тоже лицензионные?..
Я сторонник более простого, но бесплатного софта. QUARTUS - бесплатный,
а схемы и платы рисовать меня вполне устраивает лицензионный Sprint Layout 6.
http://i066.radikal.ru/1307/2e/e507d3334a7at.jpg (http://i066.radikal.ru/1307/2e/e507d3334a7a.png)
Исходники видеоконвертера лежат на форуме в теме ZXKit1- плата VGA & PAL (http://zx.pk.ru/showpost.php?p=213835&postcount=165).
--------------------------------------------------------------------------------
-- ПРОШИВКА ПЛИС ДЛЯ УСТРОЙСТВА: "ZXKit1 - ПЛАТА VGA & PAL" --
-- ВЕРСИЯ: V1.0.0.50 ДАТА: 090820 --
-- АВТОР: САБИРЖАНОВ ВАДИМ --
-- --
-- ПЛИС: EPM3128ATC100-10 (128 MACROCELLS, КОРПУС TQFP100) --
-- ОЗУ: K6R4016V1D-TI10 (256K * 16 бит) --
-- ТАКТОВАЯ ЧАСТОТА: 14 МГц, ПОДАЕТСЯ СО СПЕКТРУМА --
-- СРЕДА РАЗРАБОТКИ: Quartus II Version 9.0 Web Edition --
--------------------------------------------------------------------------------
И хватит до меня докапываться. Мало ли других разработчиков на форуме.
И сразу вопрос: а Quartus и P-CAD у него тоже лицензионные?..
Тут перед тобой никто отчитываться не должен,
хватит флудить не по теме.
Шлак свой лей на другие ресурсы.
Ну замечательно, если никаких нарушений лицензионного софта нету - я спокоен. :)
Если надо 256 цветов для ZXEvo - можно сделать модуль-переходник из регистров и резисторов. Из 6 битов цвета надо получить 9, по три бита на каждый канал цветности. Кому надо сможет сам спаять. А TSL поддержит в прошивке.
А как насчет поддержать 256 цветов в прошивке ZXKit-1 ??? Было бы полезно и для Профи и для АТМ и не только. Думаю не только я был бы признателен. Давно использую этот конвертер, впринципе доволен. Но цветов не хватает :(
Паяю платы и раздумываю про вывод спрайтов на экран.
ВидеоЦАП можно сделать по схеме R-2R по 5 бит на каждый из каналов RBG без палитры. Сначала реализовать копирование спрайтов из ОЗУ спрайтов в ОЗУ экрана с учетом прозрачного цвета. Ранее предполагалось две ОЗУ с независимым подключением шин адреса и данных к FPGA. Но теперь понятно, что просто так копировать из одной ОЗУ в другую нельзя. Надо анализировать прозрачный цвет. Если точка прозрачная - записывать не надо. На обработку будет тратиться цикл. Поэтому лучше адреса подавать на две ОЗУ параллельно, а данные и управляющие сигналы соединить отдельно у каждой. Тогда получим ОЗУ 256Kx32. Это позволит загружать и обрабатывать сразу по 4 точки.
Когда я писал дему к игре FUTURE TANK (http://zx-pk.ru/showpost.php?p=622565&postcount=279) для ZX SPECTRUM 128K я рисовал на экране танки, у которых корпуса могли быть разного цвета, а гусеницы одного. Наверно в других играх тоже бывают ситуации, когда надо изображать одинаковые объекты разными цветами. Поэтому нужно предусмотреть, чтобы перед отображением спрайта можно было бы выбирать цвет.
Допустим, мы хотим изобразить шарики одинакового размера, но разного цвета. Мы можем нарисовать шарик одного из цветов с градациями яркости. Шарик будет выглядеть объемно. Сделаем из него спрайт, а при выводе будем менять цвет на тот, который требуется. Для этого каждую точку полутонового изображения закодируем одним байтом в таком формате:
D7-D5 - номер цвета в спрайте ( при 1-6 эти цвета спрайта можно выбрать при выводе)
D4-D0 - градация яркости данного цвета.
Если D7-D5 = 0, то цвета общие у всех перекрашиваемых объектов, например, гусеницы у танков.
D4-D2 - номер цвета
D1-D0 - градации яркости
Несколько перепрограммируемых цветов могут пригодиться, например, при изображении четырех черепашек нидзя. Все одинакового зеленого цвета, глаза белые с черным, а вот повязки на голове разные. Можно нарисовать спрайты для одного, а при выводе задавать цвет повязки. Тут вроде один переопределяемый цвет. Но у врагов могут быть разные шапки, пояса, сапоги и т.п. вещи и было бы удобно нарисовать спрайты для одного, а при выводе немного изменять несколько цветов в каждом. При этом каждая деталь объекта может быть изображена объемно за счет градаций яркости. 32 градации даже может быть многовато.
Цвета 5+5+5 соответствуют MSX2+ (https://en.wikipedia.org/wiki/File:MSX2plus_YJK%26YAE_palette_color_test_chart.p ng)
Еще один вариант кодирования цветов в байте:
D7-D3 - номер цвета: 0 - черный, 1-8 - номера цветов спрайта, которые можно менять при выводе, 9-30 фиксированный набор оттенков из палитры 5+5+5, 31 - прозрачная точка.
D2-D0 - 8 градаций яркости для выбранной пары оттенков.
Оттенки можно выбрать различимые и привычные:
от черного до синего
от черного до красного
от черного до сиреневого
от черного до зеленого
от черного до желтого
от черного до голубого
от черного до белого
от красного до белого
от зеленого до белого
от синего до белого
от желтого до белого
от сиреневого до белого
от голубого до белого
от красного до сиреневого
от красного до желтого
от зеленого до голубого
от зеленого до желтого
от синего до голубого
от синего до сиреневого
Всё ж хочется 512 КБ для спрайт ОЗУ.
Всё ж хочется 512 КБ для спрайт ОЗУ.
ОЗУ лучше общее. 256Kx32 бита = 1Мбайт.
1 экран 256х192=48 Кбайт
2 экран 256х192=48 Кбайт
шрифты 256х8х8=16 Кбайт
буфер команд - несколько килобайт
остальное почти все - под спрайты
В буфер команд записывать можно будет сразу по 4 байта. За два такта видеокарты запишется, а потом при выполнении последовательности команд загрузятся 8 переопределяемых цветов для спрайтов объектов, отличающихся цветами отдельных элементов.
Для градаций яркости точки для каждого оттенка 3 бита в байте, что позволит использовать до 8 градаций.
Дла раскраски отличающихся деталей спрайтов можно будет использовать 7 основных цветов ZX SPECTRUMa, но у каждого по 8 градаций. Конечно можно будет использовать и указанные выше оттенки, но они отличаются не по яркости, а плавно переходят из одного в другой. Не идеально - но значительно лучше, тем более цвета точек независимы друг от друга плюс прозрачный цвет. Кроме этого не надо стирать объекты при движении, так как фон и движущиеся объекты можно рисовать каждый кадр на новом месте.
Слоев, аппаратных спрайтов наверно не надо. А вот карту уровня игры возможно лучше сделать в FPGA, чтобы не гонять большие объемы данных.
В кодировку байта можно добавить еще три пары оттенков по 8 градаций. Например, коричневый и еще пару каких-нибудь.
zst, а почему не использовать палитру нормальную 24бита, зачем извраты с 18битами?
Программирование, если честно, слегка путанное. всё завязано, как я понял, на индексных регистрах и почему-то на одних и тех же индексах. Касательно темы навороченных экранов и способов работы с ними, удобнее спринтеровского экрана пока ничего не встречал. Может загляните туда? исходники-то есть.
Палитра возможна, но лучше ограничиться 15-битной. По расчетам на сайте MARSOHOD (http://marsohod.org/index.php/11-blog/111-r2rdac), пятибитный ЦАП сделать можно на резисторах R-2R, а 8-ми битный можно, но имеет смысла. Поэтому выход видео нужно делать 15 битным для совместимости с платой MARSOHOD2 (http://marsohod.org/index.php/prodmarsohod2). За основу можно взять его схему, чтобы цвета были полностью такими же. 16-ый бит можно не подключать.
Этих цветов должно хватить для игр. Даже фотографии при 15-ти битной палитре (https://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_palettes#MSX2.2B)
получаются вполне различимыми.
Давайте аппаратуру разрабатывать не от палитры, а от функций, которые нам нужны при выводе изображения. Все мы знаем про особенности графики компьютера ZX Spectrum. Допустим мы сделаем новую видеокарту и хотим раскрасить старую игру, например, WHREE WEEKS IN PARADISE. Это одна из немногих игр, где можно выбирать, как отображать главного героя при его движении. На видео про эту игру (http://www.youtube.com/watch?v=H6raDtQoDxQ) в 11:03 мы видим, что Валли перекрашивается в цвета фона, а в 23:09 уже включен второй вариант отображения - фон перекрашивается в желтый цвет Валли .
Допустим, мы захотели устранить этот недостаток. Какие команды нам пригодятся? Речь идет не о перерисовке всех спрайтов как на этом видео (http://www.youtube.com/watch?v=rkxJpcn7EIc), а оставить старую графику.
Возможен такой вариант хранения спрайта в памяти видеокарты:
Так как в стандартном экране спектрума каждой клетке размером 8х8 точек соответствует один байт атрибутов, видеокарта должна быть совместима с таким заданием цвета. Клетку спрайта в старом формате можно представить как 8 байтов расположенных на экране стопкой. Сверху байт 0, снизу байт 7.
В видеокарте можно хранить их так: байт 0, маска 0, байт 1, маска 1 и т.д. Если нужно отобразить все точки спрайта, то маска должна быть FF, Обычно это применимо для построения фона. Чтобы наложить поверх фона движущийся объект в его спрайте маска должна иметь нулевые биты для точек, которые изображать не надо.
Перед отображением клетки на экране мы передаем видеокарте стандартный байт атрибута, координаты печати и номер спрайта размером 8х8 точек. Видеокарта читает одновременно байт и маску для 8 точек и определяет, каким цветом зарисовать точку на экране. Если маска 0, то эту точку ОЗУ экрана записывать не надо.
Таким образом, мы сможет без существенного изменения спрайтов устранить клэшинг атрибутов.
Палитра возможна, но лучше ограничиться 15-битной.
Нормуль.
Возможен такой вариант хранения спрайта в памяти видеокарты:
Приблизительно понятно.
Т.е. будет два формата спрайтов, байт на точку и этот ?
Будет ли полно-экранный 320x240, с теми же времянками (без бордюра) ?
Палитра возможна, но лучше ограничиться 15-битной.
Тогда вопрос - а чем 15бит палитра лучше, чем 24 бита палитра? На лицо удобство работы с полными 8ми битными компонентами. т.е. 8 бит на каждые из трёх компонент RGB. Опять-таки, удобно конвертить и ворочить эту палитру на самом zx.
пятибитный ЦАП сделать можно
ЦАП аля Спринтер (8ми битный) собирается за 15 минут. Все резюки доставаемы и достаточно не дорогие.
15 битным для совместимости с платой MARSOHOD2
и для чего эта совместимость? Почему именно с этой штукой? Почему не с zxevo или там ещё с чем-нибудь?
Давайте аппаратуру разрабатывать не от палитры, а от функций,
конечно, но для начала - а какие собственно цели преследует девайс?Вы хотите сделать "перехватывалку" 128го экрана и просто его "красить" + блиттер или всё же там у карты что-то своё, что-то новенькое и интересное должно быть? Не думаю, что делать какие-то перехваты 128го режима с целью его улучшения или изменения является чем-то сильно важным и нужным. Помню времена на пц, когда была такая штука, как voodoo 2. Она умела выдавать только 3д. Для работы с 2д нужна была отдельная карточка. Почему бы не перенять этот опыт и не сделать сквозной прогон 128го режима через эту карту, просто для того, чтобы минимизировать количество проводов и мониторов?! Извращать стандартный режим особо не к чему. Если кому-то хочется избавится от клэшинга или раскрасить, всё ровно нужно влезать в код игрушки и добавлять поддержку карты и режимов, всё ровно нужно менять графику. просто убирать атрибутный клэшинг даже не так интересно, как добавить новых цветов, да побольше.
s_kosorev
15.06.2015, 10:45
Возможно глупость скажу.
А не расматривался вариант битплановых видеорежимов. К примеру 8битный режи
можно использовать как 8-однобитных, 4-2хбитных 2-4хбитных и один байтовый видеорежим. Причем за счет палитры можно много каких фокусов провернуть.
Как по мне, спектруму с его как раз битплановым экраном, это самое логичное расширение. Использовались же аналогичные методы, к примеру в специалисте
---------- Post added at 10:45 ---------- Previous post was at 10:45 ----------
Да и самый известный битплановый адаптер EGA от PC
Тогда вопрос - а чем 15бит палитра лучше, чем 24 бита палитра? На лицо удобство работы с полными 8ми битными компонентами. т.е. 8 бит на каждые из трёх компонент RGB. Опять-таки, удобно конвертить и ворочить эту палитру на самом zx.
ЦАП аля Спринтер (8ми битный) собирается за 15 минут. Все резюки доставаемы и достаточно не дорогие.
и для чего эта совместимость? Почему именно с этой штукой? Почему не с zxevo или там ещё с чем-нибудь?
конечно, но для начала - а какие собственно цели преследует девайс?
Восьмибитные цап есть в Speccy2010, Но резисторы там 1%. Как написано по приведенной ссылке для восьмибитного цапа нужны намного более точные иначе цвета будут неточными. Кроме этого не учтено сопротивление выходов FPGA.
Поэтому не надо гнаться за предельной точностью и остановиться на реально различимых и повторяемых цветов с пятибитными цапами.
Поэтому и ориентироваться надо на MARSOHOD2, так как там схема уже сделана и учтено сопротивление выходов FPGA.
Предлагаемую видеокарту нужно разработать так, чтобы ее команды можно было реализовать на таких девбордах как Speccy2010, ReVeRse, Marsohod2. У Speccy2010 быстрая SDRAM 7,5 ns. У ZX-EVO SDRAM около 90 nS - она не успеет.
Желательно также, реализовать это в эмуляторе.
Видеокарта, на мой взгляд, должна обеспечивать скорость и устранение недостатков стандартного экрана. Имеющиеся игры для спектрума уже достаточно красивы.
Основные проблемы для написания игр:
1. сложные расчеты координат
2. медленный вывод на экран
3. клешинг атрибутов (цвета точек связаны с соседними точками в клетке 8х8)
4. отсутствие прозрачного "цвета"
5. и в последнюю очередь - малое количество оттенков.
Можно написать отличную игру и в имеющихся цветах.
Возможен такой вариант хранения спрайта в памяти видеокарты:
ИМХО, этот режим вообще не нужен.
Т.е. если я надергал скрин-шотов спрайтов из спековской игры, мне проще тут же их собрать в обычную 256-цветную картинку и влить в видюху. (Могу эту картинку раскрасить, могу и не раскрашивать)
Но, всё таки для экономии спрайт-памяти, можно добавить 16-цветовой формат спрайтов (4 бита на точку),
две точки в одном байте (как сега мегадрайв).
(Т.е. например, если хочется много всякой анимации в игре, тогда фон делаем 256 цветными и по нему спрайты 16 цветные.)
Раз тут упомянули ReVerSE, то что нужно сделать, чтобы вывести вот такую вот картинку?
Нужно преобразовать в формат BMP 320х240 256 цветов в палитре 15бит в редакторе, например, в GIMP это можно сделать так:
File -> Save as... -> 640x480_24bit.bmp [ENTER]
Advanced options -> 24 bits = R8 G8 B8 [SAVE]
File -> Save as... -> 640x480_15bit.bmp [ENTER]
Advanced options -> 16 bits = X1 R5 G5 B5 [SAVE]
File -> Open... -> 640x480_24bit.bmp [ENTER]
Image -> Scale Image... -> Wight=320, Height=240 [SCALE]
File -> Save as... -> 320x240_15bit.bmp [ENTER]
Advanced options -> 16 bits = X1 R5 G5 B5 [SAVE]
Image -> Mode -> Indexed... - > Generate optimum palette ->
Maximum number of colors: 256 [CONVERT]
File -> Save as... -> 320x240_8bit_palette.bmp [ENTER]
http://s017.radikal.ru/i419/1506/d3/924d68619c36t.jpg (http://s017.radikal.ru/i419/1506/d3/924d68619c36.png)
В результате получится 4 файла в разных форматах для сравнения. 15 бит и 24 бита неразличимы на глаз. Зачем делать 8 бит, если такие тонкие оттенки не видно. Тем более после применения палитры на экране будет только 256 оттенков и некоторые цвета все равно потеряются. Можете сами проверить, кто не верит.
http://s58.radikal.ru/i162/1506/f5/8a2770c98655t.jpg (http://s58.radikal.ru/i162/1506/f5/8a2770c98655.png)
Картинки к игре - это хорошо, но это еще не игра. Игра - это тайлы и спрайты. В играх для PC тех времен: WARCRAFT2, STARCRAFT тоже использовались тайлы и спрайты. На приведенной выше картинке игрового экрана можно заметить, что трава нарисована из повторяющихся фрагментов. Разрешение экрана в STARCRAFT 640х480, но суть от этого не меняется. Чтобы заполнить экран травой надо нарисовать несколько спрайтов травы, а потом заполнять этими тайлами-спрайтами весь экран. Подробнее можно посмотреть тут (https://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D0%B0%D1%8F_% D0%B3%D1%80%D0%B0%D1%84%D0%B8%D0%BA%D0%B0) и тут (http://gas13.ru/v3/tutorials/ru_sywtbapa_de-mystifying_greats_1.php).
У нас не такие возможности, как у PC или игровых приставок, но кое в чем мы можем их обогнать. Видеокарту создаем мы сами и придумаем такой способ вывода спрайтов на экран, который устраняет недостатки старых видеорежимов. Например, количество оттенков 256 из палитры иногда может усложнять вывод изображений, для которых нужны совсем другие цвета. Например, для игрового поля нужны свои цвета, а для панели управления - другие. Как же можно выйти из этой ситуации ?
Можно на экране хранить изображение в формате 15 бит на точку. Тогда одновременно на экране можно изобразить около 30000 оттенков. Чтобы это использовать нужно ввести новый формат спрайта. Каждая точка в спрайте может быть одного из 15 оттенков или прозрачной. При печати на экране спрайта предварительно указывают номер ее палитры. Видеокарта после этого загружает 15-цветную палитру по 15 бит на цвет. Это займет 15*15=225 триггеров в ПЛИС/FPGA. После этого видеокарте нужно будет сообщить координаты для печати спрайта и номер спрайта. Видеокарта с ОЗУ шиной данных 32 бита загружает информацию о номерах цветов сразу 8 точек. Палитра для этого спрайта уже загружена. Остается перекодировать 4-битные цвета в 15 битные и записать их в ОЗУ экрана. Уже по 2 точки сразу, но 15 битов на точку. Для изображения на телевизоре или мониторе теперь достаточно прочитать 15 битов для каждой точки (читать можно сразу по 2 точки, так как ОЗУ 32 бита) и вывести их на три ЦАП по 5 битов. Если нужно напечатать остальные спрайты травы - палитру уже загружать не надо.
Для печати спрайтов песка, камней, воды и т.п. объектов загружаем сначала палитру для этого объекта, а затем печатаем 15 цветные спрайты. 16 цвет - прозрачный позволяет накладывать спрайт произвольной формы поверх изображения на экране.
Кроме того, что спрайты у нас стали занимать в два раза меньше, цветастость экрана повысилась, мы еще получили возможнось менять цвет спрайтов при выводе, указывая другую палитру.
Допустим нам надо изображать множество предметов или объектов одинаковой формы но разного цвета. Это могут быть шарики, машинки, человечки, разноцветные лампочки, ключи, кирпичи при дневном свете или в подземелье и т.п. Мы рисуем предмет в 15 оттенках серого. И создаем несколько универсальных палитр по 15 оттенков основных цветов. А теперь при печати этих спрайтов просто указываем нужную палитру - и у нас предмет автоматически перекрашивается.
Прозрачность в спрайтах есть, но возможно ли сделать ещё и полупрозрачность?
Идея хорошая. Теоретически можно, но для этого нужно цвет точки на экране и точки печатаемого спрайта смешать по определенному закону. По какому ? Можно ли это сделать в ПЛИС ? Кроме этого нужен какой-то признак, что цвет полупрозрачный. И для этого нужно будет сначала прочитать цвет точки с экрана, что немного замедлит работу.
Хотя может потребоваться также возможность сохранять фон с экрана при печати спрайта, чтобы потом восстановить его. Для этого тоже надо будет читать цвет точек с экрана. Есть у кого соображения как это лучше делать ?
При печати спрайтов можно предусмотреть установку режима печати:
1. Сохранение фона под спрайтом.
2. Простая печать.
3. Восстановление фона под спрайтом.
4. Печать с полупрозрачным закрашиванием фона.
5. ?
Также нужно выбрать тип спрайтов:
1. 4 бита на точку, несколько палитр по 15 битов, в спрайте 15 цветов из палитры + прозрачный.
2. 8 битов на точку, одна общая палитра по 15 битов, в спрайте 255 цветов из палитры + прозрачный.
Вопросы:
1. как осуществлять смешивание цветов ?
2. как сохранять фон под спрайтом и как его потом восстановить ?
Если при возможностях вывода 256 цветов мы печатаем спрайты 16ю цветами (15 цветов+1 прозрачный), то мы всё-ровно не прыгнем выше 256цветов. Т.е. если каждый спрайт со своей палитрой, тогда мы можем вывести только 16 спрайтов со своей палитрой каждый в 16 цветов из набора 64к цветов (16 бит). И в данном случае принципиально не важно, какая палитра у нас, хоть 16 бит, хоть 15, хоть 24. Если карта позволяет выводить на экран максимум 256 цветов, то хоть тут завыводись палитры, всё-ровно 256 цветов и всё. единственное, разделять области экрана на планы и давать на каждый план свою палитру, например 4 плана по 256 цветов каждый, тогда уже интересно. кроме того есть ещё одна особенность вывода индексных спрайтов (т.е. которые 8бит на точку). например, мы загрузили какой-то фон. большая картинка на весь экран. предположим, что ей мы отдали 160 цветов из общедоступных по возможностям экрана. остаётся у нас только 96цветов на все остальные спрайты (герои, эффекты и прочее). поскольку фон был выведен первым, цвета от 0 до 159 уже заняты под фон. если в спрайтах нет тех же цветов с теми же индексами, тогда придётся после загрузки спрайта сделать переиндексацию на палитру под этот спрайт, т.к. цвета в палитре уже смещены на +160. Можно конечно предположить, что карта может держать несколько наборов по N кол-во палитр для того же нгабора спрайтов и тогда всегда цвета будут иметь корректные индексы от 0 до 16 (или до 15+16й цвет прозрачность). Условие прозрачности обязательно должно иметь возможность игнорирования, т.к. всегда могут быть спрайты без прозрачного цвета, а все 16 цветов было бы желательно использовать в таких случаях. Но при этом даже удерживая где-то у недрах карточки буфера под наборы палитры, имеет ограничение самого экрана на 256 цветов. т.е. каждый набор спрайтов для пользователя индексируются как 0 - 15, но с точки зрения устройства вывода карточки индексы должны быть от 0 до 255. таким образом можно иметь только 16 наборов по 16 цветов.
s_kosorev
16.06.2015, 13:33
2. как сохранять фон под спрайтом и как его потом восстановить ?
Спрайты выводятся во время формирования изображения, отсюда ответ, никакой фон под ними сохранять и востанавливать не надо
Полупрозрачность надо задавать не на точку спрайта, а указывать на весь спрайт.
как сохранять фон под спрайтом и как его потом восстановить ?
Зачем сохранять фон? Он и так должен каждый раз выводится при отрисовке экрана, в пиксель попадает либо фон, либо спрайт. Стоит предусмотреть приоритет отрисовки спрайтов при их наложении друг на друга.
Спрайты выводятся во время формирования изображения, отсюда ответ, никакой фон под ними сохранять и востанавливать не надо
это нужно делать, если в качестве фона используется полноэкранная картинка.
Мы же вначале картинку фона вывели, а потом поверх неё уже кидаем спрайты, ящики всякие, уроды. герои...
это нужно делать, если в качестве фона используется полноэкранная картинка
Таки не нужно, в любом случае при отрисовке всего экрана используется весь фон за исключением мест полностью перекрытых не прозрачными спрайтами, а для этого создавать его дополнительные копии в памяти видеокарты бессмысленно.
За примерами далеко ходить не надо, достаточно посмотреть как оно устроено в Денди (NES Famicom). На хабре есть несколько статей.
Таки не нужно, в любом случае при отрисовке всего экрана используется весь фон за исключением мест полностью перекрытых не прозрачными спрайтами, а для этого создавать его копии в памяти видеокарты бессмысленно.
Что значит при отрисовке всего экрана? Если мы говорим про классическую схему решения, тогда получается, что мы кидаем в карту сначала фоновую картинку, потом кидаем спрайты. Не важно, есть прозрачность у спрайта или нет. прозрачность у спрайта это всего лишь некая не выводимая область. Сейчас на 128м экране для этого используется маска. "Там" в качестве маски используют цвет с некоторым кодом. Чаще всего это цвет с кодом 0xff00ff. Для нас подходит вариант, когда цвет с кодом 0xff не подлежит выводу. Таким образом в рамках одного файла мы делаем и спрайт и маску для него. И вот наступил момент вывода - карточка при выбрасывании данных в видео память, всё что с кодом 0xff будет игнорировать. При этом все остальные данные будут записаны и они затирают ранее записанные данные фона. Это верно для одноплановых движков. Если у карточки будет несколько планов, тогда можно условится, что фоновую картинку мы выводим как план0, всё остальное выводим как план1. Тогда конечно, фон сидит в своей видеообласти, спрайты в своей. Если никаких планов нет и вся видеообласть это по сути и есть весь экран, тогда любая запись туда будет затирать прошлую запись. иначе будет требоваться предварительное сохранение. Второй вариант который не требует процедуры сохранения фона, но требует его восстановления, это делать параллельный буфер в памяти карты, с который данные будут записываться параллельно записи в видео память. Тогда для восстановления достаточно будет прочитать данные из этого буфера по нужным координатам и записать в те же координаты в видеопамять. Другие какие-либо экзотические варианты будут сильно усложнять схему карты, её сборку и увеличивает её стоимость.
Что значит при отрисовке всего экрана?
Это когда байты из памяти попадают в сдвиговые регистры для вывода их на монитор...
Поддерживаю, 15 битовость ОЗУ экрана и 4-битные спрайты (с палитрой) - хорошая идея.
Но, как правильно тут уже было замечено, если у нас одна палитра 256 цветов, то и мы будет ею ограничены в 256 возможных цветов.
Предлагаю простое решение:
перед игрой:
- в ОЗУ видео карты вливаем нужное количество палитр, (хоть 10) и спрайты к этим палитрам
в игре:
- даём команду видео-карте "загрузить палитру в чип", ПЛИС загружает палитру к себе в набортную память
(параметр команды: адрес палитры в видео-памяти откуда загружать)
- отображаем все спрайты, которые юзают 1 палитру
- опять посылаем видюхе команду "загрузить палитру в чип", ПЛИС загрузит себе на борт уже вторую палитру
- отображаем все спрайты, которые юзают 2 палитру
и т.д. хоть 10 палитр
Т.е. можем любую палитру "акивировать" в любое время.
При этом все остальные данные будут записаны и они затирают ранее записанные данные фона.
Вы, похоже, плохо представляете то как формируется изображение. Ничего никуда не нужно записывать, совсем. При выводе на экран видеокарта лишь считывает байты фона и байты спрайтов и согласно правил накладывает их и подаёт итог на вывод в монитор. Т.е. для смешивания данных нужно лишь два байта (15 бит), это и будет тем итогом идущим на отображение в монитор.
---------- Post added at 14:15 ---------- Previous post was at 14:09 ----------
и т.д. хоть 10 палитр
Если иметь таблицу привязки палитр хоть к фону, хоть к спрайту, то количество палитр ограничивается лишь размером памяти видеокарты, и как итог будем иметь все 30 тысяч цветов на экране одновременно.
на экран видеокарта лишь считывает байты фона и байты спрайтов
от куда считывает? из любого места? нет. для этого есть видеопамять. Там самая память из которой все данные попадают потом уже на монитор. А перед этим все данные должны быть туда записаны. Если у карточки есть набор буферов для спрайтов, но нет так называемой видео памяти тогда подскажите, каким образом мы будем оперировать такими понятиями как координаты?
- отображаем все спрайты, которые юзают 2 палитру
и т.д. хоть 10 палитр
что в этот момент делать с прошлыми спрайтами? прятать их? или оставлять на экране? в первом случае спрайты будут моргать, во втором случае получаем эффект флэша, но в целом то же моргание/мерцание.
Зачем сохранять фон?
Кстати тут действительно, возможно проще будет перерисовать весь экран, чем иметь гемор с сохранением задника спрайта.
Потому как ПЛИС будет тактироваться на довольно быстрой частоте.
от куда считывает? из любого места?
Не из любого места, а из буфера для фона, тайтлов и палитр. Не для того-ли и имеем память в видеокарте?
---------- Post added at 14:23 ---------- Previous post was at 14:21 ----------
каким образом мы будем оперировать такими понятиями как координаты?
Для оперирования координатами создавать полный буфер экрана вовсе не обязательно, лишь тратить дополнительное время на запись и память размером с экран по два байта на пиксель.
---------- Post added at 14:25 ---------- Previous post was at 14:23 ----------
Кстати тут действительно, возможно проще будет перерисовать весь экран, чем иметь гемор с сохранением задника спрайта.
Потому как ПЛИС будет тактироваться на довольно быстрой частоте.
Примерно так оно и сделано в старых приставках. В тойже денди нет буфера экрана, там оперативной памяти мизер.
Не из любого места, а из буфера для фона, тайтлов и палитр. Не для того-ли и имеем память в видеокарте?
Тогда каким образом карта будет узнавать, что нам нужно в такой-то момент времени сделать восстановление фона? или вы предлагаете каждый кадр полностью всё перерисовывать? ну тогда мы переходим к теме реализации современной модели видеокарт:
Видеопамять выполняет функцию кадрового буфера, в котором хранится изображение, генерируемое и постоянно изменяемое графическим процессором и выводимое на экран монитора (или нескольких мониторов). В видеопамяти хранятся также промежуточные невидимые на экране элементы изображения и другие данные. Видеопамять бывает нескольких типов, различающихся по скорости доступа и рабочей частоте. Современные видеокарты комплектуются памятью типа DDR, GDDR2, GDDR3, GDDR4, GDDR5 и HBM. Следует также иметь в виду, что, помимо видеопамяти, находящейся на видеокарте, современные графические процессоры обычно используют в своей работе часть общей системной памяти компьютера, прямой доступ к которой организуется драйвером видеоадаптера через шину AGP или PCIE. В случае использования архитектуры Uniform Memory Access в качестве видеопамяти используется часть системной памяти компьютера.
и сколько тогда такая карта стоить будет? не дешевле ли будет прикупить на свой родной пц какой нить geforce?:)))
- отображаем все спрайты, которые юзают 2 палитру
и т.д. хоть 10 палитр
что в этот момент делать с прошлыми спрайтами? прятать их? или оставлять на экране? в первом случае спрайты будут моргать, во втором случае получаем эффект флэша, но в целом то же моргание/мерцание.
Не будет такого. Все там норм.
В тойже денди нет буфера экрана,
Да, в денди нет.
Но автор карты, выбрал именно систему с 15 битными экранными буферами (активным и теневым), и это ж нужно учитывать, в своих размышлениях.
s_kosorev
16.06.2015, 14:45
Sayman, zst сейчас предлагает кадравый буфер, второй вариант предалагают, как в приставках, нет кадрового буфера, изображение формируется вслед за телевизионным лучем. По мере надобсности читаются данные для тайловых плоскостей, спрайтовых, в конце концов растровых.
В NES SEGA изображение мира формируется находу
---------- Post added at 14:45 ---------- Previous post was at 14:43 ----------
Про прозрачноть, в битплановых режимах она достается бесплатно, правильной настройкой палитры, есть конечно ограничения, полоценно прозрачный можно сделать 1-2 слоя, но в конце концов это видеокарта для 8 битного компьютера а не для PC
как осуществлять смешивание цветов ?
Из инета
http://stackoverflow.com/a/746937
Стандартная формула смешивания
out = alpha * new + (1 - alpha) * old
out, new, old - RGB цвета
alpha - число с павающей точкой в диапазоне [0,1]
Если карта позволяет выводить на экран максимум 256 цветов, то хоть тут завыводись палитры, всё-ровно 256 цветов и всё.
Теперь в буфере экрана уже не 8 битов на точку (1 байт), а 15 битов (2 байта), что позволит иметь на экране до 32*32*32=32768 оттенков. У спрайтов по 4 и по 8 битов на точку тоже палитры 15 битные. То есть в палитрах выбраны любые цвета из 32768 возможных.
Спрайты выводятся во время формирования изображения, отсюда ответ, никакой фон под ними сохранять и востанавливать не надо
К сожалению не всегда получится выводить фон на лету. Иногда лучше нарисовать фон в буфере экрана, при выводе спрайтов сохранять фон в буфере для сохранения фона, а потом восстанавливать для печати спрайтов движущихся объектов на новом месте.
Полупрозрачность надо задавать не на точку спрайта, а указывать на весь спрайт.
Зачем сохранять фон? Он и так должен каждый раз выводится при отрисовке экрана, в пиксель попадает либо фон, либо спрайт. Стоит предусмотреть приоритет отрисовки спрайтов при их наложении друг на друга.
Я не планирую копировать видеорежимы SEGA, DANDY, АТМ и др. Я хочу сделать удобные для программирования и быстрые видеорежимы. В моем проекте видеокарты есть буфер экрана. Каждой точке соответствует 15 битов. При выводе на телевизор или монитор ПЛИС читает из буфера экрана последовательно по точке (15 битов) и выводит их на три ЦАПа RGB по 5 битов.
Перед этим нужно сформировать картинку в буфере экрана. Для этого каждый кадр заново (для простых движущихся фонов ) или меняя изображение в отдельных частях экрана (для статических фонов) нужно напечатать спрайты в буфер экрана. То есть считать из буфера спрайтов и записать в буфер экрана. Этим конечно занимается видеокарта. Z80 передает только изменяемые параметры спрайта из параметров: тип спрайта (4 или 8 бит на точку), размер, координаты на экране, номер палитры, номер спрайта. Можно накладывать спрайты рядом или друг на друга. Возможно использовать прозрачный цвет. Вот результат этих наложений и выводится потом из буфера экрана. Никаких слоев или аппаратных спрайтов нет.
Поддерживаю, 15 битовость ОЗУ экрана и 4-битные спрайты (с палитрой) - хорошая идея.
Но, как правильно тут уже было замечено, если у нас одна палитра 256 цветов, то и мы будет ею ограничены в 256 возможных цветов.
Этого ограничения уже нет.
Предлагаю простое решение:
перед игрой:
- в ОЗУ видео карты вливаем нужное количество палитр, (хоть 10) и спрайты к этим палитрам
в игре:
- даём команду видео-карте "загрузить палитру в чип", ПЛИС загружает палитру к себе в набортную память
(параметр команды: адрес палитры в видео-памяти откуда загружать)
- отображаем все спрайты, которые юзают 1 палитру
- опять посылаем видюхе команду "загрузить палитру в чип", ПЛИС загрузит себе на борт уже вторую палитру
- отображаем все спрайты, которые юзают 2 палитру
и т.д. хоть 10 палитр
Т.е. можем любую палитру "акивировать" в любое время.
Я так и предлагал. Под спрайты по 4 бита на точку можно сделать до 256 разных палитр. И все они по 32K цветные. Размер каждой 32 байта.
Кстати тут действительно, возможно проще будет перерисовать весь экран, чем иметь гемор с сохранением задника спрайта.
Потому как ПЛИС будет тактироваться на довольно быстрой частоте.
Не всегда можно быстро перестроить экран. Иногда для этого нужно больше одного кадра. Например, в игре целая галактика и данные хранятся в упакованном виде и распаковка ведется прямо на экран. Для этих случаев лучше сохранять фон под спрайтами.
Я придумал такой метод:
Выделяем место в памяти видеокарты под буфер для сохранения фона под спрайтами. Вначале указатель в буфере установлен на начало. Там записан 0 - буфер пуст. При печати нужно выбрать одну из двух команд - печать спрайта с сохранением фона и печать спрайта без сохранения фона. Для первого варианта копируем из буфера экрана в буфер для сохранения фона прямоугольную область начиная с левого верхнего угла прямоугольника размером со спрайт и так до правого нижнего угла. Затем сохраняем в буфер размер спрайта и координаты правого нижнего угла прямоугольника под спрайтом. После этого добавляем в буфер для сохранения фона число 2 (значит там лежит прямоугольник). Для отдельных точек зарезервируем число 1. И так печатаем все спрайты, добавляя после данных параметры и 2.
Когда приходит пора перестроить экран для передвижения спрайтов, даем команду ВОССТАНОВИТЬ ФОН. Видеокарта начинает брать данные с конца буфера для сохранения фона. Там лежит 2 - значит надо восстановить прямоугольную область. Читаем из буфера координаты правого нижнего угла прямоугольника на экране, размеры прямоугольника и последовательно восстанавливаем фон, копируя по точке из буфера для сохранения фона в буфер экрана. И так пока после данных читается 1 или 2. Если 0 - конец работы, буфер восстановлен.
Из инета
http://stackoverflow.com/a/746937
Стандартная формула смешивания
out = alpha * new + (1 - alpha) * old
out, new, old - RGB цвета
alpha - число с павающей точкой в диапазоне [0,1]
Спасибо, пока отложим для более важных команд.
s_kosorev
16.06.2015, 18:26
Я не планирую копировать видеорежимы SEGA, DANDY, АТМ и др. Я хочу сделать удобные для программирования и быстрые видеорежимы.
Тогда вообще не понятно в чем удобство.
Если будет все копироваться в кадровый буфер, нужен просто модуль для блочного копирования памяти, возня с палитрой будет совсем лишняя, по 4 бита + палитра, зачем оно нужно? если это аппратно все будет копироваться и очень быстро?
Сохранение фонов итд, опять же ничего не надо выдумывать, все решается модулем блочного копирования. Его просто нужно обучить работать с прозрачностью, все. Вся карта
Такая акселерация была в первых видекартах PC с аппартными функциями ускорения, можно даже в VESA VBE посмотреть набор функций
zst, ты меня в конец запутал. в первопосте сказано, что:
320х240 точек, 255 цветов с палитрой + «прозрачный» цвет.
т.е. физическая возможность отобразить всего 256 цветов из палитры 32768 цветов. теперь ты говоришь про гору палитр для той же горы спрайтов, что наводит на мысль о том, а каковы в действительности тогда хар-ки девайса? тут или всего 256цветов (хоть 1000 спрайтов и палитр, но только 256 цветов подлежат выводу) или реально у карты экран 15 бит и можно спокойно кидать 32к картинки. если начинается делёжка на палтиры в рамках 8бит на точку, тогда уже вводятся планы. иначе я не понимаю, что за параметр такой, "255 цветов с палитрой + «прозрачный» цвет".
собственно говоря, а почему бы не обратиться к алгоритмам современных карт и местами, где это выглядит жирно и дорого, упростить? можно ещё 3д прикрутить, тогда я в первых рядах на заказ))))
Тогда вообще не понятно в чем удобство.
Цель - устранение недостатков стандартной видеокарты ZX SPECTRUM. При этом избавить программиста от расчета адресов по координатам, ускорить копирование на экран, ускорить сохранение и восстановление фона под спрайтами, устранить клешинг атрибутов, увеличить количество цветов. И мы уже близки к технически реализуемому варианту.
Если будет все копироваться в кадровый буфер, нужен просто модуль для блочного копирования памяти, возня с палитрой будет совсем лишняя, по 4 бита + палитра, зачем оно нужно? если это аппратно все будет копироваться и очень быстро?
Сохранение фонов итд, опять же ничего не надо выдумывать, все решается модулем блочного копирования. Его просто нужно обучить работать с прозрачностью, все. Вся карта
Такая акселерация была в первых видекартах PC с аппартными функциями ускорения, можно даже в VESA VBE посмотреть набор функций
Отлично! Такой метод нам подойдет. Долой палитру. Или использовать ее при загрузке спрайтов в видеокарту. Осталось решить, какого объема и типа озу использовать.
---------- Post added at 21:12 ---------- Previous post was at 21:09 ----------
собственно говоря, а почему бы не обратиться к алгоритмам современных карт и местами, где это выглядит жирно и дорого, упростить? можно ещё 3д прикрутить, тогда я в первых рядах на заказ))))
Палитра нас только тормозила. После загрузки преобразовываем все спрайты в 15 битов на точку.
Уже вполне хорошо получается:
У нас 32K цветов на экране.
Аппаратная печать в буфер экрана спрайтов по координатам и номеру спрайта.
Возможность при печати аппаратно сохранить, чтобы потом восстановить фон под спрайтами.
Прозрачный цвет для печати спрайтов произвольной формы и возможность их накладывания.
s_kosorev
16.06.2015, 19:25
устранить клешинг атрибутов, увеличить количество цветов. И мы уже близки к технически реализуемому варианту.
клешинг это как раз артефакты индексного указания цвета, нет индексов и палитр, нет клешига, элементарно же
---------- Post added at 19:23 ---------- Previous post was at 19:21 ----------
Опять же аппаратные спрайты, тоже решают проблему клешинга очень простым путем.
---------- Post added at 19:25 ---------- Previous post was at 19:23 ----------
но это если ориентироваться на удобство программирования, а так ради хобби, можно конечно что угодно придумать
Теперь можно подумать о реализации. Наверно лучше использовать память SDRAM 4 Мбайт, так как 1 Мб может не хватить. Тем более, SDRAM стоит в Speccy2010, ReVeRse, Marsohod2 и других девбордах. Это позволит сделать новый видеорежим массовым.
Дла начала надо написать алгоритм печати спрайта с учетом прозрачного цвета в буфер экрана. И подумать, как это реализовать на Verilog.
Давайте прикинем максимальную скорость копирования. Если использовать тактовую частоту ПЛИС 14*6=84 МГц, то один экран размером 256*192=49152 точек можно будет аппаратно скоприровать за время около (49152*2)/84 MHz=1,17 mS. Время отображения одного кадра на TV 20 mS.
После загрузки преобразовываем все спрайты в 15 битов на точку.
Опять не понятная заморочка. почему я не могу загрузить спрайт/картинку сразу в 15бит формате? Если у меня исходный спрайт имеет 32цвета, то после преобразования он будет иметь...32 цвета)) в чём прикол каких-то преобразований? или карточка даёт работать с 15бит спрайтами сразу на входе (т.е. я гружу с диска спрайты сразу 15бит и просто перебрасываю в карточку или если подключена её память, то гружу туда сразу) или лишние заморочки ни к чему.
это как раз артефакты индексного указания цвета, нет индексов и палитр, нет клешига, элементарно же
оно как бы любая картинка или спрайт 8бит на точку уже индексная, т.к. в картинке любое значение это индекс в палитре из 256 цветов, в которую мы выбрали цвета из большей палитры. Если заглянуть в bmp файл, там палитра 768байт. Никаких клэшенгов я не замечал)))
Опять не понятная заморочка. почему я не могу загрузить спрайт/картинку сразу в 15бит формате?
Конечно, если все уже 15-битное - ничего преобразовывать не надо.
s_kosorev
16.06.2015, 20:14
оно как бы любая картинка или спрайт 8бит на точку уже индексная, т.к. в картинке любое значение это индекс в палитре из 256 цветов, в которую мы выбрали цвета из большей палитры. Если заглянуть в bmp файл, там палитра 768байт. Никаких клэшенгов я не замечал)))
это если исходники изначально в одной палитре, а если палитра на ходу подбирается, то возникают искажения средней палитры, или дизеринг, патерны или еще какой то метод что бы в цвет примерно попасть, тоже подвиды клешига
s_kosorev, клэшингу нас тут атрибутный, а не цветовой и связан с тем, что мы не можем в 128м экране рисовать в цвете с точностью до точки, только до знакоместа. а дизеринг или иной способ эмуляции большего числа цветов, это слегка другое.
---------- Post added at 23:34 ---------- Previous post was at 23:26 ----------
Конечно, если все уже 15-битное - ничего преобразовывать не надо.
Т.е. мы можем сразу оперировать спрайтами и картинками не 8 бит, а сразу 15 (16) бит?! интересно конечно, но тогда памяти для буферов в 4метра будет маловато. мне на спринтере памяти для 8ми битных не хватает, а ты для 16битных хочешь. 16 метров резервируй, не меньше.
---------- Post added at 23:46 ---------- Previous post was at 23:34 ----------
и ещё один не понятный момент - если карта умеет работать с данными 15бит, тогда для чего нужно делать гору палитр для горы спрайтов? мы и так можем грузить 15бит спрайты без извратов. В том и прикол, что 8бит спрайты, это набор индексов в палитре, а 15юит и выше спрайты, это и есть сама палитра. вместо индекса от 0 до 255 мы указываем данные rgb в формате (1:)5:5:5.
Отлично! Такой метод нам подойдет. Долой палитру.
Поддерживаю, нафиг палитру.
15 битные спрайты - это гуд.
Осталось решить, какого объема и типа озу использовать.
8 метров минимум.
16 оптимально.
сдрам вероятно.
p.s. 84 МГц это жесть :)
Надо выбрать режим работы SDRAM. Как известно, SDRAM работает так:
Вся область памяти внутри этого устройства делится на блоки (ROW) по 256 ячеек. Чтобы прочитать или записать данные из ячейки нужно сначала включить (ACTIVE) нужный блок. Потом подать команду чтения (READ) или записи (WRITE), указав одновременно номер ячейки (COL) в блоке. Если надо затем обратиться к ячейке в другом блоке этот блок надо выключить (PRECHARGE), а новый включить (ACTIVE) и т.д.
Команды и данные подаются синхронно тактовой частоте CK. После команды включения блока или чтения нужно подождать 1 или 2 такта (подавать 1 или 2 команды NOP ). Число зависит от частоты тактов и быстродействия памяти. Раньше на древних компьютерах (в BIOS) выбирали частоту тактов на память (например, 100 или 133 MHz) и режим работы (2-2-2, 3-3-3). Но раньше мы не знали, что это за числа. Так вот сейчас мы это посчитаем и выберем нужный режим.
Частота смены точек на экране TV 7 MHz, на экране VGA 14 MHz. Тактовую для ПЛИС и SDRAM выберем 14*6=84 MHz. tCK=1/84 MHz = 12 nS. Время между включением блока и подачей команды чтения или записи tRCD должно быть не менее 20 nS. При CL=2 tRCD будет равно 24 nS, что соответствует требованиям. То есть выберем режим работы SDRAM 2-2-2. Это значит, что после команды включения блока мы можем пропустить только один такт (подавать команду NOP). После этого получаем данные из памяти. Как видим, SDRAM очень медленно и неудобно работает, но в ней большой объем памяти, который нам нужен для видеокарты. Что же делать? Как ускорить работу ?
SDRAM позволяет читать и писать данные пакетами (BURST). Для нашей видеокарты подходит пакет длиной 8. Причем выберем режим чтения с автоотключением (AUTO PRECHARGE) блока после чтения 8 точек. Т.е. чтобы прочитать 8 точек из буфера спрайтов нужно будет подать следующие команды:
1 такт - ACTIVE (включение нужного блока памяти)
2 такт - NOP (ожидание включения блока)
3 такт - READ с A10=1 (чтение пакета длиной 8 с автоотключением блока)
4 такт - NOP (ожидание из буфера спрайтов первой точки спрайта)
5 - 12 такты - NOP (данные из памяти - последовательно 8 точек спрайта)
Чтение пакетами по 8 точек и организация памяти блоками по 256 ячеек накладывает ограничение на структору видеокарты - размеры спрайтов должны быть кратны 8, иначе может возникнуть ситуация перехода спрайта в другой блок. А SDRAM не может читать последовательно данные из разных блоков.
s_kosorev
18.06.2015, 21:43
Это значит, что после команды включения блока мы можем пропустить только один такт (подавать команду NOP). После этого получаем данные из памяти. Как видим, SDRAM очень медленно и неудобно работает, но в ней большой объем памяти, который нам нужен для видеокарты. Что же делать? Как ускорить работу ?
Не обязательно NOP, можно другому банку подавать команду, сигналы BAxx выбирают номер банка которому команду отдают
---------- Post added at 21:43 ---------- Previous post was at 21:40 ----------
Причем выберем режим чтения с автоотключением (AUTO PRECHARGE) блока после чтения 8 точек.
плохой режим, надо будет после каждого цикла, ждать отключение строки, регенерацию эффективней делать к примеру во время строчного гашения
плохой режим, надо будет после каждого цикла, ждать отключение строки, регенерацию эффективней делать к примеру во время строчного гашения
Видеокарта будет работать так - чтение 8 точек из буфера спрайтов в ПЛИС, запись 8 точек из ПЛИС (с учетом прозрачного цвета) в буфер экрана и т.д. Иногда надо будет прочитать 8 точек из буфера экрана в ПЛИС для отображения на TV или VGA. И все эти данные лежат в разных блоках памяти SDRAM. Выключать и включать блоки (STRINGS) все равно придется после чтения или записи 8 точек.
s_kosorev
18.06.2015, 22:09
Иногда надо будет прочитать 8 точек из буфера экрана в ПЛИС для отображения на TV или VGA. И все эти данные лежат в разных блоках памяти SDRAM. Выключать и включать блоки все равно придется после чтения или записи 8 точек.
Ну так положить в разные банки, буфер кадров, данные графики спрайтов, а что бы меньше переключать строки, распологать спрайт в памяти последовательно, тогда к примеру при чтении спрайта, нужно будет ACTIVE выдавать только при смене строки. Опять же, чтение видео данных можно сделать к примеру по 4-8 BURST циклов, вообще с SDRAM по максимуму надо оптимизировать последовательные чтения, при произвольном доступе SDRAM не намного быстрее обычной DRAM
SDRAM имеет аж 4 конвеера, к тому же пока выдает 8 циклов данных, можно опять же подавать команды
---------- Post added at 22:09 ---------- Previous post was at 22:01 ----------
Отключение строки можно всегда послать в командах чтения записи, а вот если включен Auto Precharge - уже не отменить отключение, даже если чтение идет следующих байт в той же строке
Если бы спрайт был размером 16х16 точек, то он занял бы весь блок 256 ячеек. Тогда теоретически можно было бы за один пакет прочитать в ПЛИС весь спрайт. Это было бы максимально быстрое чтение.
s_kosorev
18.06.2015, 22:13
Тогда теоретически можно было бы за один пакет прочитать в ПЛИС весь спрайт. Это было бы максимально быстрое чтение.
без автоотключение строки можно и так максимально быстро прочитать, потери будут только на первый цикл, остальное конвеер скроет
без автоотключение строки можно и так максимально быстро прочитать, потери будут только на первый цикл, остальное конвеер скроет
Можно было бы и стоку из буфера экрана для вывода на TV или VGA (256 точек) читать одним пакетом. Тем более на VGA строку надо показывать дважды. Для таких чтений нужно статическую память и ПЛИС или внутреннюю память FPGA.
Кто за то, чтобы для ускорения работы до приемлемой скорости размеры спрайтов внутри видеокарты были размером 16х16 точек ?
Записывать в буфер экрана можно было бы пакетами по 16 точек.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot