Я всё-таки не пониамю (вот так пусть и остаётся - не пониамю), почему все придумывая новые концепции видеоотображения оставляют плоский экран? Ну, отбросив нехватку памяти (2 М - уже как бы и не проблема подключить), остаётся ещё ведь и скорость. Даже на турбе заполнить весь экран 16с за кадр не получается, минимум за 2.
Давайте подумаем что можно было бы всё-таки сделать, если отбросить пробему совместимости (нет такой проблемы, потому что переделывать всё равно придётся оченно глЫбоко, и это практически то же, что написать заново - тогда о чём говорить). И отбросить узость и плокость мышления.
Вот такой вариант. Читаем внимательно. Картинка состоЯИт из 2х планов - переднего и заднего. Задний - это прежний спековский экран, с его клэшингом и атрибутом на знакоместо. Только 2 маленьких усовершенствования: 1) палитра берётся из таблицы палитр, и для каждой из 192 строк может быть выбрана своя собственая таблица палитр. Флэшем можно спокойно пожертвовать, и превратить в отдельный бит "яркости" для заднего плана. 2) Всю эту картинку можно скролльнуть влево-вправо и вверх-вниз, оставив её там, где она есть, просто указав в регистре порта пиксель (не байт из 8 пикселей, а именно пиксель), с которого начинается экран. И если кто-то думКает, что это пригодится только для создания крутых эффектовОВ в дЭмах, то это - зря. Такой режим, когда каждая плоскость независимо аппаратно скроллится куда угодно, чрезвычайно интересен для гейм-мэйкинга.
А теперь самое интересное - это спрайты. Кто сказал, что они обязаны быть квадратными (или прямоугольными?). Нет, не так. КТО СКАЗАЛ, ЧТО ОНИ ОБЯЗАНЫ БЫТЬ КВАДРАТНЫМИ? Вот, так будет видно. Спрайтом у нас будет последовательность 4-битных пикселей, по 2 на байт. Формат атрибутов может быть такой же, цвет берётся из палитры по номеру, для каждого участка спрайта палитра задаётся отдельно (т.е. если в совокупности спрайт - это несколько цветных линий, то каждая линия может быть раскрашена своей палитрой, из того же общего набора палитр по 16 цветов на палитру). Спрайты размещаются в памяти где угодно. Если у нас есть круглый колобок, то мы можем поместить все его линии впритык друг к другу, и это займёт места меньше, чем квадрат (для которого ещё нужен и "прозрачный" цвет, или маска прозрачности). Задавать "видеопроцессору" что рисовать, мы будем таблицей разметки. Вид таблицы очень простой: несколько полей на каждый участок, который есть линия из нужного спрайта, плюс длина прозрачного участка, в котором спрайтов нет. Проблемы наложения спрайтов друг на друга тоже нет, т.к. в таблице разметки задаётся, сколько конкретно пикселей брать, и с какого (чётного или нечётного пикселя в байте) начинать брать. Сколько спрайтов рисовать одновремено (на экране, в строке, ...), решает программер. Ограничения физические есть, но они компенсируются и ограничены размером внутреннего буфера видеопроцессора. Рисование экрана (точнее перерисовка) сводится к построению новой таблицы разметки, что наверняка будет быстрее, чем все пиксели самому на экран перебрасывать любыми изощрёнными приёмами. Чтобы, пока строится новая таблица, можно было отображать прежнюю, да или просто быстро переключаться между уже несколькими заранее построенными - не нужно никакое ограничение на количество "экранов", то бишь этих самых таблиц разметки. Т.е. где-то надо указать, где начинается таблица, и всё переключение экранов на этом и заканчивается.
Ну, и напоследок, как вариант, формат элемента таблицы (набросок):
- 2 байта - длина в пикселях пустого пространства, то бишь заднего плана (младшие 10 бит, например) + номер палитры в таблице палитр (старшие 6 бит) для описанного далее кусочка спрайта,
- 2 байта адрес в памяти, где лежит первый пиксель очередного спрайта в памяти,
- 1 байт - длина пиксельной строки 0..63, старший бит устанавливается, если начинать отображать строку с нечётного пикселя в этом "спрайте", бит 6 - если пиксели брать в обратном порядке ("аппаратный" горизонтальный флиппинг).
Итого - 5 байт на фрагмент спрайта + пустого пространства перед ним.
Для того, чтобы спрайты можно было разместить в памяти в настоящий момент не впечатаных страницах, девайсу в отдельной четвёрке регистров можно было бы задавать свой собственый набор страниц для адресов, примерно как в самом 128 спеке сделано, но для каждой страницы 16К - отдельно. Соответственно, одновременно получаем доступ к 64К для спрайтов, одновременно присутствующих на экране - более чем предостаточно.
Ну и как? Почему нельзя было такую элементарщину реализовать ещё в 95 году? Плоское мышление и гигантизм, стремление за какой-то гипотетической совместимостью.
(Да, я понимаю, берём V9990 или сколько там девяток, сопрягаем, и всё работает, коли руки не кривы. Осталось найти достаточное количество дешёвых V9990, выполнить дешёвую плату сопряжения, и дальше пытаться что-то под неё запрограммировать. Сразу же обнаружится, что программить некому, и нечего, и это опять монстростроение (в том смысле, что девайс к спеку оказывается дороже его самого). Вообще, мне интересно, что железячный народ скажет в плане реализуемости описанного мною выше сюжета. (Ну на своём новом эмуляторе, я бы взялся его проэмулировать, жаль, паяльник мне не друг - в самом широком смысле, в том числе в плане проектирования ПЛМ )