Outpost 2 د فایل فارمیټونه · bei.pm

دا متن په اتومات ډول د OpenAI GPT-4o Mini لخوا ژباړل شوی دی

پدې صفحه کې توضيح شوي د فایل فارمیټونه د Dynamix, Inc. او Sierra Entertainment د ذهني ملکیت تخنیکي تحلیل پراساس دي.
ذهني ملکیت اوس د Activision Publishing, Inc.- / Activision Blizzard, Inc. د مجموعې برخه ده او اوس د Microsoft Corp. په مالکیت کې دی.

معلومات د Reverse Engineering او Datenanalyse له لارې د ارشیف کولو او د تاریخې معلوماتو سره د تعامل لپاره راټول شوي دي.
هیڅ ځانګړي یا محرمانه مشخصات نه دي کارول شوي.

بازی اوس مهال په gog.com کې د ډاونلوډ په توګه د اخیستلو لپاره موجود دی.

د لوبې هنر

دا مقاله لړۍ زما د "Outpost 2: Divided Destiny" په اړه د معلوماتو فارمیټونو په اړه زما پوهه مستندوي، چې په 1997 کال کې د Sierra لخوا خپره شوه او د Dynamix لخوا انکشاف شوې.

ما د 2015 کال د نومبر له ۱ څخه تر ۱۴ نومبر پورې د لوبې د معلوماتو تحلیل کولو سره زیات وخت تېر کړی.

د هغو معلوماتو له مخې چې ما تر اوسه ترلاسه کړي، Dynamix - لکه څومره تجارتي شرکتونه - ځینې معلوماتي فارمیټونه په ځانګړي ډول د Outpost 2 لپاره نه دي جوړ کړي، بلکې په نورو انکشافاتو کې لکه د Mechwarrior لړۍ (بدل شوي) هم کارول شوي.
بغیر له دې، دا هم څرګندېږي چې د معلوماتي فارمیټونو نوښت ځواک په حقیقت کې محدود دی او اکثراً د معمول فارمیټونو لکه JFIF او RIFF په اوږدمهاله مفاهیمو ولاړ دی.

د جدولونو او معلوماتي فارمیټونو د تفسیر لپاره نور معلومات دلته موندل کیږي څه دی څه؟.
دلته ورکړل شوي معلومات عموماً د Little Endian په توګه باید وپېژندل شي.

په پای کې، دا ویل کیدی شي چې د ریورس انجینرینګ خورا خوندور و، که څه هم دا بشپړ نه دی.
یقیناً زه هم یوازې سپارښتنه کولی شم چې خپله لوبه وکړئ، ځکه چې دا د زړه پورې لوبې میکانیکونه وړاندې کوي.

پیژندنه

د اوټپوست ۲ لخوا کارول شوي د معلوماتو فورمې د JFIF / PNG په څېر جوړښت لري - هر یوه د معلوماتو بلاک تل ۸ بایټ هيډر لري. نو زه د دې لپاره وخت نه ضایع کوم چې د هر یوه هيډر په ځانګړو ځایونو کې مستند کړم او هلته یوازې انحرافات مستند کوم.

فورمې تل همدا لاندې دي؛ اصلي کارونکي معلومات بیا پکې شامل دي:

ادریس x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF کریکټر
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
اُفست د معلوماتو ډول نوم تشریح
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 دی. دا دې ته اشاره کوي چې دا ممکن د یو فلیګ سیټ وي.

حجمونه

په حجمونو کې د لوبې لپاره د معلوماتو یوه کانتینر دی، چې د آرشیف فورمټ په څیر دی لکه د ټاربال. تر لږه په اوټپوست ۲ کې دا فورمټ یوازې فایلونه پیژني - هیڅ فولډر نه لري. ممکن دا په مناسب فایل نومونو سره شبیه شي.

یو حجم د حجم سرلیک او څو حجم بلاکونه لري چې د ځانګړو فایلونو سره سمون لري.

"حجمونه" هغه فایلونه دي چې د '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) د پیلوډ اوږدوالی

دا ښیي چې د لاندې معلوماتو څخه څو بایټونه واقعاً ګټه اخیستونکي معلومات دي.

د حجم-سټرینګ لیست پاتې نور معلومات په څرګنده توګه باید د غوړیدو په توګه وڅیړل شي.

په هغو فایلونو کې چې نیټه یې وروسته ده، دا 'پاتې معلومات' 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 = د فایل تخصیص جدول)

د فایلونو شمیر د بلاک اندازه د فهرست داخلو اوږدوالی - ۱۴ بایټ سره ویشلو له لارې ترلاسه کیږي.

د هر فهرست داخله په لاندې جوړښت کې وي:

ادریس 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(16) جھنډې؟

ظاهراً د فایل کوډینګ په اړه اضافي معلومات وړاندې کوي.

  • 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) جھنډې

د حجم بلاک یوه کانتینر ده، چې فایلونه پکې شامل دي. دا یوازې یو ځل بیا - د بلاک د شکل له امله - د فایل اندازه تکراروي او بیا مستقیمې کارونې ډاډې ته ځي.

ټایلېز

ادریس 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 ګرافیک فارمیټ دی. دا ۱۳ ټایل سیټونو کې پراخېږي، چې "ویلونه" نومېږي (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 د نقشه قطبي خولۍ لري، د روښانه ډبرو په توګه د بنسټ په توګه

دا د دقیقې پلي کېدو لپاره مشوره ورکول کیږي چې ټایلونه مخکې له مخکې نه رینډر شي ترڅو دا کیش شي، ځکه چې د ورځې/شپې دوره لپاره معلومات لا هم پروسس کول اړین دي - او ډیر ډیر معلومات به جمع شي.

ټایلونه 8bpp ګرافیکونه دي چې د 32x32 پکسل resolutio په هره برخه کې د انډيکس شوي پلېټ سره ترتیب شوي دي، چې د یو بل سره ترتیب شوي دي. په داسې جوړ شوي ټایل سیټ کې بیا هم ډیر زیات

اصلي کانتینر د 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 ټولو Wells کې دلته به ارزښت 0x20 یا 32 تمه کېږي.

0x0010 uint(32) اړخ (عمودي حل)

دلته ښيي چې د انځور فایل لوړوالی څومره دی (په پیکسل کې).

د اوت پوست ۲ ټولو چاهونو لپاره دلته به ارزښت 0x20 یا 32 تمه وشي.

0x0014 uint(32) رنګ ژوروالی؟

د دې ارزښت معنی نه پوهیږو.

لکه څنګه چې دا په ټولو معاینه شوو فایلونو کې د 8 ارزښت لري، دا کیدای شي د رنګ ژوروالي اشاره وي.

0x0018 uint(32) رنګ ژوروالی ۲؟

د دې ارزښت اهمیت نامعلوم دی.

ممکن دا د 'هدف' رنګ ژوروالی وي.

د دې معلوماتو وروسته یوه په معیاري 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-Bitmaps په بڼه وي، د رنګ په رنګ پالټ کې د رنګ شاخص سره برابر دی.

پیکسل ډاډې له پورته کیڼ څخه پیل کیږي او په لاندې ښۍ کې پای ته رسي.

د لوبې انجن د ټایلونو رسمول *احتمالاً* د غوښتنې پراساس کوي.
دا د ورځې او شپې دورې سره تړاو لري، چې ۳۲ درجې د جلا ټایلونو لري. په دې کې، ښکاري چې د رڼا ارزښت نه 'یو څه' کم شوی دی. دقیق ارزښتونه لا تر اوسه نه دي موندل شوي، زه د محاسبې په بنسټ کار کوم

v *= (daylight / 48) + 0.25;

د پکسلونو د HSV معلوماتو سره، چیرته چې daylight د 0-31 ترمنځ یوه ارزښت دی او v د 0-1 ترمنځ یوه ارزښت دی. سربیره پردې، باید په یاد ولرئ چې په نقشې کې هر اړخ ته ۱۶ ټایلونه لا هم شتون لري (دا د واحدونو د نه لیدونکو رامنځته کولو لپاره دی).

سربیره پردې، ښکاري چې د ورځې او شپې دوره هر لوبه دورې کې یوازې د نقشې یوه ستونه تازه کوي.
د ګړندۍ شوې ورځې او شپې دوره داسې ښکاري:

د ورځې او شپې دورې بصری کول

PRT

ادریس 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 لپاره دقیقاً څه معنی لري، زه نه پوهیږم؛ ممکنه ده چې دا د مثال په توګه 'Palette and Ressource Table' وي - ځکه چې دا فایل، چې د op2_art.prt په نوم په maps.vol کې موندل کیږي، د دې ډول دی، یا دا د دې فعالیت ښه توضیح ورکوي.

این فایل یوه لیست لري د پالتو، یوه جدول د ټولو کارول شویو بټ مپونو، د ټولو انیمیشن تعریفونو او همدارنګه د نامعلومو معلوماتو څو شمېرې. دا د تیر کانتینر فورمټ سره په آزاد ډول پیروي کوي، ځکه چې ټول معلومات په دې سکیم کې نه دي.

د CPAL برخه (احتمالاً د پالتو کانتینر لپاره) یوازې د پالتو معلوماتو محاصره کوي، په دې سره چې کومي معمولاً ۱۰۵۲ بایته لویه ۸-بیت پالتې شتون لري، څرګندوي.

د ۱۰۵۲ بایته اندازه د الزامي په توګه نه شمیرل کیږي، ځکه چې د پالتو فورمات ممکن مختلف پالتو اندازه ونه لري. دا یوازې د هغو معلوماتو لپاره ده چې د اوټپوسټ ۲ سره توزیع کیږي.

د پالتو لیستونو وروسته، سمدستي او پرته له کوم مقدماتي سرلیک، د بټ مپونو لیست راځي؛ همدارنګه سمدستي د انیمیشن لیستونه راځي.
هر یو د 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) راښکاره شوی عرض

د پکسل ډاډو د کرښو پلنوالی په بایټ کې ښیي - ځکه چې دا د ۴-بایټ سرحدونو سره تنظیم شوي دي.

نو، دا په چټکۍ سره ممکنه ده چې یوه ځانګړې د انځور کرښه ته لاړ شئ.

دا چې ولې دغه ارزښت جلا ذخیره کیږي، سره له دې چې محاسبه کېدی شي، روښانه نه ده.
شاید دا د رینډر کوډ لپاره یوه اصلاح وي.

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 کاروي، چې په کې دا سرلیک موقتي ډول اخیستل کیږي او اړوند، مختلفې برخې بیا لیکل کیږي.

د بټ میپ فایل کې د پکسل معلومات په Offset + uint32-Offset کې موندل کیږي، چې په بټ میپ فایل کې په پتې 0x000A کې موندل کیږي (RIFF بټ میپ د معلوماتو Offset)، او بیا هم د چپ څخه ښي لوري ته د پورته څخه ښکته د ترتیب سره سمون لري.

مونوکروم 1bpp ګرافیکونه په دې ډول رسم کیدی شي، چې رنګ 0 بشپړ شفافیت او رنګ 1 نیم شفاف تور/خاکستري دی، ځکه چې مونوکروم ګرافیکونه عموماً د انیمیشنونو کې د موټر او ودانیو سیوري لپاره کارول کیږي.

نو تاسو کولی شئ چې ډیرې ګرافیکونه سره یوځای کړئ.

محفوظ شوی استوګنځی (Plymouth)

انیمیشنونه

اوس موږ د Outpost 2 د معلوماتو د فارمیټونو په دننه کې د ځانګړو انیمیشنونو پیاوړي کچې ته راځي:
د انیمیشنونو.

د انیمیشن لیستونه د یوه نړیوال سرلیک سره پیل کیږي، چې په عمده توګه د معلوماتو تصدیق لپاره کارول کیږي. بیا د انیمیشن ځانګړي تعریفونه راځي، چې په ۳ مرحلو ویشل شوي:

  1. انیمیشن
    یو انیمیشن د لوړې کچې مثال دی؛ دا د یوه واحد، یوه ودانۍ یا د 'ذراتو انیمیشن' (د کمیتونو ټکر، هوا، چاودنه) په یوه مشخص حالت کې انیمیشن وړاندې کوي.
  2. فریم
    یو فریم د انیمیشن په دننه کې یو انځور دی. یوه انیمیشن یوه یا څو فریمونه لري.
  3. سب فریم
    یو سب فریم هغه معلومات دي چې ښیي یوه ځانګړې بټ مپ باید د ځانګړو معیارونو لاندې په فریم کې یوې ځانګړې نقطې ته رسم شي. یو فریم یوه یا څو سب فریمونه لري.

بیا مستقیم د انیمیشن ځانګړي تعریفونه راځي.

ادریس 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) نامعلوم ۱

نامعلوم معلومات

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) نامعلوم ۲

نامعلوم معلومات

0x0020 uint(32) د فریمونو شمېر

ښیي چې په دې انیمیشن کې څو انیمیشن فریمونه شامل دي

0x0024 uint(32) د وینډوز شمېر

څومره کړکۍ د رسم کولو پر مهال کارول کیږي، وښایاست

د انیمیشن د لوړ پوړي طبقې معلومات عمدتاً د مدیریت معلومات دي - Boundingbox د وسیلې/عمارت د نښه کولو همغږي ښیي، کله چې دا انتخاب شي او همدارنګه ښیي چې کومه سیمه باید کلک شي.

آفسیټ عمدتاً "صفر ټکی" ټاکي؛ هغه ټکی چې باید د لوبې دننه همغږیو ته اضافه یا کم شي. یوه ریاضي اصطلاح په توګه، آفسیټ دلته د همغږۍ اصل ښیي.

د وینډوز په اړه، لکه څنګه چې د آفسیټ په اړه، هره وینډوز ۴ uint(32) ارزښتونه لري، چې یوه سیمه مشخصوي چې د انفرادي سب فریمونو لپاره کارول کیږي. د وینډوز بهر، که چیرې دا د bitmap لپاره مناسب وي، رسم کول اجازه نه لري.

فریم

ادریس x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF کریکټر
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
اُفست د معلوماتو ډول نوم تشریح
0x0000 uint(8) سبفریم شمېر او د اختیاري ۱، ۲ لپاره ټوګل

دا ارزښت په کې شامل دی:

  • 0x7F (بیت ماسک): د سب فریمونو شمیر چې په دې فریم کې کارول کیږي
  • 0x80: د دې معلومات چې آیا اختیاري 1 او 2 شتون لري
0x0001 uint(8) نامعلوم ۱ او د اختیاري ۳، ۴ لپاره ټوګل

دا ارزښت پکې شامل دی:

  • 0x7F (بیت ماسک): نا معلوم - زه په قوي توګه ګمان لرم چې دا د ګیم ټيکس شمېر دی چې تېرېږي تر څو بل فریم وښودل شي
  • 0x80: د دې په اړه معلومات چې آیا اختیاري ۳ او ۴ شتون لري
0x0002 uint(8) اختیاري ۱

نامعلوم

0x0003 uint(8) اختیاري ۲

نامعلوم

0x0004 uint(8) اختیاري ۳

نامعلوم

0x0005 uint(8) اختیاري ۴

نامعلوم

د فرعي چوکاټ

ادریس x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF کریکټر
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
اُفست د معلوماتو ډول نوم تشریح
0x0000 uint(16) بټ میپ - شناخت

دا مشخصوي چې کومه بټ میپ د دې فرعي چوکاټ لپاره کارول شي

0x0002 uint(8) نامعلوم ۱

نامعلوم دی - خو زه پوره شک لرم چې دا د رینڈر لومړیتوب (Z-Layer) په اړه دی.

0x0003 uint(8) سب فریم-آی ډی

ښيي چې موږ په کوم فرعي چوکاټ کې یو

0x0004 sint(16) افست - افقي

دا ښیي چې د فریم دننه چیرته باید سب فریم ځای پرځای شي، یا په افقی ډول د بټ میپ څومره پکسلونه لېرې شي

0x0006 sint(16) اوفسیټ - عمودي

ښیي چې د فریم دننه د سب فریم ځای چېرته دی، یا د بټ مپ څو پکسل عمودي سره ښکته کیدل پکار دي

په دې سره موږ اوس کولی شو چې انفرادي فریمونه او همدارنګه بشپړ انیمیشنونه په مناسب ډول سره ترتیب کړو، دلته د یوه پیچلي انیمیشن، د انیمیشن په اندیس 500 کې، یو مثال وړاندې شوی دی

انیمیشن ۵۰۰

انیمیشن 500 ښیي چې څنګه یوه پلایموټ د ټرانسپورټر، چې د عادي کانکریت سره بار شوی، خالي کیږي. دا د څو انیمیشنونو څخه یوه ده چې د وینډوز فعالیت کاروي.

او داسې کولی شئ چې بشپړه انیمیشن یو ځای کړئ.
افسوس، د لوړ بار کولو دروازې سره لاهم یو مشکل شته، ځکه چې دلته اړوند بیټ په ګرافیک ډول معلوماتو کې نه دی ټاکل شوی.

دلته د لوبې څخه نور څو ښکلي انیمیشن شوي سپرایټونه دي:

انیمیشن 500 د رینډر کولو تصویر

انیمیشن 500 بشپړ شوی

پلیموث ودانی - فابریکه

ایدن فضایي بندر

ایدن طبي مرکز

اسکات

پلیموث فضایي بندر

ایسټرایګ:
کرسمس سړی

ایسټرایګ:
ډانس سپی

د کارونکي انٹرفیس

اوس د لوبې کارن انٹرفیس پاتې دی، چې په برش شوی فلز شکل کې دی.

خو دلته هم څرګند دی چې Dynamix اړتیا نه وه چې چرخې نوې اختراع کړي؛ دلته یوازې د وینډوز لخوا چمتو شوي User32 او GDI32 APIs نه یوازې ساده کارول کیږي - ځانګړې توګه د User32 د سرچینو مدیریت هم کارول کیږي.

دا د مثال په توګه د Angus Johnson لخوا د Freeware په توګه جوړ شوي Resource Hacker په څیر پروګرامونو له لارې، یا که څوک د لینوکس / مک OS لاندې د Wine کارولو څخه ډډه کوي - د icoutils کې شامل wrestool په مرسته استخراج کړي.

فایل نوم محتوا
Outpost2.exe یوازې د لوبې آیکون لري، چې د New Terra په وړاندې فضا سټېشن ښیي
op2shres.dll د کنټرول عناصرو لپاره ګرافیکونو سره، لکه حاشیې، تڼۍ، رادیو تڼۍ او چیک باکسونه، د خبرو اترو پس منظرونه، د داستان د ماموریت متون لپاره ملګري انځورونه او د اصلي مینو پس منظر ګرافیک هم لري
out2res.dll د انګیم کړکیو د سینګار لپاره، د عادي او ځانګړي فلز لپاره آیکونونه، د بار کولو سکرین، د خبرو اترو لپاره ګرافیکونه او نور د کشر ګرافیکونه، له انیمیشن سره د لوبې په فولډر کې شتون لري