Я хотел бы использовать стандартное разрешение 256х192, чтобы прежний спековский экран (с учётом сдвига по х,у) можно было использовать как задний план. Что касается цветов на точку, то их получается столько, сколько хочется, было бы место, где разместить достаточное число палитр. Номер палитры может быть расширен до байта, но независимо от того, лежат палитры в общей памяти, или предварительно загружаются в собственную память "процессора спрайтов", занимают они довольно прилично (например, если это RGBA8, т.е. 32 бит на цвет). Меня в чисто спрайтовом движке смущает только ограничение на число спрайтов по горизонтали. Оно можно подумать над таким вариантом, когда таблица задаёт не размещение спрайтов по строкам, а просто задаются местоположения спрайтов, дальше их размещением занимается процессор, а будет это блиттер или схема, строящая изображение на лету - уже не суть важно. Но в случае схемы слишком много одновременно спрайтов задать не получится, у схемы должно быть физическое ограничение хотя бы на количество одновременно считающих счётчиков, а ещё компараторов до кучи... В случае блиттера ограничение как бы снимается, можно построить изображение по такой таблице...Сообщение от Valen
Это я не понимаю. Блиттер, получается, делает гладкое изображение, а спрайтовый движок - нет? Чушь какая-то, тем более что спрайтовый движок принципиально ничем от блиттера не отличается, кроме того, что в случае блиттера изображение строится в буфере, а потом кидается на экран, а в спрайтовом режиме - изображение сразу отправляется на экран, минуя буфер.
И сколько пикселей у верхней кромки эллипса будет в разрешении 256х192? Думаю, 16 максимум. Как раз столько, чтобы можно было выделить особую палитру под верхнюю кромку. А с учётом симметрии эллипса, и до 32 дотянет. Это если действительно требуется уникальное значение на каждый пиксель (половины эллипса, вторая половина симметрична). Но это тоже не очень умно: по мне, можно использовать одинаковый "цвет" с альфой и на 2-3 подряд пикселя.
Что имеется в виду под перегружать? Все палитры или берутся из страницы видеопамяти, или заранее загружаются в собственную видеопамять видеоустройства. Даже если их 256 штук, по 16 цветов х 4 байта.
Я не схемотехник.
Но почему 8 строк надо читать за 224 такта? По мне так достаточно читать те "пиксели", которые в данной точке подлежат отображению. В большинстве случаев это будет 0,5 (ноль целых пять десятых) байта на точку, итого 128 байт пикселей. Плюс 32 байта на чтение описателя спрайтов, если их 8 в строке, плюс по одному байту на чтение длины спрайтной строки, для присутствующих спрайтов (т.е. от 0 до 8 байтов). Если учесть наложения полупрозрачных пикселей, то ограничив их максимум 3 слоями, получим 1,5 байта на точку. Неужели <500 байт не потянет? Что-то не верится. Я потому и говорю, что вы чего-то недопоняли: мой набросок показывает, что общие требования на физические параметры даже меньше, чем требования на режим 16с, о котором здесь все слышали.
И почему надо читать 2 бакграунда? Задний план в моём варианте - это стандартный спековский видеорежим с одновременным скроллом всех точек и атрибутов с точностью до пикселя. Итого 64 байта на строчку для него.
Я хочу реализовать настолько простую "машинку" для спрайтов, чтобы её можно было чрезвычайно легко повторить, в другом эмуляторе, или в железе, мысля под железом не конкретно то железо, которое использовалось для спектрума традиционно, но и всякие эмуляторы спектрума на фпга. Может, и появятся желающие попробовать что-нибудь запрограммировать, хотя бы сначала на эмуляторе. Но я - почти полный ноль в схемотехнике, и поэтому мне совершенно неизвестны ограничения, которые могут возникнуть при реализации совсем простого, на взгляд программера, устройства, в том же фпга. Мне очень не хочется останавливаться на 8 спрайтах в ширину, но судя по описанию v9990, там это ограничение ещё жёстче - 6 штук на строку. Я бы очень хотел вообще не ограничиваться в числе спрайтов на строку, предпочитая общее ограничение на число спрайтов или пикселей. Это даёт блиттер, но мне он кажется слишком громоздким из-за промежуточной памяти для буфера изображения. Если включать в машинку масштабирование или повороты, т.е. делать полноценный 2Д, то это уже потянет на громоздкую реализацию, а это сложности с отладкой-доводкой, и этого мне тоже не хочется. В общем, я ещё подумаю над своим видеорежимом, пока довожу чужой до ума.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
Проблема надумана, поскольку легко решается в рамках любого графического движка простым удвоением разрешения по горизонтали за счет цветности (в простейшем варианте это "кулибинский" режим 512x192) - и поддержу знакогенератора городить незачем.
