Цитата Сообщение от inozemcew Посмотреть сообщение
Та не.. Объяснять таки надо. Народ начинает понимать идею, но до конструктивной критики (ради чего я сюда собственно и запостился) дело еще не дошло.
Думаю, самый большой недостаток системы - частичное устранение (спрайты 8х8 всё ещё одноцветные) не самого большого недостатка применением огромного количества памяти и повышенным требованием к быстродействию.

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

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

Цитата Сообщение от inozemcew Посмотреть сообщение
Можно даже просто взять 4-8 битовых планов и обычную палитру, и затем заполнив эту палитру специальным образом, получить псевдополупрозрачные слои. Именно так это делается на "Векторе". Плюс еще там 16-256 цветов на точку и т.д. и т.п.
Так вы и предлагаете по сути нечто похожее на векторовскую реализацию. Там тоже при разбивке на слои получается по 1 цвету на однобитный слой. Но там немного проще оперировать со слоями. Разве что, самый нижний слой будет уступать по количеству цветов вашей реализации.

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

Цитата Сообщение от inozemcew Посмотреть сообщение
Все изменения, которые нам потребуются для устранения клэшинга - это вывести в порт номер слоя перед процедурой рисования спрайта. Т.е. модифицировать придется всего несколько байт.
Не совсем модифицировать. Точнее, вставить. Для этого нужно подвинуть некий код, в нём придётся поковыряться на предмет перемещаемости. Думаю, это не так и просто будет адаптировать игру к такому выводу на экран. Правда, если спрайт выводится xor'ом, то можно будет команды чтения заменить на команду вывода в порт, тогда да, будет не так сложно. Или сначала запоминается фон, то тоже его можно заменить на запись в порт.

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