Просмотр полной версии : Новый графический режим для игр
http://s020.radikal.ru/i723/1509/a6/5d22094b554bt.jpg (http://s020.radikal.ru/i723/1509/a6/5d22094b554b.jpg) http://s016.radikal.ru/i337/1509/95/fe827124ba82t.jpg (http://s016.radikal.ru/i337/1509/95/fe827124ba82.jpg) http://s017.radikal.ru/i422/1608/14/f09fe7bd753at.jpg (http://radikal.ru/fp/c11eca74a7e147de94d87e053f904f20)
Видеокарта/видеорежим "Meteor Graphics" для устранения клешинга атрибутов в старых играх и облегчения написания новых
На текущий момент концепция видеокарты «Meteor Graphics» такая:
Изображение на экране получается путем наложения 8 слоев. Они располагаются в статической памяти видеокарты (SRAM) общим объемом 2 MB. Неиспользуемые слои можно отключать. Каждая точка представлена 16 битами (одним словом SRAM). В слое может быть до 32768 разных цветов. Каждый слой состоит из двух блоков размером 256 х 256 точек. Слой можно использовать для фона из тайлов или изображения движущихся объектов из спрайтов. Для фона можно применить аппаратный скроллинг. А для устранения мерцания спрайтов можно рисовать их в одном блоке и отображать при этом другой блок. Для отображения нужной части слоя задается смещение по X и Y для каждого слоя. Размер активной части экрана 256 x 224 точки.
Для устранения клешинга атрибутов в старых играх и экономии памяти на графику в новых играх в тайлах и спрайтах на каждую точку приходится по 2 бита. Перед рисованием тайла или спрайта выбираются 4 текущих цвета из возможных 32768 (с кодами 0000-7FFF) и двух кодов прозрачности (8000 — не менять цвет точки в слое или 8001 — сделать точку слоя прозрачной). Текущие цвета можно менять в любой момент. Спрайты и тайлы рисуются сразу по 8 точек. Для этого в видеокарту на каждые 8 точек записывается по 2 байта. Получается по 2 бита на точку. Это дает 4 комбинации. Каждой комбинации соответствует один из четырех текущих цветов. Видеокарта записывает по 8 точек в текущий слой, перекрашивая точки в текущие цвета.
При выводе на телевизор читаются цвета всех восьми точек из восьми слоев с одинаковыми координатами. В процессе анализа определяется видимый цвет и передается на VIDEODAC для преобразования в аналоговые сигналы на телевизор или через скандаблер на монитор. INT остается 50 Hz. VIDEODAC R-2R по 5 бит на резисторных сборках 270 R. Выход на разъем WF-09MR, к которому подключается разъем SCART или VGA. Частота 50 Hz. Пока. Для 60 Hz можно подключить VGA SPUTNIK через IDC-20M.
http://s019.radikal.ru/i639/1506/36/f2bf9b657467t.jpg (http://s019.radikal.ru/i639/1506/36/f2bf9b657467.png)
Палитра как у MSX2+ и SUPER NINTENDO - 32K цветов при 15-битном RGB 5+5+5
Ссылки:
Разработка видеокарты "Meteor Graphics" (http://zx-pk.ru/showpost.php?p=809937&postcount=201).
Сколько уж карт разрабатывалось на эту тему? Мне идя нравится, но ещё хотелось бы, что бы и разрешений было несколько. 512x240 (256) для Профика скажем. 320 на 240 для порта игр от CPC.
Сколько уж карт разрабатывалось на эту тему? Мне идея нравится, но ещё хотелось бы, что бы и разрешений было несколько. 512x240 (256) для Профика скажем. 320 на 240 для порта игр от CPC.
320х240 согласен. 512х240 может не хватить скорости. Напоминаю, видеорежим нужен для простых но быстрых игр типа THREE WEEKS IN PARADISE и R-TYPE. Все остальные задачи типа текстовых редакторов, медленная статическая графика и другие старые бесчисленные режимы лучше не предлагать. Или обосновывать, что в этом режиме хорошо, что плохо, что можно было бы улучшить. Также прошу воздержаться от 3D. Не надо далеко отходить от Спектрума. Мы его хотим сделать лучшим компьютером, а не PC.
---------- Post added at 12:12 ---------- Previous post was at 12:11 ----------
Те режимы что есть в Evolution уже из коробки чем-то не устраивают?
Давайте обсудим их достоинства-недостатки. Подумаем, что улучшить.
Надо коллективно принять решение, какая система команд оптимальна. Обосновывая, почему так проще, быстрее и т.д.
denpopov
20.06.2015, 10:22
Многа букаф из ничего.
Хотите спрайты? валите на Atari/GBC, или с готовыми квартирами на тс-денди-конф.
Но есть маленький нюанс: только Атари поможет детектить столкновение спрайтов с объектами.
режим 320х240? простите, а какой формат видеопамяти, и куда все это пихать? у Амстрада есть похожий режим, он отжирает 16К памяти.
Многа букаф из ничего.
Хотите спрайты? валите на Atari/GBC, или с готовыми квартирами на тс-денди-конф.
Но есть маленький нюанс: только Атари поможет детектить столкновение спрайтов с объектами.
режим 320х240? простите, а какой формат видеопамяти, и куда все это пихать? у Амстрада есть похожий режим, он отжирает 16К памяти.
320х240х2=150Кбайт. Память SDRAM 4Mx16бит.
Аппаратные спрайты не нужны, нужна простая видеокарта. Просто быстрое аппаратное копирование обычных спрайтов из буфера спрайтов в буфер экрана. В этих приставках все сложно и полно недостатков, поэтотому это не образец для подражания.
Есть дендиконфа от TSlabs, сделана именно для тех же целей, чем собственно она не устраивает? Если будет платка расширяющая любой клон с zxbus до ее видеорежимов будет отлично, я бы например взял. А просто еще один пусть прикольный но пустой девайс за 3-4 к как бы не особо нужен. Я надеюсь, уважаемый zst, читал цикл статеек на хайпе о tsconf, все же как бы придумано. А идея с портированием игр это утопия, максимум новодел на чурчеле будут переводить.
Вы можете кратко описать здесь: достоинства, недостатки, почему сделано так, а не иначе ? Все режимы нужно собрать вместе, проанализировать и сделать наконец второй стандартный режим графики. Он должен быть удобным и быстрым.
denpopov
20.06.2015, 10:36
Есть дендиконфа от TSlabs, сделана именно для тех же целей, чем собственно она не устраивает?
У нее блиттер нервно курит ващет.
Есть дендиконфа от TSlabs, сделана именно для тех же целей, чем собственно она не устраивает? Если будет платка расширяющая любой клон с zxbus до ее видеорежимов будет отлично, я бы например взял. А просто еще один пусть прикольный но пустой девайс за 3-4 к как бы не особо нужен. Я надеюсь, уважаемый zst, читал цикл статеек на хайпе о tsconf, все же как бы придумано. А идея с портированием игр это утопия, максимум новодел на чурчеле будут переводить.
Заглянул сюда (http://hype.retroscene.org/blog/dev/209.html#cut) Очень сложная штука. Тут может разобраться гений типа CHRV или TSL. Нам же нужно только спрайты напечатать. Зачем все усложнять то ? Дайте ссылки на игры и эмулятор для TS-CONF, если есть. Как впечатление у видевших ?
Давайте сделаем простой режим, без ДМA, кэша, окон, палитр и т.п. усложнений ! Хорошо бы вернуть TSL на этот форум. Нас осталось мало. Чего ругаться.
denpopov
20.06.2015, 11:00
Тут может разобраться гений типа CHRV или TSL.
А все просто - TS-фюрер ненавидит тебя и боится демок,которые он называет ААА-стайл, поэтому и бережет инфу, тщательно пряча примеры и тд.
Так что твоя концепция с его реализацией спрайта выеденного не стоит. Как и его конфа тоже.
denpopov
20.06.2015, 11:00
Тут может разобраться гений типа CHRV или TSL.
А все просто - TS-фюрер ненавидит тебя и боится демок,которые он называет ААА-стайл, поэтому и бережет инфу, тщательно пряча примеры и тд.
Так что твоя концепция с его реализацией спрайта выеденного не стоит. Как и его конфа тоже.
Вполне достойно впеЧАТление. Спаяй переходник себе для Speccy2010, полчаса делов - и сам увидишь. а эмуль есть, тоже нормально вполне кажет. Анрил с TS
Ссылки, пожалуйста ?
---------- Post added at 13:14 ---------- Previous post was at 13:09 ----------
А все просто - TS-фюрер ненавидит тебя и боится демок,которые он называет ААА-стайл, поэтому и бережет инфу, тщательно пряча примеры и тд.
Так что твоя концепция с его реализацией спрайта выеденного не стоит. Как и его конфа тоже.
Надо обсудить здесь его режимы графики, подумать, как сделать универсально, без привязки к ZX-EVO. Упростить по максимуму. Основная задача - устранение клешинга без усложнения программирования. А также скорость должна быть до 50 fps.
Мы в топике при разработки видеокарты METEOR пришли к выводу, что палитра не нужна. Проще сделать спрайты в нужном цвете.
Наверно нужно также ограничить количество режимов. Оставить только 320х240. То есть нужно упростить все до предела, чтобы было просто, быстро.
То что просто TSL, не значит, что просто другим. Должно быть простое программирование, проще чем для обычного экрана Спектрума. Для этого нужен коллективный разум, а не разум отдельных разработчиков.
denpopov
20.06.2015, 11:28
Надо обсудить здесь его режимы графики, подумать, как сделать универсально, без привязки к ZX-EVO. Упростить по максимуму. Основная задача - устранение клешинга без усложнения программирования. А также скорость должна быть до 50 fps
Веришь, нет - Е АДО! все уже изябретено до тебя.
То что просто TSL, не значит, что просто другим. Должно быть простое программирование, проще чем для обычного экрана Спектрума. Для этого нужен коллективный разум, а не разум отдельных разработчиков
Зачем тогда создал тред? типа "уголок любви и обожания ТС-Троллса"?
Спасибо. Хорошо бы, чтобы он разработал для всех нас новый простой режим графики.
Видно, что он хороший специалист, но характер у него тяжелый.
Но нужно еще обсудить, как эффективнее отправлять команды в видеокарту и т.п. вопросы
Чтобы видеокарта получилась действительно оптимальной и хорошей. Тогда, возможно, больше людей будут писать игры для Спектрума.
denpopov
20.06.2015, 12:19
Хорошо бы, чтобы он разработал для всех нас новый простой режим графики
Бугога, сколько можно дождаться инфы от "нового режима"? забутьте.
Веришь, нет - Е АДО! все уже изябретено до тебя.
Зачем тогда создал тред? типа "уголок любви и обожания ТС-Троллса"?
Ну и где на Спектруме этот простой быстрый режим ? У TS-Labs не простой !
Мне посоветовали обратиться к программистам игр за помощью в разработке видеокарты. Я считаю, что надо разработать не видеокарту, а видеорежим, который будет работать на всех компьютерах.
Как насчет интерфейса для управления видеорежимом ? Представьте, что есть железка, которая может копировать спрайты и выводить результат на экран. Придумайте простые команды. У вас есть опыт разработки игр и вы знаете сложности в графике Спектрума.
denpopov
20.06.2015, 12:51
Придумайте простые команды. У вас есть опыт разработки игр и вы знаете сложности в графике Спектрума
Покопайся в плане гр.режимов СэмКуп или Таймекса. ДенисГрачев с мультиколором немного помаялся, я думаю, что ему подобные бы режимы пошли на пользу.
Я считаю, что надо разработать не видеокарту, а видеорежим, который будет работать на всех компьютерах
И что ты разработаешь? тут такие эксперты насоветуют, что хоть плачь:v2_dizzy_facepalm:
Покопайся в плане гр.режимов СэмКуп или Таймекса. ДенисГрачев с мультиколором немного помаялся, я думаю, что ему подобные бы режимы пошли на пользу.
И что ты разработаешь? тут такие эксперты насоветуют, что хоть плачь:v2_dizzy_facepalm:
Может он сам что посоветует. И давайте не будем усложнять - обойдемся пока без мультиколоров. Нам нужна просто графика. Чтобы Диззи был белым на фоне дерева и дерево не стало белым. И чтобы просто и быстро. Это основные критерии. Программистам виднее. Мы же можем спросить - а как это сделать проще ?
Большинство игр можно сделать, используя видеорежим, предлагаемый мной. И не надо усложнять !
---------- Post added at 15:08 ---------- Previous post was at 14:56 ----------
Вот отличная картинка из какой-то демы:
http://i023.radikal.ru/1506/64/51db23c2e330t.jpg (http://i023.radikal.ru/1506/64/51db23c2e330.png)
Очень красиво! Даже 15 цветов не мешает. Но - догадайтесь, что не так ?
А как бы игра выглядела лучше в новом режиме графики ! Не надо гнаться за 3D, большим количеством цветов, спрайтами как Денди и Сега. Устранить основной недостаток-клешинг, сделать работу простой и быстрой и этого достаточно !
denpopov
20.06.2015, 13:16
Может он сам что посоветует. И давайте не будем усложнять - обойдемся пока без мультиколоров. Нам нужна просто графика
Как это - "Не будем усложнять"? оО. Как это - просто графика? Диззи без клэшинга атрибутов?
Короче, я покидаю этот трэд и трепло кормить ен буду.
А зачем мультиколор, если можно сделать просто колор 32K?
Можно же два экрана у 128к спектрума наложить средствами видеокарты, исключая мерцание, и получим больше цветов и меньше клешинга.
Lethargeek
20.06.2015, 14:31
нужна просто графика. Чтобы Диззи был белым на фоне дерева и дерево не стало белым. И чтобы просто и быстро. Это основные критерии. Программистам виднее. Мы же можем спросить - а как это сделать проще?
Мы когда-то обсуждали узким коллективом очень давно, на какую внешнюю видеокарту было бы проще переделывать старые игрушки. Схема приблизительно такова - перехват на шине записи в экранную область Спека и соотв-но запись в память видеокарты до восьми пикселей (многобитных, но для совместимости на два цвета атрибуты будут влиять; после резета эти два и привязаны к 0 и 1 спектрумовской записи в растр). Далее, вывод спрайта в большинстве игрушек такой примерно: чтение (побайтно) с экрана, чтение маски, чтение спрайта, AND с маской, OR со спрайтом, запись в экран. Это всё достаточно заменить на: чтение маски, запись маски, чтение спрайта, запись спрайта. И при входе в процедуру включить режим, при котором при каждой чётной записи в экран единицы - прозрачный цвет, а нули - цвет маски (допустим, чёрный); а для каждой нечётной записи нули - прозрачный цвет, единицы - цвет спрайта. Потом выключить (для оставленных без изменений процедур печати фона, текста, стирания). Это если минимально хотим вмешаться, только чтобы клэшинг убрать. Правда, на старом спековском экране спрайты будут затирать фон (что неважно, если вывод только через новую видеокарту предполагается, а можно сделать, чтоб игра и на обычном Спеке шла без отличий, а через видеокарту - уже без клэшинга, лишь слегка замедлится процедура из-за лишней записи фона с маской).
---------- Post added at 14:31 ---------- Previous post was at 14:27 ----------
Копирование спрайтов из буфера спрайтов в буфер экрана - аппаратное
при копировании это получается уже блиттер, а не аппаратные спрайты
но тогда уж делать его нормально, без спрайтовых ненужных ограничений
не совсем понял, что значит:
Карта не занимает порты компьютера - пересылка команд видеокарте идет через адреса атрибутов
это что же, атрибутами как для Спека уже будет пользоваться нельзя?
при копировании это получается уже блиттер, а не аппаратные спрайты
но тогда уж делать его нормально, без спрайтовых ненужных ограничений
Я же говорю - зачем нам аппаратные спрайты с их ограничениями. Нам достаточно аппаратного копирования. Z80 разгружается и ту же игру можно сделать быстрее.
это что же, атрибутами как для Спека уже будет пользоваться нельзя?
Я предлагал после сброса - стандартный экран. Записью подряд три раза в определенный из адресов атрибутов, например, чисел 1, 2, 3. Включаем новый видеорежим. Однократной записью 0 - выключаем. Возвращается стандартный.
При использовании адресов атрибутов несколько преимуществ. Использование адресов в ОЗУ не занимает адресов портов. И запись в ОЗУ быстрее записи в порт. Можно первые 256 или 512 байтов атрибутов использовать для загрузки спрайтов или картинок в видеокарту, например, командой LDIR.
---------- Post added at 17:42 ---------- Previous post was at 17:38 ----------
Можно же два экрана у 128к спектрума наложить средствами видеокарты, исключая мерцание, и получим больше цветов и меньше клешинга.
Это нужно делать для стандартного экрана. Для нового - не надо.
---------- Post added at 17:55 ---------- Previous post was at 17:42 ----------
Мы когда-то обсуждали узким коллективом очень давно, на какую внешнюю видеокарту было бы проще переделывать старые игрушки. Схема приблизительно такова - перехват на шине записи в экранную область Спека и соотв-но запись в память видеокарты до восьми пикселей (многобитных, но для совместимости на два цвета атрибуты будут влиять; после резета эти два и привязаны к 0 и 1 спектрумовской записи в растр). Далее, вывод спрайта в большинстве игрушек такой примерно: чтение (побайтно) с экрана, чтение маски, чтение спрайта, AND с маской, OR со спрайтом, запись в экран. Это всё достаточно заменить на: чтение маски, запись маски, чтение спрайта, запись спрайта. И при входе в процедуру включить режим, при котором при каждой чётной записи в экран единицы - прозрачный цвет, а нули - цвет маски (допустим, чёрный); а для каждой нечётной записи нули - прозрачный цвет, единицы - цвет спрайта. Потом выключить (для оставленных без изменений процедур печати фона, текста, стирания). Это если минимально хотим вмешаться, только чтобы клэшинг убрать. Правда, на старом спековском экране спрайты будут затирать фон (что неважно, если вывод только через новую видеокарту предполагается, а можно сделать, чтоб игра и на обычном Спеке шла без отличий, а через видеокарту - уже без клэшинга, лишь слегка замедлится процедура из-за лишней записи фона с маской).
Очень интересно, а что делать с атрибутами ? Можно было бы для нового видеорежима записать атрибут с установленным битом FLASH, затем байт спрайта.
Заглянул сюда Очень сложная штука.
Кстати да, сделано добротно, почти все хотелки там есть. TSL молодец, в техническом плане.
Но, сложновато разбираться среднему программеру.
У zst, , карта на порядок по-проще.
Блитер и всё.
Вообщем, каждому своё.
---------- Post added at 16:23 ---------- Previous post was at 16:00 ----------
Мы когда-то обсуждали узким коллективом очень давно, на какую внешнюю видеокарту было бы проще переделывать старые игрушки. Схема приблизительно такова
Зачем такие битплановые "заморочки" ещё и с привлечением z80.
Я думаю, не особо нужно, т.к.
как-только мы нашли в переделываемой игре коорд спрайта,
мы оправляем эти коорд видюхе, которая быстро нарисует спрайт,
без привлечения z80.
s_kosorev
20.06.2015, 16:26
Ну у блиттера тоже есть свои минуса.
К примеру надо построить фрейм игрушки, 320х200х16бит = 120кб
Что бы построить кадр надо
На примере SNES марио
1. Залить задний план фоном (градиент неба) - 120кб
2. Нарисовать задник (тучки, горы) , пусть будет из не перекрывающихся кусков, скопировать из теневой области = 240кб
3. Нарисовать игровое поле, 25% заполнение экрана 60кб
4. Спрайты, HID итд, пусть на все про все еще 20кб
5. Прочитать буфер для вывода на экран 120кб
Если марио не классический, а скрол постоянный, то эти телодвижения надо делать каждый раз
Итого на простенькую игрушку 600кб на кадр, 30мб потом данных в секунду.
Не кажется многовато для простейшего марио с плавным скролом?
К примеру на спрайтовой видеокарте на все тоже самое понадобилось
1. Фон формируется аппаратно = 0
2. Задник = 120кб, только чтение данных
3. Поле = 30кб
4. Спрайты HID итд = 10кб
5. Буфер читать не надо, его нет
Итого на кадр приходится 160кб или 8мб в секунду
denpopov
20.06.2015, 16:32
парни, тормозите, а то изгои на #z80 уже угорают.
зы:блитер нужен.
Lethargeek
20.06.2015, 16:47
Я же говорю - зачем нам аппаратные спрайты с их ограничениями. Нам достаточно аппаратного копирования.
тогда надо не по "номерам" обращаться, а указывать длину и конфигурацию
а то вдруг захотим небольшой кусок отдельно отобразить
Я предлагал после сброса - стандартный экран. Записью подряд три раза в определенный из адресов атрибутов, например, чисел 1, 2, 3. Включаем новый видеорежим. Однократной записью 0 - выключаем. Возвращается стандартный.
а зачем два разных режима-то? пусть всё время только в новом работает
а для совместимости просто выбор пары цветов исходных для нулей и для единиц
эти два и будут "атрибутнозависимы", и при выводе подменяться на атрибутные
При использовании адресов атрибутов несколько преимуществ. Использование адресов в ОЗУ не занимает адресов портов. И запись в ОЗУ быстрее записи в порт. Можно первые 256 или 512 байтов атрибутов использовать для загрузки спрайтов или картинок в видеокарту, например, командой LDIR.
снова вспоминаючи старое: запись #NN в порт видеокарты (один-единственный) выбирает нужный
диапазон адресов #NN00-#NNFF, куда запись перехватывается уже как в управляющие порты
можно на пзу назначить, чтоб не портить данные в озу, если всё занято
но тогда записи в порты не запоминаются (мб нужно, если девайс пассивный)
Очень интересно, а что делать с атрибутами ?
ничего не делать, как писали так и пишем прямо в экран
и видеокарта себе тоже продублирует эти записи
---------- Post added at 16:35 ---------- Previous post was at 16:34 ----------
Зачем такие битплановые "заморочки" ещё и с привлечением z80.
да необязательны битпланы (они были бы удобней для рассыпухи), важен сам принцип
---------- Post added at 16:38 ---------- Previous post was at 16:35 ----------
как-только мы нашли в переделываемой игре коорд спрайта,
мы оправляем эти коорд видюхе, которая быстро нарисует спрайт,
речь зашла о простоте переделки игр
так надо же найти и выдрать еще и графику
и загрузить отдельно в память видеокарты
что сложнее правки лишь процедуры
---------- Post added at 16:44 ---------- Previous post was at 16:38 ----------
К примеру надо построить фрейм игрушки, 320х200х16бит = 120кб
Что бы построить кадр надо
На примере SNES марио
делать так неэффективно - необязательно
---------- Post added at 16:47 ---------- Previous post was at 16:44 ----------
Не кажется многовато для простейшего марио с плавным скролом?
не покажется для того, что сможет не только в марио
shurik-ua
20.06.2015, 19:08
Аппаратная точка не помешала бы, ну и линии кружочки с заливкой - совсем хорошо было бы )
s_kosorev
20.06.2015, 21:11
Аппаратная точка не помешала бы, ну и линии кружочки с заливкой
зачем? какому проценту по вообще может понадобиться такой функционал?
Зачотная тема, адназначна.
И давайте не будем усложнять - обойдемся пока без мультиколоров. Нам нужна просто графика. Чтобы Диззи был белым на фоне дерева и дерево не стало белым. И чтобы просто и быстро
да вроде уже давно решение есть (https://github.com/raydac/zxpoly)
https://raw.githubusercontent.com/raydac/zxpoly/master/docs/screenshots/atw_zxpoly.png
да еще и не только для игр, но и текстовых редакторов и жывотных убивать не надо
shurik-ua
20.06.2015, 23:30
зачем? какому проценту по вообще может понадобиться такой функционал?
Да какие уж там проценты - одного человека достаточно, например вот человек спрашивает как побыстрее линию нарисовать - http://zx-pk.ru/showpost.php?p=811234&postcount=43 - ему если дать аппаратную точку или линию, он глядишь и DOOM соберёт ))
Lethargeek
21.06.2015, 00:37
да вроде уже давно решение есть
не простое и не быстрое нифига
требует ВСЮ графику переделывать
и не может разным цветом один объект
не может разным цветом один объект
Вообще-то может.
Lethargeek
21.06.2015, 02:53
Вообще-то может.
можно в разные цвета раскрасить объект - но только в одном варианте
чтобы просто напечатать букву другого цвета, требуется копия этой буквы
чтобы просто напечатать букву другого цвета, требуется копия этой буквы
Требуется лишь спрайты в каждой из четырёх битпланов рисовать так, чтобы нужные цвета в одном объекте получить.
Lethargeek
21.06.2015, 06:26
Требуется лишь спрайты в каждой из четырёх битпланов рисовать так, чтобы нужные цвета в одном объекте получить
"лишь", хехе... они все рисуются одинаково, адреса-то совпадают для всех битпланов
и все команды жёстко синхронизированы, отличаются лишь данные в адресах
с такой схемой цвет без копии поменять (причём если на любой - только с белого)
можно через лишний and с цветомаской (для которой еще надо регистр выделить)
и таки в код программный лезть придётся при переделках
Линии и буквы - это нужно. Но давайте все делать поэтапно. Добавим потом. Пока линии будем рисовать спрайтом с одной точкой, а буквы будут одного цвета. Давайте вернемся к выводу картинок в обычных играх. Например, мы хотим сделать новую игру "Диззи".
http://i023.radikal.ru/1506/64/51db23c2e330t.jpg (http://i023.radikal.ru/1506/64/51db23c2e330.png)
Когда Диззи переходит в другое место надо нарисовать картинку/фон, а потом Диззи. На приведенной картинке видно, что она рисуется из нескольких типов маленьких картинок-квадратиков размером 8х8 точек. Их называют тайлами. Нарисуем на черновике область размером 32х24 клетки и пронумеруем каждую клетку номером тайла. Теперь нам надо изобразить эти тайлы на экране.
Начнем заполнение экрана с левого верхнего угла. Установим координаты Y=0, X=0. Далее укажем размеры тайла LY=8, LX=8, количестов тайлов в строке К = 32. Потом подаем команду PRINT, 32 номера тайлов. Видеокарта принимает поток данных и записывает в буфер команд. И постепенно начинает по номеру и размеру тайла высчитывать адрес в буфере спрайтов, адрес на экране, копировать по 8 точек за раз. Короче - заниматься своими делами.
А в это время Z80 меняет координаты на Y=8, X=0, команду PRINT, другие 32 номера тайлов. Так мы зарисуем тайлами весь экран.
Теперь нам надо нарисовать Диззи. Он у нас размером 20х15 точек. Значит LY=20, LX=15. Далее координаты, например, Y=152, X=201. Спрайт один, значит К=1. Далее команду PRINT, номер спрайта Диззи.
И все. Как видите, все просто и быстро.
Спрайт с номером 0 не копируется - только пропускается место размером со спрайт. Это почти как пробел в тексте, только картинка под ним не будет затираться. Это позволит выводить тайлы и спрайты с промежутками. Например, когда нужно наложить сверху второй план: редкие камешки, кустики, травинки, деревья и т.п. объекты.
Нужно определиться с количеством байтов на каждый параметр. LY, LX, К - по одному байту, Y, X, N - по два (YH, YL, XH, XL, NH, NL). Тут все понятно.
Но нужно проработать эффективную систему для записи команд в видеокарту. Мы можем выделить 256 разных адресов для разных команд или подавать их все через один адрес, чередую КОМАНДУ и ДАННЫЕ или передавать КОМАНДЫ и ДАННЫЕ с помощью команды LDIR через область 256/512 байт. Какой способ лучше ?
s_kosorev
21.06.2015, 09:37
Нужно определиться с количеством байтов на каждый параметр. LY, LX, К - по одному байту, Y, X, N - по два (YH, YL, XH, XL, NH, NL). Тут все понятно.
Но нужно проработать эффективную систему для записи команд в видеокарту. Мы можем выделить 256 разных адресов для разных команд или подавать их все через один адрес, чередую КОМАНДУ и ДАННЫЕ или передавать КОМАНДЫ и ДАННЫЕ с помощью команды LDIR через область 256/512 байт. Какой способ лучше ?
Писать процеесором команды это тоже расход проца бесполезный, команды надо в памяти хранить и блок по смыслу аналогичный DMA их копирует в порты сам, как только завершилось выполнение предыдущей команды.
---------- Post added at 09:37 ---------- Previous post was at 09:32 ----------
ему если дать аппаратную точку или линию, он глядишь и DOOM соберёт ))
глупости, аппаратную точку возможно даже дольше будет выводить чем програмную, так как надо кучу параметров настроить, записать их итд, адреса соседних точек обычно вообще элементарно вычисляются, а тут целая история буде
На скорую набросал вывод 640х480@60Hz 24bpp + текстовый режим 80x30 16 цветов вторым слоем.
52627
640х480=921600 байт видео буфер, точки хранятся по три байта линейно как [RRRRRRRR,GGGGGGGG,BBBBBBBB],[RRRRRRRR,GGGGGGGG,BBBBBBBB]...
shurik-ua
21.06.2015, 10:36
глупости, аппаратную точку возможно даже дольше будет выводить чем програмную
не знаю как вы себе видите аппаратную точку, но я делал так:
;hl - x,y coord
ld ($5c00),hl
после записи старшего байта, через 2 такта точка уже нарисована
мне кажется быстрее некуда )
кстати если делать точку для режима "байт на точку" то рисовать точку получится вообще за такт.
На скорую набросал вывод 640х480@60Hz 24bpp + текстовый режим 80x30 16 цветов вторым слоем.
52627
640х480=921600 байт видео буфер, точки хранятся по три байта линейно как [RRRRRRRR,GGGGGGGG,BBBBBBBB],[RRRRRRRR,GGGGGGGG,BBBBBBBB]...
MVV, сделай, пожалуйста режим 320х240 RRRRR, GGGGG, BBBBB для частоты SDRAM 84 MHz.
Типа так (https://en.wikipedia.org/wiki/File:MSX2plus_YJK%26YAE_palette_color_test_chart.p ng):
Заполнять 640х480 будет трудновано. Спрайты будут в 4 раза больше и копирование будет в 4 раза медленнее. Также три байта на 1 точку многовато. Двух байтов на точку для игр должно хватить.
после записи старшего байта, через 2 такта точка уже нарисована
мне кажется быстрее некуда )
кстати если делать точку для режима "байт на точку" то рисовать точку получится вообще за такт.
Наверно у тебя память статика. У SDRAM 1 точку (одно слово, 15 бит) надо рисовать тактов 6. Поэтому проще рисовать сразу 8 точек за 13 тактов, маскируя сигнал записи для лишних точек.
MVV, а у ReVeRse какая тактовая частота подается на FPGA и как получаешь частоту вывода точек 640x480 60 Гц ?
s_kosorev
21.06.2015, 13:37
после записи старшего байта, через 2 такта точка уже нарисована
мне кажется быстрее некуда )
1. Цвет?
2. для 320x240 в 16битный регистр не влезет, возникают нюансы
Мне кажется, что у Z80 будет много свободного времени на вычисления. Сделали ведь ELITE. А там все рисовалось программно. У нас достаточно только вычислить координаты точки, остальное делает видеокарта.
s_kosorev
21.06.2015, 13:47
Гораздо более адекватно реализовать блок который автоинкрементом координаты менять может
Набор портов может быть к примеру следующий
1. 2байта коррдина X
2. 1байт координата Y
3. 2 байта fixed point прирощение X
4. 2 байта fixed point прирощение Y
5. 2 байта цвет точки
Запись в видеопамять происходит при записи цвета, после запси срабатывают приращения координат
что дает?
можно линии, спрайты процессором рисовать, причем нужно фактически только половина операций, только чтение из памяти и запись цвета
Если додумать немного и к примеру что бы по достижению определенной координаты X она в начальное значение сбрасывалась и блок сам мог данные из памяти брать, получается уже нечто похожее на блиттер с маштабированием, даже больше, блок которым можно какие никакие текстуры выводить, вот вам и DOOM
Наверно у тебя память статика. У SDRAM 1 точку
Так всё таки будет стоять статика 1 метр + 8 метров SDRAM,
верно ?
Так всё таки будет стоять статика 1 метр + 8 метров SDRAM,
верно ?
Наверно лучше сделать карту немного помедленнее, без статики. Да и метр статики это две микросхемы. Громоздко было бы. И портировать на Speccy2010 и ReVeRse было бы труднее. А так, если у ReVeRse входные такты тоже 20 МГц, как у Speccy2010, то и на видеокарту надо поставить тоже самое.
Возможности закрасить экран три раза за кадр должно хватить. Не так быстро, зато останется совместимость.
Линии и буквы - это нужно. Но давайте все делать поэтапно
Думаю линии тоже "в кассу", есть же игры wire-frame псевдо 3д.
s_kosorev
21.06.2015, 14:01
Так всё таки будет стоять статика 1 метр + 8 метров SDRAM,
верно ?
это сколько ног надо, 19+16+5 SRAM 13+16+4+2+2 SDRAM 15+2 Видео 16+8+8 CPU это 126 USER IO + меловчевка всякая, это BGA корпус, стоимость устройства какая планируюется?
это сколько ног надо, 19+16+5 SRAM 13+16+4+2+2 SDRAM 15+2 Видео 16+8+8 CPU это 126 USER IO + меловчевка всякая, это BGA корпус,
ZX-BUS/ZST-BUS 35
SDRAM - 38
VGA 5+5+5+2
-------------------------------
итого: 90
стоимость устройства какая планируюется?
2 т.
Да и метр статики это две микросхемы.
А если 512КБ статики, меньше чипов ?
Наверно лучше сделать карту немного помедленнее, без статики. Да и метр статики это две микросхемы. Громоздко было бы. И портировать на Speccy2010 и ReVeRse было бы труднее. А так, если у ReVeRse входные такты тоже 20 МГц, как у Speccy2010, то и на видеокарту надо поставить тоже самое.
Возможности закрасить экран три раза за кадр должно хватить. Не так быстро, зато останется совместимость.
ИМХО, какая-то "мифическая" совместимость.
Получается сами себе порезали возможности карты.
Вообщем, решать конечно автору.
Может он и прав.
Схема то точно будет попроще, если без статики.
Надо, чтобы была максимальная совместимость, иначе 30 быстрых карт, которые я смогу сделать будут без программного обеспечения. Желательно, чтобы была совместимость и с TS-LABS. Надеюсь он не будет сильно разгонять свою видеокарту, чтобы не остаться один.
Если есть совместимость. можно будет писать новые игры в эмуляторе и она будет работать на перечисленных компьютерах и видеокартах. Должен быть какой-то стандарт. И этим стандартом я предлагаю сделать новый режим графики.
Надо, чтобы была максимальная совместимость
Хорошо.
SDRAM будет один чип или два ?
На какой частоте ?
Сколько байтов нужно для адресации точки в SDRAM 8Mбайт ? Нам понадобится группировать тайлы и спрайты одинакового размера в банки по 256 шт. У каждого банка есть описание: адрес начала, ширина спрайта, высота спрайта и номер. Тогда при печати тайлов травы надо выбрать определенный банк. После этого не надо будет указывать размер и достаточно будет однобайтного номера тайла в банке тайлов.
---------- Post added at 17:08 ---------- Previous post was at 17:05 ----------
Хорошо.
SDRAM будет один чип или два ?
На какой частоте ?
SDRAM один чип. Частота 84 MГц. Может быть максимум 112 МГц. Желательно кратно 14 МГц. Если будет ПЛИС, то можно будет поставить PLL как в ZX-EVO. Если FPGA - то кварцевый генератор, например, на 100 МГц. Надо спросить у специалистов: MVV, TS-LABS.
Если ПЛИС - EPM1270ATC144, если FPGA - EP2C5Q208.
---------- Post added at 17:32 ---------- Previous post was at 17:08 ----------
Для адресации до 16 M хватит трех байтов адреса.
zst, за 2к сделать что-то быстрее и лучше чем ordroid-w вряд ли получится, уже проще его и прикручивать через gpio, но здравого смысла в этом нет, т.к. делать всё за спек он умеет сам.
Идея сделать новую видео карту/видео режим, сама по себе не плохая, по крайней мере можно чему-то да и научиться, а иначе зачем всё это?
В начале всегда трудно определиться и решить с чего начать. Возможность реализации видео режима на zx-evo, speccy2010, reverse, de1... это уже хорошее начало.
Вот, на мой взгляд простое железо карты:
Слот подключения: ZX-Bus, Nemo-Bus, uBUS. Transceiver 74LVC16245A (опция)
Видеоинтерфейсы: VGA, HDMI (опция)
Память: SDRAM 4 Mбайт х 16 бит (опция)
FPGA: EP4CE6E22C8N (опция)
Конфигурация: M25P40 (опция)
GPIO: PS/2, SPI, SD Card, Delta sigma stereo (опция)
Универсальность: DivMMC, TurboSound, GeneralSound, SounDrive, Z-Controller...
zst, за 2к сделать что-то быстрее и лучше чем ordroid-w вряд ли получится, уже проще его и прикручивать через gpio, но здравого смысла в этом нет, т.к. делать всё за спек он умеет сам.
Идея сделать новую видео карту/видео режим, сама по себе не плохая, по крайней мере можно чему-то да и научиться, а иначе зачем всё это?
В начале всегда трудно определиться и решить с чего начать. Возможность реализации видео режима на zx-evo, speccy2010, reverse, de1... это уже хорошее начало.
Вот, на мой взгляд простое железо карты:
Слот подключения: ZX-Bus, Nemo-Bus, uBUS. Transceiver 74LVC16245A (опция)
Видеоинтерфейсы: VGA, HDMI (опция)
Память: SDRAM 4 Mбайт х 16 бит (опция)
FPGA: EP4CE6E22C8N (опция)
Конфигурация: M25P40 (опция)
GPIO: PS/2, SPI, SD Card, Delta sigma stereo (опция)
Универсальность: DivMMC, TurboSound, GeneralSound, SounDrive, Z-Controller...
Я тут прикидывал, если во 2 циклоне 142 I/O, то -90 = 52. Вывести их на гребенки. Может получится какой-нибудь контроллер SD-CARD подключить. Ведь если карту поставить в Ленинград или Пентагон - как загружать мегабайты спрайтов ?
Можно ли сделать в ReVeRse выход VGA с частотой точек 14 МГц ?
Я тут прикидывал, если во 2 циклоне 142 I/O, то -90 = 52. Вывести их на гребенки. Может получится какой-нибудь контроллер SD-CARD подключить. Ведь если карту поставить в Ленинград или Пентагон - как загружать мегабайты спрайтов ?
Я бы в начале попробовал бы всё как можно оптимально ужать. Не делать же новый speccy2010? Наличие sd card, delta-sigma, ps/2... вкус не испортят, на то она и опция. Узкое место это VGA(18 выводов) и ZX-Bus/Nemo-Bus (без оптимизации нужно 43 вывода FPGA). Можно отказаться от VGA в пользу HDMI (минимально нужно 8 выводов всего, разница впечатляет - 24bpp против 15bpp).
Можно ли сделать в ReVeRse выход VGA с частотой точек 14 МГц ?
Можно.
ZX_NOVOSIB
21.06.2015, 16:29
Ведь если карту поставить в Ленинград или Пентагон - как загружать мегабайты спрайтов ?
ага, ограничение TR-DOS дискеты 640 кб. Если применить нестандартный формат, то вроде бы можно еще несколько десятков кб выиграть.
---------- Post added at 19:29 ---------- Previous post was at 19:27 ----------
хотя игра Черный Ворон вообще на двух дискетах шла, и никто не возражал ))
Lethargeek
21.06.2015, 16:42
Когда Диззи переходит в другое место надо нарисовать картинку/фон, а потом Диззи. На приведенной картинке видно, что она рисуется из нескольких типов маленьких картинок-квадратиков размером 8х8 точек.
Из картинки это не очевидно. Не скажу именно за Диззи, но часто и прямоугольники разного размера сразу печатают.
Нарисуем на черновике область размером 32х24 клетки и пронумеруем каждую клетку номером тайла. Теперь нам надо изобразить эти тайлы на экране...
Ну зачем такое, не понимаю. Почему ты упорно хочешь блиттер кастрировать? Зачем жёстко сетка и мелкотайлы зафиксированного размера? Зачем делать неуниверсально и явно то, что само получается неявно по общей схеме?
Нужно определиться с количеством байтов на каждый параметр. LY, LX, К - по одному байту, Y, X, N - по два (YH, YL, XH, XL, NH, NL). Тут все понятно.
Блиттеру простому для переброски произвольного прямоугольного блока нужны только следующие параметры:
- способ наложения (или код прозрачного в простом случае)
- длина общая перебрасываемого блока
- длина "строки" блока
- приращение в конце строки для источника
- приращение в конце строки для приёмника
- адрес источника
- адрес назначения
Все параметры прошлой операции запоминаются, все записи параметров идут в буфер, а переброска может запускаться автоматически при получении полного адреса приёмника (или проще - только старшего байта). Так что если захотелось всё-таки порисовать мелкотайлами одинакового размера, после первого (с полным описанием всех параметров) можно только адреса-параметры изменять. В том числе, возможно, и процедурой, номера преобразующей в адреса. Но, по-моему, экран в формате списка пар "параметр, значение" в общем случае места занимать будет меньше и отрисовываться быстрее. И само собою, лучше смотреться.
Но нужно проработать эффективную систему для записи команд в видеокарту. Мы можем выделить 256 разных адресов для разных команд или подавать их все через один адрес, чередую КОМАНДУ и ДАННЫЕ или передавать КОМАНДЫ и ДАННЫЕ с помощью команды LDIR через область 256/512 байт. Какой способ лучше ?
Чередуя, ты "командой" выбираешь адрес порта фактически. То же самое, как записью в разные адреса, только медленней и не запоминаешь в обычной памяти. Лдиры, кстати, не нужны при правильной организации отрисовки, часто шевелить необходимо только несколько байт.
И повторю, для простой и быстрой переделки существующих игрушек нужно, чтоб стандартный спектрумовский экран незаметно и "прозрачно" для оригинального кода отображался в новый цветной экран (что позволит переделывать игры постепенно до любой степени). А не разные видеорежимы несовместимые с обязательной полной перекраской-перерисовкой.
Блиттеру простому для переброски произвольного прямоугольного блока нужны только следующие параметры:
самому простому блиттеру нужно всего то знать, от куда, куда и сколько. при этом было бы хорошо, если после выполнения операции регистры поменяли свои значения на n+размер.
Может получится какой-нибудь контроллер SD-CARD подключить. Ведь если карту поставить в Ленинград или Пентагон - как загружать мегабайты спрайтов ?
Правильный вопрос.
Я за набортный sd card. (IO выводов немного занимает.)
Насчёт аудио stereo выхода, я думаю это хорошо, но по выводам
как это уже будет, уместно или нет...
---------- Post added at 17:55 ---------- Previous post was at 17:27 ----------
за 2к сделать что-то быстрее и лучше чем ordroid-w вряд ли получится, уже проще его и прикручивать через gpio, но здравого смысла в этом нет, т.к. делать всё за спек он умеет сам.
Ещё есть опен сорсный gameduino 1, но по параметрам чуть слабее.
http://excamera.com/sphinx/gameduino/
Lethargeek
21.06.2015, 17:55
самому простому блиттеру нужно всего то знать, от куда, куда и сколько. при этом было бы хорошо, если после выполнения операции регистры поменяли свои значения на n+размер.
ты не путай, это называется DMA и для графики пригодно мало и ограниченно
s_kosorev
21.06.2015, 18:42
DDRII если есть смысл?
DDR2 с резисторами согласующими головняк, уж лучше DDR3
Alex Rider
21.06.2015, 18:49
Правильный вопрос.
Я за набортный sd card. (IO выводов немного занимает.)
Очень не надо. Потому как их уже расплодилось достаточно. Можно перекинуть графику и через Z80, или подружить через DMA с существующими.
ты не путай, это называется DMA и для графики пригодно мало и ограниченно
я ничего не путаю. если капнуть чуть глубже, то блиттер это разновидность дма, но с той лишь разницей, что дма просто пересылает, а блиттер ещё и наложение делать умеет. но в целом:
Блиттер (англ. Blitter) — первоначально микросхема или часть графического сопроцессора, осуществляющая быстрое копирование и наложения фрагментов изображений в памяти
На спринтере так оно и работает - пересылка + 3 режима наложения. но никто никогда не говорил, что там есть блиттер. кол-во параметров которое указал ты слишком велико. это всё лишнее нагромождение.
s_kosorev
21.06.2015, 19:04
а блиттер ещё и наложение делать умеет. но в целом:
DMA работает с блоком памяти, блитер работает с прямоугольным блоком изображения, разницу заметил? Можно конечно при помощи DMA заставить, но! нужно каждую строку изображения заново настраивать DMA то есть, процессор вместо того что бы заниматься чем то полезным, ждет когда DMA выведет строку, что бы настроить на вывод следующей.
Сделал наброски схемы в черновике ep4ce6e22 + spiflash (4) + sdram 4m16 (36) + hdmi (8) + sd (5) + zx-bus/nemo-bus (38), по выводам всё оптимально. Можно ещё i2c добавить под часы и ddc если это тут нужно. Размер платы предположительно 85х50мм, из-за разъема великовата выйдет. Не, ну можно переходник с разъемом и всё в BGA - FPGA и DDRII если есть смысл?
На вскидку может получится DivMMC, TurboSound, GeneralSound, SounDrive, Z-Controller... из коробки, ps/2 (2+2) и Audio (2) только добавить...
В следующей версии наверно сделать можно... Зависит то всё от zst.
Я бы на плате ZX-BUS разместил: генератор 50 МГц + ep4ce6e22 + spiflash (4) + sdram 4m16 (36)+схемы согласования с +3.3V на 5*74LVC245, стабилизаторы и разъем IDC-16M,
А на корпусе разместил бы плату с ЦАП R-2R, VGA и SD.
Опционально hdmi (8) + sd (5) или что-нибудь еще
Но по моим подсчетам SDRAM надо 38 io. На R-2R подал бы сигналы тоже через 2*74LVC245, как в ZX-EVO, так как выходы у FPGA высокоомные и будут вносить погрешности.
Хорошо бы еще входной регистр сдвига для настройки джамперами режимов работы видеокарты. Типа:
Частота кадров 48 / 50 Гц
Видеовыход SCART / VGA
SD вкл / выкл
...
На это потребуется дополнительный IO для данных, а на загрузку состояни джамперов и сдвг KSI+SSI
s_kosorev
21.06.2015, 19:16
А на корпусе разместил бы плату с ЦАП R-2R, VGA
зачем связываться с DAС если есть возможность HDMI? Cyclone IV если не путаю в QFP корпусе только 144пин, если больше то только BGA
s_kosorev
21.06.2015, 19:18
Если у кого то нет HDMI, можно воспользоваться китайским переходником, которые сейчас на кажом углу продают, либо предусмотреть посадочное место для микросхемы из переходника, правда не знаю доступны ли они в продаже.
DMA работает с блоком памяти, блитер работает с прямоугольным блоком изображения
конечно, особенно если учесть то, что спрайты в памяти лежат не прямоугольно, а линейно. исключение составляет только случай, когда нам нужно вывести не весь спрайт, а только его часть. Опять-таки посыл к Спринтеру, там аксель не забывает последнюю операцию, точнее её параметры. при включении девайса мы указываем размер данных и потом указываем на операцию и уже потом даём команду выполнить. даже когда мы выключаем аксель, он помнит размер последнего блока.
да и ждать когда он там что-то выполнит не требуется. он это выполняет быстрее, чем работает проц. соответственно я даю команду пересыла и тут же могу дать новую команду для нового блока. никаких ожиданий нет.
А на корпусе разместил бы плату с ЦАП R-2R, VGA и SD.
Под VGA(5:5:5) не хватает 7 выводов, да и в цвете и новизне ещё проигрыш. Можно SDRAM на 8 бит поставить вместо 16 бит, тем самым получишь old school VGA 15bpp. Вторая версия платы? Тоже вариант. Я через переходник на U16 когда тестирую видео получаю VGA 6bpp, это если HDMI нет :)
Но по моим подсчетам SDRAM надо 38 io.
36 для 4M16
s_kosorev
21.06.2015, 19:21
я даю команду пересыла и тут е могу дать новую команду для нового блока. никаких ожиданий нет.
А если надо вывести перекрывающихся блоков до 128х64 пикселя, да еще штук 10 на экран? На примере того же марио, задний фон, горы, деревья итд
Под VGA(5:5:5) не хватает 7 выводов, да и в цвете и новизне ещё проигрыш. Можно SDRAM на 8 бит поставить вместо 16 бит, тем самым получишь old school VGA 15bpp. Вторая версия платы? Тоже вариант. Я через переходник на U16 когда тестирую видео получаю VGA 6bpp, это если HDMI нет :)
36 для 4M16
SDRAM обязательно должна быть 16 бит.
Я считал 35 на ZX-BUS, 38 на SD-RAM, 17 на VGA, 1 на регистр = 91.
У циклона 4 с 144 ногами как раз столько. Только вот SD-CARD не влезает. Но у меня 2 лишних вывода от SD-RAM освободятся. 3 можно от ZX-BUS откусить (ненужные сигналы).
А если надо вывести перекрывающихся блоков до 128х64 пикселя, да еще штук 10 на экран? На примере того же марио, задний фон, горы, деревья итд
да, мне вот тоже это интересно, как оно на местной карте будет работать. как ты считаешь, что нужно для того, чтобы всё это вывести, особенно если учесть, что аппаратных спрайтов аля денди нет. наверно, раз есть (будет) своя память под спрайты, эти самые спрайты нужно будет в железку загрузить. ну сам вывод фоновой картинки, всякого уровневого фетиша и самого марио с его противниками, выводить будет в некотором цикле, в котором будет ритмично подсовывать карточке команды на вывод то одного, то другого, попутно ещё обрабатывать клавиатуру, звук и фиг знает чего ещё. ну т.е. довольно обычный набор процедур.
Lethargeek
21.06.2015, 19:38
конечно, особенно если учесть то, что спрайты в памяти лежат не прямоугольно, а линейно. исключение составляет только случай, когда нам нужно вывести не весь спрайт, а только его часть.
хто сказал, что исключение, из чего?
"спрайты" в принципе могут быть рисунками на "экране"
и загружаться целиком "экраном", и редактироваться
нынче правилом скорей является такой способ
На ZX-BUS можно урезать до 32:
ША и ШД = 24
ШУ 8: RD, WR, IORQ, MREQ, M1, INT, RD_TBUF, IORQGE
RESET подать на FPGA через регистр сдвига.
Я считал 35 на ZX-BUS, 38 на SD-RAM, 17 на VGA, 1 на регистр = 91.
Для SDRAM 4M16 (36), если больше 4M то (37) без CS# и CKE.
Чего так за VGA 15bpp? Думаю не проблема, две версии плат на вкус...
Stereo audio out (delta-sigma) я по любому ставлю :) SID, GS, TS... как-никак.
s_kosorev
21.06.2015, 19:44
в котором будет ритмично подсовывать карточке команды на вывод то одного, то другого, попутно ещё обрабатывать клавиатуру, звук и фиг знает чего ещё. ну т.е. довольно обычный набор процедур.
ну как минимум возможно несколько вариантов
1. Где то хранится набор команд и параметров и карта сам по этому Display List все выводит
2. Можно по окончании работы блиттера, вызывать прерывание процессору
Т.е. процессоро и карта работают асихронно и карта от процессора требует внимания только там где действительно нужно
хто сказал, что исключение, из чего?
"спрайты" в принципе могут быть рисунками на "экране"
и загружаться целиком "экраном", и редактироваться
нынче правилом скорей является такой способ
да это не важно где оно расположено, хоть на sd карте. изначально данные представлены линейно. как уж там экран будет устроен не знаю, но загрузив картинку или мелкий спрайт в память (буфер) карты, он изначально записан в линейно форме. а уже потом оно перемещается в экран, и получает некую структуру, уж как экран выглядит. не считая случаев, когда девайс рисует сразу из буфера спрайтов.
Для SDRAM 4M16 (36), если больше 4M то (37) без CS# и CKE.
Чего так за VGA 15bpp? Думаю не проблема, две версии плат на вкус...
Stereo audio out (delta-sigma) я по любому ставлю :) SID, GS, TS... как-никак.
HDMI как-то ново. А звук тоже через него ?
Вот думаю, может лучше SDRAM 8Mx16 бит, так как у них блоки по 512 байт, что пригодилось бы для 320 точек в строке.
1. Где то хранится набор команд и параметров и карта сам по этому Display List все выводит
хороший вариант. т.е. кодеру мало того, что нужно придумать как реализовать свои алгоритмы, ему ещё и листы сидеть писать (читай сценарий для карты). хотя что, ну на всяких пц под гфорсы же пишут шейдеры. ну тут тоже можно. да, вариант интересный.
2. Можно по окончании работы блиттера, вызывать прерывание процессору
скорей всего, когда карта закончит рисовать, проц ещё будет ачухрваться от посыла прошлой команды карточке. тут на спринтере 256 байт пересылаются за 3.65 такта проца. т.е. быстрее, чем команда nop. и для чего тогда нужно прерывание?
Lethargeek
21.06.2015, 19:48
Sayman, повторю: нафига же непременно в линейной форме?
мож они на пц были нарисованы в bmp и одним массивом залиты в файл
Sayman, повторю: нафига же непременно в линейной форме?
мож они на пц были нарисованы в bmp и одним массивом залиты в файл
я просто не знаю как правильно сформулировать. я потом по этому поводу скажу...
s_kosorev
21.06.2015, 19:52
хороший вариант. т.е. кодеру мало того, что нужно придумать как реализовать свои алгоритмы, ему ещё и листы сидеть писать (читай сценарий для карты). хотя что, ну на всяких пц под гфорсы же пишут шейдеры. ну тут тоже можно. да, вариант интересный.
Да вот какая разница, или сразу в порты писать или в DisplayList ? К тому же если в DisplayList предумостреть команды перехода на откуда дальше читать, то можно заготовки использовать и не надо его формировать постоянно. Хотя и из памяти заготовку копировать не намного сложнее, но можно было и развить тему, циклы итд
Да вот какая разница, или сразу в порты писать или в DisplayList ? К тому же если в DisplayList предумостреть команды перехода на откуда дальше читать, то можно заготовки использовать и не надо его формировать постоянно.
писать в порт долго. лучше куда то в область памяти кинуть, а карта заберёт. вариант листа интересен тем, что можно в нём описать все спрайты и последовательность вывода, включая условия. аля шейдеры (hlsl или подобное). чем не устраивает? файлик накидали, дали карточке каманду забрать и начать обработку, сами делаем свои дела. при этом в произвольный момент времени можно подкинуть новый лист. а в порт кидать это гемор. нафиг оно е надо.
но тогда, раз там будет целый сценарий. то карточке предусмотреть-таки выдавать прерывания. тогда будем знать что в какой стадии.
Я вообще думал про видео выходы как-то так:
- стандартный разъём VGA (RGB, H, V)
Если в видео-карту интегрирован PAL кодер:
- тюльпан композит
- стандартный s-video
s_kosorev
21.06.2015, 20:45
Если в видео-карту интегрирован PAL кодер:
- тюльпан композит
- стандартный s-video
такие преходники с HDMI тоже есть
HDMI как-то ново. А звук тоже через него ?
Со звуком пока я научился формировать пакеты и отправлять, а вот с содержимым пакетов пока непонятно, отправляю пакеты #84 Audio InfoFrame, #02 Audio Sample, #01 Audio Clock Regeneration (N/CTS) но телик молчит :( наверно ECC или содержимое не так собрано... нужны наглядные примеры передачи с их содержимым, как к примеру здесь (http://www.quantumdata.com/pdf/980_HDMI_Protocol_Analyzer_Module_UserGuide_RevA13 .pdf).
Я вообще думал про видео выходы как-то так:
- стандартный разъём VGA (RGB, H, V)
Вероятнее всего нужно делать две карты HDMI и VGA, т.к. вывода под завязку, а там уже по выбору кому что... Или ставить BGA.
s_kosorev
21.06.2015, 21:01
тут на спринтере 256 байт пересылаются за 3.65 такта проца. т.е. быстрее, чем команда nop. и для чего тогда нужно прерывание?
кстати, посчитал 3.65 такта, при 3.5мгц процессоре, это примерно 256мбайт в секунду, какая там память с спринтере стоит?
---------- Post added at 21:01 ---------- Previous post was at 20:48 ----------
нашел схему, 32бит SIMM, т.е. крутые чипы то на 33мгц могут отдавать данные, память организована как 16бит, то есть теоретический пик 66мб в секунду при монопольном страничном чтении данных, где то не правильно посчитал
Lethargeek
21.06.2015, 21:17
писать в порт долго. лучше куда то в область памяти кинуть, а карта заберёт.
дык порты можно и на память отображать))
вариант листа интересен тем, что можно в нём описать все спрайты и последовательность вывода, включая условия. аля шейдеры (hlsl или подобное). чем не устраивает?
буфер (очередь) команд (записей в порты) уже есть фактически дисплей-лист, чем не устраивает?
файлик накидали, дали карточке каманду забрать и начать обработку, сами делаем свои дела
это требует усложнения железки и подключения
ей бы лучше в память спектрума не соваться
только шину спектрумовскую слушать
Со звуком пока я научился формировать пакеты и отправлять, а вот с содержимым пакетов пока непонятно, отправляю пакеты #84 Audio InfoFrame, #02 Audio Sample, #01 Audio Clock Regeneration (N/CTS) но телик молчит :( наверно ECC или содержимое не так собрано... нужны наглядные примеры передачи с их содержимым, как к примеру здесь (http://www.quantumdata.com/pdf/980_HDMI_Protocol_Analyzer_Module_UserGuide_RevA13 .pdf).
Со временем наверно все заработает.
Вероятнее всего нужно делать две карты HDMI и VGA, т.к. вывода под завязку, а там уже по выбору кому что... Или ставить BGA.
Пока я думаю вывести свободных выводов FPGA (около 18) на разъем. К разъему можно будет подключить небольшую платку. На ней получаем 15 бит на резисторы R-2R. Поставить вместо двух буферов 74LVC245 три регистра. Управлять все тактовыми импульсами с FPGA. Через 8 выходов при 0 подавать 8 битов цвета, при 1 - остальные 7. По фронту записываем 8 битов в первый регистр, По спаду - из 1 во второй регистр и из FPGA в третий.
Так из 10 выходов получим 15. 5 на SD-CARD, 2 на KSI, SSI. 1 - на ввод данных с последовательного регистра с джамперами. Итого надо с FPGA подать 18 сигналов. Можно найти.
где то не правильно посчитал
выдержка из авторского мануала:
Скорость работы акселератора ограничивается только физической скоростью работы основного ОЗУ.
Определить время работы команды с акселератором можно по такой примерной формуле:
Время работы = время работы команды без акселератора + время работы акселератора
Время работы акселератора = число пересылаемых байт /7000000 (секунд)
буфер (очередь) команд (записей в порты) уже есть фактически дисплей-лист, чем не устраивает?
если ты имеешь в виду то, что я в порты железки кидаю набор команд который в буфере железки скапливается и потом выполняется, то не очень удобно. файлик я могу напихать на пц в текстовом редакторе. и не один, а несколько (например на каждый уровень разные сценарии вывода). Можно конечно потом просто этот файлик загрузить и в какой-то порт скинуть, как моды у ГСки.
s_kosorev
22.06.2015, 08:49
Время работы акселератора = число пересылаемых байт /7000000 (секунд)
2 байта на 1 такт процессора, то есть 256байт 128 тактов, похоже на правду
Таким образом, пришли к выводу, что каждой команде и параметру назначим свой адрес в области атрибутов? Будем записывать параметры в определенный адрес:
LD HL, 0 ; координата Y
LD (KOORD_Y), HL
LD HL, -3 ; координат X
LD (KOORD_X), HL
LD A, 32 ; количество тайлов в строке
LD (KOL), A
LD HL, #003F ; номера тайлов 1 и 2
LD (PRINT), HL
LD HL, #2902 ; номера тайлов 3 и 4
LD (PRINT), HL
аким образом, пришли к выводу, что каждой команде и параметру назначим свой адрес в области атрибутов? Будем записывать параметры в определенный адрес:
LD HL, 0 ; координата Y
LD (KOORD_Y), HL
LD HL, -3 ; координат X
LD (KOORD_X), HL
LD A, 32 ; количество тайлов в строке
LD (KOL), A
LD HL, #003F ; номера тайлов 1 и 2
LD (PRINT), HL
LD HL, #2902 ; номера тайлов 3 и 4
LD (PRINT), HL
Нужно ещё послать команду установки размера тайла LY=8, LX=8.
Если всего 256 номеров тайлов, то тут получается ограничение,
на размер тайловой графики,
всего-то можно адресовать 256 * 8 * 8 = 16КБ из 4 МБ ?
Какая формула, у видео-карты, для пересчета номера тайла в линейный адрес видео-памяти ?
---------- Post added at 13:29 ---------- Previous post was at 12:43 ----------
К разъему можно будет подключить небольшую платку.
Может туда PAL кодер добавить ?
s_kosorev
22.06.2015, 13:36
Таким образом, пришли к выводу, что каждой команде и параметру назначим свой адрес в области атрибутов? Будем записывать параметры в определенный адрес:
LD HL, 0 ; координата Y
LD (KOORD_Y), HL
LD HL, -3 ; координат X
LD (KOORD_X), HL
LD A, 32 ; количество тайлов в строке
LD (KOL), A
LD HL, #003F ; номера тайлов 1 и 2
LD (PRINT), HL
LD HL, #2902 ; номера тайлов 3 и 4
LD (PRINT), HL
Собсно не особо понятно, где тут акселерация, проц должен будет за видеокартой пританцовывать?
Lethargeek
22.06.2015, 14:47
:v2_dizzy_wall: Нет, я всё же никогда не смогу понять, зачем делать растровый нормальный экран и блиттер и превращать их в жалкий тайловый движок а-ля денди (при том, что конвертация игрушек лишь усложнится). Автор, видно, тоже не понимает, что он хочет сделать и для чего. Ладно, я свою ТЗ высказал. Пожелаю всем успехов в мертворождении. :v2_dizzy_bye:
Нет, я всё же никогда не смогу понять, зачем делать растровый нормальный экран и блиттер и превращать их в жалкий тайловый движок а-ля денди (при том, что конвертация игрушек лишь усложнится). Автор, видно, тоже не понимает, что он хочет сделать и для чего. Ладно, я свою ТЗ высказал.
Хотелось бы конструктива.
Ну вот напиши, как ты думаешь лучше, отрисовать слой тайлов.
Нужно ещё послать команду установки размера тайла LY=8, LX=8.
Да, когда меняем размер тайлов/спрайтов надо подать команду типа
LD HL, #0808
LD (SIZE), HL
Если всего 256 номеров тайлов, то тут получается ограничение,
на размер тайловой графики,
всего-то можно адресовать 256 * 8 * 8 = 16КБ из 4 МБ ?
Для адресации памти до 16 М достаточно три байта. Программист при проектировании игры распределяет имеющуюся память под тайлы, спрайты, картинки, шрифты и т.п. графические объекты. Группирует в блоки до 256 спрайтов одинакового размера. Начало каждого блока в ассемблере называет как ему удобно, например, TILES1, TILES_20X20, SPRITES1_16X16, SPRITES_100X100.
Как только переходим к печати тайлов или спрайтов из другого блока загружаем в видеокарту адрес этого блока спрайтов:
LD HL,SPRITES_100X100
LD (SPR_ADDR), HL
Какая формула, у видео-карты, для пересчета номера тайла в линейный адрес видео-памяти ?
АДРЕС НАЧАЛА БЛОКА * 256+НОМЕР СПРАЙТА * РАЗМЕР ПО-ГОРИЗОНТАЛИ * РАЗМЕР ПО-ВЕРТИКАЛИ
Может туда PAL кодер добавить ?
Предполагаю разъем SCART. Сигналы с него можно подать на внешний PAL-кодер, который есть в продаже.
---------- Post added at 18:28 ---------- Previous post was at 17:54 ----------
Собсно не особо понятно, где тут акселерация, проц должен будет за видеокартой пританцовывать?
Совсем без команд ничего работать не будет. Микропроцессор ведь не знает, что ему делать, пока мы не загрузим ему программу с игрой. Так и видеокарте нужно говорить, что делать, где и что рисовать. А вот рисует она сама и быстро.
Давайте прикинем ускорение. Сколько пришлось бы выполнить работы микропроцессору при копировании тайла минимального размера 8х8 точек. Так как точка представлена двумя байтами размер тайла 8х8х2=128 байтов.
Даже важно не количество точек, важно, что Z80 это делал бы программным способом долго, а с помощью нового режима графики быстро, достаточно для динамичных игр.
Шина данных у FPGA 16 бит, а у Z80 - 8 (FPGA быстрее в 2 раза).
Тактовая частота у FPGA 84 MHz, а у Z80 - 3,5 (FPGA быстрее еще в 24 раза)
У Z80 команды копирования 1 байта выполняются около 20 тактов, а у FPGA копирование одной точки - 3 (FPGA быстрее еще в 3 раза)
Итого - ускорение в 2 * 24 * 3 = 144 по сравнению с программным копированием спрайта.
Кроме этого Z80 выполняет программы последовательно и кроме чисто копирования должен вычислять адрес каждой точки, что занимает определенное время. А в FPGA процессы могут выполняться параллельно, то есть при копировании точки может вычислять адрес следующей точки в буфере спрайта и буфере экрана.
Возможно вы сравниваете ускорение нового режима с видеокартами Денди, Сеги и PC, поэтому вам кажется мало. Но для игр, какие делают на Спектруме, ускорение в 150 раз - это уже очень хорошо.
---------- Post added at 18:36 ---------- Previous post was at 18:28 ----------
:v2_dizzy_wall: Нет, я всё же никогда не смогу понять, зачем делать растровый нормальный экран и блиттер и превращать их в жалкий тайловый движок а-ля денди (при том, что конвертация игрушек лишь усложнится). Автор, видно, тоже не понимает, что он хочет сделать и для чего. Ладно, я свою ТЗ высказал. Пожелаю всем успехов в мертворождении. :v2_dizzy_bye:
Что не так ? Важно, что новый режим упростит написание новых игр, возможно также поможет в ускорении старых. Если что-то мы упустили - пишите, как это исправить. Только с доказательствами, что так эффективнее. Как раз Денди мы копировать не собираемся, но и 3D делать тоже нет. Надо немного ускорить обычную графику Спектрума. Тайлы и спрайты просто помогают построить изображение из повторяющихся элементов. Так почти везде делают.
s_kosorev
22.06.2015, 17:03
Совсем без команд ничего работать не будет. Микропроцессор ведь не знает, что ему делать, пока мы не загрузим ему программу с игрой. Так и видеокарте нужно говорить, что делать, где и что рисовать. А вот рисует она сама и быстро.
рисует быстро, но без процессора она сразу становится и процессор что бы заниматься чем то другим, синхронизируется под видеокарту, что бы как можно быстрее подавать следующие команды
---------- Post added at 16:57 ---------- Previous post was at 16:52 ----------
Давайте прикинем ускорение. Сколько пришлось бы выполнить работы микропроцессору при копировании тайла минимального размера 8х8 точек. Так как точка представлена двумя байтами размер тайла 8х8х2=128 байтов.
понятно что быстрее чем процессором, но! пока рисует видеокарта, процессор крутится в цикле и к примеру ожидает бит готовности, что можно следующую команду подавать, что фактически означает безсмысленое проедание ресурсов онного, нужно не только быстро рисовать, но еще и грамотно с процессором синхронизироваться.
---------- Post added at 17:03 ---------- Previous post was at 16:57 ----------
Sayman подкинул хрошую идею с шейдерами, это вообще идеальный вариант, у карты грубо говоря есть FSM которая умеет команды читать и блиттер, написал простейший код в 2-3 десятка команд, видеокарта при помощи блиттера вывела вам тайловый слой, причем нет каких то заморочек с ограничением размеров итд, надо к примеру эмулировать поведение странного экрана спектрума, тот же шейдер может и эту задачу выполнять
Lethargeek
22.06.2015, 18:08
Что не так ?
ВСЁ не так. Повторю: зачем делать неуниверсально и явно то, что само получается неявно по общей схеме??
Важно, что новый режим упростит написание новых игр,
Их не будет. Ибо кто захочет делать игру отдельно под несовместимый новый режим, существующий в реале в нескольких экземплярах (если вообще существующий)
возможно также поможет в ускорении старых.
Не поможет. Ибо нет прозрачной совместимости со старым экраном - следовательно, трудоёмкость переделки сопоставима с написанием игрушки наполовину. Очень мало кто способен столько возиться.
Как раз Денди мы копировать не собираемся,
Как раз денди вы копировать и пытаетесь, причём именно что худшие его стороны, да еще неэффективным затратным способом.
Надо немного ускорить обычную графику Спектрума.
ОБЫЧНАЯ графика Спектрума ускоряется исключительно турбированием проца.
А ты предлагаешь новый и полностью несовместимый режим не-Спектрума.
Тайлы и спрайты просто помогают построить изображение из повторяющихся элементов.
Блиттер без дурацких ограничений помогает строить его не хуже, а гораздо лучше - из элементов произвольного размера и положения.
Слово "произвольный" тебе понятно? Это значит, что сетка тайлов одинакового размера туда тоже входит как частный случай.
Так почти везде делают.
"Везде делают" то, что позволяет делать железо.
Но зачем его искусcтвенно ограничивать?????
Чтобы вдруг лучше чем на денди не получилось?
:v2_dizzy_tired2:
---------- Post added at 18:06 ---------- Previous post was at 17:54 ----------
Хотелось бы конструктива.
Ну вот напиши, как ты думаешь лучше, отрисовать слой тайлов.
дык писал же: http://zx-pk.ru/showpost.php?p=812185&postcount=61
иииии? кто-нибудь отреагировал вообще? только sayman прицепился, но не к тому
---------- Post added at 18:08 ---------- Previous post was at 18:06 ----------
.
Lethargeek
22.06.2015, 18:25
если ты имеешь в виду то, что я в порты железки кидаю набор команд который в буфере железки скапливается и потом выполняется, то не очень удобно. файлик я могу напихать на пц в текстовом редакторе. и не один, а несколько (например на каждый уровень разные сценарии вывода). Можно конечно потом просто этот файлик загрузить и в какой-то порт скинуть, как моды у ГСки.
ну и наборов этих (тупо массивов) можно так же несколько заготовить
и потом их перекидывать в порты карты, совершенно никакой разницы
или ты непременно хочешь скармливать девайсу ASCII зачем-то?
(между прочим, занимающего в памяти больше места)
Lethargeek
22.06.2015, 18:29
MVV, для игрушек (мб кроме очень редких и специфических) чтение из памяти видеокарты вообще не нужно
для игрушек (мб кроме очень редких и специфических) чтение из памяти видеокарты вообще не нужно
Глянь какие сигналы на ZXBus ещё нужны. Может RTC(часы на бордюр) ещё добавить? Ethernet или USB контроллер, PS/2 keyboard?
дык писал же: http://zx-pk.ru/showpost.php?p=812185&postcount=61
Ясно,
ты привел универсальный интрефейс работы с блиттером.
Используя его можно нарисовать экран любой степени сложности.
Никакие дополнительные команды блитеру, придумывать не нужно.
дык писал же: http://zx-pk.ru/showpost.php?p=812185&postcount=61
иииии? кто-нибудь отреагировал вообще? только sayman прицепился, но не к тому
На что там реагировать надо? Я привел пример, как можно заполнить экран для игры Диззи по той картинке. А вам почему-то не понравилась жесткая сетка и фиксированный размер. C чего это они жесткие? Как раз наоборот - мы их можем выбирать. Какие тайлы были, такой размер и указан. Будут другие размеры - будет другая сетка. Мы сами выбираем размер тайлов и спрайтов при проектировании игры. Но если выбрали 8х8, значит так надо было. Что тут не так ?
Ну а насчет тайлов разного размера - это как-то странно, как ими заполнить экран без промежутков ? Сначала можем заполнить крупными весь экран, потом можно мелкими добавить случайные камешки или другого размера нарисовать одиночные деревья. Я ведь об этом писал.
По параметрам блиттера - так они у меня как раз такие.
По адресации - я согласен с вашим замечанием, что лучше писать по разным адресам - так и сделал, как вы написали.
Язык сломал писать все в множественном числе - перехожу на ты.
Печатать строку тайлов лучше одинакового размера (для данной полоски), при этом карта сама сможет определить адрес начала следующего спрайта в буфере спрайтов и в буфере экрана. Это же логично. Строка из спрайтов разного размера - это уже не строка, а неизвестно что.
Размер спрайтов настраивается, координаты начала строки спрайтов можно задать. Этого хватит, чтобы напечатать экран, какой желает программист.
---------- Post added at 22:18 ---------- Previous post was at 21:50 ----------
понятно что быстрее чем процессором, но! пока рисует видеокарта, процессор крутится в цикле и к примеру ожидает бит готовности, что можно следующую команду подавать, что фактически означает безсмысленое проедание ресурсов онного, нужно не только быстро рисовать, но еще и грамотно с процессором синхронизироваться.
Процессор пишет команды и данные в видеокарту. Она запоминает в буфер типа FIFO и начинает работать. Z80 ее не ждет.
Sayman подкинул хрошую идею с шейдерами, это вообще идеальный вариант, у карты грубо говоря есть FSM которая умеет команды читать и блиттер, написал простейший код в 2-3 десятка команд, видеокарта при помощи блиттера вывела вам тайловый слой, причем нет каких то заморочек с ограничением размеров итд, надо к примеру эмулировать поведение странного экрана спектрума, тот же шейдер может и эту задачу выполнять
Объясните еще раз подробнее.
MVV, для игрушек (мб кроме очень редких и специфических) чтение из памяти видеокарты вообще не нужно
это нужно чтобы знать что и где находится. удобно, например, для коллизий всяких.
Объясните еще раз подробнее.
что такое hlsl знаешь?
C-подобный язык высокого уровня для программирования шейдеров
так вот. если предположить, что у карты будет своё пзу (биос), который мог бы обрабатывать сценарии и компилировать в пригодный для местного гпу формат. в оригинале, шейдер это:
это программа для одной из ступеней графического конвейера, используемая в трёхмерной графике для определения окончательных параметров объекта или изображения.
для наших целей своего рода сценарий в которой мы могли бы спихнуть номера спрайтов, их названия и прочее. в том числе различные варианты вывода тех и других спрайтов. можно отвести раздел для программы (имена файлов для загрузки, ещё что-то) и раздел для карты (условия, номер и различные идентификаторы данных и всё такое подобное). мы загрузили сценарий (шейдер) в нашу игру. обработчик смотрит на раздел файлов, грузит их и передаёт карте, потом карте подсовываем всё остальное от файла сценария. в нужный момент даём команду запуска сценария и карта работает по нему. в нужные моменты генерит прерывания и мы по нему можем читать состояние (или состояния). и т.д.
Сделал схему, пока это только наброски, нужно придумать название девайса и обсудить что нужно исправить или доработать...
Планируешь сделать карту ? A12 я бы на SDRAM не подавал. INT подал бы через диод. Согласование с шиной данный просто сигналом DIR что-то мне не нравится. Не уверен, что будет работать.
Светодиод и аудио разъем лишние. Или там звук через ШИМ ?
2V5 для чего используется ?
Разъем uBUS не подключен.
Lethargeek,
ну и наборов этих (тупо массивов) можно так же несколько заготовить
и потом их перекидывать в порты карты, совершенно никакой разницы
или ты непременно хочешь скармливать девайсу ASCII зачем-то?
(между прочим, занимающего в памяти больше места)
Разница в том, что кидать в порт байт за байтом в цикле каждый раз когда мне это нужно в итоге будет геморно и не удобно. зачем создавать себе проблему? куда удобнее заготовить всё заранее и один раз сбросить данные карте, а она пускай уже пашет. Про ascii, ну конечно, или вы хотите девайс забабахать без какого либо пзу? хотя судя по хотелке это уже карта по навороченности аля ГС получается и без своего пзу тут явно не обойтись. объясните мне кто-нибудь из железячников, зачем мне как кодеру извращения в виде десятка циклов с кидательством по портам и прочего гемора, когда можно всё решить простым методом - снабдить карту своим пзу и пущай "разговаривает по человечески".
и вапще, давно пора уже 3д вводить! даёшь gl es 1.1 (или хотя бы 1.0+).
Планируешь сделать карту ?
Наверно не потяну в одиночку, в подпись глянь, могу помочь в разработке железа и конфигурации.
A12 я бы на SDRAM не подавал.
Т.е. ограничить на 128Mb(8Мх16)?
INT подал бы через диод.
Т.е. имитация ОК(открытый коллектор)?
Согласование с шиной данный просто сигналом DIR что-то мне не нравится. Не уверен, что будет работать.
А как по другому?
Светодиод и аудио разъем лишние.
Светодиод, прикольно ведь? Ладно, не будем запаивать ок?
Звук думаю тут не лишний, мало ли что, вдруг видео конфиг не сделаем, то хоть TurboSound, SounDrive, GeneralSound, SID... будет?
2V5 для чего используется ?
PLL
Разъем uBUS не подключен.
Это не вопрос, пару сек...
Лучше на ZXBus глянь, какие сигналы ещё нужны?
---------- Post added at 20:45 ---------- Previous post was at 20:43 ----------
и вапще, давно пора уже 3д вводить! даёшь gl es 1.1 (или хотя бы 1.0+)
Это можно, выше я писал на чем можно сделать, только у всех мозк поплывет сразу, тут простой вывод спековского экрана сделали бы хоть...
Для согласования с 3.3 V я бы поставил два 74LVC245 встречно с фиксированным направление каждый. Выходы первого (от Z80 к FGPA) я бы включал сигналом WR. Выходы второго (от FPGA к Z80) я бы включал сигналом от FPGA когда надо передать данные в Z80 (чтение из SD-CARD, ОЗУ или вектор прерывания, например, про конце отображения экрана).
Спасибо за предложение помощи. Я бы тогда разработал подобную, но с VGA и SCART выходами.
Это можно, выше я писал на чем можно сделать, только у всех мозк поплывет сразу
у кого всплывёт? ну я немного на ogl когда то кодил. в целом, разобраться то можно.
s_kosorev
22.06.2015, 21:11
Процессор пишет команды и данные в видеокарту. Она запоминает в буфер типа FIFO и начинает работать. Z80 ее не ждет.
FIFO не резиновый, опять же надо проверять место в нем, то есть ничем не отличается от варианта подавать команды и ждать когда карта готова следующую принять. А теперь в уме заменяем фифо на буфер в памяти видеокарты и опа! получился DisplayList
Лучше обсуждение схемы видеокарты продолжить в раздел железо (http://zx-pk.ru/showpost.php?p=812628&postcount=267). А тут обсуждать систему команд и нужные функции.
Ну что прояснилось что-нибудь ? Может приведете картинки из игр с объячнением, что нужно для изображения подобных экранов ?
---------- Post added at 23:14 ---------- Previous post was at 23:12 ----------
FIFO не резиновый, опять же надо проверять место в нем, то есть ничем не отличается от варианта подавать команды и ждать когда карта готова следующую принять. А теперь в уме заменяем фифо на буфер в памяти видеокарты и опа! получился DisplayList
Давайте популярно, что это такое и кто его будет за нас заполнять ? На примере Диззи или другой игры.
s_kosorev
22.06.2015, 21:21
Объясните еще раз подробнее.
Поселить в карте продвинуты кончный автомат, считай недопроцессор специализированный, который умеет читать данные из дисплей листа и программировать на этот раз уже DMA. Именно DMA так как это КА вполне нормально что будет ждать завершения транзакции, КА обучить командам сравнения, ветвления, работы с переменными, в итоге если заставить его выполнять процедуру BitBlt карта будет выполнять функцию блитера, заставь выполнять процедуру DrawTileLayer, КА по нужному алгоритмы перенастраивая DMA выведит тайловую карту, в конце концов можно написать и процедуры TrawTriangle DrawCircle итд, и самое главно, процессору только нужно подсунуть какрте "Прошивку" считай написаный на ассемблере шейдер, и дальше может заниматься своими делами, карта построит всю сцену.
---------- Post added at 21:17 ---------- Previous post was at 21:16 ----------
Давайте популярно, что это такое и кто его будет за нас заполнять ?
Простейший вариант, писать процессором не в порты а в этот буфер, все!
---------- Post added at 21:21 ---------- Previous post was at 21:17 ----------
КА в итоге еще и ресурсов занять может меньше, чем аппаратно реализованые выдумки из топика, так как фактически программа для КА определяет что карта умеет в данный момент времени
Для согласования с 3.3 V я бы поставил два 74LVC245 встречно с фиксированным направление каждый.
Не совсем понял, зачем так. Сигнал WR это от Z80 который?
но с VGA и SCART выходами
Эти магические названия... Может в этом что-то и есть. Я бы проиграл в цвете, звуке, габаритах и новизне... VGA это еще плюс 7 хз откуда выводов, около 15-ти и больше 1% резисторов и большой разъем на плату. Ограничим качество картинки(аналоговая против цифровой) и цвет на 15bpp против 24bpp. Пусть спонсоры решают...
у кого всплывёт? ну я немного на ogl когда то кодил. в целом, разобраться то можно.
Тогда прикручивай ordroid-w
http://dn.odroid.com/homebackup/201407222013337548.jpg
Хорошо бы предусмотреть возможность загрузки спрайтов или целой игры с PC. Для отладки.
Вот как сделано на сайте марсоход.
USB-UART можно добавить...
Сигналы, которые идут на HDMI, SD-CARD и другие свободные я бы вынес на разъем. А там свобода выбора будет, что к ним подключать.
C HDMI лучше так не шутить...
Чет в сторону BGA начинаю косить... может её...?
s_kosorev
22.06.2015, 21:43
C HDMI лучше так не шутить...
100% он на китайском шнуре от сильного перегиба начинает снег выводить, а я так понял что HDMI не совсем честно планируется реализовать, согласование будет +- как повезет
---------- Post added at 21:39 ---------- Previous post was at 21:37 ----------
А то придумаете видеокарту которой по факту спектрум как бы и не к чему
да ладно, сейчас видеокарты таже среднего уровня, гораздо производительный центральных процессоров в ПЦ
---------- Post added at 21:43 ---------- Previous post was at 21:39 ----------
посмотрел на ULA+ опять же прошивкой для КА решаемо очень просто
s_kosorev
22.06.2015, 21:47
игры о которых говорил камарад Lethargeek вообще просто переделывать, достаточно КА обучить координаты спрайтов читать из нужного места памяти и выводить их на экран уже картой, с графикой из карты. Z80 вообще не нужно о чем то думать кроме как, записать в нужно место памяти координаты
как на ленинграде простым смертным ULA+ сделать
Это к Black_Cat (http://zx.clan.su/forum/). Я пока с ней не разбирался, нечего сказать сейчас не могу.
Ретро платформа же, дядьки, опомнитесь.
А ведь точно, это уже ретро FPGA.
достаточно карту КА обучить координаты спрайтов читать из нужного места памяти и выводить их на экран уже картой, с графикой из карты. Z80 вообще не нужно о чем то думать кроме как, записать в нужно место памяти координаты
Если сделать ПДП, то Z80 в спектруме можно отключать сразу после подачи им команды GO например, чтобы комнату не обогревал и ток не жрал.
Может приведете картинки из игр с объячнением, что нужно для изображения подобных экранов ?
Да почти каждую первую можно взять и увидеть чёрный фон, при том что в игре как-бы день.
за юлу плюс обеими руками за
на рассыпухе
к ULA + барсики есть, игрушки есть
ПДП есть схема у велесофт, ничего сложного
только где сам чип брать
Чорный Кот гдето в своих эмпиреях , к простым смертным не спускается
s_kosorev
22.06.2015, 23:17
и зачем для какой то унылой ULA+ делать видеокарту? любители ЛА3 не поймут что такое FPGA
Lethargeek
23.06.2015, 02:28
На что там реагировать надо? Я привел пример, как можно заполнить экран для игры Диззи по той картинке.
а можно и не так заполнять)) а ты подгоняешь управление девайсом под частный случай - нинада так делать!
А вам почему-то не понравилась жесткая сетка и фиксированный размер. C чего это они жесткие? Как раз наоборот - мы их можем выбирать. Какие тайлы были, такой размер и указан. Будут другие размеры - будет другая сетка. Мы сами выбираем размер тайлов и спрайтов при проектировании игры. Но если выбрали 8х8, значит так надо было. Что тут не так ?
потому и жёсткие, что выбираются один раз на всю игру
Ну а насчет тайлов разного размера - это как-то странно, как ими заполнить экран без промежутков ?
"как-то странно" заполнять экран непременно "без промежутков", когда в играх (втч Диззи) дофига экранов полупустых :D
я ж сказал - список пар "координаты, номер объекта" (и по номеру из массива прочие параметры взять)
для объектов одинакового размера, как ты хотел, можно тупо сделать сразу массив адресов изображений
остальные все параметры одинаковы, а экранный адрес в цикле меняешь сам
Сначала можем заполнить крупными весь экран, потом можно мелкими добавить случайные камешки или другого размера нарисовать одиночные деревья. Я ведь об этом писал.
да размер тут совершенно же ни при чём, отрисовка - по порядку перекрытия у объектов
Язык сломал писать все в множественном числе - перехожу на ты.
да здесь на форуме всегда народ общался "на ты"
Печатать строку тайлов лучше одинакового размера (для данной полоски), при этом карта сама сможет определить адрес начала следующего спрайта в буфере спрайтов и в буфере экрана. Это же логично. Строка из спрайтов разного размера - это уже не строка, а неизвестно что.
блиттер может выводить изображения где угодно, заставлять его печатать "строками" - НЕлогично
Размер спрайтов настраивается, координаты начала строки спрайтов можно задать. Этого хватит, чтобы напечатать экран, какой желает программист.
нет, не хватит - ну, вот я, например, желаю кучу перекрывающихся слоёв (и даже независимых отдельных объектов) :p
---------- Post added at 02:24 ---------- Previous post was at 02:20 ----------
это нужно чтобы знать что и где находится. удобно, например, для коллизий всяких.
это можно делать в обычной памяти, а пассивные девайсы проще присобачить к любому спектруму
Разница в том, что кидать в порт байт за байтом в цикле каждый раз когда мне это нужно в итоге будет геморно и не удобно. зачем создавать себе проблему?
где проблема, вызвал простенькую процедуру, она кидает, времени на это уйдёт немного
куда удобнее заготовить всё заранее и один раз сбросить данные карте, а она пускай уже пашет.
"мелкий" доступ по одному объекту (или даже частичному параметру) тоже нужен (а точнее даже - необходим!)
а ресурсы железяки небесконечны, так что - только в качестве необязательной примочки, а не основы
---------- Post added at 02:25 ---------- Previous post was at 02:24 ----------
FIFO не резиновый, опять же надо проверять место в нем, то есть ничем не отличается от варианта подавать команды и ждать когда карта готова следующую принять
проще вейтить проц при переполнении буфера, всё равно оно маловероятно
разве что нарочно бомбить девайс переброской кучи огромных блоков
Простейший вариант, писать процессором не в порты а в этот буфер, все!
не, в простейшем варианте как раз в порты, буфер же прозрачно работать должен
есть он, или без него видеокарта всё успевает - программисту разницы никакой
---------- Post added at 02:28 ---------- Previous post was at 02:25 ----------
Глянь какие сигналы на ZXBus ещё нужны. Может RTC(часы на бордюр) ещё добавить? Ethernet или USB контроллер, PS/2 keyboard?
издиваишси? :) ну при чем тут видеокарта
wait проца как защиту от переполнения буфера
+ хорошо бы строчное прерывание
потому и жёсткие, что выбираются один раз на всю игру
Размер тайлов выбирает разработчик игры и может изменить в любой момент
"как-то странно" заполнять экран непременно "без промежутков", когда в играх (втч Диззи) дофига экранов полупустых :D
Промежутки после перехода в другое место может потребоваться заполнять черным тайлом, чтобы затереть предыдущую картинку (на этом месте в предыдущей картинке могло быть дерево или другой объект). Если наносим уже второй слой (этой же картинки) также построчно - можно использовать нулевой прозрачный спрайт. Или указывать координаты для каждого одиночного тайла. Можно конечно заполнить экран черным цветом, а потом рисовать одиночные объекты. Это выбирает разработчик игры - как ему удобно, так и заполняет. Новый графический режим только ускоряет вывод тайлов и спрайтов.
я ж сказал - список пар "координаты, номер объекта" (и по номеру из массива прочие параметры взять)
для объектов одинакового размера, как ты хотел, можно тупо сделать сразу массив адресов изображений
остальные все параметры одинаковы, а экранный адрес в цикле меняешь сам
Дело в том что предлагаемый графический режим так тоже может, он используется для печати одиночных тайлов и спрайтов. Но для быстрого заполнения всего экрана и введена построчная печать, также как и печать вертикальными столбиками из тайлов. Согласитесь, если тайлы идут друг за другом, то координаты следующего тайла на экране может вычислять сама видеокарта. Если же указывать их для каждого тайла в строке - это замедлит вывод.
да размер тут совершенно же ни при чём, отрисовка - по порядку перекрытия у объектов
блиттер может выводить изображения где угодно, заставлять его печатать "строками" - НЕлогично
нет, не хватит - ну, вот я, например, желаю кучу перекрывающихся слоёв (и даже независимых отдельных объектов) :p
Печать строками и столбцами введена для ускорения вывода нескольких графических объектов.
Я ведь и так предлагаю кучу перекрывающихся слоев и независимых объектов. Прозрачный цвет позволяет накладывать объекты без клешинга атрибутов. Указываем координаты на экране с точностью до точки для каждого объекта и печатаем по номеру. Не по адресу, а по координатам и номеру. А видеокарта/видеорежим сам определяет адреса. Ведь так проще и быстрее ?
Как выводить тайлы на экран построчно, столбиками или указывая координаты каждого - это выбор разработчика игры. Режим должен поддерживать все три вида печати. Это сделано для обеспечения скорости и гибкости построения экрана. Все это вместе с прозрачным цветом на краях тайлов и спрайтов, а также прозрачный тайл/спрайт с нулевым номером позволяет строить практически любые экраны в играх.
---------- Post added at 08:05 ---------- Previous post was at 06:58 ----------
Лучше бы рассказали как на ленинграде простым смертным ULA+ сделать. Реально полезно и нужно, сделали бы 50%+ народу, и игр полно и поддержка в коде простая. А то придумаете видеокарту которой по факту спектрум как бы и не к чему, спартан там пожирнее 16 метров все дела. Ретро платформа же, дядьки, опомнитесь.
Посмотрите там (http://zx-pk.ru/showthread.php?p=445085#post445085), может поможет. ULA + это всего лишь палитра. Она не облегчает написание игр. Мы хотим при той же графике упростить и ускорить построение изображений.
s_kosorev
23.06.2015, 07:49
Размер тайлов выбирает разработчик игры и может изменить в любой момент
а если тайлы шестигранные? есть же куча игрушек где они именно такие
---------- Post added at 07:47 ---------- Previous post was at 07:31 ----------
проще вейтить проц при переполнении буфера, всё равно оно маловероятно
разве что нарочно бомбить девайс переброской кучи огромных блоков
опять же это какое то жесткое ограничение, т.е. нельзя карту бомбить большими изображениямии, а мочему собстно? Да и что такое большие? Это те что карта не успеет вывести пока проц не подаст следующую команду, ну к примеру какая та играшка, которой надо вывести ну 50-70 спрайтов, 32х32 на экран, карта однозначно не будет успеваь их походу отрисовывать, фифи переполнить нараз.
не, в простейшем варианте как раз в порты, буфер же прозрачно работать должен
есть он, или без него видеокарта всё успевает - программисту разницы никакой
Вообще с портами работать это на самом деле криво, даже если эти порты в память отражены, нужно работать с командами и аргументами, а это поток команд с разным числом аргуметов, а еще лучше это высокоуровневый DisplayList
---------- Post added at 07:49 ---------- Previous post was at 07:47 ----------
экран 320х240 при тайле 8х8 это надо карте подать 40х30=1200 комнд, а если слове 3-4? ну блин тоже же глупо, проще такие тривиальные вещи как вывод мелких тайлов в цикле, обучить карту делать через КА
а если тайлы шестигранные? есть же куча игрушек где они именно такие
http://s020.radikal.ru/i704/1506/23/897b5c6723fdt.jpg (http://s020.radikal.ru/i704/1506/23/897b5c6723fd.jpg)
Нужно при печати очередной строки тайлов сместить координаты начала строки на требуемое место.
Тайлы произвольной формы надо вписыть в прямоугольный тайл и лишние части закрасить прозрачным цветом.
опять же это какое то жесткое ограничение, т.е. нельзя карту бомбить большими изображениямии, а мочему собстно? Да и что такое большие? Это те что карта не успеет вывести пока проц не подаст следующую команду, ну к примеру какая та играшка, которой надо вывести ну 50-70 спрайтов, 32х32 на экран, карта однозначно не будет успеваь их походу отрисовывать, фифи переполнить нараз.
Вообще с портами работать это на самом деле криво, даже если эти порты в память отражены, нужно работать с командами и аргументами, а это поток команд с разным числом аргуметов, а еще лучше это высокоуровневый DisplayList
---------- Post added at 07:49 ---------- Previous post was at 07:47 ----------
экран 320х240 при тайле 8х8 это надо карте подать 40х30=1200 комнд, а если слове 3-4? ну блин тоже же глупо, проще такие тривиальные вещи как вывод мелких тайлов в цикле, обучить карту делать через КА
Можно для неизменяемой части экрана создать описание в виде строки данных типа SIZE, 8, 8, SPR_ADDR, 1, 2, PRINT, AT, X, Y, 1, 2, 3, 4, 5, ENTER, PRINT, 3, 4, 5, 6, 7, AT, Y2, X2, SPR_ADDR, 7, 8, SIZE, 20, 20, PRINT, 1, ... END.
Можно описать так 15 экранов и разместь в SD-RAM. Тогда при переходе Диззи в очередное место передавать видеокарте адрес описания фона этого места и команду типа DRAW_LOCATION. После этого сразу команды печати спрайтов объектов.
s_kosorev
23.06.2015, 13:51
ясно, сторонники костылей
---------- Post added at 13:51 ---------- Previous post was at 13:36 ----------
Можно описать так 15 экранов и разместь в SD-RAM
можно всю игру нарисовать и подгружать с карты, вообще тайлы не нужны, только дма, что бы на экран выводить то что с карточки загрузили
предлагаю параллельно со схемой видеокарты начать совместно разработку режима "METEOR" для ReVeRse.
Для какой из конфигураций?
"METEOR"??? Почему не "болид" тогда? Неудачное название, это даже не объект какой-то там, а явление возникающее при сгорании... Не хотелось бы это явление наблюдать при подключении карты.
Параллельно не потяну, задача хоть и простая, но не из легких. Свои мысли устройства я наглядно изложил здесь (http://zx-pk.ru/showpost.php?p=812525&postcount=105) в виде схемы.
От SCART, на мой взгляд рано отказываться. Много старой техники. И режим 50 Гц не все мониторы показывают. 15 бит также позволяет сделать копирование в два раза быстрее, чем 24 бита при достаточно хорошем качестве изображения.
Для VGA не хватает выводов, разве что 6bpp получится (решается простым переходником HDMI2VGA), выхлоп переходника можно на шурупы, чтобы карта не выпадала и всё хорошо.
Будет 60Гц как у нормальных людей, а 50Гц смотреть и фапать через SCART или S-Video с выхода видео компа, он то у нас будет свободный, я планирую TV подключить двумя шнурками VGA/SCART комп и HDMI для DivGPU или exGPU или как там по понятней карту назвать...
Чтобы была большая скорость нужна FT2232H. Она дороговатая. Лучше использовать внешний программатор с ней, чем устанавливать на карту. Хотя, может лучше иметь встроенный программатор и порт связи через один шнурок USB. Так сделано в MARSOHOD2.
Большая скорость кого/чего? Во первых плохое соотношение цены и функционала. Уже лучше VNC2, дешевле и в разы для этого случая лучше.
Добавил в схему CP2104, раз нужна возможность отладки и загрузки обновлений или обмен данными с PC (USB-UART).
Раз пошла такая пьянка с U16, то мне лучше идти по пути совместимости обвеса и простоты. Т.к. отлаживать видео режим мне придется на U16, соответственно делать новую конфигурацию спека с этим режимом.
Lethargeek
23.06.2015, 18:36
Размер тайлов выбирает разработчик игры и может изменить в любой момент
зачем ты вообще принуждаешь разработчика выбирать какой-то общий (пусть даже на время) размер?
Промежутки после перехода в другое место может потребоваться заполнять черным тайлом, чтобы затереть предыдущую картинку (на этом месте в предыдущей картинке могло быть дерево или другой объект). Если наносим уже второй слой (этой же картинки) также построчно - можно использовать нулевой прозрачный спрайт. Или указывать координаты для каждого одиночного тайла. Можно конечно заполнить экран черным цветом, а потом рисовать одиночные объекты. Это выбирает разработчик игры - как ему удобно, так и заполняет. Новый графический режим только ускоряет вывод тайлов и спрайтов.
ускорять и делать удобным нужно вывод ЛЮБЫХ объектов в ЛЮБОМ порядке
а ты хочешь один частный случай в ущерб другому - нинада так делать!
Дело в том что предлагаемый графический режим так тоже может, он используется для печати одиночных тайлов и спрайтов.
так - не может, блиттер выгодней запускать выдачей приёмника чем источника
можно быстро с промежутками печатать один объект, а потом к другому переходить
Но для быстрого заполнения всего экрана и введена построчная печать, также как и печать вертикальными столбиками из тайлов.
это как "быстрый" бег в грязи по колено вместо "медленной" ходьбы по дороге :D
Согласитесь, если тайлы идут друг за другом,
а зачем им друг за другом идти так часто, чтобы обращать на это внимание?
то координаты следующего тайла на экране может вычислять сама видеокарта. Если же указывать их для каждого тайла в строке - это замедлит вывод.
вычисление координаты - это копейки, но из-за обязательного вывода ненужных тайлов они накапливаются
ты пойми: для разгрузки медленного z80 выгодней очистить полностью фон и вывести поменьше крупных объектов!
Печать строками и столбцами введена для ускорения вывода нескольких графических объектов.
Я ведь и так предлагаю кучу перекрывающихся слоев и независимых объектов. Прозрачный цвет позволяет накладывать объекты без клешинга атрибутов. Указываем координаты на экране с точностью до точки для каждого объекта и печатаем по номеру. Не по адресу, а по координатам и номеру. А видеокарта/видеорежим сам определяет адреса. Ведь так проще и быстрее ?
нифига не проще и не быстрее, а ты снова "улучшаешь" частный случай в ущерб ВСЕМУ!
а если вывод не в экран, а в буфер прямоугольный, а потом уже его на экран?
а если крупные объекты для начала конструируются из мелких, а после вывод?
а если у разраба более трёхсот объектов разных размеров?
или вовсе нарезаемых из большой картинки как ему нужно
как их напечатать по номерам?
Как выводить тайлы на экран построчно, столбиками или указывая координаты каждого - это выбор разработчика игры. Режим должен поддерживать все три вида печати. Это сделано для обеспечения скорости и гибкости построения экрана.
как уже мной было сказано выше, для скорости гораздо выгодней не мельчить
а для гибкости в построении любого экрана хватит одного универсального интерфейса
---------- Post added at 18:36 ---------- Previous post was at 18:27 ----------
опять же это какое то жесткое ограничение, т.е. нельзя карту бомбить большими изображениямии, а мочему собстно? Да и что такое большие? Это те что карта не успеет вывести пока проц не подаст следующую команду, ну к примеру какая та играшка, которой надо вывести ну 50-70 спрайтов, 32х32 на экран, карта однозначно не будет успеваь их походу отрисовывать, фифи переполнить нараз.
можно, но бессмысленно, потому что емнип блиттер с современной доступной памятью в одном кадре успевает обновить площадь экрана несколько раз, для over 95% игрушек этого хватит, притом место в буфере по ходу отрисовки даже очень крупных спрайтов всё же постепенно освобождается
Вообще с портами работать это на самом деле криво, даже если эти порты в память отражены, нужно работать с командами и аргументами, а это поток команд с разным числом аргуметов, а еще лучше это высокоуровневый DisplayList
к портам доступ нужен как ни крути, разраб может хоть скриптами хранить экраны, всех его хотелок не предусмотришь, и чем более высокоуровневый и специализированный интерфейс, тем больше шансов чем-то не устроить больше людей, в чём-то накосячить и недодумать
экран 320х240 при тайле 8х8 это надо карте подать 40х30=1200 комнд, а если слове 3-4? ну блин тоже же глупо, проще такие тривиальные вещи как вывод мелких тайлов в цикле, обучить карту делать через КА
повторю, проще и быстрей не мельчить, и вообще отказываться от тайлов
можно всю игру нарисовать и подгружать с карты, вообще тайлы не нужны, только дма, что бы на экран выводить то что с карточки загрузили
или так :D только всё же лучше прямоугольником
s_kosorev
23.06.2015, 18:51
разраб может хоть скриптами хранить экраны, всех его хотелок не предусмотришь, и чем более высокоуровневый и специализированный интерфейс, тем больше шансов чем-то не устроить больше людей, в чём-то накосячить и недодумать
Ну так разработчик игры сам формат ему удобный и придумает, потом просто "шейдер" реализует и вуаля, процессор свободен, карта варится в своем соку, рисуя все что надо
зачем ты вообще принуждаешь разработчика выбирать какой-то общий (пусть даже на время) размер?
Для работы видеокарта должна знать размер тайла/спрайта.
а зачем им друг за другом идти так часто, чтобы обращать на это внимание?
Чтобы можно было заполнить экран графикой, а не пустотой.
вычисление координаты - это копейки, но из-за обязательного вывода ненужных тайлов они накапливаются
ты пойми: для разгрузки медленного z80 выгодней очистить полностью фон и вывести поменьше крупных объектов!
При вводе параметров каждого тайла загрузка на Z80 тоже увеличивается.
как уже мной было сказано выше, для скорости гораздо выгодней не мельчить
а для гибкости в построении любого экрана хватит одного универсального интерфейса
Размер тайла выбирает разработчик игры, а не я.
к портам доступ нужен как ни крути, разраб может хоть скриптами хранить экраны, всех его хотелок не предусмотришь, и чем более высокоуровневый и специализированный интерфейс, тем больше шансов чем-то не устроить больше людей, в чём-то накосячить и недодумать
повторю, проще и быстрей не мельчить, и вообще отказываться от тайлов
или так :D только всё же лучше прямоугольником
Доступ к портам медленнее, чем к ячейкам памяти, поэтому параметры и данные и передаются через область атрибутов стандартного экрана.
Тайлы используют для экономии места на графику. Если рисовать каждый экран одним куском даже 8 мегабайтов не хватит.
s_kosorev
23.06.2015, 20:31
Размер тайла выбирает разработчик игры, а не я.
я вот даже теряюсь, какой тут размер тайла выбрать http://pscd.ru/uploads/posts/2012-02/1329303316_f1-world-championship-edition-1.png
или тут
http://www.fresher.ru/images6/igrofresher-luchshie-igry-90-x/63_4.jpg
а в таком варианте?
http://spectrum4ever.org/files/screens/x1/2830/65.png
---------- Post added at 20:29 ---------- Previous post was at 20:28 ----------
Доступ к портам медленнее, чем к ячейкам памяти, поэтому параметры и данные и передаются через область атрибутов стандартного экрана.
почему именно через область атрибутов?
---------- Post added at 20:31 ---------- Previous post was at 20:29 ----------
Доступ к портам медленнее, чем к ячейкам памяти
5тыс записей в память будет медленней чем 100-200 записей в порт
Тогда прикручивай ordroid-w
почему это я? я не железячник, для меня это дебри. если к спектруму или какому клону 3д прикрутят, я может чёнить накидаю под это дело. а сам мутить железки - вот уж нет.
а пока с вашими тайлами и фиксированными размерами мне и на спринтере удобно и хорошо.
я вот даже теряюсь, какой тут размер тайла выбрать http://pscd.ru/uploads/posts/2012-02/1329303316_f1-world-championship-edition-1.png
или тут
http://www.fresher.ru/images6/igrofresher-luchshie-igry-90-x/63_4.jpg
а в таком варианте?
http://spectrum4ever.org/files/screens/x1/2830/65.png
---------- Post added at 20:29 ---------- Previous post was at 20:28 ----------
Цифры и буквы - это тоже тайлы. Вы ведь не будете рисовать текст в виде картинки. Вы его печатаете из одних и тех же букв. И тексты можно писать разные. При этом средний размер памяти на изображение будет меньше, чем целыми картинками. Так в играх печатают огромные площади фона из нескольких типов тайлов (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).
почему именно через область атрибутов?
5тыс записей в память будет медленней чем 100-200 записей в порт
Чтобы не занимать адреса старых и будущих устройств, чтобы был разнообразный способ адресации к ячейке разными командами на выбор программиста и меньше тратить времени на команды.
100-200 записей в область памяти быстрее, чем 100-200 записей в порт !
LD (BC), A ; 7 тактов
OUT (C),A ; 12 тактов
s_kosorev
23.06.2015, 22:44
ладно, проектируйте как виднее, по всей видимости видеокарта будет ограничена пониманием вещей zst а не физическими возможностями
Lethargeek
24.06.2015, 07:37
Для работы видеокарта должна знать размер тайла/спрайта.
на колу мочало, начинай сначала... смысл блиттера в переброске блоков любых размеров
зачем карте с растровым экраном и блиттером знать размер фиксированного тайла?
и вообще "знать", как разработчик хочет работать с графикой?
Чтобы можно было заполнить экран графикой, а не пустотой.
это и без дурацких тайлов прекрасно делается, притом с меньшими нагрузками на процессор
а как раз твой способ приводит к худшим тратам времени на кучу мелких пустот
При вводе параметров каждого тайла загрузка на Z80 тоже увеличивается.
а все параметры не надо передавать, только те, что с прошлыми не совпали
и нагрузки уменьшаются многократно с ростом площади печатаемых объектов
Размер тайла выбирает разработчик игры, а не я.
нееет, так ему придётся выбрать из-за тебя!
хотя мог бы ничего и не выбирать, но твои ошибки его заставят
Доступ к портам медленнее, чем к ячейкам памяти, поэтому параметры и данные и передаются через область атрибутов стандартного экрана.
ты хоть иногда читаешь, что я пишу? все порты на память отображаются!
кроме одного, через который (однократно) и происходит выбор окна для них
и не надо будет лезть в атрибуты, лучше бы подумал о совместимости
Тайлы используют для экономии места на графику. Если рисовать каждый экран одним куском даже 8 мегабайтов не хватит.
8 мег это 4 194 304 двухбайтных пикселя, что больше чем игровая площадь всех экранов у Диззи-5 :p
а нарезкой даже очень крупными объектами - в разы меньше, так что нету никакой необходимости в мелкотайлах
Цифры и буквы - это тоже тайлы. Вы ведь не будете рисовать текст в виде картинки.
непонятно лишь, зачем пытаться ускорить то, что в ускорении не нуждается
даже просто Спектрум, самый обычный, текст и то выводит вполне приемлемо
Чтобы не занимать адреса старых и будущих устройств,
дык влезая в атрибуты, ты как раз адреса "старого устройства" (экрана) и занимаешь
и уничтожаешь притом возможность быстрой адаптации старых игр
---------- Post added at 07:37 ---------- Previous post was at 07:29 ----------
ладно, проектируйте как виднее, по всей видимости видеокарта будет ограничена пониманием вещей zst а не физическими возможностями
между прочим, я не первый раз отмечаю феномен зашоренности приставками
но обычно жертвы жаждут спрайтиков аппаратных, "шоб как на любимой %consolename%"
а тут случай уникальный на моей памяти - изувечить блиттер до их подобия :v2_wacko:
Ребята, вы извращаетесь сильно. Сделайте для начала простую макетину с необходимым обвесным минимумом, прикрутите к какому-нить пню128 или профику или к фениксу или к недоЭве и испытывайте начиная с какого-то минимального функционала. Сделайте хотя бы подобие спринтеровской графики. А то тайлы, спрайты, блиттеры. вы так ещё пару веков будете мусолить эту тему. будет железка для обкатки, тогда и говорите про навороты. если известна память, какая плисина ещё там всякое, вкарячте простой блиттер, самый простой, хоть от спринтера хоть какой. а потом уже дальше ехать.
shurik-ua
24.06.2015, 13:19
Дежа вю - http://zx-pk.ru/showpost.php?p=644695&postcount=161
Какая формула, у видео-карты, для пересчета номера тайла в линейный адрес видео-памяти ?
АДРЕС НАЧАЛА БЛОКА * 256+НОМЕР СПРАЙТА * РАЗМЕР ПО-ГОРИЗОНТАЛИ * РАЗМЕР ПО-ВЕРТИКАЛИ
Сложновато (да и не нужно) разбивать графику на куски по 256 значений.
Я прикинул, номер спрайта нужен не 256 значный, а двух байтовый.
С двухбайтовым всё норм.
При печати строки спрайтов, посылать карте 2 байта номера спрайта.
зачем карте с растровым экраном и блиттером знать размер фиксированного тайла?
Всё ж у zst, при печати тайлами строки,
адреса считаются автоматом, т.е. это чуть быстрее.
все порты на память отображаются!
кроме одного, через который (однократно) и происходит выбор окна для них
и не надо будет лезть в атрибуты, лучше бы подумал о совместимости
Пример кода приведи, чтоб понятнее было.
shurik-ua
24.06.2015, 15:11
Чувствуешь разницу в скорости?
как там у Леся Подерев'янського - "скорость охреневающая" )
Единственное отличие какое я вижу - там байт на точку и палитра, здесь 2 байта и без палитры.
И да судя по бурным дебатам я думаю что тайлы здесь не к месту - они лишь дополнительный промежуточный уровень абстракции - поэтому лучше без тайлов
Смотрю, интереса к карте здесь не у кого нет, будет ещё один хлам пылится, а времени и средств на её разработку потрачу не мало. Да и как показало время, всё что разработал тяну сам. Так что парни я тут пас. Создавайте соответственно тему на kickstarter, как к примеру на это барахло Bluetooth ZX Spectrum (https://www.kickstarter.com/projects/952953995/bluetooth-zx-spectrum-recreating-the-sinclair-zx-s), собирайте средства на разработку, заинтересовывайте разработчиков и тех кто готов их поддержать, а иначе дела тут не будет. Не ценят здесь халяву...
Смотрю, интереса к карте здесь не у кого нет, будет ещё один хлам пылится, а времени и средств на её разработку потрачу не мало. Да и как показало время, всё что разработал тяну сам. Так что парни я тут пас. Создавайте соответственно тему на kickstarter, как к примеру на это барахло Bluetooth ZX Spectrum (https://www.kickstarter.com/projects/952953995/bluetooth-zx-spectrum-recreating-the-sinclair-zx-s), собирайте средства на разработку, заинтересовывайте разработчиков и тех кто готов их поддержать, а иначе дела тут не будет. Не ценят здесь халяву...
Я продолжу пока разработку видеорежим/видеокарту "Meteor Graphics" как представляю сам. Да, сначала надо сделать прототип с простыми командами работы с графикой, потом заняться улучшением и оптимизацией.
Дежа вю
DjVu говоришь :) :
IPVC http://zx-pk.ru/showthread.php?t=15176
http://zx-pk.ru/attachment.php?attachmentid=31905&d=1325174293
IPVC2 http://zx-pk.ru/showpost.php?p=401000&postcount=60
TSXB http://forum.tslabs.info/viewtopic.php?f=6&t=233
https://dl.dropboxusercontent.com/u/31743315/ZX/photo/IMG_4888s.JPG
Не парни, лучше я сделаю конфигурацию того что выше для U16, дешевле и практичней получится.
http://zx-pk.ru/attachment.php?attachmentid=48256&d=1401869377
DjVu говоришь
это всё не существующие девайсы, прототипы и не более. в массах нет, особенно ТСлабовой железки. он до сих пор там парится с ней судя по их форуму.
лучше я сделаю конфигурацию того что выше для U16
а что мешает сделать нормальный девайс для любого клона? что за ограничение такое?
а что мешает сделать нормальный девайс для любого клона? что за ограничение такое?
А что такое "нормальный девайс для любого клона"?
Ограничение - формула (сколько сейчас просят за zx-evo или клон, zx-spectrum + стоимость нормального девайса + стоимость разработки и ПО). Не, парни, уже лучше взять новое железо и не городить велосипед под ёлку. Спектрум пусть остаётся спектрумом, не нужен этот велосипед никому ещё с 1980-го :) Вы сообщения наверно с IBM PC 16bit + "нормальный девайс для любого PC" набираете здесь? :)
Ответ Иви на вопрос - "Что ты знаешь про zx-spectrum"
52679
Я аж офигел от ответа :)
http://www.existor.com/ru/
MVV, а ты в ahdl разбираешься?
ты в ahdl разбираешься?
Думаешь Sprinter портировать как zx-evo?
Думаешь Sprinter портировать как zx-evo?
ну была мысль, но сейчас разборки тут учиняю. есть некоторые непонятки по работе с некоторыми железками, а сам я в ahdl не шарю и соответственно не знаю толком, как к ним обращаться. например, с теневой памятью (типа кэш). знаю, что для включения одной страницы нужно делать in a,(#fb). а как включать ещё 2 страницы (всего по описанию доступны 3 страницы), я не могу понять. ну и так по мелочам ещё тут есть. помог бы кто... ну и да, можно было бы портировать его на другую базу какую-то, тот же реверс.
Lethargeek
26.06.2015, 04:28
Всё ж у zst, при печати тайлами строки,
адреса считаются автоматом, т.е. это чуть быстрее.
ну, во-первых, "чуть", во-вторых, хранить экраны тайловыми строками неэффективно
нужно будеть больше номеров отправлять, и в итоге получается не быстрее
Пример кода приведи, чтоб понятнее было.
мы же это обсуждали давным-давно
ld bc,#port - единственный реальный порт вк
ld a,#XX - старший байт диапазона
out (c),a
всё, после этого запись по любому адресу #XX00-#XXFF
будет трактоваться видеокартой как запись в порт
с соответствующим номером (младший байт)
---------- Post added at 04:28 ---------- Previous post was at 04:15 ----------
Где, блин, палитра? Как можно без нее вообще?
а как с ней можно при 15-16bpp? :)
или ты об чём говоришь
Простой пример, плавное гашение экрана.
Т.е. если у меня на U16 вывод 24bpp, то мне нужно перед выводом добавить память по 256 байт на каждый цвет?
r((x<=7)..0)->[addres(7..0),data(7..0)->R(7..0)
g((x<=7)..0)->[addres(7..0),data(7..0)->G(7..0)
b((x<=7)..0)->[addres(7..0),data(7..0)->B(7..0)
Я могу рассматривать сейчас это для U16. Не вопрос, можно сделать. Есть двухпортовая память 1 блок M9K=1024x9бит 9-й бит палитры к примеру задействовать как альфа. Получится 4-ре страницы палитры. Чтобы не использовать 3-ри блока, можно увеличить в трое частоту выборки выходных данных палитры (256х3=768 байт), это уже техническая сторона решения...
Почти, а теперь немного другая задача. Нужно оставить посередине картинку, остальное затенить. В играх часто бывает типа фон серый становится а герой яркий и цветной.
Если оставить 4 страницы палитры, то переключить на нужную нам в момент вывода героя, это как уже выше писали может делать простой блиттер или работать через наложение альфа слоя. Пока я этим не занимался, сказать ничего точно не могу, нужно брать и пробовать делать.
Спецификация этого "нового графического режима" есть?
Если нет, то для начала хотя-бы нужно привязаться к одному из стандартных видео разрешений. Взять к примеру индустриальный стандарт VGA 640х480@60Hz 24bpp, Pixel freq.=25.175 MHz(округлим под PLL до 25МГц).
Получается, что максимальное разрешение 640х480 24bpp, сюда теперь можно вложить несколько видео режимов, к примеру так:
1) 640х480
2) 320x240
3) ZX-Spectrum screen (x2 = H:32+256+32; V=24+192+24)
4) ZX-Spectrum screen (х1 = 4-ре поля H:32+256+32; V=24+192+24):
https://github.com/mvvproject/ReVerSE-U16/raw/master/u16_quadspeccy/readme/20150322_123219.jpg
https://github.com/mvvproject/ReVerSE-U16/raw/master/u16_quadspeccy/readme/20150302_095132.jpg
Lethargeek
26.06.2015, 15:46
Почти, а теперь немного другая задача. Нужно оставить посередине картинку, остальное затенить. В играх часто бывает типа фон серый становится а герой яркий и цветной. Как такие штуки делать без палитры я не знаю. Понятно что можно процом пройтись,
Блиттером. Операция наложения с частичной прозрачностью "блока" из единственной точки на часть экрана.
или подготовить кучу тайлов с различной яркостью, но палитра решает проблему на корню, и еще вдобавок уменьшает bpp, что для спекки с его дискетами актуально.
Это лучше не через физическую палитру, а распаковкой сжатых изображений.
Так можно заменять раскраски (в том числе частично), не то что яркость.
Lethargeek
26.06.2015, 16:24
Во уже альфа канал начался,
говоришь, как будто это что-то плохое
также пригодился бы и для сглаживания
Да ладно, тоесть надо сделать 20 одинаковых изображений. Ок.
20 (или сколько там тебе надо) небольших табличек для распаковки
но изображение то же самое (и таблички можно юзать не только с ним)
Alex Rider
26.06.2015, 19:33
Сорри, весь тред не осилил, но расскажу мнение адаптатора игр на примере Саботера 2. Мне было бы очень кайфово и быстро адаптировать Саботера, если бы можно было:
1. Сказать видеокарте, что у меня n тайловых слоев.
2. Отправить ей тайлы 8x8 для каждого слоя
3. Замапить куски ОЗУ на тайловые буфера для слоев.
4. Получить от карты момент окончания отрисовки экрана чтобы включить другую страницу с тайлмапами в момент отрисовки бордюра.
Это позволит мне отключить рендерер. А, чтобы оптимизировать вывод тайлов в тайлмапы, было бы неплохо, чтобы сами тайлмапы были размером больше, чем 32x24, желательно раза хотя бы в 3. Чтобы не париться с клиппированием.
PS Не претендую на то, что так оно будет удобно для всех игр. С Elite такое явно не прокатит, ей нужен 3D-успоритель :)
Простой пример, плавное гашение экрана. Хотя тут конечно предложат сделать 50 экранов в памяти (у нас же 16 метров) или шейдеры (куда же без них это же гашение экрана).
То есть для гашения нужна команда, по которой видеокарта должна будет пройтись по всем точкам экрана: прочитать точку из буфера экрана, уменьшить число в каждом канале RGB на 1 и записать обратно в буфер экрана. За 31 цикл с паузами для обеспечения нужной скорости можно плавно погасить весь экран.
---------- Post added at 23:39 ---------- Previous post was at 23:25 ----------
Сорри, весь тред не осилил, но расскажу мнение адаптатора игр на примере Саботера 2. Мне было бы очень кайфово и быстро адаптировать Саботера, если бы можно было:
1. Сказать видеокарте, что у меня n тайловых слоев.
2. Отправить ей тайлы 8x8 для каждого слоя
3. Замапить куски ОЗУ на тайловые буфера для слоев.
4. Получить от карты момент окончания отрисовки экрана чтобы включить другую страницу с тайлмапами в момент отрисовки бордюра.
INT надо подавать после отображения на телевизоре правой нижней точки экрана 256х192 ?
Это позволит мне отключить рендерер. А, чтобы оптимизировать вывод тайлов в тайлмапы, было бы неплохо, чтобы сами тайлмапы были размером больше, чем 32x24, желательно раза хотя бы в 3. Чтобы не париться с клиппированием.
PS Не претендую на то, что так оно будет удобно для всех игр. С Elite такое явно не прокатит, ей нужен 3D-успоритель :)
Т.е. каждую локацию подготовить в виде таблицы 32х24 тайла (768 на экран) и загрузить в SDRAM в буфер локаций. Дополнительные слои делать с прозрачными цветами и прозрачным спрайтам № 0. После этого для копирования из буфера локаций в буфер экрана достаточно будет указать адрес локации. После перехода в новое место скопировать в буфер экрана нижний слой, потом спрайты героев, потом верхний слой. Я правильно понял?
Сколько примерно надо локаций?
Сколько байтов надо на номер тайла ?
Перечислите, пожалуйста, названия игр, для которых такой способ тоже подойдет.
А для каких нужен другой способ ?
Какой ?
Кто-бы что тут не говорил... вот рабочий пример, можно попробовать в конфигурации Zet:
; fadeout.asm
; выполняет плавное гашение экрана
.model tiny
.code
.186 ; для команд insb/outsb
org 100h ; СОМ-программа
start:
cld ; для команд строковой обработки
mov di,offset palettes
call read_palette ; сохранить текущую палитру, чтобы
; восстановить в самом конце программы,
mov di,offset palettes+256*3
call read_palette ; а также записать еще одну копию
; текущей палитры, которую будем
; модифицировать
mov cx,64 ; счетчик цикла изменения палитры
main_loop:
push cx
call wait_retrace ; подождать начала обратного хода луча
mov di,offset palettes+256*3
mov si,di
call dec_palette ; уменьшить яркость всех цветов
call wait_retrace ; подождать начала следующего
mov si,offset palettes+256*3 ; обратного хода луча
call write_palette ; записать новую палитру
pop cx
loop main_loop ; цикл выполняется 64 раза - достаточно для
; обнуления самого яркого цвета (максимальное
; значение 6-битной компоненты - 63)
mov si,offset palettes
call write_palette ; восстановить первоначальную палитру
ret ; конец программы
; процедура read_palette
; помещает палитру VGA в строку по адресу ES:DI
read_palette proc near
mov dx,03C7h ; порт 03C7h - индекс DAC/режим чтения
mov al,0 ; начинать с нулевого цвета
out dx,al
mov dl,0C9h ; порт 03C9h - данные DAC
mov cx,256*3 ; прочитать 256 * 3 байта
rep insb ; в строку по адресу ES:DI
ret
read_palette endp
; процедура write_palette
; загружает в DAC VGA палитру из строки по адресу DS:SI
write_palette proc near
mov dx,03C8h ; порт 03C8h - индекс DAC/режим записи
mov al,0 ; начинать с нулевого цвета
out dx,al
mov dl,0C9h ; порт 03C9h - данные DAC
mov cx,256*3 ; записать 256 * 3 байта
rep outsb ; из строки в DS:SI
ret
write_palette endp
; процедура dec_palette
; уменьшает значение каждого байта на 1 с насыщением (то есть, после того как
; байт становится равен нулю, он больше не уменьшается из строки в DS:SI
; и записывает результат в строку в DS:SI
dec_palette proc near
mov cx,256*3 ; длина строки 256 * 3 байта
dec_loop:
lodsb ; прочитать байт,
test al,al ; если он ноль,
jz already_zero ; пропустить следующую команду
dec ax ; уменьшить байт на 1
already_zero:
stosb ; записать его обратно
loop dec_loop ; повторить 256 * 3 раза
ret
dec_palette endp
; процедура wait_retrace
; ожидание начала следующего обратного хода луча
wait_retrace proc near
push dx
mov dx,03DAh
VRTL1: in al,dx ; порт 03DAh - регистр ISR1
test al,8
jnz VRTL1 ; подождать конца текущего обратного хода луча,
VRTL2: in al,dx
test al,8
jz VRTL2 ; а теперь начала следующего
pop dx
ret
wait_retrace endp
palettes: ; за концом программы мы храним две копии
; палитры - всего 1,5 Кб
end start
Взято отсюда: http://devotes.narod.ru/Books/3/ch05_10d.htm
Ну, это так для примера, чтобы понятнее было как оно в реале на пальцах по простому работает.
У меня уже написаны модули текстового и графического режимов для VGA 640x480@60Hz (ссылка (https://github.com/mvvproject/ReVerSE-U16/tree/master/u16_test/rtl/video)).
Текстовый режим 80х30 16 цветов, под текст и атрибуты используется 4800 байт, символы с атрибутами хранятся линейно - символ 0, атрибут 0, символ 1, атрибут 1, ... символ 2399, атрибут 2399. Реализован аппаратный курсор, может принимать два вида - большой и подчеркивание.
Графический режим 640х480@60Hz 24bpp, используется 921600 байт, точки хранятся линейно - (R,G,B); (R,G,B); ...
Попробую сделать ещё палитру. У кого есть желание и FPGA платы могут уже подключаться, есть возможность попробовать свои силы и научить нас чему-то...
У меня уже написаны модули текстового и графического режимов для VGA 640x480@60Hz (ссылка (https://github.com/mvvproject/ReVerSE-U16/tree/master/u16_test/rtl/video)).
Текстовый режим 80х30 16 цветов, под текст и атрибуты используется 4800 байт, символы с атрибутами хранятся линейно - символ 0, атрибут 0, символ 1, атрибут 1, ... символ 2399, атрибут 2399. Реализован аппаратный курсор, может принимать два вида - большой и подчеркивание.
Графический режим 640х480@60Hz 24bpp, используется 921600 байт, точки хранятся линейно - (R,G,B); (R,G,B); ...
Попробую сделать ещё палитру. У кого есть желание и FPGA платы могут уже подключаться, есть возможность попробовать свои силы и научить нас чему-то...
Может все-таки начнем с простого 256х192 без текстового режима ?
Lethargeek
26.06.2015, 22:56
Повторю, это просто один из них, который при использовании палитры становится простым и не напряжным для процессора
если что-то посложней гашений экрана полностью, напрягаться будет разраб/художник
часть цветов только на эффекты придётся выделить
Я почему выбрал режим 15 бит на точку - он влезает в одно слово SDRAM. Соответственно, точки обрабатывать можно за раз.
640х480 заполнять не сможет. В этом разрешении были игры типа WarCraft 2. Но там процессор был 386DX40, ОЗУ 4М, видеокарта Trident 8900 512K, жесткий диск 40 Мб, CD-ROM 4x, Sound blaster 16 бит.
Мы же максимум сможем сделать DOOM2 для экрана 320х240.
Поэтому ориентироваться надо сразу на 320х240 15 bpp максимум.
Может все-таки для начала лучше 320х240 или 256х192 ?
Для первого варианта достаточно не использовать нулевой бит адресного счетчика точек в памяти. Соответственно корректируется разрядность и позиции бит цветов.
Второй вариант похоже на выделенную прямоугольную область, скорей всего отображающуюся по центру экрана 640х480 в масштабе x2 (512х384) ?
Для удобства масштабирования, на мой взгляд, оставить линейную память с раздельным хранением данных о цвете, т.е. три байта последовательно (R,G,B) на точку. Или использовать упакованный вид - два байта (три байта или один байт...) на точку? С раскладкой бит только определится... Или R,G,B распихать по банкам, добавится время на переключение... и хз как со страничным чтением тогда их с SDRAM?
С раскладкой бит только определится... Или R,G,B распихать по банкам, добавится время на переключение... и хз как со страничным чтением тогда их с SDRAM?
Размесить 5+5+5 в одном слове и нет проблем. Пакеты по 8 слов можно будет читать из любого банка.
Мы же максимум сможем сделать DOOM2 для экрана 320х240.
Да ну :)
http://turbogrill.blogspot.com/2014/06/doom-on-zpu.html
http://www.youtube.com
А лучше на DOOM2 не замахиваться для начала, а сделать типа R-TYPE (http://www.youtube.com/watch?v=pVWtI0426mU)
http://www.youtube.com
---------- Post added at 01:50 ---------- Previous post was at 01:43 ----------
Чтобы вывести статическую картинку надо настроить для нее развертку, убрав лишние навороты, определить, где она будет лежать и как ее туда загрузить. Для начала можно вывести мусор из SDRAM. Лучше настроить пакеты по 8 слов, TS-LABS тоже пришел к такому выводу.
А лучше на DOOM2 не замахиваться для начала, а сделать типа R-TYPE
Для начала хоть статическую картинку вывести из SDRAM :) Нужно браться за контроллер SDRAM с пакетным чтением/записью и видео буфер строки куда пакеты складывать.
Для начала хоть статическую картинку вывести из SDRAM :) Нужно браться за контроллер SDRAM с пакетным чтением/записью и видео буфер строки куда пакеты складывать.
У TS-LABS (http://forum.tslabs.info/viewtopic.php?f=6&t=233&sid=c4643c3ac350de472eb9e24552d043c6&start=475#wrap) может посмотреть ?
Я уже писал, что на чтение 8 слов надо 14 тактов. На запись 15. Округляем до 16. Это у нас будет квант времени. За 16 тактов мы загружаем данные из SD-RAM в буфер FPGA. Для этого надо организовать массив 8х16 бит. 16-ый бит признак прозрачности.
Вывести из SDRAM не очень сложно. Надо продумать, как организовать доступ к памяти в разные кванты. Для начала в 1 из 4х квантов организовать чтение из SDRAM в буфер видео. Оттуда 8 точек постепенно выводить на TV/VGA.
Лучше настроить пакеты по 8 слов, TS-LABS тоже пришел к такому выводу.
TS-Labs сильно занятой для такого, так-что дальше вывода, он никуда больше не ходит.
С Git сейчас проще думаю будет, можно удалённо теперь работать всем над одним проектом. Спецификацию нужно попутно начинать делать, чтобы была документация, иначе лес...
Для начала в 1 из 4х квантов организовать чтение из SDRAM в буфер видео. Оттуда 8 точек постепенно выводить на TV/VGA.
Я планировал сделать буфер на всю строку на 3-х M9K по 1024-байт на каждый цвет. Добавить установку стартовой позиции и текущего положения в буфере, и заполнять его по мере загрузки SDRAM. Что-то типа FIFO с которым может работать и блиттер.
С Git сейчас проще думаю будет, можно удалённо теперь работать всем над одним проектом. Спецификацию нужно попутно начинать делать, чтобы была документация, иначе лес...
Для начала можно фрагменты обсуждать здесь. Может кто подскажет. Желательно начать с простого типа ZX-48 и к нему добавить один новый режим 256х192 15 bpp. А расширять можно когда простое заработает.
Я планировал сделать буфер на всю строку на 3-х M9K по 1024-байт на каждый цвет. Добавить установку стартовой позиции и текущего положения в буфере, и заполнять его по мере загрузки SDRAM. Что-то типа FIFO с которым может работать и блиттер.
Целую строку сразу нельзя. Нужно, чтобы в любой из квантов Z80 мог получить доступ к SDRAM. И хранить придется только 8 слов. Если частота смены точек на VGA 14 MГц, то за 4 кванта отобразится ровно 8 точек VGA.
Для блиттера оставить все свободные кванты, которые не заняты Z80 и сканером.
Желательно начать с простого типа ZX-48 и к нему добавить один новый режим 256х192 15 bpp. А расширять можно когда простое заработает.
Для такого случая сделал конфигурацию zx128k (https://github.com/mvvproject/ReVerSE-U16/tree/master/u16_zx128k), так-же её использую для работы с расширителем uBUS to ZXBus.
Целую строку сразу нельзя. Нужно, чтобы в любой из квантов Z80 мог получить доступ к SDRAM.
Я про видео FIFO строку, а не про бурст буфер SDRAM на 8-мь слов, он тоже нужен будет. Проц пока меня не интересует, пусть пока крутится в кэш странице.
Для такого случая сделал конфигурацию zx128k (https://github.com/mvvproject/ReVerSE-U16/tree/master/u16_zx128k), так-же её использую для работы с расширителем uBUS to ZXBus.
Я про видео FIFO строку, а не про бурст буфер SDRAM на 8-мь слов, он тоже нужен будет. Проц пока меня не интересует, пусть пока крутится в кэш странице.
Пойдет и ZX-128K. FIFO можно и на всю строку, если заполнять порциями по 8.
В каждом из тактов 0-15 кванта должна выполняться сооствующая команда SRRAM. Например, цикл чтения для режима 3-3-3 с AUTO PRECHARGE.
NOP, ACTIVE, NOP, NOP, READ, NOP, NOP, NOP, NOP, NOP, NOP, NOP, NOP, NOP, NOP, NOP. В тактах 7-14 с шины данных будут точки 0-7.
Для записи 8 точек:
NOP, ACTIVE, NOP, NOP, WRITE, NOP, NOP, NOP, NOP, NOP, NOP, NOP, NOP, NOP, NOP, NOP. В тактах 4-11 на шину данных подавать точки точки 0-7.
Когда бордер вместо команды чтения сканера в 1 кванте выполнять команду регеренации.
Компактно по режиму:
http://s014.radikal.ru/i329/1506/cf/91d18faab768t.jpg (http://s014.radikal.ru/i329/1506/cf/91d18faab768.png)
Это не спецификация, а ребусы по теме ZX-Spectrum.
Давай разбираться
по железу: плата для тестирования и работы с видео режимом? Спецификация на платы?
по устройству отображения: TV, монитор...? Интерфейсы-VGA, SCART, HDMI, S-Video?
Я сейчас могу работать и развернуть проект только на 4-х платах: DE1-SoC, ReVerSE-U9, ReVerSE-U8, ReVerSE-U16. Спецификация первой (http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=836&PartNo=2) и последних трёх (http://zx-pk.ru/showthread.php?t=8993).
RGB должно быть не менее 5:5:5.
SDRAM 8-16 Mх16.
Основной режим SCART 50 Гц. Прозрачное отображение его на VGA 50 Гц или HDMI.
В Speccy2010 только аналоговый VGA, в ReVeRse только HDMI. Это никак не должно влиять на общую часть видеорежима.
Если в Speccy2010 получится добавить PAL - отлично.
Предлагаю сделать так, чтобы я мог отлаживать на Speccy2010, а ты на ReVeRse U16. Для этого надо сделать два простых проекта, в которых настройки на конкретную FPGA, тактовый генератор и видеовыход. А остальная часть - общая.
Основной режим SCART 50 Гц. Прозрачное отображение его на VGA 50 Гц или HDMI.
А как 50Гц связать с VGA640x480@60Hz ? Привязка то к стандарту должна быть. Или no-name режим делать, а вдруг он заработает? К примеру не все TV 50Гц спековские режимы переваривают. Или это относится к SCART? И нужно делать переходник VGA->SCART?
А как 50Гц связать с VGA640x480@60Hz ? Привязка то к стандарту должна быть. Или no-name режим делать, а вдруг он заработает? К примеру не все TV 50Гц спековские режимы переваривают. Можешь уменьшить частоту до 640x480@50 Hz.
Так сделано в VGA&PAL видеоконвертере, наверно в Speccy2010, ZX-EVО.
Тактовая точек 14 MHz, количество строк увеличить до 312*2=624. Частота строк 31250 Гц.
Важно, чтобы частота обновления кадров в игре и на TV/мониторе собпадало. Тогда не будет мельканий.
Основной режим у игр 50 Гц. Новый режим тоже надо делать 50 Гц. При 60 Гц за кадр Z80 может не успеть сделать что хотел.
Теоретически можно из буфера экрана читать данные с другой частотой, а не 50 Гц, например, 60 или 100. Но при этом кадры будут уже не синхронно игре.
В VGA&PAL 60 Гц я записывал в SRAM весь кадр с частотой 50 Гц, а выводил из SRAM c частотой 60 Гц. Режим 640х480, но частота точек 14 МГц. Каждую строку выдавал дважды.
Можешь уменьшить частоту до 640x480@50 Hz.
Можешь дать ссылку на док этого режима?
Вот индустриальный стандарт VGA 640x480@60Hz который должен поддерживать TV и монитор http://tinyvga.com/vga-timing/640x480@60Hz
52714
На базе него мы вроде как получается решили сделать 320х240 15bpp(8bpp) и развить дальше к 640х480 24bpp/15bpp/8bpp?
Можешь дать ссылку на док этого режима?
Вот индустриальный стандарт VGA 640x480@60Hz который должен поддерживать TV и монитор http://tinyvga.com/vga-timing/640x480@60Hz
52714
На базе него мы вроде как получается решили сделать 320х240 15bpp(8bpp) и развить дальше к 640х480 24bpp/15bpp/8bpp?
Я делал VGA&PAL по тому же описанию, только частота точек другая. Скандаблер - частота точек и строк удваивается, каждая строка выдается 2 раза.
Через HDMI можно подавать на TV 50 Гц ?
Через HDMI можно подавать на TV 50 Гц ?
Можно, но как показывает практика не все TV работают, оно нам надо такое недо?
Забудь ты про эти 50Гц как страшный сон, добавится контроллер прерываний с выдачей вектора SSG, VGA... всё будет работать нормально как вот здесь:
http://www.youtube.com
Давай немного порассуждаем. Все игры, которые показал работают с частотой INT 50 Гц. Они обычно работают с телевизором 50 Гц. Ты научился преобразовывать этот телевизионный сигнал в режим VGA со стандартными частотами точек, строк и кадров. Это - отлично. То есть так и продолжаем дальше на U16 через HDMI. На U8/U9 возможно тоже можно будет добавить внешний 5:5:5 с помощью трех регистров. Спектрум работает в старом и новом режиме с частотой 50 Гц, а показываем на мониторе с частотой 60 Гц.
Но можно же сделать и выбор для тех людей, кому больше нравится 50 Гц. Мы выводим на те же цапы R-2R обычный сигнал на SCART. При этом все будет синхронно игре с частотой INT 50 Гц.
Мы можем читать из буфера экрана с частотой точек 7 МГц и выдавать на SCART с той же частотой или добавить буфер FIFO, и дополнительно преобразовывать в стандартный VGA 60 Гц. На Speccy2010 через аналоговый VGA, на ReVeRse - через HDMI.
Я сейчас рассматриваю новый видео режим с привязкой к стандарту, со своим разрешением, цветами, адресным пространством, портами, прерываниями... То, что там выводит спек к новому режиму никаким боком, он выводит в стандартном (https://ru.wikipedia.org/wiki/Видеорежимы_ZX_Spectrum) видео режиме 0 со своим прерыванием 50Гц (карта его просто дублирует на VGA).
Давай сделаем так, что при смене режима все времянки остаются те же. Меняется только количество цветов и принцип построения экрана.
---------- Post added at 16:34 ---------- Previous post was at 16:27 ----------
Если отображать на VGA то лучше привязаться к разрешению современных мониторов, а не 640х480. Тогда мы могли бы сделать точки квадратными. Но у каждого монитора свое основное разрешение, зависящее от используемой матрицы. Матриц 640x480 уже нет, поэтому монитор внутри преобразует.
Теоретически, минимальные искажения на телевизоре через SCART.
Возможно большинство мониторов теперь 1920X1080, тогда надо будет вписать 320х240 в это разрешение. Если увеличить в 4 раза получится 1280х960
Получается надо 4 режима:
SCART 50 Гц
VGA 50 Гц (нестандартный)
VGA 640X480 60 Гц - стандартный, но устаревший
FULL HD 1920X1080 60 Гц.
При всех режимах Спектрум должен работать с частотой 3.5 МГц, частотой INT, BORDER 50 Гц как в стандартном так и в новом режимах.
Для совместимости с мониторами для уменьшения возможных мерцаний возможно лучше было бы в новом режиме перейти на частоту INT 60 Гц, но тогда нельзя будет использовать старую музыку, доработать старую игру.
---------- Post added at 17:21 ---------- Previous post was at 16:34 ----------
Ориентировочно параметры 1920х1080:
Mode "1920x1080" # vfreq 60.000Hz, hfreq 67.500kHz
DotClock 148.500000
HTimings 1920 2008 2052 2200
VTimings 1080 1084 1089 1125
Flags "+HSync" "+VSync"
Для совместимости с мониторами для уменьшения возможных мерцаний возможно лучше было бы в новом режиме перейти на частоту INT 60 Гц, но тогда нельзя будет использовать старую музыку, доработать старую игру.
Да, если делать новый режим 60 Гц, то он хорошо войдет и в NTSC TV (220 строк), и в VGA (240 строк).
Но спековкие игры, которые 50 Гц, будет сложновато переделывать.
Или же, делать новый режим 50Гц, но тогда VGA в пролёте,
а со спековскими играми норм.
Да, если делать новый режим 60 Гц, то он хорошо войдет и в NTSC TV (220 строк), и в VGA (240 строк).
Но спековкие игры, которые 50 Гц, будет сложновато переделывать.
Или же, делать новый режим 50Гц, но тогда VGA в пролёте,
а со спековскими играми норм.
Трудно выбрать лучший вариант. Возможно большинство любителей спектрума смотрят игры на мониторе 60 Гц или через телевизор, который преобразует 50 в 60 Гц. Из-за этого на изображении возможны рывки или мерцания. Поэтому переход на 60 Гц инт мог бы устранить все эти недостатки.
Оставаясь на 50 Гц в старых играх на мониторе 60 Гц не заметно, так как они были медленные. А в новом режиме может быть заметно мерцание.
Что будет, если переделали старую игру под новый режим. Например, она успевала менять экран за 2-3 кадра 50 Гц, а теперь за 1-2 кадра 60 Гц.
У современных телевизоров есть вход VGA. Наверно при этом он показыает с частотой 60 Гц. Возможно уже не осталось современных телевизоров с честными 50 Гц. Кто их знает, как они преобразовывают изображение внутри, чтобы работало и SCART и VGA и HDMI ?
Давай сделаем так, что при смене режима все времянки остаются те же. Меняется только количество цветов и принцип построения экрана.
Если отображать на VGA то лучше привязаться к разрешению современных мониторов, а не 640х480. Тогда мы могли бы сделать точки квадратными. Но у каждого монитора свое основное разрешение, зависящее от используемой матрицы. Матриц 640x480 уже нет, поэтому монитор внутри преобразует.
Теоретически, минимальные искажения на телевизоре через SCART.
Возможно большинство мониторов теперь 1920X1080, тогда надо будет вписать 320х240 в это разрешение. Если увеличить в 4 раза получится 1280х960
Получается надо 4 режима:
SCART 50 Гц
VGA 50 Гц (нестандартный)
VGA 640X480 60 Гц - стандартный, но устаревший
FULL HD 1920X1080 60 Гц.
При всех режимах Спектрум должен работать с частотой 3.5 МГц, частотой INT, BORDER 50 Гц как в стандартном так и в новом режимах.
Для совместимости с мониторами для уменьшения возможных мерцаний возможно лучше было бы в новом режиме перейти на частоту INT 60 Гц, но тогда нельзя будет использовать старую музыку, доработать старую игру.
Нефига я тут не смог понять, хоть и старался... Рабочий пример на видео, не смог этому горю даже помочь :( Непонятно, зачем вам вообще таким со спектрумом на новые мониторы лезть? У него стандарт PAL/SECAM. И причём тут 1920х1080, бери сразу UHD 4К/8K. И почему ты решил, что у меня ничего работать не будет? В подпись мою глянь.
Тут рассматривается новый режим, старый стандартный будет работать как и работал, чего так пугаться то?
Нефига я тут не смог понять, хоть и старался... Рабочий пример на видео, не смог этому горю даже помочь :( Непонятно, зачем вам вообще таким со спектрумом на новые мониторы лезть? У него стандарт PAL/SECAM. И причём тут 1920х1080, бери сразу UHD 4К/8K. И почему ты решил, что у меня ничего работать не будет? В подпись мою глянь.
Я вижу, что все работает. Давай остановимся на 640х480 60 Гц. Скорее всего все современные телевизоры преобразовывают все внутри к частоте 60 Гц. Чтобы в новом режиме не было мерцаний из-за несовпадения частот лучше INT в новом режиме делать 60 Гц.
Старые игры должны отображаться на VGA также как у тебя сейчас. Только добавить аналоговый VGA для тех, у кого нет HDMI. На современных телевизорах есть VGA вход.
Разрешение экрана 320х240. Надо на чем-то остановиться. Пока за основу этот режим возьмем. В эмуляторах на PC тоже наверно не 50 Гц, а 60 Гц на экране монитора.
Старые игры должны отображаться на VGA также как у тебя сейчас. Только добавить аналоговый VGA для тех, у кого нет HDMI. На современных телевизорах есть VGA вход.
Ну так, а я о чем, у меня даже на U16 можно выхлоп на SCART под стандартное спектрумское видео сделать через простой переходник с двумя разъемами, тремя резисторами и проводками. Кнопочкой F12 или джампером к примеру переключай и смотри на TV.
Если прикручивать 50Гц к VGA, то тут нужна тройная буферизация. Можно попробовать сделать, тому пример эмулятор на PC, нормально себе показывает при разрешении 4K@60Hz.
Разрешение экрана 320х240. Надо на чем-то остановиться. Пока за основу этот режим возьмем.
Я правильно понял, базовый 640х480@60Гц в котором х2 320х240 15bpp?
Я правильно понял, базовый 640х480@60Гц в котором х2 320х240 15bpp?
Да.
Я правильно понял, базовый 640х480@60Гц в котором х2 320х240 15bpp?
Да.
Ну так, а я о чем, у меня даже на U16 можно выхлоп на SCART под стандартное спектрумское видео сделать через простой переходник с двумя разъемами, тремя резисторами и проводками. Кнопочкой F12 или джампером к примеру переключай и смотри на TV.
Это тоже хороший вариант. Стандартные цвета можно и на мониторе и на телевизоре, а новый режим на мониторе или на телевизоре с VGA входом.
Старые игры должны отображаться на VGA также как у тебя сейчас.
У mvv, же спек, в его новой конфе, работает на обычных 50 Гц, а выход VGA 60ц.
Т.е. там преобразуется 50 --> 60 Гц, каким-то методом с буферизацией всего экрана ?
У mvv, же спек, в его новой конфе, работает на обычных 50 Гц, а выход VGA 60ц.
Т.е. там преобразуется 50 --> 60 Гц, каким-то методом с буферизацией всего экрана ?
Наверно, ведь у TV точки выводятся с частотой 7 МГц, а на монитор ПО СТАНДАРТУ надо выводить с частотой 25,175 МГц. Поэтому нужен какой-то буфер для согласования частот. При преобразовании в 60 Гц возможны небольшие мерцания, но они малозаметны, так как старые игры или медленные или сами идут рывками. Кроме этого в современных телевизорах возможно есть такое же преобразование из 50 в 60. Или в переходниках SCART-HDMI.
А для нового быстрого режима нужно избежать преобразования частот кадров. Поэтому придется частоту INT тоже сделать 60 Гц. Длительность кадров и интервал между импульсами INT, немного уменьшится с 20 до 16.7 мс, зато процессор разгрузится и мы сможем сделать INT в том месте кадра, где нам удобнее. И изображение будет без рывков и мерцаний.
мы сможем сделать INT в том месте кадра, где нам удобнее.
Это имеется в виду, внутренний INT видео-карты.
Верно ?
Т.е. спековкий инт сигнал мы не трогаем никак ?
Это имеется в виду, внутренний INT видео-карты.
Верно ?
Т.е. спековкий инт сигнал мы не трогаем никак ?
В стандартном режиме Спектрума INT формируется примерно в начале кадрового импульса. Но место INT выбрано не очень удачно. Было бы больше времени на построение следующего экрана игры, если бы он формировался не в самой нижней точке кадра, а как только закончится изображение на телевизоре последней точки экрана 256x192. Тогда мы смогли бы сразу начать построение нового экрана.
Я предлагаю в новом режиме так и сделать. То есть в новом режиме частота и положение импульсов INT для Z80 новое.
Я предлагаю в новом режиме так и сделать. То есть в новом режиме частота и положение импульсов INT для Z80 новое.
Поправил. Теперь сигнал INT приходит после вывода последней точки. Отключается сигналом INTA. Можно даже сделать возможность задавать его положение к примеру после последней точки в каждой строке. Хотя это пока не нужно.
zst, у тебя Speccy2010 рабочая? Я могу пересобрать тестовый проект для неё, U8 и U9.
Поправил. Теперь сигнал INT приходит после вывода последней точки. Отключается сигналом INTA. Можно даже сделать возможность задавать его положение к примеру после последней точки в каждой строке. Хотя это пока не нужно.
zst, у тебя Speccy2010 рабочая? Я могу пересобрать тестовый проект для неё, U8 и U9.
Хорошо. У меня из девборд только Speccy2010. Пока без второго SD разъема. Проект под Speccy2010 нужен с выходом на аналоговый VGA. Сначала поизучаю, потом тоже подключусь, если знаний хватит.
Я вот думаю надо такие этапы отладки.
Сделать развертку VGA.
Потом новый контроллер SDRAM с чтение 8 точек сканера в кванте 0. На экране будет мусор.
Потом в кванте 3 добавить запись 8 точек в SDRAM. Записать сигналы типа цветных полос с 32 градациями яркости (любая часть картинки в 1 посте).
Потом добавить возможность включения/выключения нового режима из программы в машинных кодах. Для этого нужно выбрать, или оно уже есть средство для загрузки программ. Достаточно sna образа, который легко получить в компиляторе на PC.
Еще нужно выбрать расположение экрана, даже двух в SDRAM.
Пока такие отрывочные наброски, но уже можно начать двигаться. А глобальный план и спецификацию пока не составляй. Можно мелкими шажками пока.
В стандартном режиме Спектрума INT формируется примерно в начале кадрового импульса.
Это стандартное место, практически для всех приставок / компов (сега-мега, v6z80p, ...)
Я удивляюсь, откуда могла прийти такая идея со сдвигом инта ?
Вообще, не понятно где этот "сдвиг инта" в конфе спека mvv или в конфе-видео карты.
Это стандартное место, практически для всех приставок / компов (сега-мега, v6z80p, ...)
Я удивляюсь, откуда могла прийти такая идея со сдвигом инта ?
В стандартном режиме у нас есть время на рисование на экране только во время верхнего бордера. А время во время нижнего бордера пропадает зря.
Вообще, не понятно где этот "сдвиг инта" в конфе спека mvv или в конфе-видео карты.
Надеюсь они оба будут работать аналогично.
В стандартном режиме INT должен остаться на старом месте, чтобы времянки в старых играх не уплыли.
---------- Post added at 20:48 ---------- Previous post was at 20:44 ----------
Мне было бы очень кайфово и быстро адаптировать Саботера, если бы можно было...
4. Получить от карты момент окончания отрисовки экрана чтобы включить другую страницу с тайлмапами в момент отрисовки бордюра.
Выполняем пожелание программистов.
Предлагаю распределить память следующим образом:
Начиная с 0 адреса - буфер спрайтов размером 6.5 Мбайт
Буфер экрана 1 - 256 Кбайт
Буфер экрана 2 - 256 Кбайт
ZX ОЗУ - 1 Мбайт
Предлагаю распределить память следующим образом
Лучше добавить регистры:
1) адрес видео буфера 0
2) адрес видео буфера 1
3) управления (бит 0=0 отображается буфер 0; 1=буфер 1)
Хотя хватит одного регистра адреса видео буфера, дальше меняя его, можно хоть 10 буферов в памяти переключать. А так-как видео память линейная, то это ещё можно использовать как сдвиг вверх/вниз на строку или на х строк.
Со спрайтами и блиттером пока повременить. Сейчас доделаю тестовую конфигурацию для U16, потом перенесу на Speccy2010 (нужно будет припаять второй SD разъем для возможности работы DivMMC для загрузки ПО).
Лучше добавить регистры:
1) адрес видео буфера 0
2) адрес видео буфера 1
3) управления (бит 0=0 отображается буфер 0; 1=буфер 1)
Хотя хватит одного регистра адреса видео буфера, дальше меняя его, можно хоть 10 буферов в памяти переключать. А так-как видео память линейная, то это ещё можно использовать как сдвиг вверх/вниз на строку.
Со спрайтами пока повременить. Сейчас доделаю тестовую конфигурацию для U16, потом перенесу на Speccy2010 (нужно будет припаять второй SD разъем для возможности работы DivMMC, нужен будет для загрузки ПО).
Идея нежесткого расположения буферов хорошая. Но надо 2 регистра для адреса буфера 0 и 1. Обычно в 1 писать а из другого сканер будет отображать на монитор.
Как работать с DivMMC ? ссылку пожалуйста.
Какие устройства используют память SDRAM кроме ориентировочного ОЗУ 1M ?
Наверно надо прикинуть программку для Z80, которая могла бы закрасить экран какими-нубудь полосками.
Посылать данные из Z80 в видеокарту наверно лучше по 2 байта, например,
LD (PIXEL), HL.
Уже надо дешифраторы для команды включения/выключения режима, адресов буферов, адреса точки в SDRAM, данных точки (PIXEL),
Эти команды надо расположить в адресах 5AXX Z80.
Биты цвета в слове расположи, как я нарисовал в таблице. Тогда можно будет загрузить в ZX картинку 15 бит, а потом загрузить для пробы в видеокарту.
---------- Post added at 14:14 ---------- Previous post was at 14:09 ----------
Память буфера экрана с промежутками. 320 округлил до 512, 240 - до 256. Это немного увеличивает затраты в SDRAM, зато очень легко по координатам вычислить адрес точки в буфере экрана.
Эти команды надо расположить в адресах 5AXX Z80.
Лучше сделать базовый регистр, будет возможность спроэцировать массив регистров карты на любой из адресов памяти.
Память буфера экрана с промежутками. 320 округлил до 512, 240 - до 256
Это уже работа блиттера разные прямоугольники и квадраты из памяти вырезать. Если делать так, то тогда видео буфер должен быть 1024x1024, 512х512, 512х256 с возможностью указания базы нулевой позиции x,y отображаемой области. Тогда можно отображаемую область двигать ещё влево и вправо, типа сгролл в играх, дорисовывая только по краям :)
Лучше сделать базовый регистр, будет возможность спроэцировать массив регистров карты на любой из адресов памяти.
Можно так:
LD A,1
LD (0),A
LD A, BASE_ADDR
LD (0),A
Это уже работа блиттера разные прямоугольники и квадраты из памяти вырезать. Если делать так, то тогда видео буфер должен быть 1024x1024 с возможностью указания базы нулевой позиции x,y отображаемой области.
Это на один экран уйдет 2 мегабайта. На два экрана 4 мегабайта. Многовато. Давай не будем тратить.
За базовый объем ОЗУ девборды/видеокарты лучше взять 8 Мегабайт.
Максимум 512*512 на экран - это 512 Кбайт. 1 Мбайт на два экрана.
---------- Post added at 14:40 ---------- Previous post was at 14:30 ----------
Если использовать возможность дорисовывать часть экрана сбоку, а потом сдвигать путем указания смещения, надо возможность по-вертикали и горизонтали по два экрана. То есть 1024*512. Если при этом вместо двух буферов использовать 1, то 1 Мбайт дожно хватить на такой режим.
---------- Post added at 14:43 ---------- Previous post was at 14:40 ----------
Надо составить адресацию всех регистров, чтобы можно было начать разработку дешифратора в FPGA.
Но место INT выбрано не очень удачно. Было бы больше времени на построение следующего экрана игры, если бы он формировался не в самой нижней точке кадра
Если карта будет генерить сигнал INT, то будет конфликт со спековским инт.
Если карта будет генерить сигнал INT, то будет конфликт со спековским инт.
Смотрим бит регистра прерывания карты или врубаем IM2 и идем по вектору (их может быть несколько от карты) на ISR. Для обычного режима спектрума, карта INT может и не выдавать.
Если карта будет генерить сигнал INT, то будет конфликт со спековским инт.
В некоторых современных спектрумах с ZX-BUS предусмотрено подключение внешней видеокарты. Нужно просто снять на материнской плате перемычку, через которую идет INT. Примеры - ZXM-Phoenix, KAY-2010.
---------- Post added at 16:50 ---------- Previous post was at 16:30 ----------
Однобайтовые регистры видеорежима/видеокарты:
00 MODE - режим графики: 1 = 256х192 32K, 2 = 320х240 32K, 0 - стандартный 256х192 с атрибутами
01 ADDR_SCR1 - адрес экрана 1
02 ADDR_SCR2 - адрес экрана 2
03 CLEAR - закрасить экран цветом COLOUR
04 PLOT - нарисовать точку цветом COLOUR по координатам Y, X с предварительным смещением в качестве параметра: 0 = без смещения
Двухбайтовые регистры видеорежима/видеокарты:
F6 DY_L - смещение экрана по Y (мл. байт)
F7 DY_H - смещение экрана по Y (ст. байт)
F8 DX_L - смещение экрана по X (мл. байт)
F9 DX_H - смещение экрана по X (ст. байт)
FA Y_L - координата Y (мл. байт)
FB Y_H - координата Y (ст. байт)
FC X_L - координата X (мл. байт)
FD X_H - координата X (ст. байт)
FE COLOUR_L - цвет точки или экрана (мл. байт)
FF COLOUR_H - цвет точки или экрана (ст. байт)
Alex Rider
28.06.2015, 14:55
INT надо подавать после отображения на телевизоре правой нижней точки экрана 256х192 ?
Да
Т.е. каждую локацию подготовить в виде таблицы 32х24 тайла (768 на экран) и загрузить в SDRAM в буфер локаций. Дополнительные слои делать с прозрачными цветами и прозрачным спрайтам № 0. После этого для копирования из буфера локаций в буфер экрана достаточно будет указать адрес локации. После перехода в новое место скопировать в буфер экрана нижний слой, потом спрайты героев, потом верхний слой. Я правильно понял?
Сколько примерно надо локаций?
Не надо тайлмапы загружать в видеопамять. Они должны быть в памяти Спека, а карте Спек говорит только адреса тайломапов. Причем карта должна вычитывать тайломапы из тех страниц, которые в данный момент включены в адресное пространство Z80. Ну или сделать возможность указывать карте не только адреса тайломапов, но и страницы памяти, из которых надо читать.
Сколько байтов надо на номер тайла ?
Было бы круто сделать переключалку 1/2 байта на тайл. Скажем, в Саботере в слой фона выводится 256 тайлов. Зачем нужна переключалка: адаптировать код игры под 2 байта на тайл может быть ни разу не просто, а вот для новых игр и для коренных переделок старых 256 тайлов может и не хватить.
Перечислите, пожалуйста, названия игр, для которых такой способ тоже подойдет.
А для каких нужен другой способ ?
Какой ?
К сожалению, другие игры я подробно не разбирал.
Давайте, раз адреса атрибутов использовать нежелательно под адреса регистров видеорежима, используем старший адрес в области ПЗУ от 00 до 3F. Какой предпочтительнее ?
Не надо тайлмапы загружать в видеопамять. Они должны быть в памяти Спека, а карте Спек говорит только адреса тайломапов. Причем карта должна вычитывать тайломапы из тех страниц, которые в данный момент включены в адресное пространство Z80. Ну или сделать возможность указывать карте не только адреса тайломапов, но и страницы памяти, из которых надо читать.
Надо выбрать формат хранения тайломапа.
Было бы круто сделать переключалку 1/2 байта на тайл. Скажем, в Саботере в слой фона выводится 256 тайлов. Зачем нужна переключалка: адаптировать код игры под 2 байта на тайл может быть ни разу не просто, а вот для новых игр и для коренных переделок старых 256 тайлов может и не хватить.
Можно добавить режим номеров 1 или 2 байта.
К сожалению, другие игры я подробно не разбирал.
Может кто поделится опытом устройства других игр ? Для ELITE команды рисования точки и очистки экрана я уже добавил.
Давайте, раз адреса атрибутов использовать нежелательно под адреса регистров видеорежима, используем старший адрес в области ПЗУ от 00 до 3F. Какой предпочтительнее ?
Для начала я бы сделал 24-разрядный базовый регистр указывающий на блок регистров карты в памяти, тогда будет возможность включать их по любому адресу конкретно в любой из страниц памяти, ну или кратно 256.
Т.е. нужен видео порт карты IN/OUT n, доступный после её подключения. Чтение его даст информацию о наличии и состоянии карты, а запись включит блок регистров карты по указанному адресу в памяти в нужной нам странице.
Alex Rider
28.06.2015, 19:05
Т.е. нужен видео порт карты IN/OUT n, доступный после её подключения. Чтение его даст информацию о наличии и состоянии карты, а запись включит блок регистров карты по указанному адресу в памяти в нужной нам странице.
Да, согласен. Карта должна быть, во-первых, определяемая, а, во-вторых, отключаемая, причем все это через порт. BASIC 48, например, пытается писать с #0000, если карта будет всегда включена, то даже BASIC-программы будут творить с ней чудеса. При чтении из порта предлагаю со стороны карты выдавать ее версию.
---------- Post added at 19:05 ---------- Previous post was at 18:54 ----------
Надо выбрать формат хранения тайломапа.
Сложный вопрос... Если я предложу Саботеровский, то только ему подобные игры будут переделываться под карту без проблем. В целом, если забить на клиппирование спрайтов (а оно очень затратно по памяти Спека), есть резон сделать буфера либо на 32 * 24 = 768 байт (для однобайтных тайлов), либо 32 * 24 * 2 = 1536 байт для двухбайтных. В памяти слои идут последовательно. Карте нужно сказать сколько есть слоев, где в памяти начинается первый, какой набор тайлов для слоя использовать и надо ли зеркалировать (по X и Y) байты в графике тайлов. Хотя, при наличии у карты много ОЗУ в него можно закачать и перевернутые как угодно тайлы. За зеркалирование тайлов в тайлмапах отвечает код игры.
Чтобы не генерить дополнительное прерывание по окончанию вывода графики, можно сделать 2 набора тайломапов в памяти и переключать активный в начале кадра. Удобно было бы хранить их в разных страницах по одному адресу Z80.
Для начала я бы сделал 24-разрядный базовый регистр указывающий на блок регистров карты в памяти, тогда будет возможность включать их по любому адресу конкретно в любой из страниц памяти, ну или кратно 256.
Т.е. нужен видео порт карты IN/OUT n, доступный после её подключения. Чтение его даст информацию о наличии и состоянии карты, а запись включит блок регистров карты по указанному адресу в памяти в нужной нам странице.
Подожди, давай пока не будем усложнять. Базовый адрес установим в фиксированное место. Понадобится - добавим выбор. Но порты занимать не надо. Давай пока 0, 3F или AF. Это не существенно.
Можно было бы и порт занять, но сразу вопросы - какой ? не занят ли он ? не помешаем ли мы разработчикам будущего железа ?
Я предложил использовать адреса буфера атрибутов, так как в новом режиме атрибуты не используются. Давайте выбирать.
Я вот тут пересмотрел начало топика. Еще раз посмотрел твои картинки QuadSpeccy. Раз у нас режим VGA 640x480 60 Гц как основа всего - может быть добавить режим, когда в ОДНОЙ игре 4 окна, как у тебя на фотке и видео 4 РАЗНЫХ игры ? Это позволило бы без затирания основного динамического окна остальные окна использовать как вспомогательные, например, тексты, карты, выбор предметов и т.п. Как вам такая возможность ? То есть, кроме основного режима на весь экран добавить возможность отображать 4 экрана сразу.
Тогда надо добавить адреса еще для трех экранов. Для динамического будет 2 номера. Это на будущее. Программист сможет выбрать расположение в памяти каждого экрана или не использовать эту возможность.
Alex Rider
28.06.2015, 20:07
Подожди, давай пока не будем усложнять. Базовый адрес установим в фиксированное место. Понадобится - добавим выбор. Но порты занимать не надо. Давай пока 0, 3F или AF. Это не существенно.
Ты никогда не угадаешь какой софт какие адреса как использует. Некоторые клоны умеют ставить ОЗУ в 0-ю банку, они тебе в карту такого понапишут... Опять же, никто не мешает софту (STS, например) рисовать все только в 1-й экран, а 0-й использовать как обычную память. Никто никогда не гарантирует, что софт не будет писать в твою память не то, что надо тебе. Так что карта должна уметь включаться и выключаться через порты. Ну и определяться тоже - не хорошо выпускать игру, которая не может при загрузке сказать, что ей нужно вот такое вот железо, и без него она работать не будет.
Ты никогда не угадаешь какой софт какие адреса как использует. Некоторые клоны умеют ставить ОЗУ в 0-ю банку, они тебе в карту такого понапишут... Опять же, никто не мешает софту (STS, например) рисовать все только в 1-й экран, а 0-й использовать как обычную память. Никто никогда не гарантирует, что софт не будет писать в твою память не то, что надо тебе. Так что карта должна уметь включаться и выключаться через порты. Ну и определяться тоже - не хорошо выпускать игру, которая не может при загрузке сказать, что ей нужно вот такое вот железо, и без него она работать не будет.
Хорошо, давайте добавим порт для чтения состояния, готовности, выбора адреса и т.п.
Это верно, но так как мы всё строим в песочнице, то порт можно взять практически любой из диапазона 0-65535, но это будет незаконно, поэтому на это нужно получит разрешение в "Стандартизация портов и сертификация", а это не безплатно. Нужно подать заявку на рассмотрение Black_Cat.
PS. Это даже не штука.
Да, он этим занимался. Может у него есть список свободных портов.
А пока для отладки обойдемся без портов ? Или взять порт FF. Пока проект в FPGA - ничего не погорит.
Я подумал, если тактовую FPGA и SDRAM сделать кратно тактовой точек VGA, может это нам упростит разработку.
Да, он этим занимался. Может у него есть список свободных портов.
А пока для отладки обойдемся без портов ?
Нельзя, нужно дождаться ответа от Black_Cat. Спонсоров проекта нет, сейчас только ты да я, так-как порт по любому нужен, то придется скидываться на 1 (один) порт, очень надеюсь, что его будет достаточно, иначе просто не потянуть, очень дорогое хобби выйдет...
А пока для отладки обойдемся без портов ? Или взять порт FF. Пока проект в FPGA - ничего не погорит.
Пока проект в песочнице, то можно брать любой на выбор из свободных. Думаю тут никто возражать не будет.
Пока проект в песочнице, то можно брать любой на выбор из свободных. Думаю тут никто возражать не будет.
Ок. Как насчет многооконного интерфейса в играх. Весь экран в динамической графике не потянем, а один быстрый и три статических - наверно да:
http://s017.radikal.ru/i419/1506/58/6a75ddc217d6t.jpg (http://s017.radikal.ru/i419/1506/58/6a75ddc217d6.jpg) http://s017.radikal.ru/i443/1506/e1/87e624716abbt.jpg (http://s017.radikal.ru/i443/1506/e1/87e624716abb.png) http://s020.radikal.ru/i700/1506/6b/7cd2b2228b6ft.jpg (http://s020.radikal.ru/i700/1506/6b/7cd2b2228b6f.jpg) http://s010.radikal.ru/i313/1506/7b/3670b24eee75t.jpg (http://s010.radikal.ru/i313/1506/7b/3670b24eee75.jpg) http://s013.radikal.ru/i323/1506/80/8c52ddf17628t.jpg (http://s013.radikal.ru/i323/1506/80/8c52ddf17628.jpg)
Имеется ввиду, что в каждом окне своя информация. Конечно не 3D.
---------- Post added at 23:15 ---------- Previous post was at 23:01 ----------
При этом в динамическом окне у нас возможно изображение 320х240 точек. А на последней картинке динамическое окно 144х144 точек.
Таким образом у нас экран как бы имеет разрешение 640х480 точек, а спрайты и затраты на отображение экрана не увеличиваются.
Хотя, если пойти дальше, добавив еще один режим 640х480, но закрашивая динамическим изображением только часть экрана получим тоже самое, но границы статических частей будут произвольного размера, а не четверть экрана...
Smalovsky
29.06.2015, 10:34
Новая видеокарта нужна обязательно. Разработку игр нужно упростить до предела. Мне после высокоуровнего программирования графики неохота мучиться со стандартным спектрумовским экраном( а его структура не из самых простых).
Если у вас получится, напишу что-нибудь под эту железку!
Новая видеокарта нужна обязательно. Разработку игр нужно упростить до предела. Мне после высокоуровнего программирования графики неохота мучиться со стандартным спектрумовским экраном( а его структура не из самых простых).
Если у вас получится, напишу что-нибудь под эту железку!
Хорошо, а я пока займусь написанием первого теста на ассемблере.
На экране в режиме 320х240 будут изображены 10 горизонтальных полос высотой по 24 точки. Каждая полоса будет состоять из 64 прямоугольников шириной по 5 точек.
Цвета полос такие:
1. От черного до красного и от красного до белого.
2. От черного до зеленого и от зеленого до белого.
3. От черного до синего и от синего до белого.
4. От черного до сиреневого и от сиреневого до белого.
5. От черного до желтого и от желтого до белого.
6. От черного до голубого и от голубого до белого.
7. От черного до белого и от белого до черного.
8-10. В центре красный, зеленый, синий соответственно. Налево и направо - постепенный переход в другой оттенок (сиреневый, желтый, голубой).
Рисоваться все будет пока по точкам с помощью команды PLOT со смещением 0. Предварительно загружать координаты и цвет точки соответствующими командами, адреса которых приведены выше.
Включение командой записи в порт FFFF старшего байта блока адресов видеокарты. Можно проверить наличие видеорежима/видеокарты чтением из порта FFFF. Должно читаться 0.
Как насчет многооконного интерфейса в играх.
Как-то надуманно, лишнее усложнения.
Проще 640x480 сделать и нет проблем для программера.
Хотя, если пойти дальше, добавив еще один режим 640х480
Да, просто добавить 640x480, хотя конечно блиттер-у там будет побольше работы.
(если частоты провисают - смело дропайте полосу для блитера, режимчик важнее, пусть даже помедленее)
---------- Post added at 12:59 ---------- Previous post was at 12:22 ----------
Рисоваться все будет пока по точкам с помощью команды PLOT
Линия конечно обязательно.
(кружочки, прямоугольники - опционально)
---------- Post added at 13:07 ---------- Previous post was at 12:59 ----------
ожно проверить наличие видеорежима/видеокарты чтением из порта FFFF. Должно читаться 0.
Лучше чтоб строка (ноль в конце строки) читалась.
Каждый IN читает след байт.
типа "super video card ", 0
Потом, откуда-то, нужно прочитать "версия прошивки FPGA" и "версия платы". Это уже в байтами читается, не строкой.
Насчет инта:
Кадровый инт генерить как обычно, не сдвигать никуда.
Но, чтобы можно было карте задать номера линий, на этих линиях карта будет генерить строчный инт.
Да, просто добавить 640x480, хотя конечно блиттер-у там будет побольше работы.
(если частоты провисают - смело дропайте полосу для блитера, режимчик важнее, пусть даже помедленее)
Посмотрел картинки из игр на плоском мониторе с соотношением сторон 3х4 в WINDOWS в режиме 640х480@60Hz. Удвоенного размера (имитация размера точек в режимах 256х192 и 320х240) отлично, даже крупновато. Одинарного размера - тоже хорошо различимо. Если большую часть экрана занять статическими изображениями, параметрами, предметами и т.п., а действие будет происходить только на части экрана, то скорость может быть приемлемой.
В режиме 640х480 только затраты времени на сканер выше, так как точки надо выводить в два раза чаще. Тут может помочь буфер VGA. Буфер имеет две границы MAX и MIN. Пока к памяти нет обращений от Z80 и блиттера заполнять буфер по максмуму по 8 точек зараз. Частоту тактов SDRAM сделать 100 или 125 МГц. Это кратно частоте точек VGA 25 МГц в режиме 640х480 или 12.5 МГц в режиме 320х240. Как только объем данных в буфере становится MIN - приостанавливается блиттер и производится чтение данных в буфер VGA, пока не заполнится до MAX. Естественно, Z80 имеет больший приоритет при доступе к SDRAM.
Линия конечно обязательно.
(кружочки, прямоугольники - опционально)
Как только сделаем блиттер, перейдем к линиям. А точку сделать очень просто. Цвет мы записываем в регистр COLOR, координаты в регистры Y и X. А по координатам легко вычислить адрес точки на экране.
Лучше чтоб строка (ноль в конце строки) читалась.
Каждый IN читает след байт.
типа "super video card ", 0
Потом, откуда-то, нужно прочитать "версия прошивки FPGA" и "версия платы". Это уже в байтами читается, не строкой.
Это конечно интересно, но нам важно не название карты, а наличие режима. Он должен быть на всех видеокартах с разным названием. Нет режима - название уже не важно. Хотя потом, может быть, добавим.
Насчет инта:
Кадровый инт генерить как обычно, не сдвигать никуда.
Но, чтобы можно было карте задать номера линий, на этих линиях карта будет генерить строчный инт.
В стандартном режиме INT использовался для начала построения изображения в ОЗУ экрана, запуска очередной ноты в музыке, опроса клавиатуры. Самое важное - определить время, когда можно начать рисовать на экране новый кадр игры, а музыке и клавиатуре не важно положение инта на экране.
Поэтому, если сделать выбор, в какой строке генерировать INT - этого будет достаточно. Если делать два или больше интов - то нужно уже будет генерировать разные вектры прерываний. Может когда-нибудь. Пока оставим один с выбором строки (для справки - их 525).
Это конечно интересно, но нам важно не название карты, а наличие режима.
Тогда так "super video mode" или "SVM".
(Чуть веселей, чем нолик из порта.)
Тогда так "super video mode" или "SVM".
(Чуть веселей, чем нолик из порта.)
VGA ?
VGA ?
Я имею в виду, чтобы проверка на наличие режима, было чтение строки "SVM" из карты, из порта FFFF.
Вместо чтения байта из порта FFFF.
Я имею в виду, чтобы проверка на наличие режима, было чтение строки "SVM".
Вместо чтения байта из порта FFFF.
Это надо спросить у MVV, легко ли сделать ?
shurik-ua
29.06.2015, 20:43
легко ли сделать ?
Да легко это сделать только смысла нет - только тратить лишние байты в программе проверки наличия карты.
Одного бита достаточно ж )
Alex Rider
29.06.2015, 21:35
Я имею в виду, чтобы проверка на наличие режима, было чтение строки "SVM" из карты, из порта FFFF.
Ребята, не надо читать "SVM" из порта. Не хочу я писать в игре вот такой код:
ld bc,#ffff
in a,(c)
cp "S"
jr nz,.missing
in a,(c)
cp "V"
jr nz,.missing
in a,(c)
cp "M"
jr nz,.missing
.present:
...
.missing:
...
Я хочу вот такой:
ld bc,#ffff
halt ; чтобы не прочитать атрибуты экрана вместо номера версии
in a,(c)
cp MINIMAL_SUPPORTED_CARD_VERSION
jr c,.version_mismatch
inc a
jr z,.missing
.present:
...
.version_mismatch:
...
.missing:
...
Кстати, использование порта #xxff черевато тем, что самоделки с дешифрацией порта #00ff по младшему байту и кидающие всякую хрень (ну или честные атрибуты) для имитации порта #ff будут мешать карте. Да и вероятность того, что при выполнении in a,(#ff) в a будет #ff достаточно высока, соответственно, на платах, выдающих честные атрибуты, нарушится синхронизация видео по этому порту.
shurik-ua
29.06.2015, 21:46
Не хочу я писать в игре вот такой код
вот и я о том же )
вообще для программиста в идеале карта должна предоставлять какойто минимальный API - например команды "загрузить в карту спрайт № 1 из памяти по адресу 0xc000", "отобразить спрайт № 3 по координатам X,Y" - после чего программы будут писаться легко и непринуждённо даже на бейсике.
Alex Rider
29.06.2015, 22:41
вообще для программиста в идеале карта должна предоставлять какойто минимальный API - например команды "загрузить в карту спрайт № 1 из памяти по адресу 0xc000", "отобразить спрайт № 3 по координатам X,Y" - после чего программы будут писаться легко и непринуждённо даже на бейсике.
И все-таки тайломапы нужны. Ибо далеко не во всех играх логика работает только с координатами спрайтов - часто нужно и текущее их "окружение" (фон, передний план, соседние спрайты).
Alex Rider
29.06.2015, 22:41
вообще для программиста в идеале карта должна предоставлять какойто минимальный API - например команды "загрузить в карту спрайт № 1 из памяти по адресу 0xc000", "отобразить спрайт № 3 по координатам X,Y" - после чего программы будут писаться легко и непринуждённо даже на бейсике.
И все-таки тайломапы нужны. Ибо далеко не во всех играх логика работает только с координатами спрайтов - часто нужно и текущее их "окружение" (фон, передний план, соседние спрайты).
Lethargeek
30.06.2015, 00:43
вообще для программиста в идеале карта должна предоставлять какойто минимальный API - например команды "загрузить в карту спрайт № 1 из памяти по адресу 0xc000", "отобразить спрайт № 3 по координатам X,Y" - после чего программы будут писаться легко и непринуждённо даже на бейсике.
для программиста должно быть удобно писать движки
чему лишняя специализация железки скорей вредит
И все-таки тайломапы нужны. Ибо далеко не во всех играх логика работает только с координатами спрайтов - часто нужно и текущее их "окружение" (фон, передний план, соседние спрайты).
зачем логике работать с изображением? ну, кроме редких случаев типа ксоникса
Alex Rider
30.06.2015, 01:42
зачем логике работать с изображением? ну, кроме редких случаев типа ксоникса
С тайломапами, на базе которых строится изображение. Часто бывает достаточно пробежаться по списку спрайтов на экране чтобы понять кто где и с кем столкнулись. Но зачастую надо определить, на опоре ли стоим, и на опоре какого типа - тут и сгодится тайломап. Ну отсюда неплохо реализовать отрисовку тайломапа в карте. Повторюсь, весь мой "богатый" опыт почерпнут из Саботера. Сюда бы goodboy'а с его опытом расковыривания игр, он бы подсказал какие бывают способы вывода изображения в играх.
Возможно добавить возможность выполнять блоки команд при построении изображения. Предварительно в одном блоке Z80 настраивает, что и где нужно вывести. Потом видеокарта обрабатывает и выводит в соответствующими блоками команд.
COMBLOCK1:
DW BLOCK1 ; дальний план - заполнение экрана полностью мелкими тайлами
DW BLOCK2 ; средний план - заполнение части экрана тайлами
DW BLOCK3 ; отображение спрайтов движущихся объектов
DW BLOCK4 ; передний план - печать одиночных тайлов
DW 0 - конец блока
В каждом блоке заготовки для вывода объектов. Можно поменять координаты, номера спрайтов, адрес таблицы для заполнения фона. Z80 в процессе игры вычисляети заполняет эти параметры, а потом видеокарта это все выводит.
Давайте описание места запишем на языке, подобном BASIC, в разных стилях:
BLOCK1 - задний план
DW SIZE_Y, 8, SIZE_X, 8 - размер тайлов в таблице
DW ADDR_TL, TILES1 - адрес блока тайлов
DW Y=0, X=0 - координаты печати таблицы
DW STR, 24, COL, 32 размер таблицы
DW ADDR_TAB, LEVEL1 - адрес таблицы
DW PRINT_TAB - печать таблицы
DW 0 - конец блока
BLOCK2 - средний план
DW SIZE_Y, 80, SIZE_X, 64 - размер картинки 1
DW ADDR_IMG, IMAGE01 - адрес картинки 1
DW Y, 20, X, 130 - координаты картинки 1
DW PRINT_IMG - печать картинки 1
DW SIZE_Y, 60, SIZE_X, 120 - размер картинки 2
DW ADDR_IMG, IMAGE02 - адрес картинки 2
DW Y, 100, X, 4 - координаты картинки 2
DW PRINT_IMG - печать картинки 2
DW 0 - конец блока
BLOCK3 - движущиеся объекты
DW SIZE_Y, 24, SIZE_X, 16 - размер спрайта
DW ADDR_SPR, SPITE2 - адрес блока спрайтов
DW Y=20, X=280 - координаты печати спрайта
DW PRINT_SPR, 240 - печать спрайта с номером 240
DW 0 - конец блока
LEVEL1 - таблица уровня 1
DB 3, 2, 2, 2, 2, 3 .. ; 32 номера тайлов 1 строки
...
DB 3, 2, 2, 2, 2, 3 .. ; 32 номера тайлов 32 строки
DB 0 - конец таблицы
LEVEL2 - таблица уровня 2
DB 1, 2, 3, 4, 5, 6 .. ; 32 номера тайлов 1 строки
...
DB 7, 8, 9, 0, 1, 2 .. ; 32 номера тайлов 32 строки
DB 0 - конец таблицы
BLOCK2 - средний план
BLOCK2 и BLOCK3 практически очень похожи.
Думаю убрать BLOCK3, оставить BLOCK2.
LEVEL1 - таблица уровня 1
Номера тайлов сразу двух байтные делать.
(Либо же переключатель где-то иметь (1 или 2 байта на номер тайла).)
Написал видеотест для режима графики 320х240. Разноцветные полосы рисуются по точкам. Рабочие переменные в области атрибутов, поэтому мигают в стандартном режиме. Проверка на наличие карты пока не делается. Время закраски около 2 секунд.
Jerri и другие программисты. Есть ли информация, как строится изображение в популярных играх для ZX Spectrum? И какие методы закраски могут пригодиться для создания подобных игр в новом режиме графики.
Smalovsky
01.07.2015, 02:49
Я пишу игры с использованием известной граф.библиотеки( правда на джаве, но может опыт и для спектрума сгодится). Так вот, проверка на столкновение всегда пишется программно!!! Алгоритмы столкновения крайне просты - пересечение ограничивающих прямоугольников или попадание точки в ограничивающий прямоугольник.
Параметры ячеек игрового мира (тип блока,например, платформа, цельный блок, лестница и пр.) хранится в памяти компьютера, как и массив этих значений для всей игровой карты. Эта информация видеокарте не нужна!!!
Принцип обработки игрового цикла:
1. Вычислили промежуток времени с момента прошлой итерации(для 8 бит вычислять не надо)
2. Подсчитали все координаты обьектов.
3. Сделали проверку на столкновение и скорректировали результаты.
4. Отрисовали фон и объекты по вычисленным координатам( причём одной функцией для каждого спрайта по его координате и размеров ограничивающего прямоугольника. Правда в джаве вместо номера спрайта нужно передать ссылку на спрайт)
Никакой лишней информации видеокарте не нужно отправлять. Видеокарта занимается только выводом.
---------- Post added at 02:49 ---------- Previous post was at 02:11 ----------
Извините, я не совсем понял принцип работы новой видеокарты.
В программе мы поместили данные в адрес памяти, который служит кодом команды. А как видеокарта определяет, что это новые данные, по факту произведённой записи в память?
BLOCK2 и BLOCK3 практически очень похожи.
Думаю убрать BLOCK3, оставить BLOCK2.
Содержимое и количество блоков произвольное. Там могут быть разные команды. Одного блока недостаточно. Например, в одном блоке надо нарисовать фон. А в другом несколько спрайтов движущихся объектов. А кол-во объектов все время разное. Поэтому после всех команд для рисования спрайтов ставим признак END. И видеокарта перейдет к следущему блоку команд.
Номера тайлов сразу двух байтные делать.
(Либо же переключатель где-то иметь (1 или 2 байта на номер тайла).)
Да, надо добавить параметр длины номера тайлов/спрайтов.
---------- Post added at 12:56 ---------- Previous post was at 12:41 ----------
Я пишу игры ... на джаве, но может опыт и для спектрума сгодится...Параметры ячеек игрового мира (тип блока,например, платформа, цельный блок, лестница и пр.) хранится в памяти компьютера, как и массив этих значений для всей игровой карты. Эта информация видеокарте не нужна!!!
...
4. Отрисовали фон и объекты по вычисленным координатам( причём одной функцией для каждого спрайта по его координате и размеров ограничивающего прямоугольника. Правда в джаве вместо номера спрайта нужно передать ссылку на спрайт)
Никакой лишней информации видеокарте не нужно отправлять. Видеокарта занимается только выводом.
Я также предполагал, что мы рисуем фон тайлами и движущиеся объектами одинаковым образом, указывая координаты на экране, прямоугольные размеры объектов и номера. Но посчитали, что при малых размерах тайлов 8х8 и большом экране 320х240 надо каждый кадр пересылать 1200 тайлов. Предложили в новых играх использовать спрайты покрупнее, но для адаптации старых игр размер тайлов/спрайтов желательно оставить старыми.
Хотя Z80 справился бы, желательно, чтобы в играх, где это возможно, видеокарта сама брала номера тайлов из таблицы в памяти.
После изображения фона надо изобразить спрайты движущихся объектов, Z80 может подождать видеокарту. Но лучше писать все команды с координатами и номерами не в видеокарту, а в область памяти, откуда видеокарта потом их сама заберет. Поэтому появилась идея деления всех команд на блоки. Т.е. надо обеспечить обработку команд из памяти. Может быть тогда непосредственная запись некоторых команд в регистры видеокарты будет и не нужна.
Извините, я не совсем понял принцип работы новой видеокарты.
В программе мы поместили данные в адрес памяти, который служит кодом команды. А как видеокарта определяет, что это новые данные, по факту произведённой записи в память?
Для параметров типа координат используются последние записанные данные (они запоминаются внутри видеокатры). Для выполнения команд служит сигнал записи в определенные адреса - адреса регистров видеокарты. Для передаче параметров и команд видеокарте выделяется область в адресном пространстве Z80 размером 256 байт. Старший байт этой области я предлагал расположить фиксированно в области атрибутов, так как в новом режиме атрибуты свободны в любой игре. Но поступило предложение настраивать старший байт этой облати. Естественно, его надо будет где-нибудь найти в старой игре или выделить в новой.
Таким образом, видеокарта имеет 256 входных регистров, в которые мы можем записывать по адресам ПЗУ или ОЗУ (зависит от выбора старшего байта). После включения нового режима видеокарта отслеживает эти адреса и записывает в регистры данные. Некоторые регистры, например, адреса, координаты, цвето точки объеденены по два. После записи в некоторые регистры параметра запускают выполнение команд видеокатры.
Smalovsky,А какие ориентировочно числа в играх: размер экрана в точках, количество тайлов по-горизонтали, вертикали, размеры тайлов и спрайтов? Как задаются указатели на спрайты (может нам тоже пригодятся)? Сохраняется ли фон перед печатью спрайтов? Какого типа игры и их аналоги среди игр для ZX Spectrum?
Smalovsky
01.07.2015, 13:03
Smalovsky,А какие ориентировочно числа в играх: размер экрана в точках, количество тайлов по-горизонтали, вертикали, размеры тайлов и спрайтов? Как задаются указатели на спрайты (может нам тоже пригодятся)? Сохраняется ли фон перед печатью спрайтов? Какого типа игры и их аналоги среди игр для ZX Spectrum?
Экраннонезависимое разрешение(от 640х480 и выше). Количество спрайтов ограничивается только возможностями видеокарты. Были спрайты 32х60, элементы
фона 16х16. Опять же всё экраннонезависимо и растягивается до разрешения монитора. В библиотеке libGDX спрайты - это любые изображения, там нет понятий спрайтов и тайлов.
Ссылка на спрайт - это пременная, которая хранит адрес области памяти, в которой находится спрайт.
Вообще, современные видеокарты, не оперируют спрайтами и тайлами. Они оперируют текстурами(изображениями в специальном формате) - это как у вас области спрайтов, и текстурными регионами - это как у вас спрайты из заданной области спрайтов. Конечно, может быть много текстур и много текстурных регионов.
Указатель на спрайт (текстурный регион) задаётся так:
TextureRegion txtregion = new TextureRegion(Texture,x,y,width,height);
,где
x,y- координаты левого верхнего угла в текстурных координатах (относительно текстуры Texture, в которой хранится спрайт);
width,height - ширина и высота требуемого спрайта в текстурных координатах.
Выводит спрайты на экран класс SpriteBatch - это как бы ваша видеокарта и очередь команд. Объект этого класса скрывает от программиста архитектуру видеокарты и предоставляет ему только команды отрисовки. Вот, как рисуются два спрайта:
spritebatch.begin();// начало очереди команд отрисовки
spritebatch.draw(txtregion1,x,y);// первая команда очереди - выводим спрайт1 на экран в позицию x,y без изменения его ширины и высоты
spritebatch.draw(txtregion1,x,y,_width,_height);// вторая команда очереди - выводим спрайт2 на экран в позицию x,y маштабируя его ширину и высоту до требуемых _width,_height
spritebatch.end();// конец очереди команд и отправка инструкций видеокарте
Есть интересная команда у SpriteBatch - setColor(R,G,B,Value),в которой
R,G,B - цвет задаваемый цветовыми компонентами, Value - интенсивность этого цвета. Так вот, эта команда придаёт как бы оттенок(блеск) выводимым спрайтам(цвет и интенсивность этого оттенка заданы в команде). Это называется Tinting.
Вам тоже можно сделать Tinting. Например, один регистр выделить на цвет, а другой на интенсивность (если он равен 0, то Tinting выключен). Это позволит например делать такой эффект как плавное появление сумерек или рассвет. То есть, с каждым кадром можно плавно увеличивать или уменьшать регистр интенсивности.
Так же не помешает сделать Blending- прозрачность для выводимых спрайтов. Речь не идёт о прозрачном цвете, нет - он остаётся как есть! Просто задавая величину блендинга можно сразу все видимые пикселы выводимого спрайта сделать полупрозрачными. Вы можете выделить один регистр для блендинга (если он равен 0, то блендинг выключен - спрайт выводится как есть, остальные значения - интенсивность прозрачности - спрайт приобретает прозрачность). Это позволит сделать такой эффект как полупрозрачные облака или окна. Например, мы отрисовали фон без блендинга, затем включили блендинг (задали ненулевое значение) и нарисовали спрайты облаков, затем конечно блендинг нужно отключить(задать нулевое значение) и дальше формировать кадр.
Lethargeek
01.07.2015, 14:44
С тайломапами, на базе которых строится изображение. Часто бывает достаточно пробежаться по списку спрайтов на экране чтобы понять кто где и с кем столкнулись. Но зачастую надо определить, на опоре ли стоим, и на опоре какого типа - тут и сгодится тайломап.
тут сгодится просто массив обычный, и не надо лезть куда-то в память девайсов
Ну отсюда неплохо реализовать отрисовку тайломапа в карте. Повторюсь, весь мой "богатый" опыт почерпнут из Саботера. Сюда бы goodboy'а с его опытом расковыривания игр, он бы подсказал какие бывают способы вывода изображения в играх.
а при чём тут вывод изображения, логику не надо с картинкой смешивать
где-то тайл захотим использовать как опору, а где-то нет
Ещё проблема есть, со сдвигом тайловой карты (массива).
Например, для скролла влево на размер тайла,
нужно будет "сдвинуть влево" карту тайлов
(и потом справа карты тайлов, добавить новый вертикальный столбец тайлов).
Сдвинуть нужно 2400 байт или 4800 байт (для двух слоевых игр).
(и ещё больше нужно двигать, в больших разрешениях)
Процессором это делать накладно.
Посему тайловые карты нужно хранить в памяти видео-карты
и по команде (например "сдвинуть влево") пусть карта и сдвигает этот массив байтов, а не медленный z80.
В блоках команд, там где указывается адрес тайловой карты,
просто будет указываться не адрес в спеке, а адрес в карте.
делается карта 2 на 2 экрана и закольцовывается
Пусть так.
Smalovsky
01.07.2015, 21:55
Я вспомнил старинный прием для изображения фона, состоящего из мелких деталей, в играх для спектрума. Суть в том, что первый раз фон формируется в видеопамяти медленно, а в последующих кадрах он не изменяется целиком, перерисовываются( изменяются, восстанавливаются) только те участки фона, которые были затерты спрайтами . Но это решение хорошо только для статических фонов.
На основе этого приема,но существенно изменив технологию, я придумал следующее решение:
Добавить в видеокарту дополнительный буфер памяти, добавить команды печати спрайтов в буфер, добавить команды отображения части буфера( или целиком) в основную видеопамять карты в любое место( участок отображаемого видеобуфера воспринимается как один огромный спрайт) .
Применение этой технологии для высокодетализированного фона:
1. Заполняем буфер фоном спрайтами фона;
2. Каждый новый кадр отображаем уже сформированный фон в видеобуфере в основную видеопамять карты( или выбранный для построения изображения банк памяти). Далее рисуем спрайты в видеопамять карты уже поверх готового фона.
Буфер желательно иметь больше размером чем участок видеопамяти экрана на случай нескольких перекрывающихся со спрайтами планов ( например, заносим в видеопамять экрана первый план из участка буфера, затем рисуем спрайты непосредственно в видеопамять экрана, и накладываем поверх передний план из другого участка буфера).
Если буфер достаточно большой( 4 экрана), то можно реализовать скроллинг. Для этого первоначально нужно заполнить буфер большим участком карты (обычной печатью спрайтов), затем часть буфера равного размеру экрана ( это как бы окно) выводить на экран. Получится, что мы двигаем окно по карте.
Lethargeek
02.07.2015, 02:33
Добавить в видеокарту дополнительный буфер памяти, добавить команды печати спрайтов в буфер, добавить команды отображения части буфера( или целиком) в основную видеопамять карты в любое место( участок отображаемого видеобуфера воспринимается как один огромный спрайт) .
да не надо там никаких буферов отдельных от основной памяти видеокарты, и вообще -
это всё самый примитивный блиттер (http://zx-pk.ru/showpost.php?p=812185&postcount=61) лишь с одной командой переброски строк с разрывом и так умеет
но увы, автору просто нравится бессмысленно и беспощадно городить сложные решения частных случаев
Никто никогда тайломап не двигает, делается карта 2 на 2 экрана и закольцовывается. Прекращайте уже, правда. Zst прочитайте пожалуйста про любой спрайтовый акселератор со слоями, про тот же tsconf, там на самом деле все просто и удобно. У него конечно есть ограничения наложенные целевой платформой, но структура и подход правильные. И наконец то надо определится блиттер или спрайты.
Почитал про устройство экранов в TSconf (http://hype.retroscene.org/blog/dev/177.html) и NES (http://habrahabr.ru/post/259171/). И там и там тайлы размером 8х8 точек и тайловая карта 64х64 клетки. Прокрутка без копирования, аппаратная. Но при движении вправо дальше двух экранов надо постоянно подрисовывать справа от экрана новый столбик. Предлагаю для упрощения написания игр выделить под тайловую карту большую площадь 256х256 клеток. Каждой клетке будет соответствовать тайл также размером 8х8, описываемый двумя байтами. Тогда при движении мы можем просто указывать координаты окна в тайловой карте в клетках и дополнительное смещение в точках.
---------- Post added at 12:58 ---------- Previous post was at 12:55 ----------
Т.к. у меня нет реального спектрума, сделал простенький zx-spectrum c 128K ОЗУ, 32К ПЗУ, Z80 на 3.5МГц, AY и DivMMC 128K + SD, добавил ещё и загрузку с реального магнитофона. Всё ОЗУ и ПЗУ разместил во внутренней памяти камня - M10K, что дает возможность пока полностью использовать SDRAM для видео карты. Видео выход VGA 640x480@60Hz (ZX-Spectrum screen x2 = H:32+256+32; V=24+192+24). Конфигурация ZX128K (https://github.com/mvvproject/DE1-SoC-Board) написана для DE1-SoC, решил использовать её, т.к. плата максимально подходит для разработки и отладки, на борту есть GPIO, можно вывести ZXBus/NemoBus и попробовать как всё будет работать с разными платками, но платок у меня тоже нет. HPS (Dual-core ARM CortexA9 + 1GB DDR3) сейчас не используется, но может быть использован для софтовой эмуляции различного спектрумовского железа, тут я пока ещё не разбирался.
Теперь можно двигаться дальше с разработкой и отладкой модуля графической карты.
Что дальше ? Надо изменить настройки SDRAM ?
Предлагаю для упрощения написания игр выделить под тайловую карту большую площадь 256х256 клеток.
Можно и столько. (в 2 раза меньше тоже нормально будет)
Ведь тайловая карта будет в памяти видео-карты ?
Тогда при движении мы можем просто указывать координаты окна в тайловой карте в клетках и дополнительное смещение в точках.
Да, но всё равно,
нужно сделать закольцовывание.
Когда видео-карта печатает,
используя тайловую карту,
чтобы при выходе за пределы тайловой карты, координаты тайлов закольцовывались.
Можно и столько. (в 2 раза меньше тоже нормально будет)
Ведь тайловая карта будет в памяти видео-карты ?
Да, но всё равно,
нужно сделать закольцовывание.
Когда видео-карта печатает,
используя тайловую карту,
чтобы при выходе за пределы тайловой карты, координаты тайлов закольцовывались.
Давайте упростим еще и увеличим размеры тайловой карты до 1024 на 1024. Хватит на 25 экранов по-горизонтали и 34 по-вертикали. Памяти пока хвватает. Можно будет двигать фон хоть влево, хоть вниз, хоть нарезать на отдельные локации.
Теперь у нас подготовлена карта для простого аппаратного скроллинга тип Денди. Задаем окно в карте тайлов для вывода на экран. Копируем в буфер экрана с помощью блиттера, добавляем сверху спрайты и тайлы переднего фона.
Спрайты можно копировать в буфер экрана с помощью командного файла с упрощенной структурой:
Y1,X1,N1, Y2,X2,N2, Y3,X3,N3, FFFF.
Давайте упростим еще и увеличим размеры тайловой карты до 1024 на 1024. Хватит на 25 экранов по-горизонтали и 34 по-вертикали. Памяти пока хвватает. Можно будет двигать фон хоть влево, хоть вниз, хоть нарезать на отдельные локации.
Добавить бы ещё закольцовывание.
Там логика простая.
Если, координата текущего печатаемого тайла (X, Y), выходит за пределы тайловой карты,
обнулить X и/или Y.
Как-то так:
Если X > TILE_MAP_WIDTH - 1, то X=0
Если Y > TILE_MAP_HEIGHT - 1, то Y=0
TILE_MAP_WIDTH, TILE_MAP_HEIGHT - размер тайловой карты (в тайлах)
Добавить бы ещё закольцовывание.
Там логика простая.
ОК.
Команды инициализации SDRAM после включения питания для тактовой частоты до 133 MHz в режиме 3-3-3 с пакетным режимом чтения и записи по 8 точек (BL=8):
NOP около 14000 тактов
PRECHARGE ALL (A10=1)
NOP 3 такта
AUTOREFRESH
NOP 9 тактов
AUTOREFRESH
NOP 9 тактов
LOAD MODE REGISTER (BA1=0, BA0=0, A[12...0] = 000 0 00 011 0 011)
NOP 2 такта
CodeMaster
02.07.2015, 21:09
Можно будет двигать фон хоть влево, хоть вниз
А двигаться он будет попиксельно или кратно 8-ми?
Памяти пока хвватает.
А игры будут только "бродилки/леталки", расширятся функционал не будет? Поддержка 3D движков? Или для этого памяти много не потребуется?
Smalovsky
02.07.2015, 22:01
ʁɔɯиҺʎvоu ɐɯdɐʞ ʁɐнɔǝdǝɯни
Alex Rider
03.07.2015, 01:16
Ok, я согласен, что сделать удобно для адаптации всех игр не получится - какие-то придется переписать основательно. Но господа, не забываем одну вещь: сделать новую хорошую игру трудно! Для этого нужны таланты геймдизайнера, художника, музыканта, программиста - сейчас командной работы в этой области почти нет. А вот для переделки игры нужны в основном только программерские способности, ну результат с текущей графикой можно предложить художнику для редизайна. Это сильно проще.
2. Подсчитали все координаты обьектов.
3. Сделали проверку на столкновение и скорректировали результаты.
4. Отрисовали фон и объекты по вычисленным координатам
а при чём тут вывод изображения, логику не надо с картинкой смешивать
Увы, чего только нет в старых играх для экономии тактов. В том числе, и определение столкновений и даже обработка логики игры во время отрисовки. А про использование экранных атрибутов и графики тайлов в качестве аркадных атрибутов писал даже "Инфорком" в своей серии про графику.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot