Войти
ФлеймФорумЖелезо

Блеск и нищета 8/16-битных консолей и ПК (88 стр)

Страницы: 187 88 89 90 91 Следующая »
#1305
22:16, 18 ноя. 2020

Shurik7777
> Но не помню где я это вычитал. Нашел только пересказ слов Джона Кармака, что 
> Джобс не верил в этот вид развлечений.

Когда Джобс имел дело с играми то игры того времени действительно имели плачевный вид в виде черно-белого пин-понга.


#1306
(Правка: 13:04) 12:46, 20 ноя. 2020

Процессор  https://ru.wikipedia.org/wiki/Texas_Instruments_TMS9900
применялся и в компьютере 82-года Cortex (Powertran производитель?)

http://ftp.whtech.com/Powertran%20Cortex

P.S. Встретился архив по Apple II https://mirrors.apple2.org.za/ftp.apple.asimov.net/

#1307
18:26, 20 ноя. 2020

Рубрика 8-бит железячная дичь

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры
#1308
22:26, 20 ноя. 2020

0iStalker
> Рубрика 8-бит железячная дичь
Вот это реально дичь, даже скорее эпик

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры
#1309
22:49, 20 ноя. 2020

=A=L=X=
> и физические уровни и куда течёт или не течёт ток по схемотехнике
замыкается
строка+столбец=кнопка.
KD2+A11=3
KD0+A11=1
KD0+KD2+A11=и 1 и 3 обе нажатые

#1310
13:28, 2 дек. 2020

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры
#1311
(Правка: 10:50) 10:47, 15 дек. 2020

Тут у нас Zosya Entertaiment появились: https://gamedev.ru/projects/forum/?id=257190 со своей игрой Valley of Rains.
Это заставило меня задуматься опять о том что немало движков есть с познакоместным скроллингом и с дёрганной конечно, но всё же играбельной скоростью.
Познакоместность таких движков означает, что единицей изображения тут является знакоместо - 8x8 пикселей и сдвиг и вообще движение чего либо возможны только с гранулярностью в эти знакоместа.
Спектруму от этого весьма тепло и по производительности и по принципу раскраски знакомест, когда графический монохром раскрашен квадратно-гнездовой таблицей атрибутов так как будто бы это текстовой видеорежим - каждое знакоместо 8x8 может иметь только два цвета внутри себя. Окай. Таким образом каждое знакоместо это 8 байт пиксельного монохрома и 1 байт цветового атрибута.
Познакоместность вышеобозначенных движков хотя и получает грубое движение, но зато исключает проблемы с клешингом и выжимает немало скорости, что важно.
В случай ZOSYA выглядит это так:

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

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

Так вот - а как собственно сделать максимально быстрое заполнение сетки знакомест при той безумной нелинейной раскладке видеопамяти спектрума?
А я кажется понял прямо вот сейчас разглядывая Valley of Rains (несомненно это было уже много кем, где и когда понятно и описано! но опишу еще раз).
Предположим что регистровая пара HL у нас смотрит в начало пиксельных данных знакоместа (полоска 8x1) в экранной области. Кто в ZX Spectrum опытен, тот знает, что переход к следующей полоске пикселей производится легко, инструкцией INC H.
Напрашивается переливка пиксельных данных откуда то допустим куда указывает регистровая пара DE типа так вот:

LOOP:
LD B, 8 ; счётчик цикла
LD A, (DE) ; возьмём из DE
INC DE ; увеличим DE (можно обойтись увеличением E если данные выровнены по 8 байт)
LD (HL), A ; положим в знакоместо
INC H ; переходим к следующей полоске
DJNZ LOOP ; цикл
Но с точки зрения производительности тут всё ужасно.
Конечно напрашивается разворачивание цикла, но какой же он неповоротливый и большой станет...
И вот до меня дошло (памятуя о технике LD/PUSH), что тут тоже надо сделать код данными!
Порылся в опкодах и да - вот оно! Инструкция засылающая в (HL) непосредственное данное: LD (HL), data8
Тогда:
TILE_XXXX:
LD (HL), data0
INC H
LD (HL), data1
INC H
LD (HL), data2
INC H
LD (HL), data3
INC H
LD (HL), data4
INC H
LD (HL), data5
INC H
LD (HL), data6
INC H
LD (HL), data7
LD A, color
LD (DE), A
RET
Делаем код данными - каждый тайл-знакоместо это код который вышеописанными инструкциями переливает данные зашитые в него в тайл. Предполагается что на входе HL содержит указатель на начало пиксельных данных знакоместа, а DE - указатель на байт с атрибутами знакоместа. Настроившись так рисовальщик должен сделать CALL TILE_NUM и вуаля - крайне быстро прямо кодом тайл и его цвет заполнят что надо.
Накладные расходы очевидны - объёмы тайлов набухают. Но на спектруме в играх реально скорость намного важнее, чем плотность данных.
Тут получается, что каждый тайл состоит из 28 байт инструкций перемешанных с данными в то время как в плотной форме данных всего 9 байт. Но код работающий с такими данными по типу того что был приведён в начале выполняется в разы медленнее, просто в разы.
Интересно, что прозрачный тайл тут может быть просто инструкцией RET. :)

Дальше - хуже. По ссылке выше на LD/PUSH можно увидеть технику когда как бы инструкции создают буфер заливающий всю экранную область.
А ведь тут можно сделать похожим образом - тот буфер тайлов который олицетворяет собой экран (и который рисуется) выполнить как последовательность команд:

CALL TILE1_1: INC BC: CALL TILE1_2: INC BC ... ; 32 раза на строку
CALL TILE2_1: INC BC: CALL TILE2_2: INC BC: ... ; следующая строка
Зачем тут понадобился BC и его инкремент - в результате выполнения программы тайла регистр HL портится смещаясь по тайлу в нижеследующие строки пикселей.
А нам надо "скользить" им по строкам экрана инкрементируясь на 1 (в рамках полутрети экрана, но тут в это я углубляться не буду). Чтобы не терять в скорости "скользить" мы будем регистровой парой BC, а в начале каждой тайловой программы добавим еще пару инструкций копирующих BC в HL (таким образом каждый тайл станет размером в 30 байт).
Зато что мы получим - мгновенную отрисовку всего экрана (вернее одной трети экрана!) на максимальных парах познакоместно с использованием той техники что описана по ссылке на LD/PUSH.
Тут конечно получается, что обновлять содержимое тайлов надо подменяя адреса TILE1_1 прямо в этой табличке и подпиливая где вход и где выход как описано.
А это круто!
Теория конечно теорией, но выглядит весьма правдоподобно. :)

#1312
11:06, 15 дек. 2020
=A=L=X=
> Так вот - а как собственно сделать максимально быстрое заполнение сетки
> знакомест при той безумной нелинейной раскладке видеопамяти спектрума?

Кстати, на современных FPGA/CPLD клонах, со статической памятью - ровно никаких проблем сделать линейный экран... правда, ценой потери всей библиотеки софта (но может иметь смысл для новодельных демосцен, например).

#1313
12:49, 15 дек. 2020

Разработчик Gameduino 1,2,3 провёл сбор средств на разработку шилда для Arduino — Gameduino 3X Dazzler (GPU, FPGA, HDMI, and Python support for gaming and audiovisuals)
www.crowdsupply.com/excamera/gameduino-3x-dazzler

P.S. Разработка с открытыми исходниками.
Firmware для FPGA на базисе стэкового процессора J1 этого же разработчика.

+ Показать

#1314
16:32, 15 дек. 2020

=A=L=X=
Добавить бы к этой игре мультиколор и был бы ваще отвал башки.

#1315
17:20, 15 дек. 2020

gamedevfor
> Добавить бы к этой игре мультиколор и был бы ваще отвал башки.

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

Вообще интересно сравнить с явным вдохновителем - игрой Savage 1988 года:

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

(геймплей с 6:10)
В 1988 году весь задний фон был монолитом - один слой - таких выкрутасов как в Valley of Rains от Zosya Entertainment чуть выше с как минимум двумя независимо скроллируемыми задними фонами не было.
При этом частота кадров в 2019 году даже выросла! :)
Вот это вот самое удивительное и радующее :)

Лично я тут же вспомнил еще одну игру: Trantor

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

И что Trantor, что Savage конечно же просто взрывали мозг тем что непонятно куда бежать, что делать и как выживать.
Главная хрень - в том, что можно только как то по горизонтали и ограниченно стрелять полностью не контролируя всё что пролетает над тобой.
Прыгать чтобы сбить то что летит чуть ниже чем обычно - это прям....
Ну и сами лабиринты намного, очень намного, прямо лет на 30 опередили своё время: https://gamedev.ru/flame/forum/?id=183103

Тем не менее всё это мне очень нравится. :)

#1316
18:42, 15 дек. 2020

=A=L=X=
> Не, с таким мультколор не вывезти уже без существенных поднятий частот.

Может Zosya покажет нам мастер-класс, я в неё верю. )))

#1317
14:00, 16 дек. 2020

По поводу линейной адресации экрана  в ZX Spectrum, во что бы это вылилось при выводе текста, например?  По идее,  если мы считаем адрес первой строки знакоместа по формуле

Аddr = Row*8*256 + Col*8

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

#1318
(Правка: 14:20) 14:19, 16 дек. 2020

0iStalker
> то адрес следующей строки в знакоместе вычисляется банальным инкрементом
> старшего байта адреса

Не понял.
В одной строке 256/8=32 байт каждый из которых соответствует полоске в 8 пикселей каждого знакоместа.
Следующая полоска пикселей текущего знакоместа таким образом находится на +32 байта дальше.
Это та же полоска пикселей знакоместа на 1 позицию ниже находится на расстоянии 32*8=256, т.е. на инкременте верхнего байта адреса.

А вот то как сделано сейчас как раз следующая полоска текущего знакоместа находится на инкременте верхнего байта адреса.
Так что вывод текста замедлился бы.

#1319
14:34, 16 дек. 2020

В "Специалисте" и "Орион-128" было сделано очевиднее - последовательная нумерация байтов шла по вертикали. Как раз вся вертикаль - 256 байт. Хочешь перейти к следующей полоске текущего знакоместа - просто инкрементируешь адрес. Хочешь перейти к следующему знакоместу (если делать 8х8) - инкрементируешь старший байт.

Правда в дефолтных биосовских процедурах вывода символа использовались знакоместа 6х8, так что мутили с масками и сдвигами, хотя такая организация видеопамяти все равно что-то упрощала.

Страницы: 187 88 89 90 91 Следующая »
ФлеймФорумЖелезо