Да, всё верно! Надо будет искать баланс между скоростью работы кода, расходом памяти, и количеством хранящейся в памяти "сдвинутой" графики. Либо универсально и медленно, либо максимально быстро и неэффективно по памяти. Думаю, для каждой игры можно найти золотую серединку.
Еще мысль: подобные движки могут (должны) учитывать ограничения и особенности отдельно взятой игры. И для другой игры этот же движок может не подойти. Таким образом, можно написать (цитата) насколько возможно быстрый и экономный скроллинг. А потом можно будет сделать еще быстрее, если учесть ограничения геймплея, и тем самым где-то упроситить/оптимизировать код.
Пример: если шаг вывода спрайта по вертикали сделать 2px вместо 1px, это может ускорить процедуру вывода спрайта. За счёт того, что down_hl будет выполняться только по чётным строкам. А по нечётным - inc h, в лоб.
Другой пример: если есть склеенные тайлы/спрайты, то для их вывода можно написать отдельную процедуру, которая напечатает в экран сразу оба. За счёт этого экономится кол-во вызовов down_hl, ровно по количеству таких тайлов/спрайтов.
Ответить с цитированием