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

[ZXMAK]

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

[zx-kit]

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

Я предлагал в качестве видеопроцессора - эмулятор на PC. А новые режимы - нужны для постепенного перехода от стандартной графики к улучшенной. Z80 тоже кое что может рисовать. Тому подтверждение огромное количество игр. Мне интереснее переделать старую игру или делать новую для компьютера типа ZX Spectrum, чем для PC или другого компьютера. Иначе я сидел бы на другом форуме.

Чтобы сделать линейную адресацию не нужен отдельный процессор. Достаточно переставить биты адреса в видеокарте при выводе на экран телевизора/монитора. То есть для этого достаточно мультиплексора: стандартная/линейная адресация экрана.

То, что Синклер сделал кривую адресацию - ему было виднее, возможно хотел сэкономить 1 килобайт ОЗУ или хотел, чтобы заставки к игре загружались красиво. Интересно было бы узнать, почему адресация именно такая? И зачем в каждом байте атрибутов вместо отдельной яркости на PAPER и INK добавили бит FLASH? Курсор не обязательно было делать аппаратно мигающим знакоместом. Это можно было бы сделать и программно. А вот в играх курсор особо и не нужен, а отдельная яркость пригодилась бы.

Линейная адресация с адреса 0000 упростила и ускорила бы вывод графики. Так давайте исправим эту ошибку хотя бы сейчас, пока еще кто-то помнит про ZX Spectrum. И будем писать игры для него, а не для других компьютеров. Да это и интереснее. Тут все просто и понятно, нет операционной системы, драйверов и т.п. усложнений.

[Destr]

Линейная адресация с адреса 0000 упростила и ускорила бы вывод графики.

Это как? Сейчас буковку выводим например так:
; HL=адрес на экране, DE=адрес буквы
LD B,8 ; высота
LD A,(HL)
LD (DE),A
INC DE
INC H ; след. линия
DJNZ
...

А по-твоему будет как?

; HL=адрес на экране, DE=адрес буквы
LD B,8 ; высота
LD A,(HL)
LD (DE),A
INC DE

; след. линия
PUSH BC
LD BC,32
ADD HL,BC
POP BC
DJNZ
...

Так что-ли?

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

А вот это правильно...

---------- Post added at 07:50 ---------- Previous post was at 07:49 ----------

Линейная адресация будет хороша если байты будут не горизонтально а вертикально (столбиком) выводится.
Тогда INC L - это на пиксель влево, INC H - на строку вниз.

[Reobne]

переход к байту справа командой inc h, переход к байту снизу командой inc l.

столбики привычные и горизонтальные.

Тогда INC L - это на пиксель влево, INC H - на строку вниз

столбики непривычные вертикальные.

; след. линия
PUSH BC
LD BC,32
ADD HL,BC
POP BC
DJNZ

Так что-ли?
...

Нет, просто INC L и всё.
То есть INC H заменяем на INC L.
И если в старом экране надо было вписаться в знакоместо, то теперь можно легко попиксельно двигать текст вверх вниз.
А речь вообщето даже не про вывод текста, а про вывод графики.

[Destr]

А речь вообщето даже не про вывод текста, а про вывод графики.

Да какая разница что выводить, на спеке текст=графике (текстового экрана нет, буквы - суть те-же спрайты 8х8).

столбики непривычные вертикальные.

Привыкнуть можно.
Зато очень хорошо для игр по типу Wolf (рэйкастинг).
Их было-бы сейчас столько-же, сколько всяких JET SET WILLY (ибо нынешняя архитектура экрана хорошо подходит для блочной графики, а вертикальные байты - для растра и вектора)

[Sayman]

было бы удобнее вот так примерно:

port_y   equ 0x89

;в DE адрес = координата по X
;в HL адрес данных
        ld b,8
        in a,(port_y)
loop: ld a,(hl)
        ld (de),a
        inc hl
        inc a
        out (port_y),a
        djnz loop

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

port_y   equ 0x89

;в DE адрес = координата по X
;в HL адрес данных
;данные расположены не "горизонтально", а "вертикально" (спрайт заранее развёрнут на 90гр).
        ld d,d     ; включить Аксель
        ld a,8     ; задали размер данных (8 байт, т.е. строк)
        ld b,b
        ld a,a     ;вертикальный перенос
        ld a,(hl)
        ld (de),a
        ld b,b
        inc hl
        inc de

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

[Reobne]

Привыкнуть можно

Программисту легче привыкнуть.
Хакеру-патчеру сложнее. Много в коде надо переделывать, и данные переформировывать, чтобы обучить старую программу поддерживать новый режим.
Разработчику аппаратуры тоже чуть тяжелее привыкнуть.
Раньше то как было? Ползёт лучик электронный по строчке экрана телевизора, схема видеовывода считала из памяти 2 байта (растр и атрибуты) и целых 8 пикселей обеспечены. А если пытаться вертикальный байтик отобразить, то пришлось-бы промежуточный буфер делать, на 512 байт, либо с хитрым доступом, либо с ещё одним промежуточным буфером на 8 байт с хитрым доступом. Либо частоту повышать.
Сейчас-то да, частота высокая, что хочешь, то и делай. Но, всё таки, в сознании сидит старая схема. Так проще думать. Так проще объяснять другим.

---------- Post added at 12:26 ---------- Previous post was at 12:19 ----------

zst,

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

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

[Sayman]

Мало того что не удобно но и медленно и не работает к тому же.

это где медленно и не удобно? т.е. удобнее и быстрее на каждую треть экрана или каждые 8 строк делать пересчёты или тратить память под таблицу адресов? я вас умоляю, прочитал порт и получил текущую строку, кинул в порт и задал нужную строку. никаких расчётов и таблиц. экономия по памяти и по тактам. И как я написал - линейный акселератор ускорит процесс вывода (вброс байтов в экранную область/видеопамять). На Спринтере это прекрасно работает и быстрее, чем на любом 128м, профике или эве (может быть только конфа ТС будет равна или чуть быстрее местами).

Пути 3 - спрайты, блиттер или что то типо шейдеров.

про шейдеры я предлагал. опять таки - блиттер+шейдеры будут интереснее, чем тайлодвиг предлагаемый ТС.

[Sayman]

становятся номером строки

потому, что спрайт повёрнут под вертикальный вывод. и вариант с табличками и третями экрана годен только для стокового 128го режима. тут же в этой теме речь идёт не про стоковый режим. если иметь цвет на точку (4бита или там 8 бит, не суть важно), то стоковыми методами ничего кроме тормоза не получишь. можно посмотреть на работу АТМ или профика с их режимами и как там всё "быстро" работает. т.е.е сли говорить не о 128м экране, а про что-то более новое и быстрое, то старые методы забудь. к примеру, спринтёр за фрейм кидает весь экран (а это, на минуточку, 82кб).

[Sayman]

ты ничего не понял)))
в примере я привёл вариант вертикального вывода. спрайт заранее развёрнут. инкремент адреса данных приводит к инкременту на следующий столбец, на первый байт этого столбца. да. там немного не точно, тем не менее - я беру первый байт столбца и акселем кинул в экран. делать +1 к координате Y не требуется, т.к. аксель это делает сам в этом режиме. кинули столбец, сделали адресу данных +1,сделали координате X +1, кинули второй столбец и т.д.
zst хочет сделать карту, которая с минимальными трудозатратами по разработке железа и переделке игр приведёт к обесклешиванию старых игр + новые режимы. я же говорю о том. что на обесклешивание нужно положить один большой инструмент и просто сделать нормальную карту, подключаемую к любому 128/атм/профи и спокойно ворочать там цветными спрайтами. и как вариант я предлагал или просто блиттер (а не тупой тайлодвиг) или шейдеры или аналог уже давно проверенной и работающей карточки аля спринтер. потому вот так и связаны такие темы как спринтер кидает пиксели и адреса данных и что ты там ещё не смог понять...

---------- Post added at 14:51 ---------- Previous post was at 14:45 ----------

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