2.25.3. Написание кода

Пожалуй, следует пояснить некоторые особенности написания кода для MCK. В отличие от "прямого" программирования в KOL, в MCK для формы создается объект-держатель формы, произведенный непосредственно от TObj (так же можно поступать и при ручном KOL-программировании, но это целиком на усмотрение программиста). Этот объект "параллелен" VCL-форме, но не является визуальным объектом. Сама форма (как экземпляр объекта типа PControl) в нем представлена полем Form. Т.е., например, если у вас в VCL-проекте создавалась форма TForm1, то в MCK-проекте создается «на этом же месте» объект с типом TForm1, с типом указателя на него PForm1. Т.е. здесь его видит таким компилятор. И все брошенные на форму во время разработки компоненты, в том числе и сама форма (зеркальная невизуальному компоненту TKOLForm, лежащему на форме), являются полями этого объекта.

Примечание. На самом деле, обыденная банальность данного описания применения слова Form скрывает за собой поистине фантастические явления. Для примера, если вы пропишете предложенный в следующем абзаце код в обработчике OnFormCreate, то уже в тот момент, когда вы его набираете с клавиатуры, вы можете обнаружить, что Code Completion, т.е. система автоматического дополнения кода, прекрасно "видит" переменную Form. И на декларацию этого поля в структуре полей "бывшей VCL-формы" можно перейти (ctrl+click). Замечательно то, что эта переменная "видна" одновременно и во время написания кода, и компилятору, при компиляции этого кода, и отладчику - при пошаговом выполнении. Наверное, следовало подать заявку на патент... но теперь уже поздно.^*

Вывод из сказанного следующий. Различие между написанием кода для VCL и для KOL+MCK заключается в том, что для того, чтобы в KOL обратиться к свойству, методу или событию самой формы, необходимо использовать не Self, а Self.Form. Например, чтобы в обработчике события OnFormCreate изменить заголовок формы, код должен быть таким:

Form.Caption := 'новый заголовок';

2.26 Графические ресурсы приложения

Так же, как и любое приложение формата PE^* в Windows32, приложение KOL позволяет хранить необходимые для его работы графические ресурсы вместе с исполняемым файлом. Эти ресурсы могут загружаться различными методами, включая неявную загрузку ресурсов методами объектов, но, в конечном счете, все они сводятся к вызовам соответствующих функций API, выполняющих создание необходимого графического объекта и возвращающих его дескриптор.

С точки зрения экономии размера приложения, может оказаться важным количество и размер таких ресурсов. Иногда удается существенно снизить размеры ресурсов, если использовать аккуратный подбор наиболее подходящих форматов для хранения графики. Прежде всего, обратите внимание на количество различных цветов, требующихся для представления графического изображения типа bitmap или icon. Даже если картинка использует нестандартные цвета, не присутствующие в стандартной системной палитре, но количество этих цветов не превышает 256, то имеет смысл использовать формат 8 бит на пиксель. А если цветов не больше 16, то прекрасно подойдет формат 4 бита на пиксель. Даже в случае перехода от полноцветного формата 24 бита на пиксель к формату 8 бит, для одного изображения размером 100х100 пикселей будет получена экономия 20000 байтов – 256х4 = 18976 байт. Здесь я вычел расходы, связанные с хранением самой палитры из 256 цветов, по 4 байта на цвет. Замечу так же, что существует формат представления (считающийся устаревшим, но вполне работоспособный), при котором в палитре на один цвет расходуется не 4, а 3 байта. При использовании такого формата можно сэкономить еще как минимум 256 байт (заголовок изображения в этом формате так же на несколько байт короче, так что экономия будет чуть больше).

В случае изображения больших размеров, когда общее количество различных использованных цветов уже достаточно велико, и не может быть ограничено числом 256, рассмотрите возможность использования изображений формата 16 бит на пиксель. Неприятная особенность этого формата заключается в том, что у цветовых каналов R и B (красный и синий) отбрасываются 3 младших бита значения, а у канала G (зеленый) – 2 младших бита. В некоторых случаях такое «округление» может несколько ухудшать качество картинки, особенно если она содержит элементы плавной градиентной заливки. Но вообще-то, во многих случаях ухудшение качества изображение малозаметно на глаз.

У некоторых начинающих программистов существует ложное представление о том, что хранение изображений в формате со сжатием, в отличие от хранения их в виде побитовой карты (bitmap) может позволить сэкономить размер приложения. Да, может, но только если суммарный эффект от сжатия всех таких ресурсов перекроет негативный эффект от добавления в код соответствующих алгоритмов распаковки. Обычно наличие распаковщика любого из наиболее распространенных форматов GIF, JPG, PNG требует для каждого более 30Кбайт кода дополнительно.

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

Существует еще один формат сжатия, иногда довольно полезный (например, в случае изображений, содержащих большие одноцветные области), о котором часто забывают: это RLE-кодирование. Метод TBitmap.LoadFromStreamEx позволяет без проблем загружать такие изображения (спасибо В. Гаврику, добавившему этот метод в KOL). Скорее всего, загружать такой ресурс вам придется своим кодом, обращаясь к вышеуказанному методу, но это не сложнее использования загрузчиков других форматов со сжатием. Разумеется, вам придется найти программное обеспечение, при помощи которого вы выполните RLE-сжатие изображений перед тем, упаковать их в ресурсы.