Outpost 2 Formati za Faili · bei.pm

Muundo wa data unaotumika na Outpost 2 una muundo unaokumbusha JFIF / PNG - vipande tofauti vya data kila wakati vina kichwa cha byte 8. Hivyo basi, sina haja ya kurekodi vichwa vya data kwenye maeneo mahsusi na ninaandika tu tofauti.

Muundo ni kila wakati ifuatavyo; data halisi za matumizi zimeingizwa ndani yake:

"Volumes" ni kontena za data kwa ajili ya mchezo, sawa na muundo wa archive kama vile Tarball. Angalau katika Outpost 2, muundo huu unajulikana tu na faili - hakuna folda. Iwezekana kwamba folda hizi zinaweza kuigwa kwa kutumia majina sahihi ya faili.

Volume inajumuisha kichwa cha Volume pamoja na vizuizi kadhaa vya Volume, ambavyo vinawakilisha faili halisi.

"Volumes" ni faili zenye kiendelezi 'vol' katika directory ya mchezo.

Header ya Volume haitoi data zozote za matumizi.
Inatumika tu kama chombo.

Tarehe ya kwanza katika Header ya Volume inapaswa kuwa Volume Strings; kisha kufuatia ni taarifa za Volume.

Volume Strings ni orodha ya majina ya faili yaliyomo ndani ya volume.

Taarifa za volumu zinachukua habari za kina kuhusu faili. Hii ni aina fulani ya kuingizwa katika orodha ya FAT (FAT = Jedwali la Mgawanyiko wa Faili)

Idadi ya faili inapata kutokana na ukubwa wa block ukigawanywa na urefu wa kuingizwa kwa orodha - 14 byte.

Kila kuingizwa kwa orodha kuna muundo ufuatao:

Volume-Block ni konteina inayohifadhi faili. Inajumuisha tena - kwa sababu ya muundo wa block - ukubwa wa faili kwa njia ya kupita, na kisha moja kwa moja zinafuatia data za matumizi.

Vyumba vinavyohusiana na Tiles ni muundo wa picha ya Bitmap maalum kwa Outpost-2. Vinapanuka juu ya Tilesets 13, vinavyojulikana kama "wells" (well0000.bmp hadi well0012.bmp), ambavyo viko ndani ya kiasi maps.vol.

Katika Tilesets / Wells kuna yafuatayo:

Inashauriwa kwa utekelezaji sahihi, kutoshiriki Tiles mapema ili zikae kwenye cache, kwani data za mzunguko wa mchana/usiku bado zinahitaji kusindika - na kutakuwa na data nyingi sana.

Tiles ni picha za 8bpp zenye palette iliyo na viwango vya rangi inayopangwa kwa 32x32 pixels, ambazo zimewekwa pamoja. Katika seti ya Tiles iliyoundwa kwa njia hii, inaweza kuwa na zaidi.

Container kuu ina sehemu 2: head na data.

Baada ya taarifa hizi, itafuata faili ya paleti iliyopo katika muundo wa RIFF wa kawaida. Maelezo kamili yanaweza kupatikana - kwa sababu paleti hizo pia zinapatikana mahali pengine - chini ya Rangi za paleti.

Mwisho, data za pikseli zimeandikwa kwa safu kutoka kushoto juu hadi kulia chini.
Thamani ya data katika picha ambazo kwa kawaida zinakuja kama bitmaps za 8bpp inalingana na kiashiria cha rangi katika pallet ya rangi.

Engine ya mchezo inachora Tiles *labda* kwa mahitaji.
Hii inaonekana kuwa na uhusiano na mzunguko wa siku na usiku, ambao una hatua 32 za Tiles tofauti. Inaonekana kwamba thamani ya mwangaza inakatwa 'kidogo' kwa kila mmoja. Thamani halisi bado hazijapata kubainishwa, nafanya kazi kwa msingi wa hesabu

v *= (daylight / 48) + 0.25;

kutumia data za HSV za pikseli, ambapo daylight ni thamani kati ya 0-31 na v ni thamani kati ya 0-1. Vilevile, inapaswa kuzingatiwa kwamba kwenye ramani kuna mipaka ya Tiles 16 upande wa kushoto na kulia (hii inatumiwa kwa kuzalisha vitengo ambavyo havionekani).

Ziada, mzunguko wa siku na usiku kwa kila mzunguko wa mchezo unasaidia kuboresha safu moja ya ramani tu.
Mzunguko wa siku na usiku unaoimarishwa unaonekana kama ifuatavyo:

Nisawa PRT inamaanisha nini hasa, siijui; inaweza kuwa mfano 'Jedwali la Palette na Rasilimali' - kwa sababu faili hii - inayopatikana kama op2_art.prt katika maps.vol - ni hivyo, au hii inaweza kuelezea kazi hiyo vizuri.

Faili hii ina orodha ya palettes, jedwali la bitmaps zote zinazotumiwa, maelezo ya kila animation, na pia safu ya data zisizojulikana. Inafuata muundo wa kawaida wa kontena kwa namna isiyo rasmi, kwani si kila rekodi inafuata mpangilio huu.

Sehemu ya CPAL (inaweza kuwa inamaanisha kontena la palettes) inashughulikia tu data za palettes, kwa kuonyesha ni ngapi kati ya palettes za 8-bit zenye ukubwa wa 1052 byte zipo.

Taarifa ya 1052-byte haitambuliki kama ya lazima, kwani muundo wa palettes unaweza kuwa na ukubwa tofauti. Inatumika tu kwa data ambayo Outpost 2 inatolewa nayo.

Baada ya orodha za palettes, inafuata mara moja bila kichwa cha utangulizi, orodha ya bitmaps; vivyo hivyo, orodha za animations zinafuata mara moja.
Zote zinazoanzishwa na uint(32) (au tena uint24 + uint8 bendera?) inayohesabu idadi ya rekodi.

Taarifa za paleti ni rahisi sana kusoma.
Zinajumuisha kichwa na sehemu ya data.

Sehemu ya data inachukua ingizo la kila pallets. Idadi ya ingizo la pallets inapatikana kutokana na urefu wa block / 4.

Ingizo kila moja ina muundo huu rahisi;

Kuhusu paleti, kuna kanuni zifuatazo ambazo zinatumika kwa paleti zinazotumika kwa michoro:

• rangi ya kwanza KILA WAKATI ni wazi, bila kujali thamani iliyowekwa hapo.
• Entries za paleti 1-24 zinachukuliwa kama rangi za mchezaji katika paleti 1-8.
  Sijui rangi zinatoka wapi isipokuwa mchezaji 1.
  Nadhani rangi zingine zimewekwa kwa njia ya hardcoded.

Muundo huu wa data wa faili ya PRT unaelezea jinsi bitmaps zinazotumika kwa sprites zilivyojengwa. Bitmaps hizi zinatumika kama sehemu moja, ambapo nyingi zinakusanywa kuwa fremu ya animasiyo ya sprite.

Taarifa halisi za picha zinapatikana katika op2_art.BMP kwenye directory ya mchezo.
Kwanini faili hii ya bitmap ina kichwa cha RIFF-bitmap ambacho ni (kimsingi sahihi), hakijulikani. Inawezekana Outpost 2 inatumia APIs za mfumo kupakia picha, kwa kuhamasisha kichwa hiki kwa muda na kubadilisha sehemu zinazofaa, zinazobadilika.

Data za pikseli zinapatikana katika faili ya BMP katika nafasi ya Offset + uint32-Offset, ambayo inaonekana katika faili ya BMP katika anwani 0x000A (offset ya data ya RIFF-bitmap), na zinawiana tena na mpangilio wa mistari kutoka juu kushoto hadi chini kulia.

Grafiki za monochrome 1bpp zinaweza kuchorwa kwa njia ambayo rangi 0 inawakilisha uwazi kamili, na rangi 1 ni nyeusi/hudhurungi ya nusu uwazi, kwani grafiki za monochrome kawaida hutumika kwa vivuli vya magari na majengo katika animations.

Hivyo mtu anaweza tayari kuunganisha grafiki nyingi.

Sasa tunafika kwenye kiwango cha juu zaidi cha nidhamu ndani ya format za data za Outpost 2:
Animasheni.

Orodha za animasheni zinaanzishwa na kichwa cha kimataifa, ambacho kinahudumu hasa kwa ajili ya uthibitishaji wa data. Baada ya hapo, zinafuatiwa na maelezo ya wazi ya animasheni, ambayo yanagawanywa katika hatua 3:

1. Animasheni
   Animasheni ni kiwango cha juu zaidi; inawakilisha animasheni ya kitengo, jengo au 'animasheni ya chembe' (mgongano wa kome, hali ya hewa, milipuko) katika hali fulani ya awali.
2. Frame
   Frame ni picha moja ndani ya animasheni. Animasheni inaweza kuwa na frame moja au zaidi.
3. Subframe
   Subframe ni taarifa inayoeleza kwamba bitmap fulani inapaswa kuchorwa kwenye nafasi maalum ya frame chini ya vigezo fulani. Frame inaweza kuwa na subframe moja au zaidi.

Mara baada ya hapo, zinakuja moja kwa moja maelezo ya kila animasheni.

Taarifa za safu ya juu, ya uhuishaji, hasa ni taarifa za usimamizi - Boundingbox inarejelea koordinati za alama inayozunguka gari/jengo, wakati inachaguliwa na pia inaonyesha eneo gani linaweza kubofyoshiwa.

Offset hasa huamua "nukta sifuri"; nukta ambayo inapaswa kuhesabiwa au kuondolewa kwenye koordinati za ndani ya mchezo. Inaweza pia kusemwa kwa kisayansi: offset hapa inamaanisha chanzo cha koordinati.

Kuhusu madirisha, kama ilivyo kwa offset, kuna kila moja (kwa kila dirisha) thamani 4 za uint(32), zinaonyesha eneo ambalo linaweza kutumiwa kwa subframes tofauti. Njia za nje ya madirisha hazitarajiwi, kama imepangwa kwa bitmap, kuchorwa.

Hivi sasa tunaweza kuunganisha frame moja moja, pamoja na animation kamili, hapa tunaonyesha mfano wa animation ngumu, animation yenye index 500.

Animation 500 inaonyesha jinsi ya kubeba na kutolewa kwa Plymouth-Transporter, ambao umejaa madini ya kawaida. Hii ni moja ya animation chache zinazotumia kazi ya Windowing.

Hivyo, animation kamili inaweza kuunganishwa.
Kwa bahati mbaya, bado kuna tatizo na mlango wa juu wa kuingilia, kwani hapa kipande husika katika taarifa ya aina ya grafiki hakijatumika.

Hapa kuna baadhi ya sprites nyingine nzuri sana zenye animation kutoka mchezo:

Sasa inabaki tu kuunda interface ya mtumiaji ya mchezo, ambayo imeandaliwa kwa muonekano wa metali iliyosafishwa.

Lakini pia hapa inaonekana kwamba Dynamix haikuhitaji kuunda tena mduara; hapa si tu kwamba inatumia APIs za User32 na GDI32 zinazotolewa na Windows - haswa pia inatumia usimamizi wa rasilimali kutoka User32.

Hizi zinaweza kutolewa kwa mfano kupitia programu kama ile iliyotengenezwa na Angus Johnson kama freeware Resource Hacker, au - ikiwa unakwepa kutumia Wine kwenye Linux / Mac OS - kwa msaada wa wrestool iliyojumuishwa kwenye icoutils.