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

[Nesser]

Предлагаю сделать палитру в 512 байт (коли 16 бит на цвет). Загружать по ldir в некую область ПЗУ, во время записи карта будет вычитвать палитру (желательно менять палитры динамически, чтобы можно было иметь разные палитры в разных локациях; желательно иметь возможность менять любой цвет в палитре, можно будет делать fade-in-эффекты).

Да нет смысла настолько усложнять такое устройство, или зажали 48 кБ из 8 МБ для нормального байтового экрана?

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

[Advertiser]

[Nesser]

Я уже даже придумал как с растрами работать

К примеру нужно сделать
PLOT 128,88,116 - То есть по центру экрана вывести точку с цветом 116

LD A,116
LD L,128
LD H,88
-----------
LD (200),HL
LD (202),A
-----------
устройство принимает при записи в пзу по адресу 200 и 201 соответственно Y и X и защелкивает их в регистр
а по адресу 202 получает цвет и сразу же записывает его на экран

---------- Post added at 21:51 ---------- Previous post was at 21:48 ----------

прямая линия по центру экрана с цветом 19

LD A,19
LD L,0
LD H,88

L1 LD BC,255
LD (200),HL
LD (202),A
INC L
DJNZ L1

[Alex Rider]

так не бывает, рисовать можно на экране 4 способами
1. Процессором хоста
2. Спрайтовый движок
3. Блиттер
4. Процессор в видеокарте (шейдер)

А давай придумаем 5-й способ = 1 + 4? Процессор рисует графику вместе с железом видеокарты? Ведь без разницы же как видеокарта помогает рисовать быстрее - прошивкой ПЛИС или прошивкой процессора?

Теперь, речь идет о ускорении, при этом последние 3 варианта исключаются, каким образом достигается ускорение?

Ахтунг! Читаем примеры кода, которые я приводил для вывода спрайтов, считаем такты, думаем. Для тех, кому лень:
1. Мы перестаем запоминать фон и восстанавливать его. upd: и передний статический слой тоже
2. Мы начинаем выводить знакоместо без маски через dup 8: ldi: edup, знакоместо с маской и 4-хцветное знакоместо - через dup 8: ldi: dec e: ldi: edup (а с новой адресацией мы можем так вывести целый столбец спрайта).
3. Для монохромных спрайтов мы перестаем выводить атрибуты.
4. С новой адресацией экрана забываем страшный код перехода к новой строке/трети.

---------- Post added at 20:59 ---------- Previous post was at 20:58 ----------

Объем данных увеличивается и при этом процессор хоста одновременно быстрее рисует? ну так не бывает.

Перестаем размышлять в рамках известных архитектур, и все начинает получаться!

---------- Post added at 21:01 ---------- Previous post was at 20:59 ----------

Подожди, но ты уже увеличил объём спрайтов в 2 раза+куча палитр, да и экран уже стал как минимум в 2 раза больше и экрана надо всё равно 2, иначе будет видно отрисовку, то есть 6144*2*2=24576 и плюс в 2-5 раз увеличенные в 2 раза спрайты и приклеенные к ним палитры которые по размерам больше чем сам спрайт, встаёт проблема запихивания этого всего в 2-3 страницы по 16к, то есть старую игру надо не просто переделать а тупо написать ЗАНОВО, по иным принципам и с помощью новых процедур, да ещё и гемор с кучей палитр всего по 3 регистра каждая

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

---------- Post added at 21:05 ---------- Previous post was at 21:01 ----------

Все эти процедуры можно произвести программно перед закидыванием спрайтов в память устройства

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

---------- Post added at 21:08 ---------- Previous post was at 21:05 ----------

К примеру нужно сделать
PLOT 128,88,116 - То есть по центру экрана вывести точку с цветом 116

Векторная графика - это тоже на будущее. Сейчас приновом формате экрана для того, чтобы сделать твой PLOT, придется пока покрутить биты и поделить x на 8, остальное все почти так же. А при поддержке растровой графики прямые линии рисовать в цикле CPU - это фи. Надо уж сразу делать аппаратные векторные примитивы, ибо в той же Elite движок более половины времени рендерит картинку на экран.

---------- Post added at 21:09 ---------- Previous post was at 21:08 ----------

Для начала, хоть кто-то сделал стандартный спектрумовский видео режим 256х192 с бордюром? О чем здесь можно ещё говорить, когда нет даже базового режима?

А, тем более, нет эмулятора. Без него совсем тяжко будет, отвыкли мы все уже от Alasm'ов на реале.

[Nesser]

По спрайтам точно так же.
К примеру есть память 1 МБ, то есть 20 бит адреса и 49 кБ экрана (два) то есть 16 бит адреса, к примеру включаем режим спрайтов 8*8 (16*16), то есть 64 байта, то бишь 6 бит адреса, остаётся 20-6=14 бит адреса на номер спрайта то есть 16384 спрайтов, можно и меньше памяти (или больше).

Задача вывести спрайт под номером 217 в координаты 200, 140

LD L,200
LD H,140
LD DE,217
-----------------
LD (204),HL
LD (206),DE
-----------------


Или к примеру нужна летающая табличка для демки (или большой монстр в R-TYPE) шириной 64 пикселя (8 спрайтов) и высотой 24 пикселя (3 спрайта), в ширину раскладываем табличку на 8 спрайтов с номерами 100-107, следующий ряд 108-115, следующий 116-123, то есть тупо картинку раскладываем подряд в спрайты, кидаем координаты и после каждого спрайта увеличиваем координаты на 8, в итоге получим боольшую шнягу на экране не сильно усложняя устройство, на такие манипуляции cpu точно хватит, пока он выполняет свои команды устройство выкидывает предыдущий спрайт на экран..

---------- Post added at 22:16 ---------- Previous post was at 22:14 ----------

нууу если вдруг не успеет то в момент записи в 206 адрес можно тормознуть камень по вайту

[Alex Rider]

По спрайтам точно так же.

Ты читаешь вообще что тут пишут? Или ты решил в этой теме придумать свою видеокарту? На данный момент никаких аппаратных точек и спрайтов не будет! Можно завести еще один тред и рассказывать там всем какая карта понравилась бы лично тебе.

[Nesser]

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

Нууу столкновение исторически вычисляется двумя способами

тупо последовательным перебором координат спрайтов в поисках наложений (программно или аппаратно)

или

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

---------- Post added at 22:26 ---------- Previous post was at 22:24 ----------

Ты читаешь вообще что тут пишут? Или ты решил в этой теме придумать свою видеокарту? На данный момент никаких аппаратных точек и спрайтов не будет! Можно завести еще один тред и рассказывать там всем какая карта понравилась бы лично тебе.

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

[Alex Rider]

Нууу столкновение исторически вычисляется двумя способами

А еще при рендеренге на экран определяется И такое есть в существующих играх.

Так новый графический режим это и есть устройство под названием видеокарта

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

[s_kosorev]

А давай придумаем 5-й способ = 1 + 4? Процессор рисует графику вместе с железом видеокарты? Ведь без разницы же как видеокарта помогает рисовать быстрее - прошивкой ПЛИС или прошивкой процессора?

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

Мы перестаем запоминать фон и восстанавливать его. upd: и передний статический слой тоже

какой профит в играх где фрейм заново рисуется каждый кадр? тот же R-Type

Мы начинаем выводить знакоместо без маски через dup 8: ldi: edup, знакоместо с маской и 4-хцветное знакоместо - через dup 8: ldi: dec e: ldi: edup (а с новой адресацией мы можем так вывести целый столбец спрайта).

маска это для спрайтов, обычно малая часть экрана, для фонов сцен толку 0

Для монохромных спрайтов мы перестаем выводить атрибуты.

Вот где экономия! ну сколько тех атрибутов на спрайт? тоже мизер

С новой адресацией экрана забываем страшный код перехода к новой строке/трети.

Какое планируемое ускорение в 2-3 раза? или хотя бы 2-3%

Перестаем размышлять в рамках известных архитектур, и все начинает получаться!

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

[Nesser]

Я в описании ничего не нашёл о том как аппаратно это устройство выглядит, линейная адресация побитовых пикселей может только создать тормоза, так как для перехода на следующую линию придётся делать ADD X,128, то есть обычным inc уже не обойдётся...

---------- Post added at 22:34 ---------- Previous post was at 22:32 ----------

А еще при рендеренге на экран определяется И такое есть в существующих играх.

Так это и есть второй способ который я указал

---------- Post added at 22:36 ---------- Previous post was at 22:34 ----------

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

Вот и я говорю что это уже видеокарта а не графический режим

[zx_]

ицых с гвоздями!
вот у компьютера Специалист восемь цветов на точку не тормозили совсем процессор
и раскрашивать легко
и всего штук пять дип и немного озу
и схему цветности к чему угодно подключить, порт только выбрать
а в ВГА преобразовать уже совсем другая и решенная задачка

от нищеты люди гораздо лучше придумывали (с)