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

[Lethargeek]

Что не так ?

ВСЁ не так. Повторю: зачем делать неуниверсально и явно то, что само получается неявно по общей схеме??

Важно, что новый режим упростит написание новых игр,

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

возможно также поможет в ускорении старых.

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

Как раз Денди мы копировать не собираемся,

Как раз денди вы копировать и пытаетесь, причём именно что худшие его стороны, да еще неэффективным затратным способом.

Надо немного ускорить обычную графику Спектрума.

ОБЫЧНАЯ графика Спектрума ускоряется исключительно турбированием проца.
А ты предлагаешь новый и полностью несовместимый режим не-Спектрума.

Тайлы и спрайты просто помогают построить изображение из повторяющихся элементов.

Блиттер без дурацких ограничений помогает строить его не хуже, а гораздо лучше - из элементов произвольного размера и положения.
Слово "произвольный" тебе понятно? Это значит, что сетка тайлов одинакового размера туда тоже входит как частный случай.

Так почти везде делают.

"Везде делают" то, что позволяет делать железо.
Но зачем его искусcтвенно ограничивать?????
Чтобы вдруг лучше чем на денди не получилось?


---------- 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]

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

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

[Lethargeek]

MVV, для игрушек (мб кроме очень редких и специфических) чтение из памяти видеокарты вообще не нужно

[MVV]

для игрушек (мб кроме очень редких и специфических) чтение из памяти видеокарты вообще не нужно

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

[Valen]

дык писал же: http://zx-pk.ru/showpost.php?p=812185&postcount=61

Ясно,
ты привел универсальный интрефейс работы с блиттером.
Используя его можно нарисовать экран любой степени сложности.

Никакие дополнительные команды блитеру, придумывать не нужно.

[zx-kit]

дык писал же: 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 десятка команд, видеокарта при помощи блиттера вывела вам тайловый слой, причем нет каких то заморочек с ограничением размеров итд, надо к примеру эмулировать поведение странного экрана спектрума, тот же шейдер может и эту задачу выполнять

Объясните еще раз подробнее.

[Advertiser]

[Sayman]

MVV, для игрушек (мб кроме очень редких и специфических) чтение из памяти видеокарты вообще не нужно

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

Объясните еще раз подробнее.

что такое hlsl знаешь?

C-подобный язык высокого уровня для программирования шейдеров

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

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

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

[zx-kit]

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

Планируешь сделать карту ? A12 я бы на SDRAM не подавал. INT подал бы через диод. Согласование с шиной данный просто сигналом DIR что-то мне не нравится. Не уверен, что будет работать.
Светодиод и аудио разъем лишние. Или там звук через ШИМ ?
2V5 для чего используется ?
Разъем uBUS не подключен.

[Sayman]

Lethargeek,

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

Разница в том, что кидать в порт байт за байтом в цикле каждый раз когда мне это нужно в итоге будет геморно и не удобно. зачем создавать себе проблему? куда удобнее заготовить всё заранее и один раз сбросить данные карте, а она пускай уже пашет. Про ascii, ну конечно, или вы хотите девайс забабахать без какого либо пзу? хотя судя по хотелке это уже карта по навороченности аля ГС получается и без своего пзу тут явно не обойтись. объясните мне кто-нибудь из железячников, зачем мне как кодеру извращения в виде десятка циклов с кидательством по портам и прочего гемора, когда можно всё решить простым методом - снабдить карту своим пзу и пущай "разговаривает по человечески".
и вапще, давно пора уже 3д вводить! даёшь gl es 1.1 (или хотя бы 1.0+).

[MVV]

Планируешь сделать карту ?

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

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+)

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