Идеальный Спектрум

[AzAtom]

В ZX-играх пересечения спрайтов разве сильно вредят?

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

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

Кое что придумал. Для следующего кадра маску же всё равно очищать надо. Ввести режим записи в банк маски, чтобы записывались только установленные биты. Тогда в обычном режиме очищается маска, затем, в режиме установки битов копируются спрайты и их маски не гасят установленные биты других спрайтов. Технически можно реализовать, запрещая сигнал write там, где бит маски равен 0. Тогда, нижний спрайт тоже будет виден, если их правильно объединить на слое спрайтов.

[barsik]

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

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

Перед тем, как сделать окончательный вывод, что клешинг при совмещении спрайтов делает абсолютно несостоятельной всю идею с вынесением спрайтов в плоскость отделённую от фона, стОит проверить идею на эмуляторе и только тогда делать вывод.

Проблема тут из-за ZX-цвета. Значит решение проблемы это изменение цвета плоскости спрайтов на попиксельный. Лучше всего на 4-х цветный, по принципу ОРИОНА (две плоскости, для каждого пикселя берём по биту из каждой плоскости). Это лучше, чем CGA, т.к позволит не менять графику. Добавив 2 бита из нечитаемой процессором теневой плоскости синхронно записываемой из двухбитного регистра палитры, получаем 4 палитры на каждый экранный байт. Это даёт 16 цветов на пиксель.

[Shiny]

блиттер нужен. Сравните с возможностями win32 BitBlt

[barsik]

блиттер нужен. Сравните с возможностями win32 BitBlt

В этой теме решают проблему клешинга, а не проблему скорости вывода на экран. А проблема скорости проще решается за счёт высокого такта процессора.

[bigral]

framebuffer очень дорогое дело для компа начала 80-х. Все разработчики пытались его уменьшить до минимума. Оно и понятно почему, потому что это снижает требования к частотам и ширине шин. Частоты можно считать ограниченными на уровне 14mhz в нашем случае. Каждые новые 8bit шины это еще 2 линейки РУ6 и пачка из 2? 4? 8? корпусов мультиплексоров. Так что "по большому счету" идея плоскостей (дополнительных framebuffer-ов) мне кажется изначально ущербной. Мы уже ее обсудили в теме про устранение клешинга как вариант "терпимой избыточности для легкой переделки игр", и по видимому концепция никому не понравилась изза того что игры будут такие же тормозные как и сейчас и даже более того.

Смотрим на классических победителей 8-bit - NES, C64, MSX2+, AMSTRAD CPC PLUS... (ну там в своем роде ПК8002). ВОТ ЭТО УРОВЕНЬ! Все что ниже него легко побеждается просто турбированным до 14mhz zx-128-ым.

[AzAtom]

Смотрим на классических победителей 8-bit

Ну так собственно, варианта 2: Либо аппаратные спрайты, либо накинуть памяти для дополнительных плоскостей. В обоих случаях корпусов прибавится сильно. Но спрайты можно реализовать в одной БИСине, что и было успешно сделано в том же NES, от чего он получил довольно приличную графику без тормозов и взлетел.

Третий вариант тоже можно рассмотреть: накинуть памяти для реализации независимых цветов для каждого пикселя, например, по 4 бита, это 24 КБ на экран. Ещё накинуть памяти для исходных спрайтов и ко всему этому добавить аппаратный блитер. Тогда и основная память в 48 КБ хватит практически для всех игр, ведь, кода и промежуточных переменных всегда гораздо меньше, чем графики.

[Lethargeek]

framebuffer очень дорогое дело для компа начала 80-х. Все разработчики пытались его уменьшить до минимума. Оно и понятно почему, потому что это снижает требования к частотам и ширине шин.

Всё к цене сводилось в конечном счёте (включая и косвенные расходы)

Частоты можно считать ограниченными на уровне 14mhz в нашем случае. Каждые новые 8bit шины это еще 2 линейки РУ6 и пачка из 2? 4? 8? корпусов мультиплексоров. Так что "по большому счету" идея плоскостей (дополнительных framebuffer-ов) мне кажется изначально ущербной.

А мне изначально ущербной кажется идея сейчас делать "удобный комп" на элементной базе 80-х

Мы уже ее обсудили в теме про устранение клешинга как вариант "терпимой избыточности для легкой переделки игр", и по видимому концепция никому не понравилась изза того что игры будут такие же тормозные как и сейчас и даже более того.

Самое реальное и дешёвое на уровне 80-х - познакоместный low-res 4x8 с выбором из 16 4-цветных палитр при ink=paper. Тут одной юлы, конечно, не хватит, но всё равно дешевле навороченного чипсета, а буфер, скорость и частоты не изменяются. В играх визуально похоже было бы на plus/4.

Смотрим на классических победителей 8-bit - NES, C64, MSX2+, AMSTRAD CPC PLUS... (ну там в своем роде ПК8002). ВОТ ЭТО УРОВЕНЬ! Все что ниже него легко побеждается просто турбированным до 14mhz zx-128-ым.

NES - консоль, там затраты "вынесены наружу", да и графика не такая уж и хорошая; а комод еще примитивнее. У MSX2 видеобуфер весьма нехилый, да и у амстрада с комодом приличные, притом далеко не на 14мгц.

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

В этой теме решают проблему клешинга, а не проблему скорости вывода на экран.

по заглавному - "упрощения игрописательства" вообще-то

[vlad]

Один экран вместо теневого и отображаемого.

Сделал две стандартные переключаемые экранные области 256х192 и добавил задний фон 256х192.

Нет скроллинга фона.

Добавил вертикальный скроллинг заднего фона.

Клешинг атрибутов при рисовании спрайтов.

Добавил режим 256с.

Планирую добавить простые спрайты 16х16 и можно будет попробовать сделать демку Xenon 2000.

[AzAtom]

А мне изначально ущербной кажется идея сейчас делать "удобный комп" на элементной базе 80-х

А с другой стороны, брать МК, который гораздо более мощный, чем 5 спектрумов вместе, и на нём делать какую-то примочку для спектрума это тоже как-то не здорОво.
Если же делать простой современный комп на современной элементной базе, то лучше сразу взять готовую малину, там и экран нормальный и куча контроллеров встроена, и не парить себе мозги.

Хотя, я приветствую программируемые плисины.

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

Если делать на более-менее современной элементной базе, то надо сразу делать 256 цветов с палитрой (или вообще 15 битный цвет) с разрешением 256х192 или 320х200 или 320х240, к этому добру аппаратный блитер, а если он ещё будет с масштабированием, то будет вообще супер. Ну или без масштабирования, а хотя бы с отражением по вертикали/горизонтали. Ну и памяти для спрайтов пару мегов, тогда будет на что посмотреть.

И никаких атрибутов и клешинга - программисты с ними достаточно помучились... А любители др... смотреть на клешинг атрибутов могут остаться на оригинальном спектруме.

[Totem]

А с другой стороны, брать МК, который гораздо более мощный, чем 5 спектрумов вместе, и на нём делать какую-то примочку для спектрума это тоже как-то не здорОво.
Если же делать простой современный комп на современной элементной базе, то лучше сразу взять готовую малину, там и экран нормальный и куча контроллеров встроена, и не парить себе мозги.

Хотя, я приветствую программируемые плисины.

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

Если делать на более-менее современной элементной базе, то надо сразу делать 256 цветов с палитрой (или вообще 15 битный цвет) с разрешением 256х192 или 320х200 или 320х240, к этому добру аппаратный блитер, а если он ещё будет с масштабированием, то будет вообще супер. Ну или без масштабирования, а хотя бы с отражением по вертикали/горизонтали. Ну и памяти для спрайтов пару мегов, тогда будет на что посмотреть.

И никаких атрибутов и клешинга - программисты с ними достаточно помучились... А любители др... смотреть на клешинг атрибутов могут остаться на оригинальном спектруме.

У вас вон сверху пилят аж 2х процах и в соседней ветке тоже, странно такие вещи писать.