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

Цитата:

---

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

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

---

Режим NO_CLASH все-таки близок к стандартному. Не надо переучиваться - используется имеющийся опыт. Подходит для улучшения некоторых игр. Позволит устранить клешинг для простых игр типа ходилок. Ускорение для такого режима незначительное, не более 1.5 раза, зато не надо переделывать графику, а только заменить небольшую подпрограмму с помощью патча.

Блиттер подразумевает серьезные изменения в спрайтах. И его труднее сделать. А тут процессор все делает сам.

При линейной адресации экрана с адреса 0000:
Первый столбик байтов имеет адреса 0000, 0001, ... 00BF.
Второй столбик - 0100, 0101, ... 01BF.
Последний столбик - 1F00, 1F01, ... 1FBF.

При линейной адресации экрана с адреса 4000:
Первый столбик байтов имеет адреса 4000, 4001, ... 40BF.
Второй столбик - 4100, 4101, ... 41BF.
Последний столбик - 5F00, 5F01, ... 5FBF.

---------- Post added at 20:17 ---------- Previous post was at 20:14 ----------

Цитата:

---

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

zst,
Тут я вижу 2 варианта, что случится при переключении линейности:
1. Картинка на экране "замиксуется"
2. Процессор будет адресовать видеопамять по другому, а картинка сохранится.

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

---

Это трудно сделать. Я даже не представляю как. Проще выбрать тип адресации и изменить подпрограммы вычисления экранного адреса и печати. И печатать все с новой адресацией.

---------- Post added at 20:17 ---------- Previous post was at 20:17 ----------

Цитата:

---

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

Как у амстрада.

---

Не знал.

---------- Post added at 20:56 ---------- Previous post was at 20:17 ----------

Цитата:

---

По поводу новой адресации я тоже ничего не понял напишите маску расчета как для стандартного: bit (7-x2x1x0) addr 010y7 y6y2y1y0 : y5y4y3x7 x6x5x4x3

---

Для экрана с адреса 0000: bit (7-x2x1x0) addr 000x7x6x5x4x3 : y7y6y5y4y3y2y1y0
Для экрана с адреса 4000: bit (7-x2x1x0) addr 010x7x6x5x4x3 : y7y6y5y4y3y2y1y0

Цитата:

---

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

zst, собрал на U16 твой синхронизатор http://zx-pk.ru/showpost.php?p=821946&postcount=364, ну что сказать, круто! Считать-считает, только ничего на экране нет :(

---

Там же только синхроимпульсы. Они идут на монитор ? KGI и SGI надо использовать для обнуления и счета адресов точек. Для начала можно из этих адресов сформировать цветные полосы.

Код:

---

always @(posedge clk)
begin
if (sgi)      // во время видимой части строки считают счетчики
    begin
    if (pix_cnt == 9)    // если max для частоты точек 12.6 МHz
        begin
        pix_cnt <= 0;
        addr_lo <= addr_lo + 1'b1;
        end
    else
        pix_cnt <= pix_cnt + 1'b1;
    end
else    // во время строчного гасящего импулься счетчики обнуляются
    begin
    pix_cnt <= 0;
    addr_lo <= 0;
    end
end

---

Частота пикселов для режима 320х240 и 256х192

Цитата:

---

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

ну что сказать, мегакруто!

---

а в чём разница между этим - http://zx-pk.ru/showpost.php?p=812088&postcount=41
и тем что zst написал )

Если по теме то как-то развитие темы забуксовало - как-то всё не очень понятно что автор задумал - какие-то тайлы вперемешку с блиттером, процессор там что-то двигает в байте прежде чем отправлять в аксель - имхо это не правильно.
Насчёт того как правильно у меня такие соображения:
как тут уже неоднократно проскакивала мысль что нагородить можно кучу любых режимов, но скорее всего они не будут поддержаны - поэтому нужен максимально совместимый режим со стандартным спековским экраном, и вот как это примерно должно быть
1. у акселя своя память и он слушает шину - никаких ДМА и прочей ереси;
2. каждый экран я бы сделал для начала байт на точку с палитрой - итого 49152 байт на экран, самих экранов от 2 до 4;
3. например при записи байта по адресу между 0х4000 .. 0х57FF аксель должен успеть записать в свою видеопамять 8 байт а при записи по адреcам из области атрибутов успеть записать уже 64 байта - также нужно после ресета первые 16 цветов палитры сделать как стандартные цвета спека - это всё для что касается режима совместимости;
4. теперь что касается самих наворотов - проц должен общаться с акселем более высокоуровнево, вот например список основных команд:
0х01 - послать в память акселя спрайт номер такой-то с размером таким то - примерно как в GS - аксель уже сам сообразит где у себя в памяти его разместить
0х02 - отобразить спрайт номер тако-то по координатам таким-то.
0хFF - типо инит - очистить внутреннюю память спрайтов или чтото ещё )
остальные команды добавлять - там точку, линию или print_char аппаратный.

в общем как-то так - игры адаптировать под такое элементарно, или даже на бейсике писать новые )

а то что-то грустно совсем следить за этой темкой ))

Цитата:

---

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

Да, zst, а в чём разница?

---

Разница в подходах, предпочтениях, характеристиках видеорежимов.

ЦЕЛИ РАЗРАБОТКИ НОВЫХ ВИДЕОРЕЖИМОВ

ZST Упростить и ускорить вывод 2D графики для улучшения старых игр и для увеличения количества и качества новых игр.
MVV: Наверно сделать более крутым ReVerSE для запуска UNIX.

ПРЕДПОЧТИТЕЛЬНЫЙ КОНСТРУКТИВ КОМПЬЮТЕРА НА БАЗЕ ZX SPECTRUM:

ZST Многоплатный конструктив, модульная конструкция с шиной ZX-BUS или ZST-BUS. Возможность реализации новых видеорежимов на большинстве компьютеров на базе FPGA и SDRAM, а также в виде видеокарты на отдельной плате.
MVV Миниатюрный компьютер типа ReVerSE с мощной FPGA, большой SDRAM, микросхемами часов, USB и сетевой карты.

ПРЕДСТАВЛЕНИЕ О ВИДЕОРЕЖИМАХ:

ZST Нужно разработать такую систему команд, чтобы передавать как можно меньше параметров. Работать на ассемблере, но на более высоком уровне. Например, чтобы напечатать спрайт, видеокарта должна получить номер спрайта и координаты для копирования, а адрес и размеры видеокарта должна взять сама из таблицы.
MVV ?.

ЧАСТОТА Z80:

ZST Для режимов с блиттером достаточно стандартной частоты 3.5 MHz. При этом процессор не будет часто требовать доступ к ОЗУ, что позволит предоставить больше квантов времени для работы сканера и блиттера.
MVV 42 MHz.

РАЗРАБОТКА ВИДЕОРЕЖИМА:

ZST Прорабатывает характеристи и команды новых видеорежимов.
MVV Более склонен к технической реализации, отлаживает режимы на FPGA.

НАЗВАНИЕ ВИДЕОРЕЖИМА / ВИДЕОКАРТЫ:

ZST Не любит сокращения. Назвал видеокарту "Meteor Graphics".
MVV Не нравится название "Meteor". Любит сокращения типа "GPU".

ВИДЕОЦАП VGA:

ZST Считает достаточным и технически реализуемым 5-битный ЦАП R-2R на каждый канал, что позволит изображать досточно качественно цвета на многих компьютерах на базе FPGA.
MVV Считает, что ЦАП должен быть 8-битным.

ВЫХОД VGA:

ZST Стандартный аналоговый VGA.
MVV Цифровой HDMI.

КОЛИЧЕСТВО БАЙТОВ НА ТОЧКУ:

ZST Для большинства режимов достаточно 1 байта на точку. Для некоторых 2 (в одно слово SDRAM уместится 3 * 5 = 15 битов цвета, что ускорит копирование).
MVV Считает, что желательно 3 байта на точку. В каждом байте по 8 бит цвета, всего 24 бита.

ПАЛИТРА:

ZST Предлагает для начала реализовать режимы без палитры, ограничившись количеством цветов 15, как в стандартных режимах ZX-Spectrum, или 64, как на плате ZX-Evo.
MVV Предлагает сразу начать с четырех палитр по 24 бита.

СПОСОБ ВЫВОДА НА ЭКРАН:

ZST Считает, что все режимы, новые и старые, должны готовить изображение в буфере экрана. Откуда потом просто выводить на VGA через буфер VGA на основе 24 восьмибитных регистров.
MVV Вывод через двухпортовую память и буфер FIFO.

РЕГЕНЕРАЦИЯ SDRAM:

ZST Достаточно 5 циклов регенерации во время строчного синхроимпульса VGA, что упростит реализацию доступа к буферу экрана при выводе на VGA.
MVV Считает, что циклы регенерации лучше проводить через равные промежутки времени.

СПОСОБЫ ПРОЕКТИРОВАНИЯ:

ZST Предпочитает начинать с простого, постепенно добавляя новые функции. Часто не отвечает на письма и любит делать перерывы в работе на обдумывание и отдых. Любит придумывать новые режимы, часто потом их модернизирует, что затрудняет следить за текущим состоянием разработки.
MVV Сначала составить спецификацию, план работ и т.п. Должна быть команда специалистов по железу и софту. Работает быстро, сделал уже много, любит отвечать на письма в реальном режиме, считает, что после обсуждения сообщения лучше удалить, что несколько затрудняет следить за нитью обсуждения в теме через некоторое время.


У них много разногласий, свои предпочтения, но их объединяет стремление что-то сделать для ZX Spectrum. В некоторых технических вопросах достигнуто соглашение:

Основная развертка экрана 640х480@60Hz с проектированием на нее остальных разрешений.
Частота FPGA и SDRAM 126 MHz
Пакетный режим работы SDRAM с длиной пакета 8.
Чтобы не изобретать велосипед можно добавлять новые режимы в TS-conf для ReVerSE и Speccy2010.

Цитата:

---

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

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

---

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

Цитата:

---

третье - никто так и не удосужился заглянуть на git и попробовать запустить то что уже было написано, zst принялся писать то, что уже отлажено и разрабатывалось не один месяц, а это всё время... Не ну, я не исключаю того, что у него возможно получится лучше с нуля, но у нас ведь не конкурс, а "вроде как" командная работа над одним проектом? Раз такая пьянка, то было-бы лучше распределить работу среди тех, у кого есть желание принять участие в проекте.

---

По текущей ссылке в твоей подписи трудно найти. Там даты старые. Если он там есть - я не нашел, если в другом месте - приведи прямую ссылку в подписи, чтобы каждый мог сразу туда попасть. Наверно лучше назвать типа новый видеорежим Meteor или GPU и две папки для ReVerSE и Speccy2010.

Цитата:

---

четвертое - на данный момент уже работает, отлажено и выложено на git:
1) контроллер SDRAM, работа в Burst 8 на частоте 126 МГц, wr=15 тактов (119,047619047619ns), rd=14 тактов (111,1111111111111ns), rfsh=9 тактов (71,42857142857143ns);
2) синхронизатор VGA
3) текстовый режим 80х30 (знакоместо 8х16), 16-цветов, аппаратный курсор.
4) zx-screen режим, INT=60Гц, на базе режима 640х480@60Hz
5) graphics режим 640х480@60Hz 24bpp, INT=60Гц
6) HDMI serializer (U16)
7) палитра
8) NextZ80@42MHz

---

Надо постепенно находить общий язык. Почему бы не сделать для нового режима стандартную частоту 3.5 MHz, убрать палитру и текстовый режим? Ты предпочитаешь для вывода на VGA двухпортовое ОЗУ вместо обычных регистров, отказался регенерацию сделать, как я предложил. Используешь ли ты буфер экрана как я предложил - я даже не знаю ? Вот и делаем каждый, как считает правильным. Тянем в разные стороны, как в басне "Лебедь, щука и рак". А воз и ныне там.

Лебедь, Щука и Рак

Когда в товарищах согласья нет,
На лад их дело не пойдёт,
И выйдет из него не дело, только мука.
Однажды Лебедь, Рак да Щука
Везти с поклажей воз взялись
И вместе трое все в него впряглись;
Из кожи лезут вон, а возу всё нет ходу!
Поклажа бы для них казалась и легка:
Да Лебедь рвётся в облака,
Рак пятится назад, а Щука тянет в воду.
Кто виноват из них, кто прав — судить не нам;
Да только воз и ныне там.

Цитата:

---

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

Да только воз и ныне там

---

Золотые слова. Лучше спроектировать задуманное, чем доказывать, что ты не верблюд.

Цитата:

---

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

учится вам и учится , глянь на сумму сборов

---

Не в обиду,человек не за баксы думает,за идею болеет,ну может компенсацию расходов на разработку.
А вы похоже зарабатывать не там решили,спектрум и его разновидности давно не коммерческий проект,вы талантливый,умный человек и найдете применение своим знаниям.Вы хотите zst завербовать чтоб панели делать на пару?
Для чего вы про солнечные панели ,видео поклали сюда,оно к видеорежимам не применить.

---------- Post added at 00:01 ---------- Previous post was at 00:01 ----------

Цитата:

---

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

учится вам и учится , глянь на сумму сборов

---

Не в обиду,человек не за баксы думает,за идею болеет,ну может компенсацию расходов на разработку.
А вы похоже зарабатывать не там решили,спектрум и его разновидности давно не коммерческий проект,вы талантливый,умный человек и найдете применение своим знаниям.Вы хотите zst завербовать чтоб панели делать на пару?
Для чего вы про солнечные панели ,видео поклали сюда,оно к видеорежимам не применить.

Новые режимы

Z80 только записывает данные в экранную область, остальные преобразования битов и закрашивание слоев выполняет видеокарта !

Режимы цвета без палитры:

1 бит на цвет точки:

ZX - 2 цвета на 64 точки (знакоместо размером 8х8 точек)
Это стандартный режим Спектрума. Работает в слое 0. Цвета точек зависят от атрибута, общего для 8 байтов пикселей. Бит FLASH в байте атрибута работает как аппаратное инвертирование цветов в знакоместе.

COLOR1C - 1 цвет на 8 точек + прозрачный
По соответствующему адресу в области пикселей нужно записать байт данных. На каждую из восьми точек приходится по 1 биту: 0 - прозрачный, 1 - цветной. Номер цвета предварительно записывается в переменную color. 0 - прозрачный, 1-255 выбранный цвет. Данный режим предназначен для наложения одноцветного изображения поверх существующего. Например, для вывода текста, рисования линии по точкам, а также для стирания тайла/спрайта с текущего слоя, если color = 0.

COLOR2 - 2 цвета на 8 точек
По соответствующему адресу в области пикселей нужно записать байт данных. На каждую из восьми точек приходится по 1 биту. Цвета задаются стандартным байтом атрибута, который записывается в переменную attr перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. Если установлен бит FLASH - цвета записываются с инверсией, но без аппаратного мигания.

COLOR2M - 2 цвета на 8 точек + маска
По соответствующему адресу в области пикселей нужно записать подряд 2 байта. Отличается от режима COLOR2 тем, что перед байтом данных записывается байт маски. Биты маски указывают - прозрачные точки или цветные. Цвета задаются стандартным байтом атрибута, который записывается в переменную attr перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. Если установлен бит FLASH - цвета записываются с инверсией, но без аппаратного мигания.


Режимы цвета с палитрой для рисования:

COLOR2P - 2 цвета на 8 точек
По соответствующему адресу в области пикселей нужно записать байт данных. На каждую из восьми точек приходится по 1 биту. Цвета задаются палитрой, номер которой записывается в переменную pl2 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 2 цвета от 1 до 255 и прозрачный 0.

COLOR2MP - 2 цвета на 8 точек + маска
По соответствующему адресу в области пикселей нужно записать подряд 2 байта. Отличается от режима COLOR2P тем, что перед байтом данных записывается байт маски. Биты маски указывают - прозрачные точки или цветные. Цвета задаются палитрой, номер которой записывается в переменную pl2 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 2 цвета от 1 до 255 и прозрачный 0.


2 бита на цвет точки:

COLOR4P - 4 цвета на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 2 байта данных. На каждую из восьми точек приходится по 2 бита из разных байтов.
Цвета задаются палитрой, номер которой записывается в переменную pl4 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 4 цвета от 1 до 255 и прозрачный 0.


3 бита на цвет точки:

COLOR8P - 8 цветов на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 3 байта данных. На каждую из восьми точек приходится по 3 бита из разных байтов.
Цвета задаются палитрой, номер которой записывается в переменную pl8 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 8 цветов от 1 до 255 и прозрачный 0.


4 бита на цвет точки:

COLOR16P - 16 цветов на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 4 байта данных. На каждую из восьми точек приходится по 4 бита из разных байтов.
Цвета задаются палитрой, номер которой записывается в переменную pl16 перед рисованием очередных 8 точек, знакоместа или тайла/спрайта. В палитре для рисования 16 цветов от 1 до 255 и прозрачный 0.

Предварительно палитры заполняются необходимыми цветами. Номер палитры выбирается перед рисованием очередных 8 точек, знакоместа, тайла/спрайта или по мере необходимости.