Вид для печати
а не проще было бы поставить отдельный видеопроцессор со своей видеопамятью, он сам графикой бы и занимался, а спектрум клавиатуру бы обрабатывал... :)
Сразу решается проблема с недостаточностью адресного пространства - в качестве видеопроцессора можно сразу 32-разрядный процессор использовать...
Я предлагал в качестве видеопроцессора - эмулятор на PC. А новые режимы - нужны для постепенного перехода от стандартной графики к улучшенной. Z80 тоже кое что может рисовать. Тому подтверждение огромное количество игр. Мне интереснее переделать старую игру или делать новую для компьютера типа ZX Spectrum, чем для PC или другого компьютера. Иначе я сидел бы на другом форуме.Цитата:
Сообщение от ZXMAK
Чтобы сделать линейную адресацию не нужен отдельный процессор. Достаточно переставить биты адреса в видеокарте при выводе на экран телевизора/монитора. То есть для этого достаточно мультиплексора: стандартная/линейная адресация экрана.
То, что Синклер сделал кривую адресацию - ему было виднее, возможно хотел сэкономить 1 килобайт ОЗУ или хотел, чтобы заставки к игре загружались красиво. Интересно было бы узнать, почему адресация именно такая? И зачем в каждом байте атрибутов вместо отдельной яркости на PAPER и INK добавили бит FLASH? Курсор не обязательно было делать аппаратно мигающим знакоместом. Это можно было бы сделать и программно. А вот в играх курсор особо и не нужен, а отдельная яркость пригодилась бы.
Линейная адресация с адреса 0000 упростила и ускорила бы вывод графики. Так давайте исправим эту ошибку хотя бы сейчас, пока еще кто-то помнит про ZX Spectrum. И будем писать игры для него, а не для других компьютеров. Да это и интереснее. Тут все просто и понятно, нет операционной системы, драйверов и т.п. усложнений.
Это как? Сейчас буковку выводим например так:Цитата:
Сообщение от zst
; 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
...
Так что-ли?
А вот это правильно...Цитата:
Сообщение от zst
---------- Post added at 07:50 ---------- Previous post was at 07:49 ----------
Линейная адресация будет хороша если байты будут не горизонтально а вертикально (столбиком) выводится.
Тогда INC L - это на пиксель влево, INC H - на строку вниз.
столбики привычные и горизонтальные.Цитата:
Сообщение от zst
столбики непривычные вертикальные.Цитата:
Сообщение от Destr
Нет, просто INC L и всё.Цитата:
Сообщение от Destr
То есть INC H заменяем на INC L.
И если в старом экране надо было вписаться в знакоместо, то теперь можно легко попиксельно двигать текст вверх вниз.
А речь вообщето даже не про вывод текста, а про вывод графики.
Да какая разница что выводить, на спеке текст=графике (текстового экрана нет, буквы - суть те-же спрайты 8х8).Цитата:
Сообщение от Reobne
Привыкнуть можно.Цитата:
Сообщение от Reobne
Зато очень хорошо для игр по типу Wolf (рэйкастинг).
Их было-бы сейчас столько-же, сколько всяких JET SET WILLY (ибо нынешняя архитектура экрана хорошо подходит для блочной графики, а вертикальные байты - для растра и вектора)
было бы удобнее вот так примерно:
тут координатой Y управляем через порт. данные соответственно для стандартного экрана( пикселя, 1 бит на точку). тогда и думать не нужно о расчётах следующей строки. просто указали нужную строку в порт и кидаем данные от 0 до сколько-там максимум по X. если прикрутить сюда линейный акселератор, то ещё и скорости добавится.Код: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
если ничего не напутал, тогда данные будут забивать 8 строк по 1 байту, при условии, что графика аля спектрум. при цветном выводе (цвет на точку) нужно добавить цикл. акселератор забивает видеопамять в разы быстрее проца. координатой Y рулить не требуется. после отработки акселя значение координаты Y будет увеличено на размер прокинутых данных акселем.Код: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
Программисту легче привыкнуть.Цитата:
Сообщение от Destr
Хакеру-патчеру сложнее. Много в коде надо переделывать, и данные переформировывать, чтобы обучить старую программу поддерживать новый режим.
Разработчику аппаратуры тоже чуть тяжелее привыкнуть.
Раньше то как было? Ползёт лучик электронный по строчке экрана телевизора, схема видеовывода считала из памяти 2 байта (растр и атрибуты) и целых 8 пикселей обеспечены. А если пытаться вертикальный байтик отобразить, то пришлось-бы промежуточный буфер делать, на 512 байт, либо с хитрым доступом, либо с ещё одним промежуточным буфером на 8 байт с хитрым доступом. Либо частоту повышать.
Сейчас-то да, частота высокая, что хочешь, то и делай. Но, всё таки, в сознании сидит старая схема. Так проще думать. Так проще объяснять другим.
---------- Post added at 12:26 ---------- Previous post was at 12:19 ----------
zst,
Каждому программисту и для каждой его текущей задачи удобно как-то по своему.Цитата:
Сообщение от Sayman
Мне кажется нужно подумать о переходе от концепции большого каталога фиксированных режимов к концепции произвольно конфигурируемой системы видеовывода.
это где медленно и не удобно? т.е. удобнее и быстрее на каждую треть экрана или каждые 8 строк делать пересчёты или тратить память под таблицу адресов? я вас умоляю, прочитал порт и получил текущую строку, кинул в порт и задал нужную строку. никаких расчётов и таблиц. экономия по памяти и по тактам. И как я написал - линейный акселератор ускорит процесс вывода (вброс байтов в экранную область/видеопамять). На Спринтере это прекрасно работает и быстрее, чем на любом 128м, профике или эве (может быть только конфа ТС будет равна или чуть быстрее местами).Цитата:
Мало того что не удобно но и медленно и не работает к тому же.
про шейдеры я предлагал. опять таки - блиттер+шейдеры будут интереснее, чем тайлодвиг предлагаемый ТС.Цитата:
Пути 3 - спрайты, блиттер или что то типо шейдеров.
потому, что спрайт повёрнут под вертикальный вывод. и вариант с табличками и третями экрана годен только для стокового 128го режима. тут же в этой теме речь идёт не про стоковый режим. если иметь цвет на точку (4бита или там 8 бит, не суть важно), то стоковыми методами ничего кроме тормоза не получишь. можно посмотреть на работу АТМ или профика с их режимами и как там всё "быстро" работает. т.е.е сли говорить не о 128м экране, а про что-то более новое и быстрое, то старые методы забудь. к примеру, спринтёр за фрейм кидает весь экран (а это, на минуточку, 82кб).Цитата:
становятся номером строки
ты ничего не понял)))
в примере я привёл вариант вертикального вывода. спрайт заранее развёрнут. инкремент адреса данных приводит к инкременту на следующий столбец, на первый байт этого столбца. да. там немного не точно, тем не менее - я беру первый байт столбца и акселем кинул в экран. делать +1 к координате Y не требуется, т.к. аксель это делает сам в этом режиме. кинули столбец, сделали адресу данных +1,сделали координате X +1, кинули второй столбец и т.д.
zst хочет сделать карту, которая с минимальными трудозатратами по разработке железа и переделке игр приведёт к обесклешиванию старых игр + новые режимы. я же говорю о том. что на обесклешивание нужно положить один большой инструмент и просто сделать нормальную карту, подключаемую к любому 128/атм/профи и спокойно ворочать там цветными спрайтами. и как вариант я предлагал или просто блиттер (а не тупой тайлодвиг) или шейдеры или аналог уже давно проверенной и работающей карточки аля спринтер. потому вот так и связаны такие темы как спринтер кидает пиксели и адреса данных и что ты там ещё не смог понять...
---------- Post added at 14:51 ---------- Previous post was at 14:45 ----------
опять таки - большая часть игр на спектруме имеет чб спрайты. таким образом минимальными затратами уже не обойтись. ГГ всегда будет просто белым, не принимающий цвет фона спрайт. т.е. желательно игру ещё и перекрасить, что уже само по себе геморно. ну а поскольку спрайты в игре придётся перерисовывать (добавлять цвета), то почему не делать тогда сразу нормальный аппаратный двиг (карту) которая может быстро это сделать, с которой не нужно сильно заморачиваться на всякие там протоколы, адреса и прочий не нужный хлам. можно взять в пример тот же зинапс. фон там чёрный, спрайт ГГ белый. особо клешинга в игре нет. но если добавить цветности и вообще цвет на точку, то ещё и эффектов наворотить можно - взрывчики всякие, звёзды, метеориты, отлетающие осколки от корабля при попадании в него всякой фигни. старыми костыльными методами расчёта трети жкрана и экранных адресов ничего путного не получится.