ПРАВДА И МИФЫ ОБ АДАПТАЦИИ ГРАФИКИ К SCF-mode

SMT> переделывать игры без исходников слишком сложно, не из-за вывода, а потому что
' нужно больше данных, меняется раскладка памяти, все привязки к тактам тоже вылетают,
' придётся думать, как в 2 раза ускорять существующий код.


ДА НЕТ ЖЕ!!!

Стал бы я вылезать с этой темой на форум, если бы предварительно не обдумал вопросы
прежде всего именно "переделки" и не имел некоторый опыт копания в коде как фирменных,
так и некоторых переделанных нашими умельцами игр! Да сидел бы тогда себе тихо,
или, как многие другие, выступал бы с перечислением голых характеристик какого-нибудь
очередного unterVGA, нимало не задумываясь о том, как другие будут это чудо использовать.

Давай по пунктам:

SMT> переделывать игры без исходников слишком сложно, ...

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

SMT> ... не из-за вывода, ...

А кто собирается лезть куда-либо, кроме вывода? Понятно, что с логикой разобраться
сложнее, вот только она нас при адаптации совершенно не интересует!

SMT> ... а потому что нужно больше данных, ...

С чего бы это??? Это при адаптации под видеочипы всякие надо ВСЮ графику переделывать
(не говоря уже о процедурах вывода). В простейшем случае (избавление от "клэшинга") при
адаптации к SCF-mode меняется не ЧТО выводится, а КУДА. Конечно, можно и графику улучшить,
спрайты/фоны раскрасить, если охота. SCF-mode выгодно отличается от всех прочих именно
тем, что ПРИ АДАПТАЦИИ ГОТОВЫХ ИГР ОБЪЕМ ПЕРЕДЕЛОК ЗАВИСИТ ТОЛЬКО ОТ ЖЕЛАНИЯ
И СВОБОДНОГО ВРЕМЕНИ
спектрумиста. Это работа, способная стать отдыхом!

SMT> ... меняется раскладка памяти, ...

Для 48-х фирменных игр (которых подавляющее большинство) это вообще не проблема - просто
используем дополнительную память (собственно, так игры у нас зачастую и переделывались)
- можно даже старый код не затирать. Со 128-ми сложнее. Но и из них очень много - те же
48-е, только с поддержкой AY-звука (плюс немного памяти на это). У каких-то еще есть
свободные страницы в пределах 128 кб, в самом крайнем случае используем дополнительную
память отечественных клонов, которая все равно пропадает зря. У наших же игрушек проще
исходники надыбать, да и автора можно достать (или тех, кто его творение ломал ).
Да и мизер это в общей массе. Если игра того стоит, можно и повозиться подольше.

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

SMT> ... все привязки к тактам тоже вылетают, ...

Ну это смотря как сделать. Если логика видеокарты будет работать аналогично стандартному
видеоконтроллеру, да еще привязываться к INT компа, особых проблем возникнуть не должно.
Даже на фирменных гробах с медленной памятью проц ведь все равно будет тормозиться, как
надо - ведь и запись в ОЗУ компа происходит. Хотя, конечно, это вопрос к схемотехникам,
надо его проработать. Правда, жесткая привязка по тактам наиболее критична для дем,
которые на других-то клонах зачастую не желают правильно работать (есть ли смысл
адаптировать демы?), а для игрушек (где обычно требуется лишь чтобы спрайты не мерцали)
существует более широкое "окно синхронизации". Да и ручками при отладке можно подстроить.

SMT> ... придётся думать, как в 2 раза ускорять существующий код.

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

Ну вот и все, что касается адаптации. Не веришь мне - спроси Spectre, он мои
идеи гораздо лучше меня растолкует.