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

[AzAtom]

Непонятно как маска в теневой плоскости возникнет в исходном месте где хранится спрайт, откуда он и переносится программно на экран.

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

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

Eltaron, современный планшет удовлетворяет этим требованиям.

[vlad]

Еще надо сделать линейную адресацию. Увеличение младшего байта адреса в экранной области должно переходить к байту снизу. Тогда проще добавлять фрагменты, которые появляются при скроллинге. Для начала заполни 16 К экранной области с адреса 0000 кодом 0. Тогда при сдвиге будет появляться пустота. Ну и ждем видео циклического плавного сдвига какой-нибудь картнинки.

[Lethargeek]

Так маску надо не накладывать, а просто записывать в ОЗУ. В этом-то и сюжет, - программное маскирование объектов на фоне заменяется аппаратным. Если маску выводить через регистр, не только отпадет необходимость коммутировать банки, но и можно быстрее двигать по фону вертикальные линии и прямоугольники, а также есть выирыш для окон, - чтобы открыть окно для сообщения, мы заносим в регистр маски FF и очищаем окно в плоскости объектов (плоскость фона не изменяется, но не видна). Получается, в 2.5 раза быстрее, чем писать маску как в обычное ОЗУ, переключая банки для каждого байта. Для вывода спрайта читаем два байта, первый байт сразу кидаем в регистр маски, а второй пишем в экран. Регистр маски экономит время, т.к отпадает переключение банок.

Эээ, минуточку. Нельзя вот так вот просто взять и записать маску. Потому что при наложении (причём даже не попиксельном, а поадресном) двух спрайтов "будит бида". Маска верхнего уничтожит маску нижнего спрайта, и он окажется уродливо обрезанным по прямой. А вот чтобы этого избежать, нужен либо хитрый контроллер записи (чуть ли не на уровне EGA, а не один какой-то жалкий регистр на запись) с режимами объединения и очистки; либо плоскость маски должна быть доступна по чтению, и работать с ней приходится как обычно; либо надо выделять буфер в памяти под операции с масками, и "просто записывать" из него, что совсем не упростит и не ускорит игровой код.

[barsik]

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

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

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

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

На мой малокомпетентный взгляд, всё остальное обсуждаемое в этой теме (ну может быть, за исключением прямого экрана 320*256), это переливание из пустого в порожнее.

Потому что настолько сложная мощная конструкция не нужна, да это и не сделать, по крайней мере быстро. Лучше сделать полноценный клон Spectrum-128 с возможностью борьбы с клешингом и дополнительным линейным экраном 320*256, чем клон ZX-48К с улучшенным цветом, аппаратными роликами и с навороченным и никем не используемым менеджером памяти.

[Lethargeek]

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

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

Еще раз: этот самый "оптимальный вариант с одной плоскостью" в таком виде НЕ ГОДИТСЯ для отображения спрайтов! То есть вообще, от слова совсем. И задник тут ни при чём.

[AzAtom]

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

[Advertiser]

[barsik]

этот самый "оптимальный вариант с одной плоскостью" в таком виде НЕ ГОДИТСЯ для отображения спрайтов! То есть вообще, от слова совсем. И задник тут ни при чём.

Объясните почему этот вариант не годится. Тем более "от слова совсем". Я считаю, что по сюжету многоплосковости это оптимально минимальная концепция, решающая проблему клешинга при сохранении родной организации экрана.

А насчёт "задника". Я ведь ничего и не говорил плохого о плоскости заднего плана, которая по определению (ради совместимости, т.к на ней прогоняются ZX-игры) должна остаться стандартным экраном ZX.

[Lethargeek]

Объясните почему этот вариант не годится.

-

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

[barsik]

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

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

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

Сначала покажите схему которая аппаратно реализует приоритеты масок для взаимного маскирования двух плоскостей. Любое решение имеет недостатки. 99% времени спрайты двигаются не закрывая друг друга. В ZX-играх пересечения спрайтов разве сильно вредят? А раз есть всё, что есть в ZX, то хуже уж точно не будет.

[Lethargeek]

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

но не сложнее же, чем в оригинале, должно быть это

Тут несколько вариантов. Во-первых нижний спрайт можно просто не выводить (как будто он закрыт передним не частично, а целиком).

во-первых, головную боль можно лечить гильотиной

Можно нижний спрайт временно вернуть на плоскость заднего фона, естественно с клешингом, пока верхний спрайт не пройдёт мимо. Т.е клешиг останется при пересечениях спрайтов.

шедеврально, то есть ради победы над клэшингом и упрощения программирования предлагается нагородить аппаратный огород, который клэшинга не побеждает, а программирование усложняет, аплодисменты!

Что только ради этого вводить третью (вторую переднюю) плоскость?

я вообще противник любых слоёв

Сначала покажите схему которая аппаратно реализует приоритеты масок для взаимного маскирования двух плоскостей.

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

Любое решение имеет недостатки.

не любое предложение есть решение

99% времени спрайты двигаются не закрывая друг друга.

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

в zx-играх спрайты обычно нецветные

А раз есть всё, что есть в ZX, то хуже уж точно не будет.

цель-то лучше сделать была заявлена