Outpost 2 ڈیٹا فارمیٹس · bei.pm

پنجابی
ایہہ متن خودکار طور تے OpenAI GPT-4o Mini دے ذریعے ترجمہ کیتا گیا۔

اس صفحے پر بیان کردہ فائل فارمیٹس Dynamix, Inc. اور Sierra Entertainment کی دانشورانہ ملکیت کی تکنیکی تجزیے پر مبنی ہیں۔
دانشورانہ ملکیت آج Activision Publishing, Inc. / Activision Blizzard, Inc. کی ملکیت ہے اور فی الحال Microsoft Corp. کے پاس ہے۔

معلومات کو ریورس انجینئرنگ اور ڈیٹا تجزیہ کے ذریعے تاریخی ڈیٹا کے ساتھ آرکائیو کرنے اور باہمی تعامل کے مقصد کے لیے جمع کیا گیا ہے۔
کوئی بھی ملکیتی یا رازدارانہ وضاحتیں استعمال نہیں کی گئیں۔

یہ کھیل فی الحال gog.com پر ڈاؤن لوڈ کے طور پر خریدا جا سکتا ہے۔

کھلونے دا فن

ایہہ مضمون دی سیریز میرے تجربات نوں دستاویز کردا اے جو "Outpost 2: Divided Destiny" دے ڈیٹا فارمیٹس بارے اے، جو 1997 وچ سیرا دی طرفوں شائع کیتا گیا تے ڈائنامکس نے تیار کیتا۔

میں تقریباً 01 نومبر 2015 توں 14 نومبر 2015 تک اس کھیل دے ڈیٹا دی تجزیہ نال زیادہ مصروف رہا ہاں - تے اوہدا کیہہ استعمال ہوندا اے -۔

جو معلومات میں ہن تک حاصل کیتیاں نے، اوہ دے مطابق ڈائنامکس - جیویں کہ بہت سارے تجارتی ادارے - کچھ ڈیٹا فارمیٹس خاص طور تے Outpost 2 لئی نہی بنایا، بلکہ انہاں نوں ہور ترقیات وچ وی استعمال کیتا، جیویں کہ Mechwarrior سیریز (بدل کے)۔
اس توں علاوہ ایہہ وی واضح کیتا جا سکدا اے کہ ڈیٹا فارمیٹس دی جدت عملی طور تے محدود اے تے اکثر عام فارمیٹس جیسے کہ JFIF تے RIFF توں قائم کیتے گئے تصور اتے مبنی ہوندی اے۔

ٹیبلز تے ڈیٹا فارمیٹس دی تشریح لئی ہور معلومات کیہہ کیہہ اے؟ تے موجود نیں۔
ایتھے دتے گئے ڈیٹا عمومی طور تے Little Endian سمجھنا چاہی دا اے۔

آخری گل ایہہ اے کہ ریورس انجینئرنگ بہت مزے دی رہی، حالانکہ ایہہ مکمل نہی اے۔
یقیناً میں وی صرف ایہہ کہہ سکدا ہاں کہ کھیل خود کھیڈو، کیوں کہ ایہہ دلچسپ کھیلنے دیاں میکانیکاں فراہم کردا اے۔

تعارف

Outpost 2 دے استعمال کردہ ڈیٹا فارمیٹس دا ڈھانچہ JFIF / PNG نوں یاد دلاون والا اے - انفرادی ڈیٹا بلاک ہمیشہ 8 بائٹ ہیڈر نال ہوندے نیں۔ ایس لئی میں ہیڈرز نوں مخصوص مقامات تے دستاویز کرن توں بچ رہیا ہاں تے اوتھے صرف انحرافات دا ذکر کرانگا۔

فارمیٹ ہمیشہ ایہہ اے؛ حقیقی صارف ڈیٹا پھر اس وچ شامل ہوندا اے:

ایڈریس 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 ہوندی اے۔ ایہہ اشارہ دیندا اے کہ ایہہ اک فلیگ سیٹ ہوسکدا اے۔

حجم

وولمز ایک ڈیٹا کنٹینر ہیں جو کھیل کے لیے ہے، جیسے کہ ایک آرکائیو فارمیٹ جیسے ٹار بال۔ کم از کم آؤٹ پوسٹ 2 میں، یہ فارمیٹ صرف فائلوں کو جانتا ہے - فولڈرز نہیں۔ شاید انہیں متعلقہ فائل ناموں کے ذریعے سمولیٹ کیا جا سکے۔

ایک والیم میں والیم ہیڈر اور کئی والیم بلاکس شامل ہوتے ہیں، جو مخصوص فائلوں کے مطابق ہوتے ہیں۔

"وولمز" وہ فائلیں ہیں جن کا ایکسٹینشن '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 = فائل الاٹمنٹ ٹیبل)

فائلوں کی تعداد بلاک کے سائز کو ڈائریکٹری کی انٹری کی لمبائی - 14 بائٹس سے تقسیم کرکے حاصل کی جاتی ہے۔

ہر ایک ڈائریکٹری کی انٹری کا اس طرح کا ایک ساخت ہوتی ہے:

ایڈریس 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 گرافک فارمیٹ ہیں۔ یہ 13 ٹائل سیٹس پر مشتمل ہیں، جنہیں "wells" کہا جاتا ہے (well0000.bmp سے well0012.bmp تک)، جو کہ maps.vol والیوم میں موجود ہیں۔

ان ٹائل سیٹس / ویلز میں درج ذیل شامل ہیں:

فائل دا ناں مواد
well0000.bmp ایک 32x32px دی وسعت والی نیلی گرافک - یہ اپنے امیج لوڈر دے کام کرن دی جانچ لئی بہترین اے
well0001.bmp ہلکے پتھر، ہلکے پتھر تے پہاڑاں دی لکیراں تے بے شمار ہلکے پتھر وچ گڑھوں دیاں مختلف اقسام شامل نیں
well0002.bmp ہلکے پتھر دے 'ڈوڈاڈز' شامل نیں - یعنی ایہہ عناصر جو ہلکے پتھر تے جگہ جگہ لگا کے سجاوٹ لئی استعمال ہوسکدے نیں، جنہاں وچ پودے بھی شامل نیں
well0003.bmp ہلکے پتھر تے ایک قشر دار ساخت شامل اے
well0004.bmp گہرے پتھر، گہرے پتھر تے پہاڑاں دی لکیراں تے بے شمار گڑھوں دیاں مختلف اقسام شامل نیں
well0005.bmp گہرے پتھر دے 'ڈوڈاڈز' شامل نیں - یعنی ایہہ عناصر جو گہرے پتھر تے جگہ جگہ لگا کے سجاوٹ لئی استعمال ہوسکدے نیں
well0006.bmp گہرے پتھر تے ایک قشر دار ساخت شامل اے، نالے ہلکے تے گہرے پتھر دے درمیان منتقلیاں
well0007.bmp لاوا شامل اے، ہر ایک دے نال 4-5 فریمز دی حرکت شامل اے
well0008.bmp ریت تے بے شمار گڑھوں دیاں مختلف اقسام شامل نیں
well0009.bmp ریت دے 'ڈوڈاڈز' شامل نیں - یعنی ایہہ عناصر جو ریت تے جگہ جگہ لگا کے سجاوٹ لئی استعمال ہوسکدے نیں
well0010.bmp ریت توں ہلکے تے گہرے پتھر تک 48 منتقلیاں شامل نیں
well0011.bmp نقشے دے قطبی ٹوپے، گہرے پتھر دے نیچے شامل نیں
well0012.bmp نقشے دے قطبی ٹوپے، ہلکے پتھر دے نیچے شامل نیں

ایہہ مشورہ دیا جاندا اے کہ اک درست عمل درآمد لئی ٹائلز نوں پہلے توں رینڈر نہ کیتا جاوے تاکہ انہاں نوں کیش کیتا جا سکے، کیوں کہ دن/رات دے چکر لئی ڈیٹا ہنوز پروسیس کرنا اے - تے بہت زیادہ ڈیٹا اکٹھا ہو جاوے گا۔

ٹائلز 8bpp گرافکس نیں جنہاں دی انڈیکسڈ پیلیٹ 32x32 پکسل ریزولوشن نال اے، جیہڑے آپس وچ ترتیب دتے گئے نیں۔ ایس طرح بنائے گئے ٹائل سیٹ وچ بہوت زیادہ ہو سکدے نیں۔

اہم کنٹینر 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) اونچائی (عمودی حل)

ایہہ دسے گا کہ تصویری فائل دی اونچائی کتنی ہے (پکسل وچ).

آؤٹ پوسٹ 2 دے سارے ویلز لئی ایہہ ویلیو 0x20 یاں 32 ہون دی توقع رکھی جائے گی.
0x0014 uint(32) رنگ کی گہرائی؟

اس قیمت کی اہمیت نامعلوم ہے۔

کیونکہ یہ تمام جانچے گئے فائلوں میں 8 کی قیمت رکھتا ہے، یہ ممکن ہے کہ یہ رنگ کی گہرائی کی وضاحت ہو۔
0x0018 uint(32) رنگ کی گہرائی 2؟

اس قیمت کی اہمیت نامعلوم ہے۔

یہ ممکن ہے کہ یہ ایک 'مقصد' رنگ کی گہرائی ہو۔

ان معلومات کے بعد ایک معیاری 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 بٹ میپس کی صورت میں ہوتے ہیں، رنگوں کی پیلیٹ میں رنگ کے انڈیکس کے مطابق ہوتا ہے۔

پکسل ڈیٹا اوپر بائیں سے شروع ہوتا ہے اور نیچے دائیں میں ختم ہوتا ہے۔

کھیل کی انجن ٹائلز کو *شاید* آن ڈیمانڈ ریکارڈ کرتی ہے۔
یہ دن رات کے چکر کی وجہ سے ہے، جس میں 32 مختلف ٹائلز کی درجہ بندیاں ہیں۔ اس میں ہلکی روشنی کی قیمت سے 'تھوڑی سی' کمی کی جا رہی ہے۔ درست قیمتیں ابھی تک معلوم نہیں ہو سکیں، میں حساب کی بنیاد پر کام کر رہا ہوں۔ 

v *= (daylight / 48) + 0.25;

پکسل کے HSV ڈیٹا کے ساتھ، جہاں daylight کا قیمت 0-31 ہے اور v کی قیمت 0-1 کے درمیان ہے۔ اس کے علاوہ، نقشے پر ہر طرف 16 ٹائلز کا ایک کنارے موجود ہے (جو یونٹس کی غیر مرئی پیدائش کے لیے ہے)۔

اس کے علاوہ، دن رات کا چکر ہر گیم سائیکل میں صرف ایک کالم کو اپ ڈیٹ کرتا ہے۔
تیز دن رات کا چکر اس طرح دکھتا ہے:

دن رات کے چکر کی بصری نمائندگی

پی آر ٹی

ایڈریس 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-سیکشن (ممکنہ طور پر پالتنوں کے کنٹینر کے لیے) صرف پالتن کے ڈیٹا کو شامل کرتا ہے، یہ بتاتے ہوئے کہ عام طور پر 1052 بائٹس کے 8-بٹ پالتنوں میں سے کتنے موجود ہیں۔

1052 بائٹس کی وضاحت کو لازمی نہیں سمجھا جاتا، کیونکہ پالتن کے فارمیٹ میں ممکنہ طور پر مختلف پالتن کے سائز موجود ہو سکتے ہیں۔ یہ صرف ان ڈیٹا سیٹ کے لیے ہے جس کے ساتھ آؤٹ پوسٹ 2 فراہم کیا جاتا ہے۔

پالتن کی فہرستوں کے بعد، بغیر کسی ابتدائی ہیڈر کے، بٹ میپس کی فہرست آتی ہے؛ اسی طرح حرکت کی فہرستیں بھی فوری طور پر آتی ہیں۔
دونوں کو ایک 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) سمت والی چوڑائی

یہ پیکسل ڈیٹا لائنوں کی چوڑائی کو بائٹس میں ظاہر کرتا ہے - کیونکہ یہ 4 بائٹ کی سرحدوں کے مطابق ہیں۔

اس طرح، کسی مخصوص تصویر کی لائن پر جلدی پہنچنا ممکن ہے۔

یہ واضح نہیں ہے کہ یہ قدر علیحدہ کیوں محفوظ کی جاتی ہے، حالانکہ اسے حساب سے نکالا جا سکتا ہے۔
شاید یہ رینڈر کوڈ کے لیے ایک بہتر بنانے کا طریقہ ہے۔
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 استعمال کردا ہے، ایہہ ہیڈر عارضی طور تے اپنایا جاندا ہے تے متعلقہ متغیر شعبے اووررائٹ ہوندے نے۔

پکسل ڈیٹا BMP فائل وچ اس دی پوزیشن آفسیٹ + uint32 آفسیٹ تے موجود ہوندا ہے، جو کہ BMP فائل وچ ایڈریس 0x000A تے ملدا ہے (RIFF بٹ میپ ڈیٹا آفسیٹ)، تے ایہہ دوبارہ اوپر توں کھبے توں نیچے دی طرف قطار وار ترتیب نوں دکھاندے نے۔

مونochrome 1bpp گرافکس اس طرح تیار کیتیاں جا سکدیاں نے کہ رنگ 0 مکمل شفافیت نوں، تے رنگ 1 نیم شفاف کالا/سیاہ ہوندا ہے، کیونکہ مونochrome گرافکس اکثر گاڑیوں تے عمارتاں دے سائے دے انیمیشن وچ استعمال کیتے جاندے نے۔

اس طرح توں بہت ساری گرافکس نوں اکٹھا کیتا جا سکدا ہے۔

محفوظ رہائشی ماڈیول (Plymouth)

اینیمیشنز

ہن اسی Outpost 2 ڈیٹا فارمیٹس دے اندر دیسیپلن دی بادشاہی کلاس والیاں آں:
انیمیشنز۔

انیمیشن کی فہرستاں اک عالمی ہیڈر نال شروع ہوندیاں نیں، جو بنیادی طور تے ڈیٹا دی تصدیق لئی ہوندی اے۔ اس توں بعد مخصوص انیمیشن ڈیفینیشنز ہوندیاں نیں، جو 3 سطحاں وچ وڈیائی جاندی نیں:

  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) غیر معروف 1

نامعلوم معلومات
0x0004 uint(32) باؤنڈنگ باکس: بائیں

بائیں سمت دا آغاز (پکسل وچ) Bounding Box دا بیان کردا اے۔
0x0008 uint(32) باؤنڈنگ باکس: اوپر

اوپرلے آغاز (پکسل وچ) بانڈنگ باکس دا بیان کردا اے۔
0x000c uint(32) باؤنڈنگ باکس: چوڑائی

یہ Bounding Box کی چوڑائی (پکسل میں) بیان کرتا ہے۔
0x0010 uint(32) باؤنڈنگ باکس: اونچائی

یہ Bounding Box کی اونچائی (پکسل میں) بتاتا ہے۔
0x0014 uint(32) آفسیٹ: X

انیمیشن دا افقی مرکز دسےندے اے
0x0018 uint(32) آفسیٹ: Y

انیمیشن دا عمودی مرکز دسے گا
0x001c uint(32) انجان 2

انجان معلومات
0x0020 uint(32) فریمز کی تعداد

دسدا اے کہ اس انیمیشن وچ کنے انیمیشن فریم شامل نیں
0x0024 uint(32) کھڑکیوں کی تعداد

بتاؤ کہ ڈرائنگ کرتے وقت کِنّے کھڑکیاں استعمال کرنی ہیں

سب سے اوپر کی پرت کے اعداد و شمار، انیمیشن کے لیے، بنیادی طور پر انتظامی ڈیٹا ہیں - Boundingbox اس وقت گاڑی/عمارت کے ارد گرد نشانی کے کوآرڈینیٹس کی نشاندہی کرتی ہے، جب یہ منتخب ہوتا ہے اور یہ بھی بتاتی ہے کہ کون سا علاقہ کلک کرنے کے لئے دستیاب ہونا چاہئے۔

آفسیٹ بنیادی طور پر "زیرو پوائنٹ" کو طے کرتا ہے؛ وہ نقطہ جو کھیل کے اندرونی کوآرڈینیٹس میں جمع یا گھٹایا جانا ہے۔ ریاضی کے لحاظ سے کہا جائے تو: آفسیٹ یہاں کوآرڈینیٹ کا نقطہ آغاز ہے۔

ونڈوز بھی، جیسے آفسیٹ، ہر ونڈو کے لئے 4 uint(32) قیمتیں ہیں، جو ایک ایسا علاقہ ظاہر کرتی ہیں جو انفرادی سب فریمز کے لئے قابل استعمال ہے۔ ونڈوز کے باہر، جب تک کہ یہ بٹ میپ کے لیے مناسب ہو، ڈرائنگ کی اجازت نہیں ہے۔

فریم

ایڈریس x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF چیر
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
آفسیٹ ڈیٹا ٹائپ نام وضاحت
0x0000 uint(8) سب فریم کی تعداد اور آپشنل 1، 2 کے لیے ٹوگل

ایہہ قیمت درج ذیل شامل ہے:

  • 0x7F (بٹ ماسک): اس فریم میں استعمال ہونے والے ذیلی فریمز کی تعداد
  • 0x80: یہ معلومات کہ آیا آپشنل 1 اور 2 موجود ہیں یا نہیں
0x0001 uint(8) انجان 1 تے متبادل 3، 4 لئی ٹوگل

ایہہ ویلیو شامل اے:

  • 0x7F (بٹ ماسک): نامعلوم - میں پختہ یقین نال کہہ سکدا ہاں کہ ایہہ اوہ گیم ٹکس دی تعداد اے جو گذرندیاں ہن، جدو تک اگلا فریم وکھایا جائے گا
  • 0x80: ایہہ معلومات کہ آیا آپشنل 3 تے 4 موجود نیں
0x0002 uint(8) اختیاری 1

نامعلوم
0x0003 uint(8) اختیاری 2

نامعلوم
0x0004 uint(8) اختیاری 3

نامعلوم
0x0005 uint(8) اختیاری 4

نامعلوم

ذیلی فریم

ایڈریس x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF چیر
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
آفسیٹ ڈیٹا ٹائپ نام وضاحت
0x0000 uint(16) بٹ میپ-آئی ڈی

ایہہ بتاؤ کہ اس سب فریم لئی کون سی بٹ میپ استعمال کیتی جائے گی
0x0002 uint(8) غیر معروف 1

یہ نامعلوم ہے - میں مگر یہ مضبوطی سے قیاس کرتا ہوں کہ یہ ایک رینڈر ترجیح (Z-Layer) ہے۔
0x0003 uint(8) سب فریم-آئی ڈی

یہ بتاتا ہے کہ ہم کس سب فریم میں ہیں
0x0004 sint(16) آفسیٹ - افقی

ایہہ بتاتا ہے کہ فریم کے اندر سب فریم کہاں رکھا جائے گا، یا بٹ میپ کو ہوریزونٹلی کتنے پکسلز تک منتقل کرنا ہے
0x0006 sint(16) آفسیٹ - عمودی

ایہہ بیان کردا اے کہ فریم اندر سب فریم کہاں رکھیا جائے، یا کتنے پکسلز دی عمودی تبدیلی ہونی چاہی دی اے۔

ایس نال اسی ہن انفرادی فریمز نوں، تے مکمل انیمیشنز نوں وی اکٹھا کر سکدے ہاں، اتھے اک مثالی طور تے اک پیچیدہ انیمیشن، جو کہ انڈیکس 500 نال ہے، دی مثال دے طور تے وکھائی جا رہی ہے۔

انیمیشن 500

اینیمیشن 500 دکھاتی ہے کہ کس طرح ایک پلائمووتھ ٹرانسپورٹر، جو کہ عام کان کنی کے مال سے بھرا ہوا ہے، کو اتارا جاتا ہے۔ یہ چند ایک اینیمیشنز میں سے ایک ہے جو ونڈوئنگ کی فعالیت کا استعمال کرتی ہیں۔

اور یوں مکمل اینیمیشن کو یکجا کیا جا سکتا ہے۔
بدقسمتی سے اوپر کی لوڈنگ کھڑکی کے ساتھ ابھی ایک مسئلہ ہے، کیونکہ یہاں گرافک ٹائپ کی معلومات میں متعلقہ بٹ سیٹ نہیں ہے۔

یہاں کھیل سے کچھ مزید خوبصورت اینیمیٹڈ سپرائٹس ہیں:

اینیمیشن 500 کا رینڈرنگ پیش کیا گیا

اینیمیشن 500 مکمل طور پر یکجا کی گئی

Plymouth عمارت-فیکٹری

Eden خلا ہوائی اڈا

Eden طبی مرکز

SCAT

Plymouth خلا ہوائی اڈا

Easteregg:
کرسمس بابا

Easteregg:
Dans کتا

صارف-انٹرفیس

ہن کھیل دے یوزر انٹرفیس دی کمی اے، جو کہ ایک برش کِتے ہوئے دھات دے نطرین وچ تیار کیتا گیا اے۔

پر ایہہ ویچ واضح اے کہ Dynamix نوں پہلاں توں کچھ نواں تے تخلیقی کرنے دی لوڑ نہی سی؛ ایہہ نہ صرف سادہ طور تے Windows دے فراہم کردہ User32 تے GDI32-APIs دا استعمال کردے نیں - خاص طور تے User32 دا وسائل منیجمنٹ وی استعمال کیتا جاندا اے۔

ایناں نوں مثلاً Angus Johnson دی تیار کردہ مفت سافٹ ویئر Resource Hacker ورگے پروگراماں تھوں، یا - جے کوئی Linux / Mac OS تے Wine دا استعمال نہ کرنا چاہندا اے - تے icoutils وچ شامل wrestool دی مدد نال نکالیا جا سکدا اے۔

فائل کا نام مواد
Outpost2.exe صرف کھیل کا آئیکن شامل ہے، جو کہ نیو ٹیریا کے سامنے موجود خلا اسٹیشن کو دکھاتا ہے
op2shres.dll کنٹرولز جیسے کہ سرحدیں، بٹن، ریڈیو بٹن اور چیک باکسز کے لیے گرافکس کے علاوہ بات چیت کے پس منظر، کہانی کے مشن ٹیکسٹ کے ساتھ معاون تصاویر اور مرکزی مینو کے پس منظر کی گرافکس شامل ہیں
out2res.dll ان گیم ونڈو کی سجاوٹ، عام اور خصوصی دھات کے آئیکن، لوڈنگ اسکرین، بات چیت کے لیے گرافکس اور مزید کرسر گرافکس شامل ہیں، کھیل کی ڈائریکٹری میں موجود متحرک گرافکس کے علاوہ