فرمت‌های فایل 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" که در سال ۱۹۹۷ توسط سیرا منتشر و توسط دینامیکس توسعه یافته، مستند می‌کند.

من از حدود ۱ نوامبر ۲۰۱۵ تا ۱۴ نوامبر ۲۰۱۵ بیشتر به تحلیل داده‌های بازی و استفاده‌هایی که از آن می‌شود پرداختم.

بر اساس اطلاعاتی که تا کنون به دست آورده‌ام، دینامیکس - مانند بسیاری از شرکت‌های تجاری دیگر - برخی از فرمت‌های داده‌ای را به طور خاص برای 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) طول بلوک

شامل اطلاعاتی است در مورد اندازه (به بایت) بلوک داده‌های بعدی.

در اینجا فقط داده‌های واقعی منظور است - ۸ بایت هدر در اینجا لحاظ نشده است.
0x0007 uint(8) پرچم‌ها؟

این مشخص نیست که این بلوک دقیقاً برای چه کاری است.

در ولوم‌ها، این مقدار معمولاً 0x80 است و در فایل‌های دیگر معمولاً 0x00 است. این نشان می‌دهد که احتمالاً یک مجموعه پرچم است.

حجم‌ها

حجم‌ها یک ظرف داده برای بازی هستند، مشابه به یک فرمت آرشیو مانند Tarball. حداقل در Outpost 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 هستند. آنها شامل ۱۳ مجموعه تایل به نام "چاه‌ها" (well0000.bmp تا well0012.bmp) می‌باشند که در داخل حجم maps.vol قرار دارند.

این مجموعه‌های تایل / چاه‌ها شامل موارد زیر هستند:

نام فایل محتوا
well0000.bmp گرافیکی به اندازه ۳۲x۳۲ پیکسل به رنگ آبی - ایده‌آل برای آزمایش اینکه آیا بارگذار تصویر شما کار می‌کند
well0001.bmp حاوی سنگ‌های روشن، رشته‌کوه‌ها بر روی سنگ‌های روشن و بی‌شماری از انواع دهانه‌های برخوردی در سنگ‌های روشن
well0002.bmp حاوی 'دوداد' سنگ‌های روشن - عناصری که می‌توانند برای تزیین (یا عمداً به عنوان ساختار، مانند دیوارها) بر روی سنگ‌های روشن قرار بگیرند، از جمله گیاهان
well0003.bmp حاوی ساختار پوسته‌ای بر روی سنگ‌های روشن
well0004.bmp حاوی سنگ‌های تیره، رشته‌کوه‌ها بر روی سنگ‌های تیره و بی‌شماری از انواع دهانه‌های برخوردی در سنگ‌های تیره
well0005.bmp حاوی 'دوداد' سنگ‌های تیره - عناصری که می‌توانند برای تزیین (یا عمداً به عنوان ساختار، مانند دیوارها) بر روی سنگ‌های تیره قرار بگیرند
well0006.bmp حاوی ساختار پوسته‌ای بر روی سنگ‌های تیره، همچنین انتقال‌ها بین سنگ‌های روشن و تیره
well0007.bmp حاوی مواد مذاب شامل ۴-۵ فریم انیمیشن از آن
well0008.bmp حاوی شن و بی‌شماری از انواع دهانه‌های برخوردی در شن
well0009.bmp حاوی 'دوداد' شن - عناصری که می‌توانند برای تزیین (یا عمداً به عنوان ساختار، مانند دیوارها) بر روی شن قرار بگیرند
well0010.bmp حاوی هر کدام ۴۸ انتقال از شن به سنگ‌های روشن و تیره
well0011.bmp حاوی قطب‌های نقشه، با سنگ‌های تیره به عنوان زیرساخت
well0012.bmp حاوی قطب‌های نقشه، با سنگ‌های روشن به عنوان زیرساخت

این توصیه می‌شود که برای پیاده‌سازی دقیق، کاشی‌ها را از پیش رندر نکنید تا بتوانید آنها را کش کنید، زیرا داده‌ها برای چرخه روز/شب هنوز باید پردازش شوند - و حجم بسیار زیادی از داده‌ها تولید خواهد شد.

کاشی‌ها گرافیک‌های ۸ بیتی با پالت ایندکس شده به ابعاد ۳۲x۳۲ پیکسل هستند که به صورت افقی کنار هم قرار گرفته‌اند. با این حال، در یک مجموعه کاشی ایجاد شده می‌توان به مراتب بیشتر از اینها وجود داشته باشد.

ظرفیت اصلی از ۲ بخش تشکیل شده است: 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، انتظار می‌رود که این مقدار 0x20 یا 32 باشد.
0x0010 uint(32) ارتفاع (وضوح عمودی)

مقدار ارتفاع فایل تصویر را (به پیکسل) نشان می‌دهد.

در تمامی چاه‌ها در Outpost 2، انتظار می‌رود که مقدار 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-Bitmap وجود دارند، معادل با شاخص رنگ در پالت رنگ است.

داده‌های پیکسل از بالا سمت چپ شروع و در پایین سمت راست به پایان می‌رسند.

انجین بازی احتمالاً *به صورت درخواستی* کاشی‌ها را ترسیم می‌کند.
به نظر می‌رسد این موضوع به چرخه روز و شب مربوط باشد که ۳۲ درجه مختلف از کاشی‌ها را شامل می‌شود. به نظر می‌رسد که از مقدار روشنایی به‌طور 'کمی' کم می‌شود. مقادیر دقیق هنوز مشخص نشده‌اند، من بر اساس محاسبات زیر کار می‌کنم 

v *= (daylight / 48) + 0.25;

با داده‌های HSV پیکسل‌ها، که در آن daylight یک مقدار بین ۰-۳۱ است و v یک مقدار بین ۰-۱. علاوه بر این، باید در نظر گرفت که در نقشه هر طرف یک حاشیه ۱۶ کاشی به سمت چپ و راست وجود دارد (که برای تولید نامرئی واحدها استفاده می‌شود).

علاوه بر این، به نظر می‌رسد چرخه روز و شب در هر چرخه بازی تنها یک ستون از نقشه را به‌روزرسانی می‌کند.
یک چرخه روز و شب تسریع شده به شکل زیر است:

تصویرسازی از چرخه روز و شب

پی آر تی

آدرس 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 برای من مشخص نیست؛ اما ممکن است به عنوان مثال به 'جدول پالت و منابع' اشاره داشته باشد - زیرا این فایل که به صورت op2_art.prt در maps.vol یافت می‌شود، شامل چنین اطلاعاتی است و این توصیف به خوبی عملکرد آن را بیان می‌کند.

این فایل شامل فهرستی از پالت‌ها، جدولی از تمام بیت‌مپ‌های استفاده شده، تمام تعریف‌های انیمیشن و همچنین تعدادی داده‌های ناشناخته است. این فایل به طور غیررسمی از فرمت کنترلی قبلی پیروی می‌کند، زیرا همه رکوردها الزماً این الگو را دنبال نمی‌کنند.

بخش CPAL (احتمالاً به معنای کانتینر پالت) فقط داده‌های پالت را در بر می‌گیرد و تعداد پالت‌های 8 بیتی معمولاً به اندازه 1052 بایت را مشخص می‌کند.

ذکر 1052 بایت به عنوان یک قاعده الزام‌آور در نظر گرفته نمی‌شود، زیرا فرمت پالت ممکن است اندازه‌های پالت متفاوتی را در نظر بگیرد. این فقط برای داده‌هایی است که با Outpost 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) پرچم‌ها

قسمت داده‌ها شامل ورودی‌های جداگانه پالت می‌باشد. تعداد ورودی‌های پالت از طول بلوک / ۴ به دست می‌آید.

ورودی‌های جداگانه دارای ساختار ساده زیر هستند؛

آدرس 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 باشد.

در مورد پالت‌ها تنها می‌توان گفت که برای پالت‌هایی که برای انیمیشن‌ها استفاده می‌شوند، قوانین زیر اعمال می‌شود:

  • رنگ اول همیشه شفاف است، مهم نیست چه مقداری در آنجا تعیین شده است.
  • ورودی‌های پالت ۱-۲۴ در پالت‌های ۱-۸ به عنوان رنگ‌های بازیکن محسوب می‌شوند.
    من نمی‌دانم که رنگ‌ها به جز رنگ بازیکن ۱ از کجا آمده‌اند.
    حدس می‌زنم که رنگ‌های باقی‌مانده به صورت سخت‌کد شده‌اند.

مرجع پالت

بیت‌مپ‌ها

آدرس 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های سیستمی برای بارگذاری گرافیک‌ها استفاده می‌کند و این هدر به‌طور موقت مورد استفاده قرار می‌گیرد و فیلدهای متغیر مربوطه بازنویسی می‌شوند.

داده‌های پیکسلی در فایل BMP در موقعیت Offset + uint32-Offset، که در فایل BMP در آدرس 0x000A (آفست داده‌های RIFF بیت‌مپ) یافت می‌شود، قرار دارند و دوباره به ترتیب خطی از بالا چپ به پایین راست مرتب شده‌اند.

گرافیک‌های تک‌رنگ 1bpp می‌توانند به‌گونه‌ای طراحی شوند که رنگ 0 نمایان‌گر شفافیت کامل و رنگ 1 یک سیاه/خاکستری نیمه‌شفاف باشد، زیرا گرافیک‌های تک‌رنگ معمولاً برای سایه‌های وسایل نقلیه و ساختمان‌ها در انیمیشن‌ها استفاده می‌شوند.

بنابراین می‌توان بسیاری از گرافیک‌ها را ترکیب کرد.

ماژول مسکونی محافظت شده (پلیموت)

انیمیشن‌ها

حال به کلاس سلطنتی رشته‌ها در قالب‌های داده‌ای 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) ناشناخته 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) ناشناخته ۲

اطلاعات ناشناخته
0x0020 uint(32) تعداد فریم‌ها

تعداد فریم‌های انیمیشن موجود در این انیمیشن را نشان می‌دهد
0x0024 uint(32) تعداد ویندوز

تعداد پنجره‌هایی که هنگام ترسیم باید استفاده شوند را مشخص می‌کند

داده‌های لایه بالایی، که انیمیشن را شامل می‌شود، عمدتاً داده‌های مدیریتی هستند - Boundingbox به مختصات علامت‌گذاری اطراف خودرو/ساختمان اشاره دارد، زمانی که آن انتخاب شده باشد و همچنین مشخص می‌کند که کدام ناحیه باید قابل کلیک باشد.

آفست عمدتاً "نقطه صفر" را تعیین می‌کند؛ نقطه‌ای که باید به مختصات داخلی بازی اضافه یا از آن کم شود. به طور ریاضی می‌توان گفت: آفست در اینجا به مبدأ مختصات اشاره دارد.

در ویندوزها، همان‌طور که در مورد آفست صحبت کردیم، هر کدام (برای هر ویندوز) شامل ۴ مقدار uint(32) هستند، که یک ناحیه را مشخص می‌کند که برای زیرچارچوب‌های جداگانه قابل استفاده است. خارج از ویندوزها، تا زمانی که برای بیت‌مپ به‌طور مناسب در نظر گرفته شده باشد، نباید طراحی شود.

چارچوب

آدرس x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF شخصیت
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
آدرس جابه‌جایی نوع داده نام توضیح
0x0000 uint(8) تعداد زیرچارچوب و سوییچ برای گزینه ۱، ۲

این مقدار شامل:

  • 0x7F (ماسک بیت): تعداد ساب‌فریم‌هایی که در این فریم استفاده می‌شوند
  • 0x80: اطلاعاتی درباره اینکه آیا گزینه ۱ و ۲ موجود هستند یا نه
0x0001 uint(8) ناشناس ۱ و سوئیچ برای اختیاری ۳، ۴

این مقدار شامل:

  • 0x7F (ماسک بیت): ناشناخته - من به شدت گمان می‌زنم که این تعداد گیم‌تیک‌ها است که باید بگذرد تا فریم بعدی نمایش داده شود
  • 0x80: اطلاعاتی درباره اینکه آیا گزینه‌های 3 و 4 موجود هستند یا خیر
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) ناشناخته 1

نامشخص است - اما من به شدت فرض می‌کنم که این مربوط به اولویت رندر (لایه Z) است.
0x0003 uint(8) شناسه زیرسازه

مشخص می‌کند که در کدام زیرچارچوب قرار داریم
0x0004 sint(16) افست - افقی

مشخص کنید که زیر قاب باید در کجا داخل قاب اصلی قرار گیرد، یا اینکه بیت‌مپ باید به اندازه چند پیکسل به صورت افقی جابه‌جا شود.
0x0006 sint(16) افست - عمودی

مشخص می‌کند که زیرچارچوب باید در کجا درون چارچوب قرار گیرد، یا اینکه بیت‌مپ به اندازه چند پیکسل به صورت عمودی جابجا شود.

بدین ترتیب می‌توانیم فریم‌های فردی و همچنین انیمیشن‌های کامل را به طور مناسب کنار هم قرار دهیم، که در اینجا به عنوان یک نمونه در یک انیمیشن پیچیده‌تر، انیمیشن با ایندکس 500 نشان داده شده است.

انیمیشن 500

انیمیشن 500 نشان می‌دهد که چگونه یک کامیون حمل و نقل پلیموث که با سنگ معدن معمولی بارگیری شده است، تخلیه می‌شود. این یکی از معدود انیمیشن‌هایی است که از قابلیت پنجره‌ای استفاده می‌کند.

و اینگونه می‌توان انیمیشن کامل را کنار هم قرار داد.
متأسفانه هنوز یک مشکل با دریچه بارگیری بالایی وجود دارد، زیرا در اینجا بیت مربوطه در اطلاعات نوع گرافیک تنظیم نشده است.

در اینجا همچنین چندین اسپرایت زیبا و متحرک دیگر از بازی وجود دارد:

رندرینگ انیمیشن 500 را نشان می‌دهد

انیمیشن 500 به طور کامل کنار هم قرار گرفته است

کارخانه ساختمان پلایموث

پایگاه فضایی ایدن

مرکز پزشکی ایدن

SCAT

پایگاه فضایی پلایموث

تخم‌مرغ عید پاک:
بابا نوئل

تخم‌مرغ عید پاک:
سگ دان

رابط کاربری

اکنون رابط کاربری بازی باقی مانده است که به سبک فلز برس‌خورده طراحی شده است.

اما در اینجا نیز مشخص است که Dynamix نیازی به اختراع دوباره چرخ نداشته است؛ در اینجا تنها از APIهای User32 و GDI32 که توسط ویندوز ارائه شده‌اند استفاده نشده است - به ویژه مدیریت منابع User32 نیز به کار گرفته شده است.

این‌ها را می‌توان به عنوان مثال با برنامه‌ای مانند Resource Hacker که توسط Angus Johnson به عنوان نرم‌افزار رایگان توسعه یافته است، یا - اگر از استفاده Wine در لینوکس / مک‌اواس پرهیز می‌کنید - با کمک wrestool که در icoutils گنجانده شده است، استخراج کرد.

نام فایل محتوا
Outpost2.exe فقط شامل آیکون بازی است که ایستگاه فضایی را در نیوتررا نشان می‌دهد
op2shres.dll شامل گرافیک‌هایی برای عناصر کنترلی مانند حاشیه‌ها، دکمه‌ها، دکمه‌های رادیویی و چک باکس‌ها، همچنین پس‌زمینه‌های دیالوگ، تصاویر همراه برای متون ماموریت داستان و گرافیک پس‌زمینه منوی اصلی است
out2res.dll شامل دکوراسیون پنجره‌های درون بازی، آیکون‌ها برای فلزات معمولی و خاص، صفحه بارگذاری، گرافیک‌های دیالوگ و گرافیک‌های دیگر نشانگرها، به‌علاوه نشانگرهای متحرک در دایرکتوری بازی است