Outpost 2 Форматы файлаў · bei.pm

Гэты тэкст быў аўтаматычна перакладзены з дапамогай OpenAI GPT-4o Mini.

Файлы фармата, апісаныя на гэтай старонцы, заснаваны на тэхнічным аналізе інтэлектуальнай уласнасці Dynamix, Inc. і Sierra Entertainment.
Інтэлектуальная ўласнасць сёння з'яўляецца часткай актываў Activision Publishing, Inc. / Activision Blizzard, Inc. і ў дадзены момант належыць Microsoft Corp..

Інфармацыя была сабрана праз Reverse Engineering і даныя аналізу з мэтай архівацыі і ўзаемадзеяння з гістарычнымі данымі.
Не былі выкарыстаны ніякія ўласніцкія або канфідэнцыйныя спецыфікацыі.

Гульню можна набыць у якасці загрузкі на gog.com.

Мастацкае афармленне гульні

Наступная серыя артыкулаў дакументуе мае веды аб фарматах даных у гульні ў рэальным часе "Outpost 2: Divided Destiny", якая была выпушчана кампаніяй Sierra ў 1997 годзе і распрацавана кампаніяй Dynamix.

Я займаўся аналізам даных гульні і таго, як іх выкарыстоўваць, прыкладна з 1 лістапада 2015 года па 14 лістапада 2015 года.

З інфармацыі, якую мне ўдалося атрымаць, вынікае, што Dynamix - як і многія камерцыйныя кампаніі - не распрацавала некаторыя фарматы даных спецыяльна для Outpost 2, а таксама выкарыстоўвала іх у іншых распрацоўках, напрыклад, у серыі Mechwarrior (адаптаваных).
Незалежна ад гэтага, таксама можна адзначыць, што інавацыйнасць фарматаў даных фактычна абмежаваная і часта будуецца на больш старых канцэпцыях з звычайных фарматаў, такіх як JFIF і RIFF.

Для інтэрпрэтацыі табліц і фарматаў даных даступная дадатковая інфармацыя па спасылцы Што такое?.
Дадзеныя, якія тут прадстаўлены, у агульным разуменні з'яўляюцца Little Endian.

На заканчэнне можна сказаць, што реверс інжынірынг прынёс шмат задавальнення, нават калі ён не зусім завершаны.
Калі ласка, рэкамендую таксама саму гульню, бо яна прапануе цікавыя гульнявыя механікі.

Уводзіны

Дадзеныя, якія выкарыстоўваюцца ў Outpost 2, маюць структуру, якая нагадвае JFIF / PNG - асобныя блокі дадзеных заўсёды маюць загаловак на 8 байт. Таму я вырашаю не дакументаваць кожны загаловак у адпаведных спецыфічных месцах і фіксую там толькі адхіленні.

Фармат заўсёды наступны; сапраўдныя карысныя дадзеныя ўключаны ў яго:

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув Тып даных Назва Тлумачэнне

0x0000

uint(32)

Магічныя байты

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(32)	Магічныя байты	Утрымлівае інфармацыю аб тым, чаго чакаць у наступным блоке даных. Вядомыя значэнні: `0x204C4F56` ('VOL '): Аб'ём `0x686C6F76` ('VOLH'): Загаловак аб'ёму `0x736C6F76` ('VOLS'): Строкі аб'ёму `0x696C6F76` ('VOLI'): Інфармацыя аб аб'ёме `0x4B4C4256` ('BLCK'): Блок аб'ёму `0x504D4250` ('PBMP'): Графічныя даныя `0x4C415050` ('PPAL'): Каляровая палітра `0x4C415043` ('CPAL'): Кантэйнер каляровых палітраў `0x64616568` ('head'): Загаловак `0x61746164` ('data'): Карысныя даныя
0x0004	uint(24)	Даўжыня блока	Утрымлівае інфармацыю аб тым, наколькі вялікі (у байтах) наступны блок дадзеных. Пры гэтым маюцца на ўвазе толькі чыстыя карысныя дадзеныя - 8 байтаў загалоўка ў іх не ўваходзяць.
0x0007	uint(8)	Сцяжкі?	Невядома, для чаго менавіта служыць гэты блок. У аб'ёмах гэтая значэнне часта роўная 0x80, у іншых файлах часта 0x00. Гэта сведчыць пра тое, што гэта набор флагаў.

Утрымлівае інфармацыю аб тым, чаго чакаць у наступным блоке даных.

Вядомыя значэнні:

0x204C4F56 ('VOL '):
Аб'ём
0x686C6F76 ('VOLH'):
Загаловак аб'ёму
0x736C6F76 ('VOLS'):
Строкі аб'ёму
0x696C6F76 ('VOLI'):
Інфармацыя аб аб'ёме
0x4B4C4256 ('BLCK'):
Блок аб'ёму
0x504D4250 ('PBMP'):
Графічныя даныя
0x4C415050 ('PPAL'):
Каляровая палітра
0x4C415043 ('CPAL'):
Кантэйнер каляровых палітраў
0x64616568 ('head'):
Загаловак
0x61746164 ('data'):
Карысныя даныя

0x0004

uint(24)

Даўжыня блока

Утрымлівае інфармацыю аб тым, наколькі вялікі (у байтах) наступны блок дадзеных.

Пры гэтым маюцца на ўвазе толькі чыстыя карысныя дадзеныя - 8 байтаў загалоўка ў іх не ўваходзяць.

0x0007

uint(8)

Сцяжкі?

Невядома, для чаго менавіта служыць гэты блок.

У аб'ёмах гэтая значэнне часта роўная 0x80, у іншых файлах часта 0x00. Гэта сведчыць пра тое, што гэта набор флагаў.

Томікі

Аб'ёмы — гэта кантэйнер дадзеных для гульні, падобны да архіўнага фармату, як, напрыклад, Tarball. Прынамсі ў Outpost 2 гэты фармат ўключае толькі файлы — без каталогаў. Напэўна, іх можна было б сымулюваць з дапамогай адпаведных імёнаў файлаў.

Аб'ём складаецца з загалоўка аб'ёму, а таксама з некалькі аб'ёмных блокаў, якія адпавядаюць канкрэтным файлам.

"Аб'ёмы" — гэта файлы з пашырэннем 'vol' у гульнявым каталогу.

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	56	4f	4c	20	--	--	--	--	--	--	--	--	--	--	--	--	V	O	L		.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Блак-даўжыня
0x0007	uint(8)	Сцягі

Загаловак аб'ёму

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	76	6f	6c	68	--	--	--	--	--	--	--	--	--	--	--	--	v	o	l	h	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Блак-даўжыня
0x0007	uint(8)	Сцягі

Загаловак аб'ёму не ўтрымлівае ніякіх карысных даных.
Ён служыць толькі як кантэйнер.

Першае значэнне ў загалоўку аб'ёму павінны знаходзіцца радкі аб'ёму; пасля гэтага ідуць інфармацыя аб аб'ёме.

Тэксты аб'ёму

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	76	6f	6c	69	--	--	--	--	--	--	--	--	--	--	--	--	v	o	l	i	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Блак-даўжыня
0x0007	uint(8)	Сцягі

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	76	6f	6c	73	--	--	--	--	--	--	--	--	--	--	--	--	v	o	l	s	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Блак-даўжыня
0x0007	uint(8)	Сцягі
0x0008	uint(32)	Даўжыня нагрузкі	Указвае, колькі байт наступных дадзеных сапраўды з'яўляюцца карыснымі дадзенымі. Астатнія, астатнія дадзеныя спісу Volume-Strings, відавочна, варта лічыць сміцьцем. У файлах з пазнейшай датай гэтыя 'астатнія дадзеныя' 0x00, што можа сведчыць аб недахопах у інструментальнай сетцы падчас распрацоўкі гульні, іншымі словамі, што распрацоўшчык звярнуўся да правільнай ініцыялізацыі буфераў толькі вельмі позна, бо гэта не ўплывае на гульню, ці былі дадзеныя ініцыялізаваны ці не.
0x000c	uint(8)[]	Спіс імёнаў файлаў	Гэта спіс назваў файлаў з тэрмінацыяй 0-байт, які - па крайняй меры ў прадстаўленым складніку дадзеных - чакае толькі ASCII-симвалы. Неабходнасці больш дэталёва аналізаваць гэты блок дадзеных пры парсінгу няма, бо ў інфармацыі аб аб'ёме непасрэдна адсылаюцца адрасы назваў файлаў.

Аб'ёмныя радкі - гэта спіс імёнаў файлаў, якія ўтрымліваюцца ў аб'ёме.

Інфармацыя аб аб'ёме

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	76	6f	6c	69	--	--	--	--	--	--	--	--	--	--	--	--	v	o	l	i	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Блак-даўжыня
0x0007	uint(8)	Сцягі

Інфармацыя аб аб'ёме ўключае падрабязную інфармацыю аб файлах. Гэта ў пэўным сэнсе з'яўляецца своеасаблівым запісам каталога FAT (FAT = табліца размеркавання файлаў).

Колькасць файлаў вылічваецца шляхам дзялення памеру блока на даўжыню запісаў каталога - 14 байт.

Кожны асобны запіс каталога мае наступную структуру:

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(32)	Імя файла-афсет	Указвае, на якім адлегласці (!) у спісе імёнаў файлаў (Volume-Strings) знаходзіцца імя файла. Гаворыць пра пачатак блока карысных даных.
0x0004	uint(32)	Файл-офсет	Указвае, на якім зрушэнні ўнутры ўсёй аб'ёмнай файлавой сістэмы знаходзіцца файл.
0x0008	uint(32)	Памер файла	Указвае, наколькі вялікі файл у байтах.
0x000c	uint(16)	Сцягі?	Калiбраваць дадатковую інфармацыю пра кадаванне файла. `0x03` усталяваны, калі файл сціснуты. Тут, відавочна, выкарыстоўваецца дрэва Хаффмана. `0x80` відавочна заўсёды ўсталяваны.

Аб'ёмны блок

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	56	42	4c	48	--	--	--	--	--	--	--	--	--	--	--	--	V	B	L	H	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Блак-даўжыня
0x0007	uint(8)	Сцягі

Аб'ёмны блок — гэта кантэйнер, які змяшчае файлы. Ён утрымлівае толькі яшчэ раз — з-за фармату блока — рэдуndантна памер файла, а затым адразу ідуць карысныя даныя.

Пліткі

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	50	42	4d	50	--	--	--	--	--	--	--	--	--	--	--	--	P	B	M	P	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Даўжыня блока
0x0007	uint(8)	Сцягі

Тайлы - гэта спецыфічны для Outpost-2 фармат графікі Bitmap. Яны распаўсюджваюцца на 13 тайлсетаў, называемых "крыніцамі" (well0000.bmp да well0012.bmp), якія знаходзяцца ў аб'ёме maps.vol.

Тайлсеты / Крыніцы ўключаюць у сябе наступнае:

Імя файла	Змястоўнасць
well0000.bmp	Графіка памерам 32x32px, сіняга колеру - ідэальна падыходзіць для тэсту работы вашага загружальніка малюнкаў
well0001.bmp	Утрымлівае светлыя пароды, горныя хрыбты на светлых пародах і незлічоныя варыянты кратэраў на светлых пародах
well0002.bmp	Утрымлівае 'Doodads' з светлых парод - элементы, якія могуць быць размешчаны для дэкаратыўнага афармлення (або свядома як структура, напрыклад, сцены) на светлых пародах, у тым ліку расліннасць
well0003.bmp	Утрымлівае структуру, падобную на скарыну, на светлых пародах
well0004.bmp	Утрымлівае цёмныя пароды, горныя хрыбты на цёмных пародах і незлічоныя варыянты кратэраў на цёмных пародах
well0005.bmp	Утрымлівае 'Doodads' з цёмных парод - элементы, якія могуць быць размешчаны для дэкаратыўнага афармлення (або свядома як структура, напрыклад, сцены) на цёмных пародах
well0006.bmp	Утрымлівае структуру, падобную на скарыну, на цёмных пародах, а таксама пераходы паміж светлымі і цёмнымі пародамі
well0007.bmp	Утрымлівае лаву, уключаючы па 4-5 кадраў анімацыі
well0008.bmp	Утрымлівае пясок і незлічоныя варыянты кратэраў у пяску
well0009.bmp	Утрымлівае 'Doodads' з пяску - элементы, якія могуць быць размешчаны для дэкаратыўнага афармлення (або свядома як структура, напрыклад, сцены) на пяску
well0010.bmp	Утрымлівае па 48 пераходаў ад пяску да светлых і цёмных парод
well0011.bmp	Утрымлівае палярныя капы карты з цёмнымі парадамі як падмуркам
well0012.bmp	Утрымлівае палярныя капы карты з светлымі парадамі як падмуркам

Рэкамендуецца для дакладнага выканання не рэндарыць тайлы загадзя, каб іх кэшаваць, бо даныя для цыклу дзень/ноч яшчэ трэба апрацаваць - і будзе з'яўляцца вельмі шмат даных.

Тайлы - гэта графікі з глыбінёй колеру 8 біт на піксель з індэксаванай палітрай памерам 32x32 пікселя, якія размешчаны ў адзін рад. Аднак у такім тайлесце можа быць значна больш

Галоўны кантэйнер складаецца з 2 секцый: head і data.

Загаловак плітак

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	68	65	61	64	--	--	--	--	--	--	--	--	--	--	--	--	h	e	a	d	.	.	.	.	.	.	.	.	.	.	.	.
0x0010	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Даўжыня блока
0x0007	uint(8)	Сцягі
0x0008	uint(32)	Версія / Сцягі?	Тут можа існаваць указанне версіі фармату файла; у ўсіх мне вядомых файлах тут стаяў значэнне `0x02`
0x000c	uint(32)	Шырыня (Гарызантальная дазвол)	Указвае, наколькі шырокі файл малюнка (у пікселях). Для ўсіх калодзежаў з Outpost 2 тут варта чакаць значэнне `0x20` або `32`.
0x0010	uint(32)	Вышыня (Вертыкальная раздзяляльная здольнасць)	Указвае, наколькі высокая малюнка (у пікселях). Для ўсіх свідравін з Outpost 2 тут чакаецца значэнне `0x20` або `32`.
0x0014	uint(32)	Глыбіня колеру?	Значэнне гэтай велічыні невядома. Паколькі ў усіх правераных файлах яна мае значэнне `8`, магчыма, гэта указанне на глыбіню колеру.
0x0018	uint(32)	Глыбіня колеру 2?	Значэнне гэтай велічыні невядома. Магчыма, гэта 'мэтавая' глыбіня колеру.

Пасля гэтых звестак будзе прадстаўлена палетта ў стандартызаваным фармаце RIFF. Дакладную спецыфікацыю можна знайсці - паколькі палеткі таксама з'яўляюцца ў іншых месцах - на Палетках.

Дадзеныя пліткі

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	64	61	74	61	--	--	--	--	--	--	--	--	--	--	--	--	d	a	t	a	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Даўжыня блока
0x0007	uint(8)	Сцягі

Нарэшце, ідуць голыя піксельныя дадзеныя, злева зверху па радках да справа ўніз.
Значэнне дадзеных для графікаў, якія звычайна прадстаўлены як 8bpp-бітмэпвы, адпавядае індэксу колеру ў каляровай палітры.

Піксельныя дадзеныя пачынаюцца зверху злева і заканчваюцца ўнізе справа.

Гульнявая рухавічка малюе тайлы *імаверна* па запыце.
Гэта, між іншым, звязана з цыклам дня і ночы, які ведае 32 адцення асобных тайлаў. Пры гэтым, відавочна, адзначаецца, што ад значэння яркасці 'трошкі' аднімецца. Дакладныя значэнні пакуль не ўдалося ўстанавіць, я працую на аснове разлікаў

v *= (daylight / 48) + 0.25;

з выкарыстаннем HSV-даных пікселяў, дзе daylight — гэта значэнне ад 0 да 31, а v — значэнне ад 0 да 1. Таксама варта ўлічваць, што на мапе з кожнага боку існуе край з 16 тайлаў (які служыць для незразумелага спавнавання юнітаў).

Дадаткова, здаецца, што цыкл дня і ночы за адзін гульнявы цыкл абнаўляе толькі адну калонку мапы.
Паскораны цыкл дня і ночы выглядае так:

Візуалізацыя цыкла дня і ночы

ПРТ

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	43	50	41	4c	--	--	--	--	--	--	--	--	--	--	--	--	C	P	A	L	.	.	.	.	.	.	.	.	.	.	.	.

Зсув Тып даных Назва Тлумачэнне

0x0000 uint(32) Магічныя байты

0x0004

uint(24)

Даўжыня паддонаў

Указвае, у адрозненне ад звычайнага блочнага фармату, колькасць палает, якія можна знайсці ў гэтым файле - не даўжыню блока ў байтах.

0x0007

uint(8)

Сцягі

Магчыма, як звычайна, флагі.

Аднак мне не вядомыя ніякія флагі; паколькі ўсе вядомыя мне значэнні адпавядаюць 0x00, было б таксама патэнцыйна магчыма, што колькасць палет проста з'яўляецца uint(32).

Што менавіта абазначае PRT, мне невядома; магчыма, гэта 'Табліца палітраў і рэсурсаў' - бо гэта файл, які знаходзіцца як op2_art.prt у maps.vol, які адносіцца да такой табліцы, і гэта добра апісвае яго функцыю.

Гэты файл утрымлівае спіс палітраў, табліцу ўсіх выкарыстаных бітаў, усе вызначэнні анімацый і шэраг невядомых даных. Ён не строга прытрымліваецца папярэдняга фармату кантэйнера, бо не ўсе запісы адпавядаюць гэтай схеме.

Секцыя CPAL (імаверна, абазначае кантэйнер палітраў) ўключае толькі дадзеныя палітраў, указваючы, колькі звычайна ёсць 1052-байтных палітраў з 8 бітамі.

Паданне 1052 байтаў не з'яўляецца абавязковым, бо фармат палітраў патэнцыйна можа прадугледжваць розныя памеры палітраў. Яно дзейнічае толькі для даных, з якімі пастаўляецца Outpost 2.

Пасля спіса палітраў адразу і без уводнага загалоўка ідзе спіс бітаў; гэтак жа адразу ідуць спісы анімацый.
Абодва яны пачынаюцца з uint(32) (ці зноў uint24+uint8 флагаў?) які ўтрымлівае колькасць запісаў.

Палеткі

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	50	50	41	4c	--	--	--	--	--	--	--	--	--	--	--	--	P	P	A	L	.	.	.	.	.	.	.	.	.	.	.	.

Зсув Тып даных Назва Тлумачэнне

0x0000 uint(32) Магічныя байты

0x0004

uint(24)

Даўжыня паддонаў

Указвае, у адрозненне ад звычайнага блочнага фармату, колькасць палет, якія можна знайсці ў гэтым файле - не даўжыню блока ў байтах.

0x0007

uint(8)

Сцягі

Магчыма, як звычайна, флагі.

Аднак мне не вядомыя флагі; паколькі ўсе мне вядомыя значэнні адпавядаюць 0x00, таксама магчыма, што колькасць палет проста з'яўляецца uint(32).

Інфармацыя аб палачках вельмі лёгка ўспрымаецца.
Яна складаецца з загалоўка і сегмента даных.

Загаловак палак

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	68	65	61	64	--	--	--	--	--	--	--	--	--	--	--	--	h	e	a	d	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Даўжыня паддонаў	Указвае, у адрозненне ад звычайнага блочнага фармату, колькасць палет, якія можна знайсці ў гэтым файле - не даўжыню блока ў байтах.
0x0007	uint(8)	Сцягі	Магчыма, як звычайна, флагі. Аднак мне не вядомыя флагі; паколькі ўсе мне вядомыя значэнні адпавядаюць `0x00`, таксама магчыма, што колькасць палет проста з'яўляецца uint(32).
0x0008	uint(32)	Версія фармату палаціны?	Вызначае, верагодна, якая версія фармату палеткі выкарыстоўваецца для гэтай палеткі. Усе палеткі Outpost2, здаецца, маюць версію `0x01`.

Дадзеныя аб паддонах

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	64	61	74	61	--	--	--	--	--	--	--	--	--	--	--	--	d	a	t	a	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва
0x0000	uint(32)	Магічныя байты
0x0004	uint(24)	Даўжына блока
0x0007	uint(8)	Сцягі

Раздзел даных ўключае асобныя запісы палеці. Колькасць запісаў палеці вызначаецца з даўжыні блока / 4.

Асобныя запісы маюць наступную простую структуру;

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	--	--	--	04	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(8)	Чырвоны кампанент	Паказвае долю чырвонага колеру
0x0001	uint(8)	Зялёны кампанент	Указвае долю зялёнага колеру
0x0002	uint(8)	Сіні кампанент	Указвае долю сіняга колеру
0x0003	uint(8)	Невядомы - Сцяжкі?	Невядома, што азначае гэтае значэнне, бо яно, здавалася б, у асноўным `0x04`.

Што датычыцца палаў, то можна сказаць, што для палаў, якія выкарыстоўваюцца для анімацый, дзейнічаюць наступныя правілы:

Першы колер ЗАЎСЁДЫ з'яўляецца празрыстым, незалежна ад таго, які значэнне там указана.
Запісы палет 1-24 у палетах 1-8 варта разглядаць як колер гульца.
Адкуль менавіта паходзяць колеры, акрамя колеру гульца 1, мне не зразумела.
Я падазраю, што астатнія колеры закодаваны.

Рэферэнцыя палет

Бітмапы

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.
0x0010	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(32)	Выраўненая шырыня	Указвае шырыню піксельных дадзеных у байтах - бо яны выраўнаваны па 4-байтавых межах. Такім чынам, хутка можна пераскочыць на пэўны радок малюнка. Чаму гэтае значэнне захоўваецца асобна, хаця яго можна было б разлічыць, застаецца незразумелым. Магчыма, гэта аптымізацыя для кода рэндэрынгу.
0x0004	uint(32)	Зрушэнне	Указвае зрушэнне першай радка ў бітмапе
0x0008	uint(32)	Вышыня	Указвае вышыню малюнка ў пікселях
0x000c	uint(32)	Шырыня	Указвае шырыню выявы ў пікселях
0x0010	uint(16)	Тып	Указвае тып малюнка. Тут, відаць, ідзе гаворка пра бітмаску: `0x04` усталяваны, калі гэта графіка з 1bpp. `0x40` усталяваны, калі гэта графіка, якая павінна рэалізаваць акнаванне
0x0012	uint(16)	Палета	Вызначае, якая палада з файла PRT павінна выкарыстоўвацца

Гэтая структура даных файла PRT паказвае, як пабудаваны біты для спрайтоў. Гэтыя біты служаць адзіным кампанентам, з якіх некалькі складаюцца ў анімацыйны кадр спрайта.

Канкрэтныя малюнкавыя дадзеныя знаходзяцца ў op2_art.BMP у дырэкторыі гульні.
Чаму гэты файл бітымаў мае (пераважна правільны) загаловак RIFF-бітымы, неясна. Магчыма, Outpost 2 выкарыстоўвае сістэмныя API для загрузкі графікі, убіраючы гэты загаловак часова і перапісваючы адпаведныя, зменлівыя палі.

Піксельныя дадзеныя знаходзяцца ў BMP-файле на пазіцыі Offset + uint32-Offset, які можна знайсці ў BMP-файле па адрасе 0x000A (RIFF-бітымыя дадзеныя offset), і адпавядаюць зноў жа радковай арганізацыі з верхняга зліва на правы ніжні кут.

Монохромныя графікі 1bpp могуць быць намаляваны так, што колер 0 адпавядае поўнай празрычасці, а колер 1 являецца паўпразрыстым чорным/шэрым, паколькі монохромныя графікі звычайна выкарыстоўваюцца для ценяў транспартных сродкаў і будынкаў у анімацыях.

Такім чынам, можна ўжо складваць шмат графікаў.

Ахоўны жыллёвы модуль (Плімуць)

Анімацыі

Цяпер мы пераходзім да каралеўскага класа дысцыплінаў у рамках фарматаў даных Outpost 2:
Да анімацый.

Спісы анімацый пачынаюцца з глабальнага загалоўка, які служыць пераважна для праверкі даных. Затым ідуць канкрэтныя вызначэнні анімацый, якія падзяляюцца на 3 ўзроўні:

Анімацыя
Анімацыя — гэта вышэйшая інстанцыя; яна ўяўляе анімацыю адзінкі, будынка ці 'партульнай анімацыі' (удар каметы, надвор'е, выбух) у пэўным пачатковым стане.
Кадр
Кадр — гэта адзінкавы малюнак у рамках анімацыі. Анімацыя можа ўключаць адзін ці некалькі кадраў.
Падкадр
Падкадр — гэта інфармацыя пра тое, што пэўная bitmap павінна быць намалявана ў пэўнай пазіцыі кадра па пэўных крытэрах. Кадр можа ўключаць адзін ці некалькі падкадраў.

Затым ідуць ужо непасрэдна асобныя вызначэнні анімацый.

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(32)	Колькасць анімацый	Колькі анімацыйных запісаў існуе
0x0004	uint(32)	Колькасць кадраў	Колькі ўсяго кадраў павінна быць
0x0008	uint(32)	Колькасць падфреймаў	Колькі ўсяго падрамкаў павінна быць?
0x000c	uint(32)	Колькасць неабавязковых запісаў	Сколькі "допаможных запісаў" існуе.

Анімацыя

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.
0x0010	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.
0x0020	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(32)	Невядомы 1	Невядомая інфармацыя
0x0004	uint(32)	Межы: Улева	Указвае левы пачатак (у пікселях) Bounding Box.
0x0008	uint(32)	Абмежавальнае акно: Зверху	Указвае верхні пачатак (у пікселях) Bounding Box.
0x000c	uint(32)	Межавы скрыня: шырыня	Указвае шырыню (у пікселях) Bounding Box.
0x0010	uint(32)	Абмежавальнае акно: вышыня	Указвае вышыню (у пікселях) Bounding Box.
0x0014	uint(32)	Зрушэнне: X	Указвае гарызантальны цэнтр анімацыі
0x0018	uint(32)	Зрушэнне: Y	Указвае вертыкальны цэнтр анімацыі
0x001c	uint(32)	Невядомы 2	Невядомая інфармацыя
0x0020	uint(32)	Колькасць кадраў	Указвае, колькі анімацыйных кадраў утрымліваецца ў гэтай анімацыі
0x0024	uint(32)	Колькасць вокнаў	Указвае, колькі акон трэба выкарыстоўваць пры маляванні

Даныя верхняга пласта, анімацыі, з'яўляюцца ў асноўным адміністрацыйнымі данымі - Boundingbox абазначае каардынаты маркера вакол аўтамабіля/будынка, калі ён выбраны, і таксама ўказвае, які ўчастак павінен быць клікабельным.

Зрушэнне ў асноўным вызначае "нульавую кропку"; кропку, якая павінна быць дададзена ці аднята ад унутраных каардынатаў гульні. Можна сказаць і матэматычна: зрушэнне тут абазначае пачатак каардынат.

Акно ўяўляе сабой, гэтак жа як і зрушэнне, па 4 uint(32)-значэння для кожнага акна, якія ўказваюць на ўчастак, які лічыцца прымальным для асобных падрамкаў. За межамі акна не павінна малявацца, калі гэта не прадугледжана для біткарты.

Рама

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(8)	Колькасць падрамнікаў і пераключальнік для Опцыянальна 1, 2	Гэты значэнне ўключае: `0x7F` (Бітмасака): Колькасць падрамкаў, якія выкарыстоўваюцца ў гэтым кадры `0x80`: Інфармацыя аб тым, ці прысутнічаюць Опцыянальныя 1 і 2
0x0001	uint(8)	Невядомы 1 і пераключальнік для Дадатковых 3, 4	Гэты значэнне ўключае: `0x7F` (Бітмаска): Невядома - Я моцна падазраю, што гэта колькасць гульнявых тактаў, якія праходзяць, пакуль не адлюструецца наступны кадр `0x80`: Інфармацыя пра тое, ці ёсць Опцыянальныя 3 і 4
0x0002	uint(8)	Неабавязкова 1	Невядомы
0x0003	uint(8)	Наведвальны 2	Невядомы
0x0004	uint(8)	Дадатковы 3	Невядомы
0x0005	uint(8)	Дадатковы 4	Невядомы

Субрама

Адр	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF	симвалы
0x0000	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.

Зсув	Тып даных	Назва	Тлумачэнне
0x0000	uint(16)	Bitmap-Ід	Укажыце, якая бітмапа павінна быць выкарыстана для гэтага падфрейма
0x0002	uint(8)	Невядомы 1	Невядома - аднак я моцна падазраю, што гэта звязана з прыярытэтам рэндэра (Z-слой).
0x0003	uint(8)	Субрамка-Ід	Указвае, у якім падфрейме мы знаходзімся
0x0004	sint(16)	Змяшчэнне - Гарызантальнае	Указвае, дзе ўнутры фрейма павінна быць размешчана падфрейм, або на колькі пікселяў бітмапа павінна быць гарызантальна перамешчана.
0x0006	sint(16)	Змяшчэнне - Вертыкальнае	Указвае, дзе ўнутры кадра павінна быць размешчана падкадра, а таксама на колькі пікселяў павінна быць вертыкальна зрушана bitmap

Такім чынам, мы цяпер можам складаць асобныя фреймы, а таксама поўныя анімацыі, тут прыкладна на больш складанай анімацыі, анімацыі з індэксам 500, дэманструецца

Анімацыя 500

Анімацыя 500 паказвае, як Плімут-транспарцёры, загружаныя звычайным рудам, разгружаюцца. Гэта адна з нямногіх анімацый, якія ўжываюць функцыянальнасць акна.

Такім чынам, можна злучыць усю анімацыю.
На жаль, усё яшчэ існуе праблема з верхнім люкам, бо адпаведны біт у інфармацыі аб графічным тыпе не ўстаноўлены.

А вось яшчэ некалькі іншых, прыгожа анімаваных спрайтаў з гульні:

Рэндарынг анімацыі 500 ілюструе

Анімацыя 500 гатовая да злучэння

Будынак фабрыкі Плімута

Космічны порт Эдэн

Медыцынскі цэнтр Эдэн

SCAT

Космічны порт Плімута

Сакрэт:
Санта-Клаўс

Сакрэт:
Сабака Данса

Карыстальніцкі інтэрфейс

Цяпер яшчэ трэба ўсталяваць карыстацкі інтэрфейс гульні, які выкананы ў стылі шліфаванага металу.

Але і тут відавочна, што Dynamix не трэба было вынаходзіць кола наноў; тут не проста выкарыстоўваюцца функцыі, прадастаўленыя Windows у API User32 і GDI32 - асабліва выкарыстоўваецца таксама кіраванне рэсурсамі з User32.

Іх можна, напрыклад, экстрактаваць з дапамогай праграм, такіх як Resource Hacker, распрацаваная Angus Johnson як бясплатнае ПЗ, або - калі вы ў Linux / Mac OS і не жадаеце выкарыстоўваць Wine - з дапамогай wrestool, які ўваходзіць у icoutils.

Назва файла	Змесціва
Outpost2.exe	Садтрымлівае толькі значок гульні, які паказвае касмічную станцыю каля New Terra
op2shres.dll	Садтрымлівае графіку для элементаў кіравання, такіх як абводкі, кнопкі, радыёкнопкі і квадраты для выбару, а таксама фоны дыялогаў, суправаджальныя выявы для тэкстаў місій і галоўную графіку фону меню
out2res.dll	Садтрымлівае дэкор для акна ў гульні, значкі для звычайнага і спецыяльнага металу, экран загрузкі, графіку для дыялогаў, а таксама додатковыя графікі курсора, акрамя аніміраваных у тэчцы гульні