Outpost 2 Dosierformat · bei.pm

Ĉi tiu teksto estis aŭtomate tradukita de OpenAI GPT-4o Mini.

La dosierformatoj priskribitaj en ĉi tiu paĝo baziĝas sur teknika analizo de intelektaj proprietoj de Dynamix, Inc. kaj Sierra Entertainment.
La intelekta propraĵo hodiaŭ estas parto de la masoj de Activision Publishing, Inc. / Activision Blizzard, Inc. kaj nuntempe estas posedaĵo de Microsoft Corp..

La informoj estis kolektitaj per Reversa Inĝenierado kaj Datoanalizo por la celo de arkivado kaj interoperacieco kun historiaj datumoj.
Ne estis uzataj proprietaj aŭ konfidencaj specifoj.

La ludo nuntempe disponeblas aĉeti kiel elŝuton ĉe gog.com.

Arto de la ludo

La sekva artikolo-serio dokumentas miajn konojn pri la datumformatado en la realtempa strategia ludo "Outpost 2: Divided Destiny", kiu estis publikigita de Sierra en 1997 kaj evoluigita de Dynamix.

Mi ĉefe okupiĝis pri la analizo de la datumoj de la ludo - kaj kion fari kun ili - inter la 1-a de novembro 2015 kaj la 14-a de novembro 2015.

La informoj, kiujn mi ĝis nun povis akiri, indikas, ke Dynamix - kiel multaj komercaj kompanioj - ne specialan datumformaton evoluigis nur por Outpost 2, sed ankaŭ uzis en aliaj evoluoj kiel ekzemple la Mechwarrior-serio (modifita).
Sendepende de tio, oni ankaŭ povas konstati, ke la novigkapablo de la datumformatado estas relative limigita kaj ofte baziĝas sur pli longvive konceptoj el kutimaj formatoj kiel JFIF kaj RIFF.

Por la interpreto de la tabeloj kaj datumformatado, pliaj informoj estas disponeblaj sub Kio estas kio?.
La ĉi tie indikitaj datumoj estas ĝenerale komprenataj kiel Little Endian.

Fine, oni povas diri, ke la inversa inĝenierado estis tre ĝoja, eĉ se ĝi ne estas kompleta.
Naturale, mi ankaŭ rekomendas ludi la ludon mem, ĉar ĝi ofertas interesajn ludmekanikojn.

Enkonduko

La datumformatoj uzataj de Outpost 2 havas strukturon similan al JFIF / PNG - la apartaj datumblokoj ĉiam havas 8-bitan kaplinion. Tial mi evitas dokumenti la apartajn kapliniojn en la konvenaj specifaj lokoj kaj nur dokumentas deviaciojn tie.

La formato ĉiam estas la sekva; la realaj uzdatenoj estas enkonstruitaj en ĝi:

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Bajtoj

Enhavas la informon pri tio, kion atendi en la sekva datumbloko.

Konataj valoroj:

  • 0x204C4F56 ('VOL '):
    Volumo
  • 0x686C6F76 ('VOLH'):
    Volum-ĉefkodo
  • 0x736C6F76 ('VOLS'):
    Volum-ĉenoj
  • 0x696C6F76 ('VOLI'):
    Volum-informoj
  • 0x4B4C4256 ('BLCK'):
    Volum-bloko
  • 0x504D4250 ('PBMP'):
    Grafikdatumoj
  • 0x4C415050 ('PPAL'):
    Kolorpaletro
  • 0x4C415043 ('CPAL'):
    Kolorpalet-konteksto
  • 0x64616568 ('head'):
    Ĉefkodo
  • 0x61746164 ('data'):
    Uzantdatumoj
0x0004 uint(24) Blok-longo

Enhavas la informon pri la grandeco (en Byte) de la sekva datumbloko.

Temas pri la puraj uzdatenoj - la 8 enhavaj Byte ne estas inkluzivitaj.

0x0007 uint(8) Flagoj?

Estas nekonate, por kio ĉi tiu bloko precize servas.

En la volumoj, ĉi tiu valoro ofte estas 0x80, en aliaj dosieroj ofte 0x00. Tio sugestas, ke temas pri aro de flagoj.

Volumoj

La volumoj estas datumkonteneroj por la ludo, simile al arkivformato kiel ekzemple Tarball. Almenaŭ en Outpost 2, la formato konas nur dosierojn - neniuj dosierujoj. Verŝajne, tamen, oni povus simuli ĉi tiujn per konvenaj dosiernomoj.

Volume konsistas el la volumenkapo kaj pluraj volumaj blokoj, kiuj respondas al la konkretaj dosieroj.

"Volumes" estas la dosieroj kun la finstrekado 'vol' en la luddirektorio.

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 56 4f 4c 20 -- -- -- -- -- -- -- -- -- -- -- -- V O L . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Byte'oj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj

Voluma Ĉapelo

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 76 6f 6c 68 -- -- -- -- -- -- -- -- -- -- -- -- v o l h . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Byte'oj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj

La Volume Header ne enhavas iujn uzajn datumojn.
Ĝi nur servas kiel kontenero.

Kiel la unua datumaro en la Volume Header, oni devus trovi la Volume Strings; sekvas tiam la Volume-informoj.

Volumaj Ŝnuroj

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 76 6f 6c 69 -- -- -- -- -- -- -- -- -- -- -- -- v o l i . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Byte'oj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj
Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 76 6f 6c 73 -- -- -- -- -- -- -- -- -- -- -- -- v o l s . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Byte'oj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj
0x0008 uint(32) Paga-longo

Indikas kiom da baitoj de la sekvaj datumoj fakte estas utilaj datumoj.

La ceteraj, restantaj datumoj de la volumstranga listo ŝajne estas konsiderataj kiel garbaĝo.

En dosieroj kun pli postaj dato, tiuj 'restantaj datumoj' estas 0x00, kio povus indiki mankojn en la ilaro dum la evoluo de la ludo, nome, ke nur tre malfrue zorgis programisto pri la ĝusta inicializado de la buferoj, ĉar ĝi ne influas la ludon, ĉu la datumoj estas inicializitaj aŭ ne.

0x000c uint(8)[] Dosiernomo-listo

Ĉi tio estas 0-byta terminita listo de dosiernombroj, kiu - almenaŭ en la nuna datumkomponento - nur atendas ASCII-karakterojn.

Ne estas necese pli detale analizi ĉi tiun datumblokadon dum la parseado de la datumoj, ĉar en la voluminformoj la ofsetoj de la dosiernombroj jam estas rekte referencitaj.

La Volumenaj Ŝnuroj estas listo de dosiernomoj, kiuj estas inkluzivitaj ene de la volumo.

Volumaj Informoj

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 76 6f 6c 69 -- -- -- -- -- -- -- -- -- -- -- -- v o l i . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Byte'oj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj

La volumaj informoj inkluzivas pli detalajn informojn pri la dosieroj. Ili estas, en certa maniero, speco de FAT-dosierujo-ero (FAT = File Allocation Table)

La nombro da dosieroj rezultas el la blokgrandeco dividita per la longo de la dosierujo-eroj - 14 bajtoj.

La individuaj dosierujo-eroj havas la sekvan strukturon:

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Dosiernoma-offset

Indikas je kiu ofseto (!) en la dosiernomo-listo (Volume-Strings) la dosiernomo de la dosiero troviĝas.

Temas pri la komenco de la uzdatos-bloko.

0x0004 uint(32) Dosieraĵa ofseto

Indikas en kiu ofseto ene de la tuta volum-dosiero la dosiero troviĝas.

0x0008 uint(32) Dosier-grandeco

Indikas, kiom granda estas la dosiero en bajtoj.

0x000c uint(16) Flagoj?

Ŝajne estas pliaj informoj pri la dosierkodado.

  • 0x03 estas agordita, se la dosiero estas komprimita. Ŝajnas, ke ĉi tie estas uzata Huffman-arbo.
  • 0x80 ŝajne ĉiam estas agordita.

Voluma Bloko

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 56 42 4c 48 -- -- -- -- -- -- -- -- -- -- -- -- V B L H . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Byte'oj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj

Volume-bloko estas kontenero, kiu enhavas dosierojn. Ĝi nur inkluzivas - pro la bloka formato - redundantan dosiergrandon, kaj poste sekvas rekte la uzdatenoj.

Teguloj

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 50 42 4d 50 -- -- -- -- -- -- -- -- -- -- -- -- P B M P . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Bitoj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj

La Tiles estas specifa bitmap-grafika formato por Outpost-2. Ili etendas super 13 tilesetoj, nomataj "wells" (well0000.bmp ĝis well0012.bmp), kiuj troviĝas ene de la volumeno maps.vol.

La tilesetoj / wells enhavas jenon:

Dosiernomo Enhavo
well0000.bmp Blua grafiko 32x32px granda - ideala por testi ĉu via bildo-ligilo funkcias
well0001.bmp Enhavas klaran rokon, montarsistemon sur clara roko kaj senfinajn variantojn de impaktkrateroj en clara roko
well0002.bmp Enhavas 'Doodads' de clara roko - do elementoj kiuj povas esti lokitaj por malstreĉiĝo (aŭ konscie kiel strukturo, ekzemple muretoj) sur clara roko, inkluzive vegetaĵon
well0003.bmp Enhavas krustecajn strukturojn sur clara roko
well0004.bmp Enhavas maldarkan rokon, montarsistemon sur maldarka roko kaj senfinajn variantojn de impaktkrateroj en maldarka roko
well0005.bmp Enhavas 'Doodads' de maldarka roko - do elementoj kiuj povas esti lokitaj por malstreĉiĝo (aŭ konscie kiel strukturo, ekzemple muretoj) sur maldarka roko
well0006.bmp Enhavas krustecajn strukturojn sur maldarka roko, same kiel transirojn inter clara kaj maldarka roko
well0007.bmp Enhavas lavon inkluzive 4-5 kadrojn de animacio pri ĝi
well0008.bmp Enhavas sablon kaj senfinajn variantojn de impaktkrateroj en sablo
well0009.bmp Enhavas 'Doodads' de sablo - do elementoj kiuj povas esti lokitaj por malstreĉiĝo (aŭ konscie kiel strukturo, ekzemple muretoj) sur sablo
well0010.bmp Enhavas po 48 transirojn de sablo al clara kaj maldarka roko
well0011.bmp Enhavas polusajn kapojn de la mapo, kun maldarka roko kiel subgrundo
well0012.bmp Enhavas polusajn kapojn de la mapo, kun clara roko kiel subgrundo

Estas konsilinde por preciza efektivigo ne antaŭe rendi la Tilingojn por ke ili estu kaŝmemoritaj, ĉar la datumoj por la tag-/nokta ciklo ankoraŭ devas esti procesitaj - kaj tre, tre multaj datumoj aperus.

La Tilingoj estas 8bpp-grafikoj kun indikita paletro de 32x32 pikseloj, kiuj estas aranĝitaj unu sub la alia. En tia formita Tilingaro tamen povas esti multe pli

La ĉefa enhavilo konsistas el 2 sekcioj: head kaj data.

Ĉapelo de Flankoj

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 68 65 61 64 -- -- -- -- -- -- -- -- -- -- -- -- h e a d . . . . . . . . . . . .
0x0010 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Bitoj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj
0x0008 uint(32) Versio / Flagoj?

Ĉi tio povus esti versio indiko de la dosierforma; en ĉiuj dosieroj, kiujn mi havas, la valoro estis 0x02

0x000c uint(32) Larĝo (Horizontala Resolucio)

Indikas, kiom larĝa estas la bilddosiero (en pikseloj).

Por ĉiuj putoj de Outpost 2, ĉi tie oni atendos la valoron 0x2032.

0x0010 uint(32) Altitudo (Vertikala Rezolucio)

Indikas kiom alta estas la bilddosiero (en pikseloj).

Por ĉiuj putoj en Outpost 2, oni atendos ĉi tiun valoron 0x2032.

0x0014 uint(32) Kolorprofundo?

La signifo de ĉi tiu valoro estas nekonata.

Ĉar ĝi enhavas la valoron 8 en ĉiuj kontrolitaj dosieroj, eble temas pri indikilo de kolordeptho.

0x0018 uint(32) Koloreco profundo 2?

La signifo de ĉi tiu valoro estas nekonata.

Eble temas pri 'celo'-kolordeptho.

Post tiuj informoj, ankoraŭ estos paletdosiero en la standardigita RIFF-formato. La preciza specifo troviĝas - ĉar la paletoj ankaŭ aperas aliloke - sub Paletoj.

Datumoj pri Keraĵoj

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 64 61 74 61 -- -- -- -- -- -- -- -- -- -- -- -- d a t a . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Bitoj
0x0004 uint(24) Blok-longo
0x0007 uint(8) Flagoj

Fine, jen la nudaj pixeldatumoj, de maldekstre supre en vicoj al dekstren malsupre.
La datumvaloro ĉe la grafikoj, kiuj plej ofte estas en 8bpp-bitmapoj, respondas al la indekso de la koloro en la kolorpaletro.

Pixeldatumoj komenciĝas supre maldekstre kaj finiĝas malsupre dekstre.

La ludmotoro verŝajne registras la tuilojn *sur postulo*.
Tio ŝajnas esti parte pro la tag-nokta ciklo, kiu havas 32 nuancojn de individuaj tuiloj. Ŝajne, la valoro de brileco estas reduktita 'iomete'. Precizaj valoroj ankoraŭ ne estis determinataj, mi laboras sur la kalkula bazo

v *= (daylight / 48) + 0.25;

kune kun la HSV-datoj de la pikseli, kie daylight estas valoro inter 0-31 kaj v estas valoro inter 0-1. Krome, estas grave konsideri, ke sur la mapo ekzistas flankoj de 16 tuiloj maldekstren kaj dekstren (tiu servas por la nevidiga apero de unuoj).

Krome, la tag-nokta ciklo ŝajnas ĝisdatigi nur unu kolumnon de la mapo por ĉiu ludciklo.
Accelerita tag-nokta ciklo do aspektas jene:

Vizualigo de la tag-nokta ciklo

PRT

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 43 50 41 4c -- -- -- -- -- -- -- -- -- -- -- -- C P A L . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Bytoj
0x0004 uint(24) Palet-longo

Indikas, male al la norma blokformato, la nombron de paletoj troviĝantaj en ĉi tiu dosiero - ne la longon de la bloko en bajtoj.

0x0007 uint(8) Flagoj

Probable, kiel kutime, Flagoj.

Tamen, mi ne konas ajn flagojn; ĉar ĉiuj konataj valoroj 0x00 egalas, eble eblas, ke la nombro de paletoj simple estu uint(32).

Kio precize signifas PRT ne estas konata por mi; eble eblas 'Paleta kaj Resurso Tablo' - ĉar ĉi tiu dosiero - trovita kiel op2_art.prt en la maps.vol - estas tia, aŭ ĉi tio sufiĉe bone priskribus ĝian funkcion.

Tiu dosiero enhavas liston de paletoj, tabelon pri ĉiuj uzataj bitmapoj, ĉiujn animaciajn difinojn kaj ankoraŭ kelkajn nekonatajn datumojn. Ĝi malpli streĉe sekvas la antaŭan kontenerformaton, ĉar ne ĉiuj datumoj sekvas tiun skemon.

La CPAL-sektoro (verŝajne signifas Paleta Kontenero) nur enhavas la paletajn datumojn, indikante kiom da 8-bitaj paletoj, kutime 1052 baitoj grandaj, estas disponeblaj.

La indiko de 1052 baitoj ne estas konsiderata deviga, ĉar la paleta formato eble antaŭvidas malsamajn paletgrandecojn. Ĝi validas nur por la datumaro, kun kiu Outpost 2 estas liverita.

Post la listoj de paletoj sekvas tuj sen enkonduka kapo, jam la listo de bitmapoj; same tuj sekvas la listoj de animacioj.
Ambaŭ estas iniciatitaj per uint(32) (aŭ denove uint24+uint8 flagoj?) kiu enhavas la nombron da datumoj.

Paletoj

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 50 50 41 4c -- -- -- -- -- -- -- -- -- -- -- -- P P A L . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Bytoj
0x0004 uint(24) Paleta longo

Indikas, kontraŭe al la norma blokformato, la nombron de paletoj trovataj en ĉi tiu dosiero - ne la longecon de la bloko en baitoj.

0x0007 uint(8) Flagoj

Verŝajne, kiel kutime, flagoj.

Tamen, mi ne konas ajnajn flagojn; ĉar ĉiuj valoroj, kiujn mi konas, respondas al 0x00, eble ankaŭ eblas, ke la nombro de paletoj simple estu uint(32).

La informoj pri paletoj estas tre facilaj por legi.
Ili konsistas el ĉefŝtupo kaj datum-segmento.

Paleta ĉapo

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 68 65 61 64 -- -- -- -- -- -- -- -- -- -- -- -- h e a d . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Bytoj
0x0004 uint(24) Paleta longo

Indikas, kontraŭe al la norma blokformato, la nombron de paletoj trovataj en ĉi tiu dosiero - ne la longecon de la bloko en baitoj.

0x0007 uint(8) Flagoj

Verŝajne, kiel kutime, flagoj.

Tamen, mi ne konas ajnajn flagojn; ĉar ĉiuj valoroj, kiujn mi konas, respondas al 0x00, eble ankaŭ eblas, ke la nombro de paletoj simple estu uint(32).

0x0008 uint(32) Paletforma versio?

Verŝajne difinas, kiun version de la paletformato sekvas la paleto.

Ĉiuj Outpost2-paletoj ŝajnas havi version 0x01.

Paletaj Datumoj

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 64 61 74 61 -- -- -- -- -- -- -- -- -- -- -- -- d a t a . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Magiaj Bytoj
0x0004 uint(24) Bloko-longo
0x0007 uint(8) Flagoj

La datosekcio inkluzivas la individuajn paletajn enirojn. La nombro da paletaj eniroj devenas el la bloklongo / 4.

La individuaj eniroj havas la sekvan, simplan strukturon;

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 -- -- -- 04 -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(8) Ruĝa komponento

Indikas la ruĝan parton de la koloro

0x0001 uint(8) Verda komponanto

Indikas la verdan proporcion de la koloro

0x0002 uint(8) Blua komponento

Indikas la bluan parton de la koloro

0x0003 uint(8) Maldanĝere - Flagoj?

Estas neklare, kion signifas ĉi tiu valoro, ĉar ĝi ŝajne estas fundamenta 0x04.

Pri la paletoj, oni nur povas diri, ke por la paletoj uzataj en animacioj, la jenaj reguloj validas:

  • La unua koloro ĉiam estas travidebla, sendepende de kio estas indikita tie.
  • La paletaj eniroj 1-24 estas konsiderataj kiel ludanto-koloroj en la paletoj 1-8.
    Kie la koloroj krom ludanto 1 precize venas, ne estas klare al mi.
    Mi supozas, ke la ceteraj koloroj estas hardkoditaj.

Palet-referenco

Bitmapoj

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0010 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Direktita larĝo

Indikas la larĝon de la pikselaj datumlinioj en bajtoj - ĉar ili estas ĝustigitaj al la 4-bajtaj limoj.

Tiel estas rapide eble salti al certa bildlinio.

Kial ĉi tiu valoro estas konservata aparte, kvankam ĝi povus esti kalkulita, ne estas klare.
Eble temas pri optimaligo por la rendera kodo.

0x0004 uint(32) Ofseto

Indikas la ofseton de la unua linio en la bitmapo

0x0008 uint(32) Altitudo

Donu la altecon de la bildo en pikseloj

0x000c uint(32) Larĝo

Indikas la larĝon de la bildo en pikseloj

0x0010 uint(16) Tipo

Indikas la tipon de la bildo. Ĉi tie ŝajnas, ke temas pri bitmasko:

  • 0x04 estas metita, se temas pri 1bpp-grafiko.
  • 0x40 estas metita, se temas pri grafiko, kiu devas realigi fenestran administradon.
0x0012 uint(16) Paleto

Difinas, kiu paletro el la PRT-failo devus esti uzata

Ĉi tiu datumstrukturo de la PRT-failo indikas, kiel la bitmapoj uzataj por la spritoj estas aranĝitaj. Ĉi tiuj bitmapoj funkcias kiel unuopa elemento, el kiu pluraj estas kunmetitaj al unu animacia kadro de sprito.

La konkretaj bilddatumoj kaŝiĝas en la op2_art.BMP en la ludkatalogo.
Kial ĉi tiu bitmapfajlo havas (plejparte ĝustan) RIFF-bitmapan kapon, estas neklara. Probable Outpost 2 uzas sistemajn APIojn por ŝarĝi la grafikojn, prenante ĉi tiun kapon provizore kaj superŝutante la koncernajn, variadajn kampojn.

La pikselaj datumoj troviĝas en la BMP-failo ĉe la pozicio Offset + la uint32-offset, kio troviĝas en la BMP-failo ĉe adreso 0x000A (RIFF-bitmap-datumofset), - kaj denove respondas al la linia aranĝo de supre maldekstre al malsupre dekstre.

Monohromaj 1bpp-grafikoj povas esti desegnitaj tiel, ke koloro 0 estas plena travidebleco, kaj koloro 1 estas duone travidebla nigra/griza, ĉar la monohromaj grafikoj ĝenerale estas uzataj por ombroj de veturiloj kaj konstruaĵoj en la animacioj.

Per tio eblas jam kunmeti multajn grafikojn.

Sekura loĝmodulo (Plymouth)

Animacioj

Now venas al la reĝa klaso de la disciplinoj ene de la Outpost 2 datumformatoj:
La animacioj.

La animaciaj listoj komenciĝas per ĝenerala kaplinio, kiu ĉefe servas por datumverifiko. Tiam sekvas la konkreta animaciaj difinoj, kiuj estas dividitaj en 3 niveloj:

  1. Animacio
    Animacio estas la ĉefa instanco; ĝi reprezentas animacion de unuopo, konstruaĵo aŭ 'partikla animacio' (kometfrapo, vetero, eksplodo) en certa startpozicio.
  2. Kadro
    Kadro estas unuopa bildo ene de animacio. Animacio povas enhavi unu aŭ pli da kadroj.
  3. Subkadro
    Subkadro estas la informo pri tio, ke certa bitmapo sub certaj kriterioj devus esti desegnita al certa pozicio de kadro. Kadro povas enhavi unu aŭ pli da subkadroj.

Poste sekvas la individuaj animaciaj difinoj.

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Kvanto de animacioj

Kiom da animaciaj datumoj ekzistas

0x0004 uint(32) Nombro de kadroj

Kiom da kadroj ĝenerale devus esti haveblaj

0x0008 uint(32) Nombro de subkadroj

Kiom da subkadroj entute devus esti

0x000c uint(32) Kvanto de opciaj eniroj

Kiom da "opcioj" estas disponeblaj.

Animacio

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0010 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0020 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(32) Nekonata 1

Nekonataj informoj

0x0004 uint(32) Limiganta Kesto: Maldekstre

Indikas la maldekstran komencon (en pikseloj) de la Bounding Box.

0x0008 uint(32) Limiga Kesto: Supre

Indikas la suprean komencan punkton (en pikseloj) de la Bounding Box.

0x000c uint(32) Limigkesto: Larĝo

Indikas la larĝon (en pikseloj) de la Bounding Box.

0x0010 uint(32) Limiga Kesto: Alto

Indikas la altecon (en pikseloj) de la Bounding Box.

0x0014 uint(32) Ofseto: X

Indikas la horizontalan mezo de la animacio

0x0018 uint(32) Ofseto: Y

Indikas la vertikalan mezan punkton de la animacio

0x001c uint(32) Nekonata 2

Ne konata informo

0x0020 uint(32) Nombro de kadroj

Indikas kiom da animaciaj kadroj estas en ĉi tiu animacio

0x0024 uint(32) Nombro de fenestroj

Indikas kiom da fenestroj oni devas uzi dum desegnado

La datumoj de la plej alta tavolo, la animacio, estas ĉefe administraj datumoj - la Boundingbox indikas la koordinatojn de la markado ĉirkaŭ la veturilo/konstruaĵo, kiam ĝi estas elektita kaj samtempe indikas, kiu areo devas esti klikebla.

La ofseto ĉefe difinas la "nulpunkton"; la punkton, kiu devas esti aldonita aŭ subtrahita al la internaj koordinatoj de la ludo. Oni ankaŭ povus diri matematike: la ofseto ĉi tie indikas la originon de la koordinatoj.

La fenestroj estas, same kiel la ofseto, ĉiu (por fenestro) 4 uint(32)-valoroj, kiuj indikas areon, kiu konsideriĝas uzebla por apartaj subkadroj. Ekster la fenestroj ne rajtas esti desegnita, se ne estas antaŭvidita por la bitmap.

Framo

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(8) Subfrekvenca nombro kaj Toglo por Opcio 1, 2

Ĉi tiu valoro enhavas:

  • 0x7F (Bitmasko): La nombro da subkadroj, kiuj estas uzataj en ĉi tiu kadro
  • 0x80: La informo pri ĉu Opcio 1 kaj 2 estas disponeblaj
0x0001 uint(8) Unknown 1 kaj Toggle por Opcie 3, 4

Ĉi tiu valoro enhavas:

  • 0x7F (Bitmasko): Nekonata - Mi forte supozas, ke tio ĉi rilatas al la nombro da gametick'oj, kiuj pasas ĝis la sekva kadro estas montrata
  • 0x80: La informo pri ĉu Opcional 3 kaj 4 estas ĉeestantaj
0x0002 uint(8) Opcie 1

Necerta

0x0003 uint(8) Opcie 2

Necerta

0x0004 uint(8) Opcie 3

Necerta

0x0005 uint(8) Optional 4

Necerta

Subkadro

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF karakteroj
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
Ofseto Datentipo Nomumo Ekspliko
0x0000 uint(16) Bitmap-ID

Indikas kiu bitmapo devus esti uzata por ĉi tiu subfeno

0x0002 uint(8) Nekonata 1

Estas nekonata - tamen mi forte supozas, ke ĉi tie temas pri render-prioritato (Z-Layer).

0x0003 uint(8) Subkadro-ID

Indikas en kiu subframo ni situas

0x0004 sint(16) Ofseto - Horizontala

Indikas kie ene de la kadro la subkadro devus esti metita, aŭ kiom da pikseloj la bildo devus esti horizontale ŝovita.

0x0006 sint(16) Offset - Vertikala

Indikas kie ene de la kadro la subkadro devus esti lokita, aŭ kiom da pikseloj la bildo devus esti vertikale ŝovita

Per tio ni povas nun kunmeti unuopajn kadrojn, same kiel kompletajn animaciojn, jen ekzemplore en pli kompleksa animacio, la animacio kun la indekso 500, montrita.

Animacio 500

Animacio 500 montras, kiel Plymouth-transportilo, kiu estas ŝarĝita per ordinara mineraloj, estas malŝarĝita. Tio estas unu el la malmultaj animacioj, kiuj uzas la fenestran funkciecon.

Kaj tiel la tuta animacio povas esti kunmetita.
Bedaurinde, ankoraŭ estas problemo kun la supera ŝarĝpordo, ĉar tie la koncerna bito en la grafika tipo-informo ne estas metita.

Jen kelkaj aliaj belanimitaj spritoj el la ludo:

Rendering de Animacio 500 ilustras

Animacio 500 finfine kunmetita

Plymouth Konstruejo-Fabriko

Eden Kosmodrome

Eden Medicina Centro

SCAT

Plymouth Kosmodrome

Easteregg:
Kristnaskapo

Easteregg:
Dans Hundo

Uzantinterfaco

Nun mankas la uzanto-interfaco de la ludo, kiu estas prezentita en bruligita metalo-aspekto.

Tamen ankaŭ ĉi tie estas klare, ke Dynamix ne devis reinvenći la ruĝan rotacion; ĉi tie ne nur simple estas uzataj la uzantaj 32- kaj GDI32-APIoj provizitaj de Windows - aparte ankaŭ estas uzata la rimedadministrado de User32.

Ĉi tiuj povas esti eltirataj per programoj kiel la Resource Hacker, kiu estas evoluigita de Angus Johnson kiel freeware, aŭ - se oni hezitas uzi Wine sub Linux / Mac OS - per la wrestool inkluzivita en icoutils.

Dosiernomo Enhavo
Outpost2.exe Enhavas nur la ikonon de la ludo, kiu montras la kosmostacion antaŭ New Terra
op2shres.dll Enhavas krom grafikojn por kontroliloj kiel ŝaltiloj, butonoj, radio-butono kaj kontrolkestoj ankaŭ dialogfondo, akompana bildo por la rakontmisio-tekstoj kaj la fono de la ĉefmenuo
out2res.dll Enhavas la in-game fenestra dekoracio, ikonojn por ordinara kaj speciala metalo, la ŝarga ekrano, grafikojn por dialogoj kaj aliajn kursorgrafikojn, krom la animaciaj en la ludkatalogo