פורמטי קובץ של 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. זה מצביע על כך שמדובר בקבוצת דגלים.

נפחים

הוולומות הם מיכל נתונים עבור המשחק, דומה לפורמט ארכיון כמו 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.

אין צורך לנתח את בלוק הנתונים הזה בצורה מדויקת בעת פענוח הנתונים, מכיוון שבפרטי הנפח בכל מקרה מתייחסים ישירות ל-offsets של שמות הקבצים.

המחרוזות של הווליום הן רשימה של שמות קבצים שנמצאים בתוך הווליום.

מידע על עוצמה

אדר 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. הם מתפרסים על פני 13 סטי טיילים, המכונים "בורות" (well0000.bmp עד well0012.bmp), שממוקמים בתוך הנפח maps.vol.

סטי הטיילים / הבורות מכילים את הדברים הבאים:

שם קובץ תוכן
well0000.bmp גרפיקה בגודל 32x32 פיקסלים בצבע כחול - אידיאלי לבדוק אם ה-Image Loader שלך פועל
well0001.bmp מכיל סלעים בהירים, רכסי הרים על סלעים בהירים ומגוון אינסופי של מכתשים בסלעים בהירים
well0002.bmp מכיל 'Doodads' בסלעים בהירים - כלומר אלמנטים שניתן למקם כדי להקל על הסביבה (או במודע כ strucure, כמו לדוגמה חומות), כולל גם צמחייה
well0003.bmp מכיל מבנה קרסטי על סלעים בהירים
well0004.bmp מכיל סלעים כהים, רכסי הרים על סלעים כהים ומגוון אינסופי של מכתשים בסלעים כהים
well0005.bmp מכיל 'Doodads' בסלעים כהים - כלומר אלמנטים שניתן למקם כדי להקל על הסביבה (או במודע כ strucure, כמו לדוגמה חומות) על סלעים כהים
well0006.bmp מכיל מבנה קרסטי על סלעים כהים, כמו גם מעברים בין סלעים בהירים וכהים
well0007.bmp מכיל לבה כולל 4-5 פריימים של אנימציה שלה
well0008.bmp מכיל חול ומגוון אינסופי של מכתשים בחול
well0009.bmp מכיל 'Doodads' בחול - כלומר אלמנטים שניתן למקם כדי להקל על הסביבה (או במודע כ strucure, כמו לדוגמה חומות) על חול
well0010.bmp מכיל 48 מעברים מחול לסלעים בהירים וכהים
well0011.bmp מכיל את כיפות הקוטב של המפה, עם סלעים כהים כרקע
well0012.bmp מכיל את כיפות הקוטב של המפה, עם סלעים בהירים כרקע

נראה כי עדיף לבצע את היישום המדויק מבלי לרנדר את הטיילים מראש כדי לשמור אותם במטמון, שכן הנתונים עבור מחזור היום/לילה עדיין צריכים להיות מעובדים - ויתקבלו המון המון נתונים.

הטיילים הם גרפיקות באיכות 8bpp עם פלטה אינדקסית ברזולוציה של 32x32 פיקסלים, הממוקמות זו מעל זו. עם זאת, בסט טיילים שנוצר כך ניתן לכלול הרבה יותר.

המיכל הראשי מורכב משתי секции: 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) עומק צבע 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-Bitmaps, תואם לאינדקס הצבע בפלטת הצבעים.

נתוני הפיקסלים מתחילים בפינה העליונה השמאלית ומסתיימים בפינה התחתונה הימנית.

המנוע של המשחק מצייר את ה-Tiles *כנראה* על פי דרישה.
נראה שזה קשור בין היתר למחזור יום ולילה, שמכיר ב-32 דרגות שונות של Tiles. כנראה שהערך של הבהירות מופחת 'מעט' בכל פעם. ערכים מדויקים עדיין לא ניתן היה לקבוע, אני עובד על בסיס החישוב

v *= (daylight / 48) + 0.25;

עם נתוני ה-HSV של הפיקסלים, כאשר daylight הוא ערך בין 0-31 ו-v הוא ערך בין 0-1. נוסף על כך, יש לקחת בחשבון שעל המפה ישנם קצוות של 16 Tiles משמאל ומימין (הם מיועדים להפקת יחידות בצורה בלתי נראית).

בנוסף, נראה שהמחזור יום-לילה מעדכן בכל מחזור משחק רק עמודה אחת של המפה.
מחזור יום-לילה מואץ נראה לכן כך:

ויזואליזציה של מחזור יום-לילה

פלטת משאבים וטבלאות

אדר 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 בתים אינו מחייב, מכיוון שפormat הפלטות יכול להציע גדלים שונים לפלטות. הוא תקף רק עבור המידע שמסופק עם 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).

מידע על הפלטות קל מאוד לקרוא.
הוא מורכב כל אחד מראש ובס Segment נתונים.

כותרת פלטות

אדר 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) דגלים

קטע הנתונים כולל את רשומות הפלטות einzelnen. מספר רשומות הפלטות נגזר מאורך הבלוק / 4.

לרשומות einzelnen יש את המבנה הפשוט הבא;

אדר 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) לא ידוע - דגלים?

לא ברור מה המשמעות של ערך זה, מכיוון שהוא aparentemente 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) אופסט

מציין את ההזזה של השורה הראשונה ב-Bitmap

0x0008 uint(32) גובה

מציין את גובה התמונה בפיקסלים

0x000c uint(32) רוחב

מציין את רוחב התמונה בפיקסלים

0x0010 uint(16) טיפ

מציין את סוג התמונה. נראה שמדובר במסכת ביטים:

  • 0x04 מוגדר כאשר מדובר בגרפיקה של 1bpp.
  • 0x40 מוגדר כאשר מדובר בגרפיקה שצריכה ליישם חלון.
0x0012 uint(16) פלטה

מגדיר איזו פלטה מקובץ ה-PRT יש להשתמש

מבנה הנתונים של קובץ ה-PRT מציין כיצד הביטמפים שמשמשים עבור הספראיטים בנויים. ביטמפים אלו משמשים כמרכיב בודד, ממנו מרכיבים מספר פריטים למסגרת אנימציה של ספראיט.

נתוני התמונה הקונקרטיים מסתתרים לעומת זאת ב- op2_art.BMP בתיקיית המשחק.
מדוע קובץ הביטמפ הזה כולל כותרת RIFF-Bitmap (בעיקר נכונה), אינו ברור. סביר להניח ש-Outpost 2 משתמש ב-APIs של מערכת כדי לטעון את הגרפיקות, על ידי כך שכותרת זו מאומצת באופן זמני והשטחים המשתנים המתאימים נכתבים מחדש.

נתוני הפיקסלים נמצאים בקובץ ה-BMP במיקום של ה-offset + ה-offset uint32, שנמצא בקובץ ה-BMP בכתובת 0x000A (ה-offset נתוני RIFF-Bitmap), ונמצאים שוב בסידור שורות מלמעלה למטה מימין לשמאל.

גרפיקות מונו-כרומטיות 1bpp יכולות להיות מצויירות כך שצבע 0 הוא שקיפות מלאה, וגם צבע 1 הוא שחור/אפור חצי שקוף, מכיוון שגרפיקות מונו-כרומטיות נמצאות בשימוש בדרך כלל עבור צללים של רכבים ומבנים באנימציות.

כך אפשר כבר להרכיב הרבה גרפיקות.

מודול מגורים מוגן (פליומאת')

אנימציות

עכשיו אנחנו מגיעים לקטגוריה הגבוהה של הדיסציפלינות בתוך הפורמטים של 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) קופסה מגודרת: למעלה

מציין את ההתחלה העליונה (בפיקסלים) של Bounding Box.

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 מציין את הקואורדינטות של הסימון סביב הרכב/בניין, כאשר הוא נבחר ומציין גם בו זמנית איזה אזור ניתן ללחוץ עליו.

ה-Offset קובע בעיקר את "נקודת האפס"; הנקודה שיש לחשב או להחסיר על פי קואורדינטות פנימיות של המשחק. ניתן גם לומר באופן מתמטי: ה-Offset מציין כאן את מקור הקואורדינטות.

בהתאם לחלונות, כמו גם עם ה-Offset, מדובר ב-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 (מסיכת ביטים): מספר התתי-frames שבהם נעשה שימוש במסגרת זו
  • 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) Bitmap-מזהה

ציין איזו ביטמאפ יש להשתמש עבור תת-המסגרת הזו

0x0002 uint(8) לא ידוע 1

זה לא ידוע - עם זאת, אני חושד חזק שזה נוגע לעדיפות רינדור (שכבת Z).

0x0003 uint(8) תעודת זהות תת-מסגרת

מראה באיזה תת-מסגרת אנחנו נמצאים

0x0004 sint(16) הסטה - אופקית

מציין היכן בתוך המסגרת יש למקם את הסאב-פריים, או בכמה פיקסלים יש להזיז את הביטמפה אופקית

0x0006 sint(16) אופסט - אנכי

ציין היכן בתוך המסגרת יש למקם את תת-המסגרת, או במדויק בכמה פיקסלים יש להזיז את התמונה באופן אנכי

בעזרת זה אנחנו יכולים עכשיו להרכיב פריימים בודדים, כמו גם אנימציות שלמות בהתאם, כאן לדוגמה על אנימציה מורכבת יותר, האנימציה עם האינדקס 500, מדגימים

אנימציה 500

אנימציה 500 מראה כיצד מסחרית פלימות' המלאה במינרלים רגילים מתפרקת. זו אחת מהאנימציות הבודדות שעושות שימוש בפונקציה של חלונות.

כך ניתן להרכיב את האנימציה המלאה.
לצערנו, ישנה בעיה עם מכסה הטעינה העליון, שכן הביט המתאים במידע על סוג הגרפיקה לא מוגדר כאן.

הנה עוד כמה ספרייטים מעוצבים בצורה יפה מתוך המשחק:

רינדור של אנימציה 500 מראה

אנימציה 500 מורכבת במלואה

מפעל בניין פלימות'

נמל חלל עדן

מרכז רפואי עדן

SCAT

נמל חלל פלימות'

הפתעה:
סנטה קלאוס

הפתעה:
כלב דן

ממשק משתמש

עכשיו חסר רק את ממשק המשתמש של המשחק, אשר מעוצב בסגנון מתכת מוברשת.

אבל גם כאן ניתן לראות שDynamix לא הייתה צריכה להמציא את הגלגל מחדש; כאן לא רק נעשה שימוש פשוט ב-User32 וב-GDI32-APIs שסיפקה Windows - במיוחד נעשה גם שימוש בניהול המשאבים של User32.

אלה יכולים להיות מופקים, לדוגמה, על ידי תוכניות כמו Resource Hacker שפותחה על ידי Angus Johnson כהפקה חופשית, או - אם אתם נמנעים משימוש ב-Wine תחת Linux / Mac OS - באמצעות wrestool הכלול ב-icoutils.

שם קובץ תוכן
Outpost2.exe מכיל רק את האייקון של המשחק, שמציג את תחנת החלל לפני New Terra
op2shres.dll מכיל גרפיקות עבור רכיבי ממשק כמו מסגרות, כפתורים, כפתורי רדיו ותיבות סימון, כמו גם רקעים לדיאלוגים, תמונות ליווי לטקסטי משימות סיפור ורקע למסך הראשי
out2res.dll מכיל את עיצוב חלונות המשחק, אייקונים למתכת רגילה ומיוחדת, מסך טעינה, גרפיקות לדיאלוגים וכן גרפיקות נוספות של עכבר, בנוסף לאלו המונפשות בתיקיית המשחק