Outpost 2 Mga Format ng File · bei.pm

Ang mga format ng data na ginagamit ng Outpost 2 ay may estruktura na kahawig ng JFIF / PNG - ang bawat data block ay palaging may 8 Byte header. Kaya't hindi ko na ito idodokumento ang bawat header sa mga kaukulang tiyak na lugar at idodokumento lamang ang mga pagkakaiba.

Ang format ay palaging ang sumusunod; ang mga aktwal na data na ginagamit ay nakapaloob dito:

Ang mga Volume ay isang lalagyan ng datos para sa laro, katulad ng isang format ng archive tulad ng Tarball. Sa Outpost 2, ang format na ito ay kumikilala lamang ng mga file - walang mga folder. Marahil ay maaring i-simulate ang mga ito sa pamamagitan ng mga naaangkop na pangalan ng file.

Ang isang Volume ay binubuo ng Volume-Header at ng maraming Volume Blocks, na tumutugma sa mga konkretong file.

"Volumes" ang mga file na may pagtatapos na 'vol' sa direktoryo ng laro.

Walang mga datos na maaaring gamitin ang Volume Header.
Ito ay nagsisilbing lalagyan lamang.

Ang unang datos sa Volume Header ay dapat na ang Volume Strings; kasunod nito ay ang mga impormasyon ng Volume.

Ang mga Volume Strings ay isang listahan ng mga pangalan ng file na kasama sa loob ng volume.

Ang mga impormasyon ng volume ay kumukuha ng mas detalyadong impormasyon tungkol sa mga file. Ito ay sa isang paraan na katulad ng isang uri ng FAT directory entry (FAT = File Allocation Table)

Ang bilang ng mga file ay nagmumula sa laki ng block na hinati sa haba ng mga directory entry - 14 Byte.

Ang bawat mga directory entry ay may sumusunod na estruktura:

Ang isang volume block ay isang lalagyan na tumatanggap ng mga file. Naglalaman ito ng muli - dahil sa format ng block - ng redundant na sukat ng file at kasunod nito ay direkta ang mga datos na ginagamit.

Ang mga Tiles ay isang tiyak na format ng Bitmap graphics para sa Outpost-2. Sumasaklaw ito sa 13 Tilesets, na tinatawag na "wells" (well0000.bmp hanggang well0012.bmp), na matatagpuan sa loob ng Volume maps.vol.

Ang mga Tilesets / Wells ay naglalaman ng mga sumusunod:

Makatuwid na hindi i-render ang mga Tiles nang maaga upang ma-cache ang mga ito, dahil ang mga datos para sa siklo ng araw/gabi ay kailangan pang iproseso - at napakaraming datos ang mabubuo.

Ang mga Tiles ay 8bpp na mga grapika na may indexed palette na may sukat na 32x32 pixel, na nakaayos nang magkakasunod. Sa isang ganitong Tileset, maaaring higit pang mga

Ang pangunahing lalagyan ay binubuo ng 2 seksyon: head at data.

Mula sa mga impormasyong ito, magkakaroon pa ng isang file ng paleta na nasa standardized na RIFF format. Ang eksaktong espesipikasyon ay matatagpuan - dahil ang mga palette ay lumilitaw din sa iba pang mga lugar - sa ilalim ng Mga palette.

Sa wakas, narito na ang mga purong datos ng pixel, mula sa kaliwang itaas na nakaayos ng linya patungo sa kanang ibaba.
Ang halaga ng datos sa mga larawang karaniwang nasa 8bpp-bitmaps ay tumutugma sa index ng kulay sa palette ng kulay.

Ang game engine ay malamang na nagda-download ng mga tiles *on-demand*.
Tila ito ay dahil sa siklo ng araw-gabi, na may 32 na antas ng mga indibidwal na tiles. Ayon sa mga impormasyon, tila may kaunting ibinabawas mula sa halaga ng liwanag. Hindi pa matukoy ang eksaktong mga halaga, nagtatrabaho ako sa batayan ng pagkalkula

v *= (daylight / 48) + 0.25;

gamit ang mga HSV na datos ng pixel, kung saan ang daylight ay isang halaga mula 0-31 at v ay isang halaga mula 0-1. Dapat ding isaalang-alang na sa mapa ay may hangganan na 16 na tiles sa kaliwa at kanan (na nagsisilbing hindi nakikitang paglitaw ng mga yunit).

Karagdagan pa, tila ang siklo ng araw-gabi ay nag-uupdate lamang ng isang column ng mapa sa bawat game cycle.
Ang pinabilis na siklo ng araw-gabi ay mukhang ganito:

Walang tiyak na kaalaman kung ano ang ibig sabihin ng PRT; maaaring tumukoy ito sa 'Palette and Resource Table' - dahil ang file na ito - na makikita bilang op2_art.prt sa maps.vol - ay isang ganitong uri, o kaya naman ay mahusay na nailalarawan ang function na ito.

Ang file na ito ay naglalaman ng isang listahan ng mga palette, isang talahanayan ng lahat ng ginamit na bitmap, lahat ng mga depinisyon ng animasyon at iba pang hindi kilalang data. Ito ay maluwag na sumusunod sa nakaraang format ng container, dahil hindi lahat ng record ay sumusunod sa schema na ito.

Ang CPAL na seksyon (malamang ay nangangahulugang Palette Container) ay sumasaklaw lamang sa mga data ng palette, sa pamamagitan ng pagtukoy kung gaano karaming karaniwang 1052 byte na 8-bit na palette ang naroroon.

Ang 1052-byte na pagtukoy ay hindi itinuturing na obligado, dahil ang format ng palette ay maaaring maglaman ng iba’t ibang laki ng palette. Ito ay nalalapat lamang sa data na kasama sa Outpost 2.

Matapos ang mga listahan ng palette, agad na sumusunod at walang paunang header, ang listahan ng mga bitmap; kasunod nito ay ang mga listahan ng animasyon.
Ang pareho ay sinisimulan ng isang uint(32) (o muling uint24+uint8 flags?) na naglalaman ng bilang ng mga record.

Ang impormasyon ng mga palette ay napakadaling basahin.
Ang mga ito ay binubuo ng isang header at isang data segment.

Ang seksyon ng datos ay naglalaman ng mga indibidwal na entry ng paleta. Ang bilang ng mga entry ng paleta ay nakabatay sa haba ng block / 4.

Ang bawat entry ay may simpleng estruktura na ganito;

Tungkol sa mga palette, maaari lamang sabihin na ang mga sumusunod na patakaran ay nalalapat sa mga palette na gagamitin para sa mga animation:

• Ang unang kulay ay PALAGING transparent, anuman ang halaga na nakalagay doon.
• Ang mga entry ng palette 1-24 ay itinuturing na kulay ng manlalaro sa mga palette 1-8.
  Hindi ko alam kung saan nagmumula ang mga kulay maliban sa Manlalaro 1.
  Suspek ko na ang natitirang mga kulay ay hardcoded

Ang estruktura ng datos ng PRT-file na ito ay nagpapakita kung paano nakaayos ang mga bitmap na ginagamit para sa mga sprites. Ang mga bitmap na ito ay nagsisilbing isang bahagi, kung saan ang marami sa mga ito ay pinagsama-sama upang bumuo ng isang animasyon na frame ng isang sprite.

Ang mga konkretong datos ng larawan ay nakatago sa op2_art.BMP sa direktoryo ng laro.
Kung bakit ang bitmap file na ito ay may isang (karaniwang tamang) RIFF-bitmap header ay hindi malinaw. Marahil ang Outpost 2 ay gumagamit ng mga system-API para sa pag-load ng mga graphics, sa pamamagitan ng pansamantalang pagkuha ng header na ito at pag-overwrite ng mga kaukulang, nag-iibang field.

Ang mga pixel data ay matatagpuan sa BMP file sa Posisyon na Offset + ang uint32-offset, na makikita sa BMP file sa address na 0x000A (RIFF-Bitmap data offset), at nauugnay muli sa line-by-line na pagkakaayos mula sa itaas-kaliwa papuntang kanan-pababa.

Ang monochrome 1bpp graphics ay maaaring iguhit sa paraang ang kulay 0 ay kumakatawan sa ganap na transparency, at ang kulay 1 ay isang semi-transparent na itim/gray, dahil ang mga monochrome graphics karaniwang ginagamit para sa mga anino ng sasakyan at gusali sa mga animasyon.

Sa ganitong paraan, maaari nang pagsamahin ang maraming graphics.

Narito na tayo sa pinakamataas na antas ng mga disiplina sa loob ng mga format ng datos ng Outpost 2:
Ang mga animasyon.

Ang mga listahan ng animasyon ay nagsisimula sa isang pandaigdigang header, na pangunahing nagsisilbing beripikasyon ng datos. Kasunod nito ang mga tiyak na depinisyon ng animasyon, na nahahati sa 3 antas:

1. Animasyon
   Ang isang animasyon ay ang pinakamataas na antas; ito ay kumakatawan sa isang animasyon ng isang yunit, isang gusali, o isang 'partikular na animasyon' (pagsabog ng kometa, panahon, pagsabog) sa isang tiyak na sitwasyon.
2. Frame
   Ang isang frame ay isang solong imahe sa loob ng isang animasyon. Ang isang animasyon ay maaaring maglaman ng isa o higit pang mga frame.
3. Subframe
   Ang isang subframe ay ang impormasyon na nagsasaad na ang isang tiyak na bitmap ay dapat iguhit sa isang tiyak na posisyon ng isang frame sa ilalim ng mga tiyak na pamantayan. Ang isang frame ay maaaring maglaman ng isa o higit pang mga subframe.

Pagkatapos nito, agad nang susunod ang mga indibidwal na depinisyon ng animasyon.

Ang mga datos ng pinakamataas na layer, ang animasyon, ay pangunahing mga datos ng pamamahala - ang Boundingbox ay tumutukoy sa mga koordinato ng marka sa paligid ng sasakyan/o gusali, kapag ito ay napili at sabay-sabay na nagsasaad kung aling bahagi ang maaaring i-click.

Ang offset ay pangunahing tumutukoy sa "zero point"; ang puntong dapat ilagay sa mga panloob na koordinato o ibawas mula rito. Maari rin itong sabihin sa mas matematikal na paraan: ang offset ay tumutukoy dito sa origin ng koordinato.

Ang mga bintana ay, katulad ng offset, binubuo ng 4 na uint(32) na halaga (para sa bawat bintana), na naglalarawan ng isang lugar na itinuturing na magagamit para sa mga indibidwal na subframe. Sa labas ng mga bintana, hangga't ito ay nakalaan para sa bitmap, hindi dapat magdrawing.

Dito maaari na nating pagsamahin ang mga indibidwal na frame, pati na rin ang mga kumpletong animasyon, ipinapakita dito bilang halimbawa sa isang mas kumplikadong animasyon, ang animasyon na may index na 500.

Ang Animation 500 ay nagpapakita kung paano ang isang Plymouth-Transporter, na puno ng karaniwang ore, ay na-unload. Ito ay isa sa mga kaunting animation na gumagamit ng windowing functionality.

At ganito maaaring i-disenyo ang buong animation.
Sa kasamaang palad, may problema pa rin sa itaas na loading hatch, dahil ang kinauukulang bit sa graphic type information ay hindi nakatakda.

Narito ang ilang iba pang magagandang animated sprites mula sa laro:

Nangangailangan pa ng User-Interface ng laro, na may brushed metal na hitsura.

Ngunit dito rin makikita na hindi na kailangang muling likhain ng Dynamix ang gulong; hindi lamang dito simpleng ginagamit ang User32 at GDI32 APIs na ibinibigay ng Windows - lalo na, ginagamit din ang pamamahala ng resources mula sa User32.

Maaari itong i-extract sa pamamagitan ng mga programa gaya ng Resource Hacker na binuo ni Angus Johnson bilang Freeware, o - kung ikaw ay nag-iingat sa paggamit ng Wine sa Linux / Mac OS - sa tulong ng wrestool na kasama sa icoutils.