Блиттер добавим потом. Сначала надо реализовать стандартный экрана + устранение клешинга.
Блиттер добавим потом. Сначала надо реализовать стандартный экрана + устранение клешинга.
"L-256"
Сообщение от zst
чтобы получилось "проще с устранением клешинга" (и прочие хотелки в первой цитате) - с блиттера надо было начинать
и вопроса "почему в жирный плис не лезет" не возникало бы
Прихожу без разрешения, сею смерть и разрушение...
Возьмем более жирную FPGA на 6272 триггеров. С таким количеством триггеров мы уж точно сможем модернизировать старые игры простыми способами. Но придется освоить сложную SDRAM и вывод на мониторы с разверткой FULL HD.
Новые режимы можно будет использовать не только на Спектруме, но и на других компьютерах, где можно добавить один параллельный порт на запись и два сигнала записи. Этого будет достаточно, чтобы записывать параметры в регистры FPGA и память SDRAM.
Последний раз редактировалось zx-kit; 25.04.2016 в 21:19.
"L-256"
блиттер кстати очень уживаются с Sdram, блочные операции, с которыми sdram работают просто и быстро
для простой модернизации старых игр нужно не большее количество лишних триггеров, а простая схема модернизации
ты говоришь так, будто несколько видеорежимов - это что-то хорошее
лучше бы всё было наоборот - чтоб в одном режиме можно было имитировать режимы других компов
Прихожу без разрешения, сею смерть и разрушение...
Упрощение уже произошло - теперь видеокарте на надо знать, как формируется изображение внутри компьютера и тратить на это свои триггеры и время. Она будет брать готовый цвет RGBI и синхросмесь. А новые слои накладывать поверх готового изображения с компьютера.для простой модернизации старых игр нужно не большее количество лишних триггеров, а простая схема модернизации
ты говоришь так, будто несколько видеорежимов - это что-то хорошее
лучше бы всё было наоборот - чтоб в одном режиме можно было имитировать режимы других компов
А программист будет знать, как формируется изображение в старом режиме и как добавить новые возможности в новом. Часть изображения в игре будет изображаться в новом режиме, а остальное останется в старом. Они будут одновременно на экране. Степень модернизации будет выбирать программист. На любом этапе модернизации будет изображение на экране. А дальше результат зависит от творческих способностей программиста.
Последний раз редактировалось zx-kit; 25.04.2016 в 22:21.
"L-256"
То есть будет неэффективно тратить свои ресурсы на убогие и ограниченные слои, на различные схемы чтения и интерпретации содержимого видеобуфера в различных режимах и, кстати, также на соответственные им режимы работы блиттера (если всё-таки захочется сделать блиттер). И при этом в результате будет пригодна лишь для улучшения софта в рамках одной платформы, а не облегчать еще и портирование софта меж любых платформ на совместимых процессорах.
Ну, и необходимость втыкать карту еще и в RGB-выход я бы не назвал упрощением
А не слишком ли много программисту придётся знать с нынешним нагромождением слоёв и разных режимов? Вообще не пойму, зачем тебе понадобились слои, только цветность ограничивают зазря и усложняют пользование устройством. Можно обойтись прекрасно без них, одним-единственным примитивным растровым массивом, но зато максимальной глубины цвета и максимального размера (в рамках развёртки) и с гибкой схемой записи группы пикселей. Что позволит модернизировать игрушки НАМНОГО проще - так, в простейшем случае (но достаточном, чтобы полностью избавить игру от клэшинга!) программисту нужно знать ТОЛЬКО лишь как выбирать два активных цвета для рисования (неважно даже, на экране или в теневом буфере). Остальных настроек хватит дефолтных.
Прихожу без разрешения, сею смерть и разрушение...
В любом случае, для "модернизации" старья, это же самое старьё придётся ещё и дизасмить, на что далеко не каждый согласится. А некоторые игры принципиально не получится зацветить, только если перерисоввывать всю графику. Так то всяких извратных решений хватает, тот же 16с или вон, ТС конфа или атм3 конфа. Не очень-то заметны тонны адаптированных игрушек под эти режимы.
В "железе" то есть эта "железяка"? Тема уже давно, теории много, но нет главного! " Желёзки".
Если невозможно связаться со мной через форум, то можно написать на электронный адрес: zhukov_gennadii@mail.ru
Соглашусь, что код придется смотреть... Предположим кто-то решил разукрасить игру из прошлого… Потребуется:
1) Переписать загрузочную часть, которая должна определять конфиг компа перед стартом и отравлять в некую видео-карту цветную графику
2) Скорее всего переписать часть основного кода программы, чтобы как-то привязать расширенную графику к нему для управления (без наличия видео-карты действительно сейчас сложно понять, как все будет работать)
При адаптации нужно будет понимать, что куча программ написана очень плотно в памяти… часто то, что было в 48к скорее всего будет проблематично адаптировать. При работе с картой желательно минимизировать количество команд для обслуживания самой видео-карты и работы с ней… Поясню… Любая команда в памяти занимает место, и в некоторых старых играх места для новых команд управления графикой может быть НУ ОЧЕНЬ МАЛО или вообще не оказаться… Так что команды должны быть короткими. Иначе нам придется переписывать код для работы в 128к и более (ну сейчас это типа не проблема … все-таки не конец 80х …), но это значит опять «шкодить» в основном блоке проги…
Мне лично интересно как развивается и ТС-Конфа и другие творческие проекты, но вот что касается TS_Labs и VDAC2… вот ведь как заворачивается история – в самом начале VDAC2 темы там уже промелькнула карточная реализации под Zx-bus… значит вопрос стандартизации начал беспокоить «самоделкиных»Но обратившись опять же к истории других платформ, мы увидим, что практически на каждой был период обкатки или даже «ветка эволюции» какой-то конкретной графической карты/чипа. И далеко не все они были совместимы между собой
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием