графоманские улучшения

ФЛЕНОВ МИХАИЛ AKA HORRIFIC

Спецвыпуск: Хакер, номер #064, стр. 064-024-4

Размер изображений также играет немаловажную роль. Если мы выбрали разрешение экрана в 800x600 пикселей при 16-битном цвете, то для хранения поверхности понадобится 800*600*2 = 960 000 байт памяти. Почти 1 Мб! А если изображение будет 1024x768, то объем необходимой поверхности памяти составит 1 572 864 байт. Снова увеличение ресурсов в два раза, следовательно, мы получаем падение производительности во время копирования содержимого поверхностей.

Оптимизация графики на первоначальном этапе — это борьба качества и скорости, выбор между ними. Современным стандартом стали ЖК-мониторы с диагональю 15 дюймов. Чтобы картинка на них выглядела приемлемо, необходимо использовать разрешение 800x600, а лучше 1024x768.

Однако неплохо было бы предусмотреть возможность выбирать необходимое разрешение. Например, у меня широкоформатный ноутбук, и для него идеально разрешение 1280x800, а разрешения 800x600 и 1024x768 выглядят растянуто, что очень неудобно. Вот почему в данном случае можно предложить пользователю самостоятельно выбирать необходимое разрешение в зависимости от имеющихся ресурсов.

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

не дай себе засохнуть

Двумерная графика может формироваться двумя способами: математическим и спрайтовым. В случае с математическим способом поверхность заполняется через прямой доступ по определенному алгоритму. Некоторые из алгоритмов создания эффектов я рассмотрю в четвертой главе. При использовании «математики» скорость формирования сцены, помимо глубины цвета и разрешения, очень сильно зависит от используемого алгоритма.

При спрайтовом формировании сцены дополнительным фактором торможения является количество спрайтов, поскольку для вывода каждого из них необходимо выполнить операцию Blt или BltFast (я имею в виду функции DirectDraw). Чем больше обращений, тем больше потеря, потому что тут проявляется эффект цикла: приходится много раз вызывать одну и ту же функцию, во время вызова несколько раз параметры поднимаются в стеке (а у Blt их немало) и происходит вызов удаленной функции, а также куча лишних проверок со всеми вытекающими последствиями. Иногда функцию Blt даже лучше заменить копированием данных через прямой доступ к памяти и WinAPI-функцию memcpy.

Потери данных при спрайтовом выводе могут быть и неоправданными. Допустим, у нас в распоряжении находится экран размером в 800x600 пикселей, как показано на рис. 3.1. Все, что закрашено черным цветом, — это оборка, которая статична и не изменяется, а в белой области данные формируются динамически, причем полностью. Эта задача решается вот так: перед формированием кадра вывести на экран изображение 800x600 с оборкой, затем сформировать среднюю часть. Стоп. Зачем делать это, если оборка статична? Не лучше ли один раз вывести оборку, а потом перекрашивать только центральную часть, которая изменяется? Конечно же, лучше. Таким образом мы сэкономим целую операцию Blt, которой приходится копировать большой объем информации.