Тёмная тема
Shurik7777
> Но не помню где я это вычитал. Нашел только пересказ слов Джона Кармака, что
> Джобс не верил в этот вид развлечений.
Когда Джобс имел дело с играми то игры того времени действительно имели плачевный вид в виде черно-белого пин-понга.
Процессор 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/
Рубрика 8-бит железячная дичь
0iStalker
> Рубрика 8-бит железячная дичь
Вот это реально дичь, даже скорее эпик
=A=L=X=
> и физические уровни и куда течёт или не течёт ток по схемотехнике
замыкается
строка+столбец=кнопка.
KD2+A11=3
KD0+A11=1
KD0+KD2+A11=и 1 и 3 обе нажатые
Тут у нас 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 ; цикл
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
Дальше - хуже. По ссылке выше на LD/PUSH можно увидеть технику когда как бы инструкции создают буфер заливающий всю экранную область.
А ведь тут можно сделать похожим образом - тот буфер тайлов который олицетворяет собой экран (и который рисуется) выполнить как последовательность команд:
CALL TILE1_1: INC BC: CALL TILE1_2: INC BC ... ; 32 раза на строку CALL TILE2_1: INC BC: CALL TILE2_2: INC BC: ... ; следующая строка
Кстати, на современных FPGA/CPLD клонах, со статической памятью - ровно никаких проблем сделать линейный экран... правда, ценой потери всей библиотеки софта (но может иметь смысл для новодельных демосцен, например).
Разработчик 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 этого же разработчика.
=A=L=X=
Добавить бы к этой игре мультиколор и был бы ваще отвал башки.
gamedevfor
> Добавить бы к этой игре мультиколор и был бы ваще отвал башки.
Не, с таким мультколор не вывезти уже без существенных поднятий частот. :)
Вообще интересно сравнить с явным вдохновителем - игрой Savage 1988 года:
Лично я тут же вспомнил еще одну игру: Trantor
И что Trantor, что Savage конечно же просто взрывали мозг тем что непонятно куда бежать, что делать и как выживать.
Главная хрень - в том, что можно только как то по горизонтали и ограниченно стрелять полностью не контролируя всё что пролетает над тобой.
Прыгать чтобы сбить то что летит чуть ниже чем обычно - это прям....
Ну и сами лабиринты намного, очень намного, прямо лет на 30 опередили своё время: https://gamedev.ru/flame/forum/?id=183103
Тем не менее всё это мне очень нравится. :)
=A=L=X=
> Не, с таким мультколор не вывезти уже без существенных поднятий частот.
Может Zosya покажет нам мастер-класс, я в неё верю. )))
По поводу линейной адресации экрана в ZX Spectrum, во что бы это вылилось при выводе текста, например? По идее, если мы считаем адрес первой строки знакоместа по формуле
Аddr = Row*8*256 + Col*8
то адрес следующей строки в знакоместе вычисляется банальным инкрементом старшего байта адреса (а адрес первой линии, соответственно - сдвигом на 3 влево этого же старшего байта). Т.е., по идее, исправление перепутанной адресации никаких накладных расходов не должно давать.
0iStalker
> то адрес следующей строки в знакоместе вычисляется банальным инкрементом
> старшего байта адреса
Не понял.
В одной строке 256/8=32 байт каждый из которых соответствует полоске в 8 пикселей каждого знакоместа.
Следующая полоска пикселей текущего знакоместа таким образом находится на +32 байта дальше.
Это та же полоска пикселей знакоместа на 1 позицию ниже находится на расстоянии 32*8=256, т.е. на инкременте верхнего байта адреса.
А вот то как сделано сейчас как раз следующая полоска текущего знакоместа находится на инкременте верхнего байта адреса.
Так что вывод текста замедлился бы.
В "Специалисте" и "Орион-128" было сделано очевиднее - последовательная нумерация байтов шла по вертикали. Как раз вся вертикаль - 256 байт. Хочешь перейти к следующей полоске текущего знакоместа - просто инкрементируешь адрес. Хочешь перейти к следующему знакоместу (если делать 8х8) - инкрементируешь старший байт.
Правда в дефолтных биосовских процедурах вывода символа использовались знакоместа 6х8, так что мутили с масками и сдвигами, хотя такая организация видеопамяти все равно что-то упрощала.