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

Цитата:

---

Сообщение от zst

Пока чтение для новых режимов не предусмострено, FLASH тоже.

---

Ну чтение, хрен с ним, нужно только для определения столкновений во время отрисовки, не велика поетря с учетом того, что такой способ не дает ответа на вопрос "с чем столкнулись". А что будет делать бит FLASH в 2-цветном режиме? Поднимать яркость PAPER'а? Кстати, в стандартном режиме (с выключенной фкнуциональностью совсем и в слое стандартного экрана) FLASH надо сделать обязательно, ибо придется что-то мудрить в играх, где FLASH используется. Не хотелось бы его делать программно.

Цитата:

---

Сообщение от Alex Rider

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

---

У меня всегда была таблица адресов по Y - 384 байта, никогда с этим не заморачивался :)

---------- Post added at 23:27 ---------- Previous post was at 23:23 ----------

Вот посмотри
http://zxaaa.untergrund.net/view_demo.php?id=4898
Я делал хер знает когда, только не ржите, графику не я рисовал :)
С адресацией Y никогда проблем не было :D

Цитата:

---

Сообщение от Nesser

Я одного не могу понять, если пытаться вкорячить это в старые игры переделывая им только часть вывода на экран то что измениться?

---

Вырастет скорость отрисовки. Исчезнет клешинг. Это уже немало.

Цитата:

---

Сообщение от Nesser

Кроме того почти во всех играх спрайты ЧЁРНО-БЕЛЫЕ, а атрибуты выставляются принудиловкой после вывода спрайтов, то есть самих цветов то и нет, если накладывать сверху цветовую маску в 2 бита так это увеличение объёма спрайта на 2 раза, был 1 бит ч/б стал 1 бит ч/б+2 бита цвета, то есть надо раздвигать код и скорее всего всё это не влезет в память и придётся делать драйвер страниц.

---

Возможно. Не обязательно переделывать все спрайты, возможно, пепекраска лишь некоторых спрайтов (особенно, статичных) сделает игру намного красивше. Если будут реализованы палитры, можно будет еще больше разнообразить игры в плане цветов (как в ULA+, например). Собственно, карта позволяет переделывать игру постепенно: сначала убрали клешинг и разогнали, потом переделали графику обрамления экрана, потом раскрасили ГГ... Частые релизы с небольшими изменениями подпитывают интерес к переделке и позволяют собрать больше мнений сообщества. Можно действительно допеределываться до того, что старого кода и не останется совсем :) Лишь бы людям было интересно.

Цитата:

---

Сообщение от Nesser

Да и получается что надо делать редактор спрайтов, выковыривать старые и дорабатывать их из 1 бита в 1+2 бита, то есть по сути заново сделать саму игру.

---

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

---------- Post added at 22:33 ---------- Previous post was at 22:30 ----------

Цитата:

---

Сообщение от Nesser

Вот посмотри

---

Неплохо :)

Цитата:

---

Сообщение от Nesser

У меня всегда была таблица адресов по Y - 384 байта, никогда с этим не заморачивался

---

Выход за пределы этой таблицы же тоже надо контроллировать, правильно? И inc hl на 31-м столбце тоже. Так что у zst как минимум не хуже, только таблица не нужна от слова "совсем"

О линейной адресации байтов на экране

Для новых режимов графики в дополнительных слоях 1-8 адресация байтов на экране линейная, экран располагается с адреса 0000 и занимает 8 KB.
Если в hl записан адрес байта, то для перехода к байту справа надо выполнить команду inc h, для перехода к байту снизу - inc l.

Преимущество линейной адресации:
Проще и быстрее вычислять адрес байта на экране.
Нет деления экрана на трети/секторы.
Для копирования/стирания тайлов/спрайтов можно использовать более эффективные комбинации команд Z80.
Можно выводить тайлы/спрайты/буквы с точностью до пиксела по-вертикали.
В дальнейшем можно будет увеличить разрешение экрана до 320х240 точек.

При линейной адресации экрана с адреса 0000:
Первый столбик байтов имеет адреса 0000, 0001, ... 00BF.
Второй столбик - 0100, 0101, ... 01BF.
Последний столбик - 1F00, 1F01, ... 1FBF.

Так это уже не линейная адресация а НЕлинейная :)
Линейная это когда номер пикселя совпадает с адресом, а тут получается 192*32 ?
А 320*240 это 240*40 ?
Я так и не понял а как вычислять смещение пикселя в байте? программно?

---------- Post added at 23:57 ---------- Previous post was at 23:55 ----------

Эээээ а как считывать байт? считается пзу ?

---------- Post added 07.09.2015 at 00:00 ---------- Previous post was 06.09.2015 at 23:57 ----------

И я не понял как это переделывать игру постепенно ? :)
Она или переделывается сразу и полностью или делается заново с модульным строением для добавления новых функций "видеорежима".

Цитата:

---

Сообщение от Nesser

Так это уже не линейная адресация а НЕлинейная

---

Никто и не спорит

Цитата:

---

Сообщение от Nesser

Я так и не понял а как вычислять смещение пикселя в байте? программно?

---

Да

Цитата:

---

Сообщение от Nesser

Эээээ а как считывать байт? считается пзу ?

---

Пока да. Надеюсь, потом уговорю zst читать что-то вразумительное из текущего слоя.

Цитата:

---

Сообщение от Nesser

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

---

Откуда инфа?
В чем я вижу плюс "Метеора" - в том, что игру можно переделывать именно постепенно. Потому что непеределанный код работает так же, как и раньше - пишет в стандартный слой, соответствющий видеорежиму Спектрума. Захотели отрисовать что-то по-другому, переделали кусочек, наслаждаемся результатом. Потренировались на статике, переделали передний слой, потом ГГ, потом врагов, в общем, как хочешь. Остальные реализованные видеорежимы требуют переделки всей отрисовки сразу. Ну, может быть, в TS-Conf из-за строчных прерываний можно оставить, к примеру, какую-то часть экрана срандартной и переделать, скажем, какую-нить приборную панель внизу.

А чё экран боком? :)

Для такой простой графики не много ли 2 проца по 4 МГц ? :)

Цитата:

---

Сообщение от MVV

Так это реально работающий проект на z80, а то что здесь намечтали уже работает?

---

А игры там можно модернизировать/писать ? Или это совсем со Спектрумом не связано ?

Цитата:

---

zst, у тебя на Specy2010 заработала тестовая конфигурация?

---

Я пока железом и кодированием не занимался. Только синхроимпульсы VGA на VERILOGе. Твои проекты слишком сложные и не подходят мне. Надо будет все видеорежимы писать с нуля. Сейчас я пока мечтаю, проектирую режимы, а кодированием займусь потом.

---------- Post added at 18:25 ---------- Previous post was at 18:10 ----------

Цитата:

---

Сообщение от Alex Rider

Предлагаю сделать палитру в 512 байт (коли 16 бит на цвет). Загружать по ldir в некую область ПЗУ, во время записи карта будет вычитвать палитру (желательно менять палитры динамически, чтобы можно было иметь разные палитры в разных локациях; желательно иметь возможность менять любой цвет в палитре, можно будет делать fade-in-эффекты).
Как адресовать палитры:
1 цвет - атрибут слоя задает номер цвета в палитре (0-255), номер палиты слоя не используется.
2 цвета - номер палитры слоя (старшие 4 бита) задают одну из 16 палитр, из которой выбираются цвета INK и PAPER (0-7), включенный бит BRIGHT означает, что к номеру цвета INK добавляется 8. После сброса номер палитры для такого режима - 0, а сама палитра инициализируется стандартными цветами Спектрума (16 одинаковых 16-цветных палитр). Кстати, бит Flash будет поддерживаться?
2 цвета + прозрачный - то же, что и 2 цвета, но цвет №0 - прозрачный (так же и для 3, 7 и 15 цветов).
3,4 цвета - каждая пара бит кодирует один из четырех цветов одной из 64 палитр, номер (смещение 1-го цвета) которой задают 6 старших бит номера палитры слоя.

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

---

512 байтов - это наверно для палитры VGA, для остальных на 2-4 бита по 256 отдельных палитр, расположить во внутреннем ОЗУ SDRAM.

На первом этапе в слоях будут использоваться номера цветов от 0 до 15, соответствующие стандартным цветам. Только вместо темного черного с номером 0 будет писаться в слой яркий черный с номером 8. Зачем нам два черных ? А номер 0 - будет для прозрачного цвета.

Как говорили в этой теме MVV и другие - надо сначала сделать что-то простое. Сразу то все не получится. Вот к этим номерам для каждого слоя потом можно добавить старшие 4 бита номера палитры для слоя. Тогда номера цветов при выводе в буфер экрана будут от 0 до 255.

Сменой номера палитры слоя и 15 цветов в этой палитре можно делать затемнение или использовать для этого палитру VGA.

А палитра VGA 255 -> 32768 будет общая для точек из буфера экрана. С другой стороны, 255 цветов на экране может не хватить в будущем. И надо об этом подумать сейчас. Может важнее затемнений возможность рисовать в каждом слое со своей палитрой 255 -> 32768.


Переменная attribute не очень подходит для разных режимов цвета. Наверно надо сделать несколько переменных для разных режимов:
1 цвет - color - номер цвета 0-15 (в дальнейшем до 255)
2 цвета - attr - атрибут как в стандартном режиме, только FLASH не используется
3-4 цвета - pl2bit - номер двухбитной палитры
7-8 цветов - pl3bit - номер трехбитной палитры
15-16 цветов - pl4bit - номер четырехбитной палитры

Надо подумать как сделать так, чтобы после сброса все палитры показывали стандартные цвета. Наверно палитры с номером 0 делать аппаратные со станlартными цветами, а палитры 1-255 уже в ОЗУ.

Окно размером 256 или 512 байтов во области ПЗУ можно выделить для загрузки палитр. Теперь надо выбрать, как указывать, какую палитру мы загружаем для каждого режима.

Цитата:

---

Сообщение от zst

А палитра VGA 255 -> 32768 будет общая для точек из буфера экрана. С другой стороны, 255 цветов на экране может не хватить в будущем. И надо об этом подумать сейчас. Может важнее затемнений возможность рисовать в каждом слое со своей палитрой 255 -> 32768.

---

Дык не проще сделать тупо по 16 бит на точку, а все перепаковки предварительно сделать программно?
Я боюсь всех этих палитр, смахивает на сжатый bmp, только тут его походу придётся пережимать в реальном времени на каждый пиксель :)