Быстрая видеокарта "METEOR-2013"

[zx-kit]

То есть будет неэффективно тратить свои ресурсы на убогие и ограниченные слои,

Слои не убогие, они позволят стирать и рисовать часть изображения при передвижении объектов на разных планах.

на различные схемы чтения и интерпретации содержимого видеобуфера в различных режимах

Особой обработки не надо. Кадр изображения с компьютера надо сохранить до вывода на монитор. Как изображение получается, какие порты использует, какой экран 128K отображается и так далее уже не важно. Есть готовые сигналы RBGI. Мы их берем и записываем в буфер VGA. При этом игра продолжает работать, а ГГ можно изобразить в верхнем слое без клешинга. Ты вроде раньше и писал про простоту доработки игр. Я это и предлагаю.

кстати, также на соответственные им режимы работы блиттера (если всё-таки захочется сделать блиттер).

. Давай забудем пока про блиттер. Первая ступень - устранение клешинга. Упростим задачу.

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

А то что я предлагаю сделать видеокарту выносной - это не облегчит перенос ее на другие компьютеры ?

Ну, и необходимость втыкать карту еще и в RGB-выход я бы не назвал упрощением

Это проще, чем дублировать формирование стандартного экрана в видеокарте. Сигналы то уже готовые.

А не слишком ли много программисту придётся знать с нынешним нагромождением слоёв и разных режимов? Вообще не пойму, зачем тебе понадобились слои, только цветность ограничивают зазря и усложняют пользование устройством. Можно обойтись прекрасно без них, одним-единственным примитивным растровым массивом, но зато максимальной глубины цвета и максимального размера (в рамках развёртки) и с гибкой схемой записи группы пикселей. Что позволит модернизировать игрушки НАМНОГО проще - так, в простейшем случае (но достаточном, чтобы полностью избавить игру от клэшинга!) программисту нужно знать ТОЛЬКО лишь как выбирать два активных цвета для рисования (неважно даже, на экране или в теневом буфере). Остальных настроек хватит дефолтных.

Для начала можно сделать один дополнительный слой. Там как раз будет массив из точек. А закрашиваться они будут внутри видеокарты в те два или три цвета, которые указаны в палитре рисования. При этом спрайты в игре останутся те же. А видеокарта из байта спрайта и байта маски сама нарисует в массиве новые 8 точек. По-моему идея простая и будет работать эффектно.

- - - Добавлено - - -

В любом случае, для "модернизации" старья, это же самое старьё придётся ещё и дизасмить, на что далеко не каждый согласится. А некоторые игры принципиально не получится зацветить, только если перерисоввывать всю графику. Так то всяких извратных решений хватает, тот же 16с или вон, ТС конфа или атм3 конфа. Не очень-то заметны тонны адаптированных игрушек под эти режимы.

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

- - - Добавлено - - -

В "железе" то есть эта "железяка"? Тема уже давно, теории много, но нет главного! " Желёзки".

Да, медленно. Каждый день думаю о железе, что-то делаю, прорабатываю режимы, улучшаю элементную базу, конструкцию, доказываю свою правоту на форуме.

- - - Добавлено - - -

Соглашусь, что код придется смотреть... часто то, что было в 48к скорее всего будет проблематично адаптировать. При работе с картой желательно минимизировать количество команд для обслуживания самой видео-карты и работы с ней… Поясню… Любая команда в памяти занимает место, и в некоторых старых играх места для новых команд управления графикой может быть НУ ОЧЕНЬ МАЛО или вообще не оказаться… Так что команды должны быть короткими. Иначе нам придется переписывать код для работы в 128к и более

Так для этого режимы и прорабатываются, чтобы можно было убрать лишние команды в игре и спрайты оставить те же, чтобы не делать лишнюю работу и не увеличивать объем программы.

При работе с новым слоем нам не нужны вычисления адреса на экране, чтение оттуда или из буфера, команды or, xor, and с байтом спрайта и маски, запись результата в буфер или на экрана. Нам надо для рисования спрайта главного героя (ГГ) один раз записать координаты в видеокарту и выбрать палитру. Затем читать в цикле байты спрайта и маски и записывать в видеокарту. Ну как - это же намного проще, чем до этого было ?

[Advertiser]

[Lethargeek]

Слои не убогие,

Убогие! Окно 256x192 c при 1-4 бита на пиксель - это убого!
Почему не 16 бит на пиксель в полном PAL-экране 360x288?
(или "круглые" 360x256, что ближе к VGAшному 360x240)

они позволят стирать и рисовать часть изображения.

ииии что? С ЛЮБОЙ структурой видеопамяти можно "стирать и рисовать часть изображения"

Особой обработки не надо. Кадр изображения с компьютера надо сохранить до вывода на монитор. Как изображение получается, какие порты использует, какие стриницы 128K или более уже не важно.

всего-навсего переключать синхронно две своих видеостраницы, куда мы рисуем вывод в страницы Спека

Есть готовые сигналы RBGI. Мы их берем и записываем в буфер VGA.

с готовыми глюками и наводками

При этом игра продолжает работать, а ГГ можно изобразить в верхнем слое без клешинга. Ты вроде раньше и писал про простоту доработки игр. Я это и предлагаю.

Ты предлагаешь НЕУДОБНО и НЕКРАСИВО. Я вот хочу просто рисовать ЛЮБЫМИ цветами, не заморачиваясь переключением слоёв и подбором палитровых цветов. Пусть даже тупо затирая фон - ну и что, Спек же успевал в оригинале фон восстанавливать - значит, и я успею так же в новом режиме, если восемь пикселей можно напечатать с такой же скоростью. Чтобы просто побороть клэшинг, быстрей не нужно (да и не дают слои заметного ускорения, потому что спрайты и в слоях приходится обнулять)

И не всё так просто, как тебе кажется. Часто игры сначала рисуют в буфер и фон, и спрайты, а потом всё копируют в экран, аккуратно избегая пересечений с лучом. Нельзя вот так просто взять и независимо несинхронно спрайты кинуть в отдельный слой, рискуя получить мерцание и обрезки. Такой буфер надо как одну цельную картинку формировать.

Давай забудем пока про блиттер. Первая ступень - устранение клешинга. Упростим задачу.

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

А то что я предлагаю сделать видеокарту выносной - это не облегчит перенос ее на другие компьютеры ?

Я вообще-то говорил об упрощении переноса СОФТА с одних компьютеров на другие (например, с Амстрада на Спек)

Это проще, чем дублировать формирование стандартного экрана в видеокарте. Сигналы то уже готовые.

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

Для начала можно сделать один дополнительный слой. Там как раз будет массив из точек. А закрашиваться они будут внутри видеокарты в те два или три цвета, которые указаны в палитре рисования. При этом спрайты в игре останутся те же. А видеокарта из байта спрайта и байта маски сама нарисует в массиве новые 8 точек. По-моему идея простая и будет работать эффектно.

Но ЗАЧЕМ? Зачем искусственно ограничивать? Почему не рисовать в единственном слое те же 8 точек, но в хайколоре?

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

Вот тут полностью согласен, только адреса оставить оригинальные, пусть их карта пересчитывает сама.

- - - Добавлено - - -

Так то всяких извратных решений хватает, тот же 16с или вон, ТС конфа или атм3 конфа. Не очень-то заметны тонны адаптированных игрушек под эти режимы.

так они и неудобны для адаптаций

[zx-kit]

Убогие! Окно 256x192 c при 1-4 бита на пиксель - это убого!
Почему не 16 бит на пиксель в полном PAL-экране 360x288?
И не всё так просто, как тебе кажется. Часто игры сначала рисуют в буфер и фон, и спрайты, а потом всё копируют в экран, аккуратно избегая пересечений с лучом. Нельзя вот так просто взять и независимо несинхронно спрайты кинуть в отдельный слой, рискуя получить мерцание и обрезки. Такой буфер надо как одну цельную картинку формировать.

Но ЗАЧЕМ? Зачем искусственно ограничивать? Почему не рисовать в единственном слое те же 8 точек, но в хайколоре?

Вот тут полностью согласен, только адреса оставить оригинальные, пусть их карта пересчитывает сама.

Хорошо, оптимизируем графику.
Поверх стандартного экрана дополнительный слой графики размером 256x192 точек по 16 бит на цвет точки. Старший бит - признак прозрачности точки.
Для рисования восьми точек надо записать в видеокарту два байта. На каждую точку получится по 2 бита на цвет - 4 цвета. Для указания цвета для каждой комбинации надо 8 регистров.

Регистры координат:
XL, XH, YL, YH

Регистры цвета:
COLOR_00_L, COLOR_00_H,
COLOR_01_L, COLOR_01_H,
COLOR_10_L, COLOR_10_H,
COLOR_11_L, COLOR_11_H,

Регистры спрайта:
SPRITE_BYTE,
MASK_BYTE

[Sayman]

zst, хоть убей, не понимаю, каким образом карточка прикрученная к RGB выходу будет выгребать отдельно спрайт ГГ и отдельно весь остальной уровень игрушки?!

Регистры координат:
XL, XH, YL, YH

при разрешении 256*192 достаточно одного 16битного регистра (или двух по 8), т.к. максимальные координаты по XY не выходят за пределы 8 бит.

так они и неудобны для адаптаций

а почему? что там такого неудобного? как для тебя (или по твоему мнению) было бы удобнее для адаптации старых игр? Было бы, конечно, интересно увидеть цветного, скажем, exolon`а. Есть его ПЦшный ремейк - exolon dx, но это для пц, а значит уже немного не то. Были бы цветные спрайты в доступе для него, уже бы под спринтера переложил его.
Мне кажется, что самое простое управление графикой как раз у спринтера. Но возможно мне это только кажется. Не требуется вообще никаких расчётов координат на экране в адрес (кроме разве что x_coord+screen_start_adr). За координату Y работает порт. Экран в любоей окно проца втыкается. Для программиста, как я думаю, проще уже некуда. АТМ и профи (и судя по мануалам и ТС конфа) по строению экрана выглядят просто монстрами какими-то. Даже 128й экран)))

[zx-kit]

И не всё так просто, как тебе кажется. Часто игры сначала рисуют в буфер и фон, и спрайты, а потом всё копируют в экран, аккуратно избегая пересечений с лучом. Нельзя вот так просто взять и независимо несинхронно спрайты кинуть в отдельный слой, рискуя получить мерцание и обрезки. Такой буфер надо как одну цельную картинку формировать.

Вот в таком случае и приходит на помощь еще один слой. Сначала отображается первый слой, а во втором рисуется ГГ. По INT первый слой выключается, а второй включается.

zst, хоть убей, не понимаю, каким образом карточка прикрученная к RGB выходу будет выгребать отдельно спрайт ГГ и отдельно весь остальной уровень игрушки?!

Кроме RBGI мы подаем с компьютера еще 8 битов данных и 2 сигнала записи. Стандартная графика просто загружается для дальнейшего отображения на VGA. В основном это фон и второстепенные персонажи. ГГ рисуется в новой графике.

при разрешении 256*192 достаточно одного 16битного регистра (или двух по 8), т.к. максимальные координаты по XY не выходят за пределы 8 бит.

Я просто подумал о будущем. Вдруг захочется рисовать на всем экране 1920x1080 или части размером 320x240.

[Lethargeek]

Хорошо, оптимизируем графику.
Поверх стандартного экрана дополнительный слой графики размером 256x192 точек по 16 бит на цвет точки. Старший бит - признак прозрачности точки.

Да не нужен никакой "стандартный" экран! RGB может быть испорчен, нестандартно сдвинут по тактам, или вообще не предусматриваться в компе (например, в новом клоне, задуманном как раз для работы только с внешней видеокартой). И опять мелкое окошко в центре экрана! Не, надо в полном цвете рисовать по всему экрану телевизора/монитора, а растр Спектрума при желании отображать на нём с любым смещением.

Для рисования восьми точек надо записать в видеокарту два байта. На каждую точку получится по 2 бита на цвет - 4 цвета. Для указания цвета для каждой комбинации надо 8 регистров.

Ничего не понял, почему опять "2 бита - 4 цвета", если выше пишешь про хайколорный слой.

Давай так. Чтоб понятней было, я сперва опишу схему совместимости с экраном без атрибутов. То есть монохром 256x192 (типа Спек без атрибутов) или быкашные постоянные 4 цвета в режиме 256x256 итд; и чтоб картинка с карты после резета ничем не отличалась от картинки через стандартный выход, хотя пиксели на самом деле там хайколорные.

Итак, видеобуфер карты - простой массив (например, размером 360x256); один пиксель - одно 16-битное слово. Для отображения читается в жёстком цикле. Никаких других режимов, слоёв, палитр. Тут всё максимально просто, как только можно.

Конкретная физическая раскладка памяти видеокарты нам не важна. Мы рисуем на виртуальном логическом экране, а не по физическим адресам. У видеокарты есть блок-транслятор, который пересчитывает адрес каждой группы из 8 (или 4 в случае двухбитного цвета) пикселей в логической раскладке (которая может совпадать со стандартным видеобуфером компа, а может и не совпадать, это совершенно неважно, имитировать мы сможем любой экран) в физический адрес 16-битного пикселя, геометрическое раположение которого на экране совпадает с расположением левого края этой группы (с учетом сдвига виртуального экрана, как нам захочется).

Соответственно, при записи байта в адреса виртуального экрана изменяются несколько (до 8 для монохрома) хайколорных пикселей физического. Изменяются в соответствии с заданной "активной палитрой" (прошу не путать с физической палитрой, это скорей таблица для распаковки) из 2 (или 4 итд) "активных цветов". Причём один из них можно задавать и "прозрачным" (да хоть все, только смысла в этом особо нет), чтобы не менять физический пиксель.

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

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

[zx-kit]

Ничего не понял, почему опять "2 бита - 4 цвета", если выше пишешь про хайколорный слой.

В игре, которую мы дорабатываем для устранения клешинга, есть спрайты с маской.
Для рисования 8 точек используется 2 байта. Это 8 * 2 = 16 битов.
На одну точку приходится 16 / 8 = 2 бита.
2 бита дают 4 комбинации: 00, 01, 10, 11.
Каждой комбинации ставим в соответствие 16-битный цвет.
0, 1 или 2 цвета из четырех можно выбрать прозрачными. Это дает разные способы закрашивания.
Этими активными цветами закрашиваются 8 текущих точек в слое с 16-ти битными цветам.
Два из четырех цветов выбираем прозрачными.
Они устраняют клешинг.
Теперь понял ?

Соответственно, при записи байта в адреса виртуального экрана изменяются несколько (до 8 для монохрома) хайколорных пикселей физического. Изменяются в соответствии с заданной "активной палитрой" (прошу не путать с физической палитрой, это скорей таблица для распаковки) из 2 (или 4 итд) "активных цветов". Причём один из них можно задавать и "прозрачным" (да хоть все, только смысла в этом особо нет), чтобы не менять физический пиксель.

Можно эти цвета назвать палитрой для рисования.

- - - Добавлено - - -

Да не нужен никакой "стандартный" экран! RGB может быть испорчен, нестандартно сдвинут по тактам, или вообще не предусматриваться в компе (например, в новом клоне, задуманном как раз для работы только с внешней видеокартой). И опять мелкое окошко в центре экрана! Не, надо в полном цвете рисовать по всему экрану телевизора/монитора, а растр Спектрума при желании отображать на нём с любым смещением.

Разрешение монитора 1920*1080. Если масштаб х4, то будем рисовать на экране размером 480х270 точек ? А как рисовать ГГ поверх старого экрана, если у них координаты начала не совпадут ?

- - - Добавлено - - -

Но хотя бы это сейчас понятно?

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

[s_kosorev]

А как рисовать ГГ поверх старого экрана, если у них координаты начала не совпадут ?

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

[perestoronin]

Эх, кто бы присоединил к Z80 вместо графики графический модуль на базе самого недорогого но достаточно мощного процессора ARM ценою рублей в 200 при заказе в мелком пакете из Китая.

[s_kosorev]

ARM за 200р видео на тв/монитор выводить не умеет