Outpost 2 کی فائل فارمیٹس · bei.pm

اردو
یہ متن اوپن اے آئی جی پی ٹی-4o منی کے ذریعے خودکار طور پر ترجمہ کیا گیا ہے۔

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

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

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

کھیل کا آرٹ ورک

یہ مضمون کی سیریز میرے تجربات کو "آؤٹ پوسٹ 2: تقسیم شدہ تقدیر" کے ڈیٹا فارمیٹس پر دستاویز کرتی ہے، جو 1997 میں سیرا کے ذریعے شائع ہوا اور ڈائنامکس نے تیار کیا۔

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

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

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

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

تعارف

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 علامات کی توقع کرتی ہے۔

ڈیٹا کو پارس کرتے وقت اس ڈیٹا بلاک کا مزید تجزیہ کرنے کی ضرورت نہیں ہے، کیونکہ والیم کی معلومات میں براہ راست فائل ناموں کے آفسیٹس حوالہ دیے گئے ہیں۔

Volume Strings ایک فائل ناموں کی فہرست ہے جو Volume کے اندر موجود ہیں۔

حجم کی معلومات

ایڈریس 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) فائل کے نام کا آفسیٹ

یہ بتاتا ہے کہ فائل کے نام کی فہرست (Volume-Strings) میں فائل کا نام کس آفسیٹ (!) پر واقع ہے۔

یہ صارف کے ڈیٹا بلاک کے آغاز کی طرف اشارہ کرتا ہے۔
0x0004 uint(32) فائل آفسیٹ

یہ بتاتا ہے کہ مجموعی Volume فائل کے اندر یہ فائل کس آفسیٹ پر موجود ہے۔
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) اونچائی (عمودی قرارداد)

یہ بتاتا ہے کہ تصویر کی فائل کتنی اونچی ہے (پکسل میں).

Outpost 2 کے تمام Wells میں یہاں کی قیمت 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;

pixel کے 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 Resource 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 ہے۔

پیلیٹ کے بارے میں مزید صرف یہ کہنا ہے کہ انیمیشنز کے لیے استعمال ہونے والی پیلیٹ کے لیے درج ذیل قوانین لاگو ہوتے ہیں:

  • پہلا رنگ ہمیشہ شفاف ہوتا ہے، چاہے وہاں کوئی بھی قیمت دی گئی ہو۔
  • پیلیٹ کی پہلی 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 بٹ میپ ہیڈر کیوں رکھتی ہے۔ ممکن ہے کہ آؤٹ پوسٹ 2 گرافکس کو لوڈ کرنے کے لئے سسٹم کے APIs کا استعمال کرتا ہے، جس میں یہ ہیڈر عارضی طور پر لیا جاتا ہے اور متعلقہ متغیرات کو اوور رائیٹ کیا جاتا ہے۔

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

مونوکروم 1bpp گرافکس کو اس طرح سے ڈرائنگ کیا جا سکتا ہے کہ رنگ 0 مکمل شفافیت ہے، جبکہ رنگ 1 آدھا شفاف سیاہ/سرمئی ہے، کیونکہ مونوکروم گرافکس عموماً گاڑیوں اور عمارتوں کے سائے کی اینیمیشنز میں استعمال ہوتی ہیں۔

اس طرح ہم پہلے ہی کئی گرافکس کو اکٹھا کر سکتے ہیں۔

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

انیمیشنز

اب ہم آؤٹ پوسٹ 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) باؤنڈنگ باکس: بائیں

بائیں طرف کی شروعات (پکسل میں) باؤنڈنگ باکس کی وضاحت کرتی ہے۔
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 مکمل طور پر اکٹھی کی گئی

پلیموث عمارت-فیکٹری

ایڈن خلا کی بندرگاہ

ایڈن طبی مرکز

ایس سی اے ٹی

پلیموث خلا کی بندرگاہ

ایسٹر ایگ:
کرسمس بابا

ایسٹر ایگ:
ڈینس کتا

صارف کے انٹرفیس

اب کھیل کا صارف-انٹرفیس باقی ہے، جو کہ برش کیے گئے دھات کے انداز میں ہے۔

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

ان کو آپ Angus Johnson کی طرف سے مفت فراہم کردہ Resource Hacker جیسے پروگراموں کے ذریعے نکال سکتے ہیں، یا اگر آپ Linux / Mac OS پر Wine کے استعمال سے گریز کر رہے ہیں تو icoutils میں شامل wrestool کی مدد سے بھی نکال سکتے ہیں۔

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