Зачем всё делать плоским? (Опять о спрайтах)

[Lethargeek]

если отбросить пробему совместимости (нет такой проблемы, потому что переделывать всё равно придётся оченно глЫбоко, и это практически то же, что написать заново - тогда о чём говорить). И отбросить узость и плокость мышления.

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

Как раз в 95 "о совместимости" походу никто не задумывался. Все ваяли "рабочие коммерческие" режимы, кое-кто дендюк спрайтовый прикручивал. И где тонны "глЫбоких переделок" под эти новации?

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

Узость мЫшления. Для гейм-мейкинга со времен NeoGeo "чрезвычайно интересно аппаратно скроллировать" независимые объекты, а не плоскости целиком.

КТО СКАЗАЛ, ЧТО ОНИ ОБЯЗАНЫ БЫТЬ КВАДРАТНЫМИ?

Узость мЫшления. Кто сказал, что они обязаны БЫТЬ?

(т.е. если в совокупности спрайт - это несколько цветных линий, то каждая линия может быть раскрашена своей палитрой, из того же общего набора палитр по 16 цветов на палитру).

Что с точки зрения железа (в сочетании с требованием "неквадратности") означает не "N линий одного спрайта", а "N фактически разных спрайтов". А это уже две БОЛЬШИЕ разницы.

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

Не стоит так извращаться из-за одного только частного случая. Идеальный общий вариант - упакованная графика на входе и выходе, и узел-перепаковщик между ними (можно обойтись и попроще - упаковка хотя бы только источника), что позволит значительно разгрузить самый узкий канал - шину данных видеопамяти. Да и графики больше влезет.

Рисование экрана (точнее перерисовка) сводится к построению новой таблицы разметки, что наверняка будет быстрее, чем все пиксели самому на экран перебрасывать любыми изощрёнными приёмами.

Самому-то зачем? (Кстати зачем вообще общая память для графики и Z80?) Да и список заданий на тупое копирование объектов ничем (кроме большей простоты для програмера) от упомянутой таблицы не отличается.

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

Ну вообще-то совсем уже не "предел", поскольку ПЛИСы все толстеют и дешевеют (причем слабые модели снимаются с производства). А про идеальный двухмерный движок я выше писал. Совместимость в такую схему можно по-разному прикрутить, и цена ее поддержки ничтожная по сравнению с основным движком.

[Advertiser]

[bigral]

Как раз в 95 "о совместимости" походу никто не задумывался. Все ваяли "рабочие коммерческие" режимы, кое-кто дендюк спрайтовый прикручивал. И где тонны "глЫбоких переделок" под эти новации?

По этому поводу вот какие мысли: Ну допустим возникла бы у кого-то потребность перевести тот же Flying Shark под этот NES видеоадаптер в каком-то виде пускай не 1:1 а скажем со своим редактором спрайтов и backgroud-a. Что бы он делал? А просто нашел бы где там лежит графика и где процедура обновляющая экран и рисующая на нем все спрайты после каждого INT-a, потом графику конвертнул бы в NES формат а процедуру вывода background-a и спрайтов переписал бы для NES-a. Скажем так если бы этим занялся бы гуру типа AloneCoder-a то закончил бы за день. Какие бы возникли проблемы? - никаких так как NES выводит background и спрайты из своей паралельной памяти а Speccy бы просто освободился от кучи кода (ломать не строить).

В чем же была причина поражения - я думаю в железе...
1. Тяжело скрестить 2 экрана, один в виде RGBI SYNC а другой в PAL, да еще так чтоб схема к любому спекки подошла; (Эта проблема есть и сейчас и решена она наверное НЕ БУДЕТ так как сложная и никому не интересная).
2. Возможно первая версия подключения NES-a имела ряд проблем например мало памяти и низкая скорость обмена с ZX-ом кроме того на практике это выглядело как спекки с TRDOS на макетных платах или как с ISA модемом - куча МГТФ-а.

"Коммерческие" режимы? - они свое получили: CPM, supercalc, turbo pascal... что называется по стопам robotron 1715. Игры и спрайты и сам ZX-SPECTRUM к этому всему отношения не имеет по-моему никакого.

Ну вообще-то совсем уже не "предел", поскольку ПЛИСы все толстеют и дешевеют (причем слабые модели снимаются с производства). А про идеальный двухмерный движок я выше писал. Совместимость в такую схему можно по-разному прикрутить, и цена ее поддержки ничтожная по сравнению с основным движком.

А на что максимум мы можем реально рассчитывать в ближайшие 5 лет с таким подходом к разработке будущего ZX видеопроцессора? S3Trio64V+? Или V9990? А какая цена его будет $100? $150? При том что цена на готовый аппарат NES или SegaMD уже давно сравнялась и составляет менее $20. А может теперь удастся сделать аля Voodoo2 плату с видеомикшером способную смешать качественно экран спекки с готовым PAL изображением?

[Valen]

А на что максимум мы можем реально рассчитывать в ближайшие 5 лет с таким подходом к разработке будущего ZX видеопроцессора?

Если syd сделает speccy2008 (ценой до 100$), это и будет современный
спек, с возможностью написать на hdl, нормальный 2Д видео-процессор (в
fpga).

[bigral]

Если syd сделает speccy2008 (ценой до 100$), это и будет современный
спек, с возможностью написать на hdl, нормальный 2Д видео-процессор (в
fpga).

Сорри но я так не думаю - то что делает syd это к сожалению никакой не zx-spectrum а очередной недо-AlteraDE1 board в стиле 1_сhip_msx. А не 100% спекки клон он уже сделал. Я думаю что zx-spectrum это: http://en.wikipedia.org/wiki/ZX_Spectrum А современный zx-spectrum это: http://www.zxdesign.info/wideMemContention.shtml

Добавлено через 18 минут

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

что за чепуха? тот hardware overlay который сейчас есть в каждом современном видео чипе и есть своего рода спрайт и все он может включая масштабирование. Та по сути тот же blitter это глупый переброс кусков информации в видео память что есть изначально тупая операция из-за того что совсем паралельно из других банков памяти можно бросать эти пиксели прямо на выходной DAC не мешая ни СPU и сканеру показывающему background. Спрайты не требуют высокой пропускной мощи памяти и тем более не должны быть в основной памяти CPU или иметь что-то общее с палитрами background-a... В гипертфророванной реализации этой модели спрайты это всеравно что наложенные друг на друга (по сложным правилам) бесконечное количество экранов каждый со своей отдельной видеопамятью и pixel shader-ом.