Outpost 2 Dosierformat · bei.pm
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.
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:
|
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.
|
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 |
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 |
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 |
0x0014 | uint(32) | Kolorprofundo? | La signifo de ĉi tiu valoro estas nekonata. Ĉar ĝi enhavas la valoron |
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.
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:
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 |
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 |
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 |
0x0008 | uint(32) | Paletforma versio? | Verŝajne difinas, kiun version de la paletformato sekvas la paleto. Ĉiuj Outpost2-paletoj ŝajnas havi version |
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 |
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.
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. |
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:
|
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.
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:
-
Animacio
Animacio estas la ĉefa instanco; ĝi reprezentas animacion de unuopo, konstruaĵo aŭ 'partikla animacio' (kometfrapo, vetero, eksplodo) en certa startpozicio. -
Kadro
Kadro estas unuopa bildo ene de animacio. Animacio povas enhavi unu aŭ pli da kadroj. -
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:
|
0x0001 | uint(8) | Unknown 1 kaj Toggle por Opcie 3, 4 | Ĉi tiu valoro enhavas:
|
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:
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 |