Новый графический режим для игр

[zx-kit]

Старую игру всё равно придётся полностью делать ЗАНОВО!
Иначе какой тогда смысл вообще начинать?

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

Экономия 5-10% мощности CPU не есть гуд, переделывать даже 1 старую игру это ппц какой гемор, а если это делать только из-за того что бы убрать на паре спрайтов наползание цвета то не вижу в этом смысла.

Главное, что нет особого торможения в новых режимах. Если клешинг не видно - нет смысла переделывать игру.

Почему нельзя сделать тупо видео DMA ?
А если я захочу сделать игру и в 256x192 и в 640x480 ? Всё? Тупик?
А ведь с видео дма это решается примитивно и просто, AMIGA тому подтверждение.

Надо все делать поэтапно. Нет пределу совершенства. Сначала отладим программое рисование спрайтов без клешинга. Потом продолжим разработку блиттера. DMA наверно не понадобится.

---------- Post added at 18:28 ---------- Previous post was at 18:26 ----------

А можно нагрузить плис выводом анимационного заднего фона?

А зачем и как это будет выглядеть ?

[Nesser]

Сейчас мне скажут что создавай свою ветку и там пиши про свою новую видеокарту

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

[Raydac]

вводные
1. игры - код старый, сырцы недоступны, разработчики недоступны, для вывода графики писался зубодробительный код что бы выжать максимум
2. новый девайс со своей системой команд и требованием существенных внесения изменений в исполняемый код
мой конклюжн - адаптация при таком возьмет примерно столько же сколько написание игры с нуля, таких стахановых в лагере спектрумистов врядли есть

[Nesser]

Берём хотя бы диззи, к примеру в лесу стоит факел, нужно сделать отрисовку всего экрана с учётом света от факела, при чём с минимальной нагрузкой, единственный вариант это наложить слой с радиальной яркостью которая изменит яркость предыдущего слоя, то есть чисто маска есть/нет здесь не прокатит. Так же интересно выглядело солнце вверху от которого идёт яркостная засветка фона.
Ну это в принципе мелочи.

Ландшафтный фон - загружаем в память видеокарты файл карты и спрайты к ней. Допустим карта 512 на 256 двухбайтовых слов в которых содержится номер спрайта ну и к примеру разброс анимации по номеру спрайта, к примеру спрайты 16 на 16, карта получается 8192 на 4096 пикселей, то есть 32 на 21 экран, че то я переусердствовал ну да бог с ним, так вот, подаю я к примеру координаты 2785, 476 и карточка будет отображать слой с ландшафтом по этим координатам, то есть CPU вообще не имеет гемора с отображением карты, а если видеокарте сказать что разрешение было изменено с 256x192 на 640x480 то она просто изменит поправочный делитель в блоке вывода и на экране прекрасно будет выводиться другое разрешение, можно даже завести туда все стандартные, скажем так на будущее чем мощнее потом ставить плисину тем большее разрешение она будет успевать перелопачивать, одна и та же игра будет заведомо работать на б`О`льших разрешениях.
Может вообще сделать её командно-управляемую? как встроенный калькулятор BASICа у которого свой язык, подаешь карте адрес и она начинает выполнять программу в своей памяти, запихать в плисину небольшой специализированный cpu с небольшим набором команд я думаю не сложно

нуу пока что так

[Reobne]

возьмет

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

[zx-kit]

Берём хотя бы диззи, к примеру в лесу стоит факел, нужно сделать отрисовку всего экрана с учётом света от факела, при чём с минимальной нагрузкой, единственный вариант это наложить слой с радиальной яркостью которая изменит яркость предыдущего слоя, то есть чисто маска есть/нет здесь не прокатит. Так же интересно выглядело солнце вверху от которого идёт яркостная засветка фона.
Ну это в принципе мелочи.

Ландшафтный фон - загружаем в память видеокарты файл карты и спрайты к ней. Допустим карта 512 на 256 двухбайтовых слов в которых содержится номер спрайта ну и к примеру разброс анимации по номеру спрайта, к примеру спрайты 16 на 16, карта получается 8192 на 4096 пикселей, то есть 32 на 21 экран, че то я переусердствовал ну да бог с ним, так вот, подаю я к примеру координаты 2785, 476 и карточка будет отображать слой с ландшафтом по этим координатам, то есть CPU вообще не имеет гемора с отображением карты, а если видеокарте сказать что разрешение было изменено с 256x192 на 640x480 то она просто изменит поправочный делитель в блоке вывода и на экране прекрасно будет выводиться другое разрешение, можно даже завести туда все стандартные, скажем так на будущее чем мощнее потом ставить плисину тем большее разрешение она будет успевать перелопачивать, одна и та же игра будет заведомо работать на б`О`льших разрешениях.
Может вообще сделать её командно-управляемую? как встроенный калькулятор BASICа у которого свой язык, подаешь карте адрес и она начинает выполнять программу в своей памяти, запихать в плисину небольшой специализированный cpu с небольшим набором команд я думаю не сложно

нуу пока что так

Видеокарта не расчитывается на математические расчеты для вычисления яркости, тени, 3D и т.п. наворотов. Это уже давно изобретено в лучшем виде на PC. Меня интересует ретро-графика, а не 3D.
Блиттер пока не добавляем. На рисование карты программными тайлами не так уж много времени надо. А если на втором этапе добавим аппаратный скроллинг фона, то надо будет заполнить фон один раз на весь экран (тут время не очень критично), а потом дорисовывать только столбик или строку (а на это времени хватит и программным способом). Потом может это все ускорит блиттер. Но не первом этапе. Потом продолжим разработку и команд и дисплей-листов. Этим мы уже занимались и в этой теме и в железе были наброски команд - перечитайте, что мы там уже напридумывали.

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

[Advertiser]

[s_kosorev]

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

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

[Nesser]

Так я и говорю что это не проблема, тем более там больше 100 МГц плисина

[Raydac]

а как планируется быть с кейсом когда в игре есть dashboard и все взаимодействие с юзером и индикация осуществляется через изменение цветов атрибутов на dashboard, целиком переписывается данные код?

[Nesser]

Я так понимаю что через изменения цвета в палитре