3. Упаковка данных.

Убедившись, что оперативной памяти мне не хватает, я начал думать об упаковке данных. В первую очередь, мне предстояло хранить несколько карт игрового поля (по одной для каждого уровня) это наиболее емкие данные.

Я подготовил несколько различных методов, поэкспериментировал с ними и, наконец, остановился на наиболее оптимальном.

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

Единицей измерения на карте я выбрал блок из четырех знакомест (размер 16x16 пикселов).

Для комнат в первом байте я решил хранить координату левого верхнего угла комнаты, я во втором байте размер этой комнаты. Вы знаете, что поскольку байт не может принимать значение больше 255, то мне нелегко было бы сделать достаточно большое игровое поле. Максимум 16x16 блоков по 16x16 пикселов, то есть, чуть больше одного экрана. Это, конечно, недостаточно, поэтому координата левого верхнего угла задается не как абсолютная, а как относительная, то есть это "смещение" начала N ой комнаты относительно N 1 ой комнаты. Тогда все стало на свое место (пример см. на рис. 1)

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