Способы хранение графики в играх и бизнес приложениях
Автор статьи: Мироводин Дмитрий
Сайт Автора: [email protected]
E-mail Автора: delphigfx.mastak.ru
Дата публикации: 25.11.2005

 Содержание

Введение
Возможная структура файла
"Компилятор"
"Загрузчик"
Хранение ресурса в рекции PE файла
Играем MP3 из EXE

Введение

В предыдущей статье я рассказал, как можно считывать растры напрямую из файла ( надеюсь информация оказалась для Вас интересная). Теперь поговорим о том, как создать собственный, удобный для нас, формат хранения графической информации. Рассматриваемый подход пригодится не только для хранения графики, но и для совершенно различных бинарных данных. Это могут быть и музыкальные треки в популярном формате MP3, видео фрагменты, текстовые данные - в общем, любые данные Вашего приложения.

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

Возможная структура файла

Для начала набросаем приблизительную структуру нашего будущего формата данных. Для примера, я создам файл для хранения обычных растров в не компрессированном виде.

FileHeader
TGameRusourceHeader
Name String[32] Название файла
Version Integer Версия
ImageCount Integer Количество изображений
ResourceTable
TGameResourceTable
ResName String[32] Название ресурса
Offset Integer Смещение от начала файла
ResourceData
Графические данные

Так выгладит заголовок файла. Количество элементов ResourceTable соответствует количеству хранимых изображений. Сразу за последней записью в ResourceTable начинаются данные изображений.

Для создания подобного форматы нам потребуется написать небольшой "компилятор" или скорее "сшиватель" ресурсного файла. В его задачи будет входить создание файла с описанным выше форматом из обычных BMP файлов. Сразу стоит оговорится, что создание компилятора или упаковщика (это кому как нравится) самый трудоемкий процесс. По этому я решил особо не выпендриваться и написать его с использованием VCL, т.к. во первых это сугубо рабочая утилита, кроме нас её никто видеть не будет, а во вторых тут совсем не принципиальна скорость работы - один раз собрали ресурс и забыли про него. Хотя для больших работ, когда суммарный объем обрабатываемых файлов переваливает за сотни МБ, стоит подумать и о оптимизации.

Компилятор

Начнем создание компилятора с заготовки необходимых структур:

TGameRusourceHeader= packed record
  Name : string[32];
  Version : Integer;
  ImageCount : Integer;
end;

TGameResourceTable = packed record
  ResName : string[32];
  Offset : Integer;
end;

Надеюсь тут все понятно. Есть только две небольшие тонкости. Первая нельзя использовать просто String - только фиксированную длину строки! Иначе SizeOf(TGameRusourceHeader) выдаст совершенно не верный результат. Вторая тонкость по организации проекта. Т.к. нам нужно написать и компилятор ресурсов и загрузчик, лучше вынести описание заголовков в отдельный модуль.

Как уже писалось выше, я буду использовать VCL компоненты и стандартный набор классов. Это сильно сократит исходный код, да и сделает его понятным. Алгоритм процедуры "сшивания" ресурсов следующий. Процедуре будем предавать список файлов, и название выходного файла.

В переменные заведем три потока и другие необходимые переменные:

procedure TDIBCompilerForm.CompileResource(const SourceFileList:TStringList; const OutFileName: string);
var
  // Поток для записи окончательного файла
  OutStream : TStream;
  // Поток для хранения таблицы смещений
  TableStream : TStream;
  // Поток для хранения данных
  ResourceStream : TStream;
  // Кол-во изображений
  ImgCount : Integer;
  // Смещение от начала файла текущее растра
  Offset : Integer;
  // Размер заголовка и размер всей таблицы смещений
  HeaderSize : Integer;
  AllTableSize : Integer;
  // Экземпляр для записи в таблицу смещений
  GameResourceTable : TGameResourceTable;
  ...

Для начала работы процедуры проинициализируем все объекты и переменные:

...
OutStream:=TFileStream.Create(OutFileName, fmCreate);
TableStream:=TMemoryStream.Create;
ResourceStream:=TMemoryStream.Create;
ImgCount:=1;
HeaderSize:=SizeOf(TGameRusourceHeader);
AllTableSize:=SizeOf(TGameResourceTable)*SourceFileList.Count;
Offset:=HeaderSize+AllTableSize;
...

Самой сложной частью процедуры я считаю рассчет смещений, все остальное достаточно прозрачно:

for I:=0 to SourceFileList.Count-1 do
begin
  Bitmap.LoadFromFile(SourceFileList[I]);
  Bitmap.SaveToStream(ResourceStream);
  GameResourceTable.ResName:=ExtractFileName(SourceFileList[I]);
  GameResourceTable.Offset:=Offset;
  ...  
  TableStream.WriteBuffer(GameResourceTable, SizeOf(TGameResourceTable));   Offset:=HeaderSize+AllTableSize+ResourceStream.Position; Inc(ImgCount);
end;

... на последок копирование данных в выходной поток и очистка занятых ресурсов.

// Перемещаемся на начало данных
ResourceStream.Seek(0, soFromBeginning);
TableStream.Seek(0, soFromBeginning);
// Устанавливаем количесво добавляемых битмапов в заголовок
GameRusourceHeader.ImageCount:=ImgCount;
// Запись выходного файла
OutStream.WriteBuffer(GameRusourceHeader, SizeOf(GameRusourceHeader));
OutStream.CopyFrom(TableStream, TableStream.Size);
OutStream.CopyFrom(ResourceStream, ResourceStream.Size);
// Блок финализации
ResourceStream.Free;
TableStream.Free;
OutStream.Free;
Bitmap.Free;

Вот собственно и всё. После успешного завершения процедуры у Вас получится файл с описываемой структурой. При работе процедуры, создается файл с расширением OutFileName.text, куда записывается вся информация о размерах структур, смещениях и т.д. Смещения записываются как в обычном десятичном виде, так и в шестнадцатеричной форме. Последняя форма записи очень помогает при анализе полученного файла в любом HEX редакторе (WinHex, Hview и т.д.).

Не возможно не упомянуть об одной особенности - уменьшении размера полученного файла. Поясню более подробно. Для примера я скомпилировал набор из 313 BMP файлов различного размера. Суммарный объем файлов 2, 359 Кб, после сборки получился файл размером 2,428 Кб - оно и понятно, мы записываем лишнею информацию. После сжатия архиватором ZIP отдельных BMP файлов получился архив размером 697 Кб, а вот при сжатии выходного файла - 640 Кб. Выигрыш очевиден, причем он растет с увеличением числа хранимых битмапов и уменьшения их размера. При сборке ~500 картинок размером 16x16 выигрыш получается более чем в два раза. Необходимо помнить, что для приложений распространяемых по сети размер дистрибутива до сих пор критичен. И если Ваша игра или утилитка "весит" в 5-6 раз меньше, чем аналоги, шанс что пользователь выберет именно её повышается не однократно.

"Загрузчик"

Надеюсь с созданием формата данных для хранения информации Вы разобрались, теперь осталась самая легкая часть - написать загрузчик графики из нашего формата. Как и с компилятором ресурсов, я напишу программу используя VCL (ну не знает наш народ API, а при виде одного dpr файла впадает в ступор - "А где же форма ? Где мой любимы TButton.OnClick ???"=) ).

Всё действо будет происходить в одной процедуре. Параметр ResourceFileName - путь и имя к файлу, а ImageCount - номер изображения для загрузки (нумерация начинается с 1). В процедуре нам понадобится всего четыре переменные:

procedure TLoaderForm.LoadBitmap(const ResourceFileName: string; const ImageCount:integer);
var
  FileStream : TStream;
  Bitmap : TBitmap;
  GameRusourceHeader: TGameRusourceHeader;
  GameResourceTable : TGameResourceTable;

Сама процедура чрезвычайно проста, обратите внимание только на получение смещение для загрузки файла:

// Инициализация
Bitmap:=TBitmap.Create;
FileStream:=TFileStream.Create(ResourceFileName, fmOpenRead);
// Чтение заголовка
FileStream.ReadBuffer(GameRusourceHeader, SizeOf(GameRusourceHeader));
// Перемещение на начало таблицы смещений ресурса
FileStream.Seek((ImageCount-1)*SizeOf(GameResourceTable), soFromCurrent);
// Чтение таблицы ресурса
FileStream.ReadBuffer(GameResourceTable, SizeOf(GameResourceTable));
// Перемещение к началу данных затребованного ресурса
FileStream.Seek(GameResourceTable.Offset, soFromBeginning);
// Непосредственная загрузка
Bitmap.LoadFromStream(FileStream);
...
// Убираем за собой
Bitmap.Free;
FileStream.Free;

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

Остановимся на возможности оптимизации. Итак:

  1. Первая возможность оптимизации заключается в кэшировании таблицы смещений. Такая структура занимает не очень много места в памяти, но позволит совершить мгновенный переход не только по индексу изображения (что не удобно), но и по его имени, если оно конечно хранится.
  2. Вторая - использование собственного загрузчика изображений. Это позволит выиграть очень много времени, особенно если использовать оптимизированные процедуры для загрузки 8 и 24-х битных изображений.

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

Хранение ресурса в секции PE файла

Теперь настала пора разобраться, как поместить созданный ресурсный файл в исполняемое приложение, т.е. просто "вшить" его в exe файл. Проблемы с соединением не возникнет, а вот как с обращением к ресурсу стоит попотеть.

Как известно в PE файле есть различные секции, при этом ничего не мешает Вам писать в секцию импорта свои данные, но есть специальная секция RCData. Она то и предназначенная для записи собственных данных приложения, т.е. в неё можно пихать всё, что угодно (в смысле бинарных данных :)), в разумных пределах конечно.

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

Итак создаем RC файл, например Resource.rc со следующим содержанием:

...
GAMEDATA RCDATA out
...

GAMEDATA - название ресурса, т.е. его идентификатор;
RCDATA - название секции;
Out - имя файла, может быть только название файла, а может и целый путь.

Создаем ресурсный файл вызывая компилятор ресурсов:

brcc32.exe Resource.rc

...ааа вот зачем программистам в Windows нужна командная строка! После успешного завершения, мы получим бинарный ресурсный файл Resource.RES, его можно подключать к проекту директивой компилятора:

{$R Resource.RES}

Теперь при сборке проекта в получившемся exe файле появится секция RCDATA и в ней ресурс с названием GAMEDATA.

Осталось совсем чуть-чуть - написать процедуру загрузки. Она будет достаточна сложна, и если Вы не сильны в таких понятиях как указатели, дескрипторы, плоская модель памяти … смело пропускайте данный материал. Бездумное копирование кода до добра не доводит :)

Начнем как всегда с расшифровки переменных:

procedure TDibFromResForm.LoadBitmap(const ImageCount:Integer);
var
  // Указатели на структуры заголовка файла
  GameRusourceHeader : PGameRusourceHeader;
  GameResourceTable : PGameResourceTable;
  // Указатели на структуры растра
  BitmapFileHeader : PBITMAPFILEHEADER;
  BitmapInfoHeader : PBITMAPINFOHEADER;
  BitmapInfo : TBitMapInfo;
  BitmapBits : Pointer;
  // Handle заголовок данных блока ресурса
  RSRC : HRSRC;
  // Handle на область памяти ресурса
  RES : THandle;
  // Указатель на область памяти загруженного ресурса
  P : Pointer;
  // Переменная для хранит начально адреса данных ресурса
  StartAddr : Integer;
  // Счетчик смещения адресов
  I : Integer;
  // Переменная для хранения полученного битмапа
  Bitmap : HBITMAP;
  // Контекст устройства
  DC : HDC;
...

Ну как, не испугались ? Дальше интереснее будет:

RSRC:=FindResource(HInstance, 'GAMEDATA', RT_RCDATA);
if RSRC = 0 then
begin
  MessageBox(Handle,'Ресурс не найден.', MessageTitle, MB_ICONERROR+MB_OK);
  Exit;
end;
RES:=LoadResource(HInstance, RSRC);
P:=LockResource(RES);

Находим ресурс функцией FindResource по его идентификатору GAMEDATA в секции RT_RCDATA. Загружаем ресурс функцией LoadResource, блокируем доступ к нему и получаем область занимаемой им памяти в указатель P.

StartAddr:=Integer(P);
I:=StartAddr;
GameRusourceHeader:=Ptr(I);
Inc(I, SizeOf(TGameRusourceHeader));
Inc(I, SizeOf(TGameResourceTable)*(ImageCount-1));
GameResourceTable:=Ptr(I);
I:=StartAddr+GameResourceTable.Offset;
BitmapFileHeader:=Ptr(I);
Inc(I, SizeOf(TBitmapFileHeader));
BitmapInfoHeader:=Ptr(I);
Inc(I, SizeOf(TBitmapInfoHeader));
GetMem(BitmapBits, BitmapInfoHeader.biSizeImage);
BitmapBits:=Ptr(I);
BitmapInfo.bmiHeader:=BitmapInfoHeader^;

В StartAddr получаем адрес памяти указателя P и устанавливаем счетчик I на это же значение. Далее все опрерации будем производить только со счётчиком, так нагляднее. Загружаем заголовок GameRusourceHeader, он находится прамо по адресу I или StartAddr, т.к. в самом начале блока памяти загруженного ресурса.

Увеличиваем счетчик на размер структуры TGameRusourceHeader. Параметр функции ImageCount хранит номер растра, который необходимо получить. По этому высчитываем смещение для требуемой таблицы ресурсов: SizeOf(TGameResourceTable)*(ImageCount-1). Получаем таблицу смещений. Из неё можно вытащить смещение требуемого растра: StartAddr+GameResourceTable.Offset. По этому смещению можно последовательно считать BitmapFileHeader, BitmapInfoHeader и BitmapBits. Вот собственно и все!

Осталось создать Bitmap и очистить ресурсы:

...
Bitmap:=CreateDIBitmap(DC, BitmapInfoHeader^, CBM_INIT, BitmapBits, BitmapInfo, DIB_RGB_COLORS);
...
UnlockResource(RES);
FreeResource(RES);

Не так все и сложно, хотя я представляю лица ( масли, выражения, жесты ... ) тех, кто сел за Delphi месяц назад :))) На самом деле, достаточно сложный для понимания материал. Хотя если Вы изучали C или ASM для Вас должно быть всё тривиально.

Пример приведённый выше далеко не оптимален:

  1. Во первых, присутствует несколько лишних переменных. Это сделано только для большей понятности кода.
  2. В коде всего одна проверка - это очень не правильно :) Нужно сопровождать каждую операцию проверками на нулевой указатель, правильность размера структуры и т.д. Самая простая - на существование запрошенного изображения, а то может получится такая ситуация, что всего в ресурсе 10 растров, а запрашиваем 1001. Процедура попытается читать данные из совсем "левой" области памяти. Мы ведь работаем с нетипизированными указателями, напрямую с памятью и ошибки вызовут крах всего приложения.

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

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

Приведу небольшой пример. Допустим, необходимо подключить к exe файлу композицию в формате MP3. Для маленьких игр это может быть музыкальный фон, звуки спец. эффектов и т.д. Файл будет называться sample.mp3

Создадим ресурсный файл MusicRec.RC и в него добавим строчку:

MUSIC1 RCDATA sample.mp3

Соберём бинарный файл ресурса командой:

brcc32.exe MusicRec.RC

и подключим к нашему приложению скомпилированный ресурсный файл:

{$R MusicRec.RES}

После этих операций в нашем exe файле будет присутствовать MP3 фрагмент sample c идентификатором MUSIC1.

Нам осталось только проиграть данный файл. Что для этого потребуется ? Конечно проигрыватель. Все конечно же подумали про WinAMP, но это же проигрыватель внешних файлов, к тому же не интересно привязывать нашу программу к WinAMP'у.

Среди свободно распространяемых проигрывателей я выбрал библиотеку BASS. Во первых она позволяет проигрывать не только MP3 файлы, но и файлы трекерных форматов XM, MOD и т.д., что очень актуально для игр и демонстраций. Ведь эти файлы занимают очень мало места, а качество музыки на очень приличном уровне. Еще один большой плюс библиотеки BASS - её бесплатность для не коммерческого использования. К тому же она распространяется в виде динамической библиотеки с открытым интерфейсом и очень проста в использовании - я буквально за 10 минут написал этот пример, при этом ранее библиотеку никогда не видел.

Собственно работа со звуком заключается в 4-х операциях:

Инициализация биьлиотеки.
Загрузка звукового фрагмента.
Воспроизведение.
Освобождение ресурсов.

Нам интересен кусочек загрузки музыкального фрагмента из памяти, по этому я рассмотрю только его.

var
  RSRC : HRSRC;
  RES : THandle;
  P : Pointer;
...
RSRC:=FindResource(HInstance, 'MUSIC1', RT_RCDATA);
...
RES:=LoadResource(HInstance, RSRC);
P:=LockResource(RES);
Music:=BASS_SampleLoad(TRUE, P, 0, MusicSize, 3, BASS_SAMPLE_OVER_POS);
...

В качестве основных параметров, процедуре BASS_SampleLoad передается указатель P и размер музыкального фрагмента в байтах (размер описывается к константах). Значение остальных параметров описаны в файле bass.pas или в файле справки.

Для лучшего осмысления работы библиотеки BASS посмотрите пример BassTest входящий в комплект поставки.

Вот собственно и всё. В следующий части статьи я поробую рассказать о хранении компрессованных ресурсов.


Список похожих статей