Outpost 2 Μορφές Αρχείων · bei.pm

Τα δεδομένα που χρησιμοποιούνται από το Outpost 2 έχουν μια δομή που θυμίζει JFIF / PNG - τα διάφορα μπλοκ δεδομένων διαθέτουν πάντα έναν επικεφαλίδα 8 byte. Γι' αυτό και παραλείπω να τεκμηριώσω τις επιμέρους επικεφαλίδες στα αντίστοιχα συγκεκριμένα σημεία και καταγράφω μόνο τις αποκλίσεις εκεί.

Η μορφή είναι πάντα η εξής; τα πραγματικά χρήσιμα δεδομένα είναι ενσωματωμένα μέσα σε αυτήν:

Τα volumes είναι ένα δοχείο δεδομένων για το παιχνίδι, παρόμοιο με ένα αρχείο αρχειοθέτησης όπως το Tarball. τουλάχιστον στο Outpost 2, η μορφή αυτή περιλαμβάνει μόνο αρχεία - όχι φακέλους. Πιθανώς θα μπορούσαν να προσομοιωθούν αυτοί μέσω κατάλληλων ονομάτων αρχείων.

Ένα volume αποτελείται από την κεφαλίδα του volume καθώς και από πολλαπλά blocks volume, που αντιστοιχούν στα συγκεκριμένα αρχεία.

"Volumes" είναι τα αρχεία με την κατάληξη 'vol' στον φάκελο του παιχνιδιού.

Η κεφαλίδα όγκου δεν περιέχει καμία χρήσιμη δεδομένα.
Απλώς χρησιμεύει ως κοντέινερ.

Ως πρώτη ημερομηνία στην κεφαλίδα όγκου θα πρέπει να βρίσκονται οι συμβολοσειρές όγκου; ακολουθούν οι πληροφορίες όγκου.

Οι Volume Strings είναι μια λίστα από ονόματα αρχείων που περιέχονται μέσα στο volume.

Οι πληροφορίες όγκου περιλαμβάνουν λεπτομερείς πληροφορίες για τα αρχεία. Αυτές είναι σε κάποιο βαθμό μια μορφή καταχώρισης στον κατάλογο FAT (FAT = Πίνακας Κατανομής Αρχείων).

Ο αριθμός των αρχείων προκύπτει από το μέγεθος του μπλοκ διαιρεμένο με το μήκος των καταχωρίσεων του καταλόγου - 14 byte.

Οι μεμονωμένες καταχωρίσεις του καταλόγου έχουν την εξής δομή:

Ένας όγκος-μπλοκ είναι ένα δοχείο που περιέχει αρχεία. Περιλαμβάνει μόνο ξανά - λόγω της μορφής μπλοκ - επικαλύπτει το μέγεθος του αρχείου και αμέσως μετά ακολουθούν άμεσα τα δεδομένα χρήσης.

Τα Tiles είναι μια συγκεκριμένη μορφή γραφικών Bitmap για το Outpost-2. Εκτείνονται σε 13 σύνολα Tiles, που ονομάζονται "wells" (well0000.bmp έως well0012.bmp), τα οποία βρίσκονται εντός του όγκου maps.vol.

Τα σύνολα Tiles / Wells περιλαμβάνουν τα εξής:

Είναι σκόπιμο για μια ακριβή εφαρμογή να μην αποδοθούν τα tiles εκ των προτέρων για να αποθηκευτούν στη μνήμη cache, καθώς τα δεδομένα για τον κύκλο ημέρας/νύχτας πρέπει ακόμα να επεξεργαστούν - και θα προκύψουν πολύ, πολύ περισσότερα δεδομένα.

Τα tiles είναι γραφικά 8bpp με δειγματοληπτική παλέτα, με ανάλυση 32x32 pixel, τα οποία είναι διατεταγμένα το ένα κάτω από το άλλο. Σε ένα τέτοιο δημιουργηθέν tileset μπορούν ωστόσο να περιλαμβάνονται πολύ περισσότερα.

Ο κύριος κοντέινερ αποτελείται από 2 ενότητες: head και data.

Μετά από αυτές τις πληροφορίες ακολουθεί ένα αρχείο παλέτας που είναι διαθέσιμο στην τυποποιημένη μορφή RIFF. Η ακριβής προδιαγραφή μπορεί να βρεθεί - καθώς οι παλέτες εμφανίζονται και αλλού - στην Παλέτες.

Τέλος, ακολουθούν τα γυμνά δεδομένα pixel, από πάνω αριστερά προς τα κάτω δεξιά, γραμμή-γραμμή.
Η τιμή των δεδομένων για τις γραφικές παραστάσεις που συνήθως είναι σε μορφή 8bpp-Bitmaps αντιστοιχεί στον δείκτη του χρώματος στην παλέτα χρωμάτων.

Η μηχανή παιχνιδιών σχεδιάζει τα Tiles *πιθανώς* κατ' απαίτηση.
Αυτό φαίνεται να οφείλεται μεταξύ άλλων στον κύκλο ημέρας-νύχτας, ο οποίος έχει 32 κλίμακες για τα μεμονωμένα Tiles. Προφανώς, αφαιρείται 'λίγο' από την τιμή φωτεινότητας. Ακριβείς τιμές δεν έχουν ακόμη προσδιοριστεί, εργάζομαι με τη βάση υπολογισμού

v *= (daylight / 48) + 0.25;

με τα δεδομένα HSV των pixels, όπου το daylight είναι μια τιμή από 0-31 και το v είναι μια τιμή μεταξύ 0-1. Επιπλέον, πρέπει να ληφθεί υπόψη ότι στον χάρτη υπάρχει μια περιφέρεια 16 Tiles αριστερά και δεξιά (η οποία εξυπηρετεί την αόρατη εμφάνιση μονάδων).

Eπιπλέον, ο κύκλος ημέρας-νύχτας φαίνεται να ενημερώνει μόνο μια στήλη του χάρτη ανά κύκλο παιχνιδιού.
Ένας επιταχυμένος κύκλος ημέρας-νύχτας φαίνεται έτσι:

Για τι ακριβώς σημαίνει PRT δεν είναι γνωστό σε μένα; Ένα πιθανό παράδειγμα θα ήταν 'Πίνακας Παλέτας και Πόρων' - καθώς αυτό το αρχείο - που βρίσκεται ως op2_art.prt στο maps.vol - αφορά κάτι τέτοιο, ή θα περιέγραφε τη λειτουργία αρκετά καλά.

Αυτό το αρχείο περιέχει μια λίστα παλετών, έναν πίνακα με όλες τις χρησιμοποιούμενες bitmap, όλους τους ορισμούς animations και μια σειρά από άγνωστα δεδομένα. Ακολουθεί χαλαρά την υπάρχουσα μορφή κοντέινερ, καθώς δεν όλα τα αρχεία δεδομένων ακολουθούν αυτό το σχήμα.

Η ενότητα CPAL (πιθανώς σημαίνει κοντέινερ παλετών) περιλαμβάνει μόνο τα δεδομένα της παλέτας, υποδεικνύοντας πόσες από τις συνήθως 1052 byte μεγάλες 8-bit παλέτες υπάρχουν.

Η αναφορά των 1052 byte δεν θεωρείται υποχρεωτική, καθώς η μορφή παλέτας θα μπορούσε ενδεχομένως να περιλαμβάνει διαφορετικά μεγέθη παλέτας. Ισχύει μόνο για το σύνολο των δεδομένων με το οποίο παραδίδεται το Outpost 2.

Μετά τις λίστες παλετών ακολουθεί άμεσα και χωρίς εισαγωγικό header, η λίστα των bitmap; ακριβώς μετά ακολουθούν οι λίστες animations.
Και οι δύο αρχίζουν αντίστοιχα με ένα uint(32) (ή πάλι uint24+uint8 flags?) που περιέχει τον αριθμό των δεδομένων.

Οι πληροφορίες των παλετών είναι πολύ εύκολες στην ανάγνωση.
Αποτελούνται από έναν τίτλο και ένα τμήμα δεδομένων.

Η ενότητα δεδομένων περιλαμβάνει τις μεμονωμένες καταχωρίσεις παλετών. Ο αριθμός των καταχωρίσεων παλετών προκύπτει από το μήκος του μπλοκ / 4.

Οι μεμονωμένες καταχωρίσεις έχουν την εξής απλή δομή.

Για τις παλέτες, πρέπει να σημειωθεί ότι για τις παλέτες που χρησιμοποιούνται σε animation ισχύουν οι εξής κανόνες:

• Το πρώτο χρώμα είναι ΠΑΝΤΑ διαφανές, ανεξαρτήτως της τιμής που έχει δηλωθεί εκεί.
• Οι εγγραφές παλέτας 1-24 θεωρούνται ως χρώμα παίκτη στις παλέτες 1-8.
  Δεν είναι σαφές από πού προέρχονται ακριβώς τα χρώματα εκτός από τον παίκτη 1.
  Υποθέτω ότι τα υπόλοιπα χρώματα είναι hardcoded.

Αυτή η δομή δεδομένων του αρχείου PRT δείχνει πώς είναι δομημένες οι bitmap που χρησιμοποιούνται για τα sprites. Αυτές οι bitmap υπηρετούν ως μεμονωμένα στοιχεία, από τα οποία πολλά συγκεντρώνονται σε ένα καρέ animation ενός sprite.

Τα συγκεκριμένα δεδομένα εικόνας βρίσκονται στην op2_art.BMP στον φάκελο του παιχνιδιού.
Γιατί αυτό το αρχείο bitmap διαθέτει έναν (κυρίως σωστό) RIFF header bitmap, είναι ασαφές. Πιθανότατα, το Outpost 2 χρησιμοποιεί System APIs για να φορτώσει τα γραφικά, υιοθετώντας προσωρινά αυτόν τον header και αντικαθιστώντας τα αντίστοιχα, μεταβλητά πεδία.

Τα δεδομένα pixel βρίσκονται στο αρχείο BMP στην θέση Offset + το uint32-Offset, που μπορεί να βρεθεί στο αρχείο BMP στη διεύθυνση 0x000A (RIFF-Bitmap-Datenoffset), και αντιστοιχούν ξανά στη γραμμική διάταξη από πάνω αριστερά προς τα κάτω δεξιά.

Μονοχρωματικά γραφικά 1bpp μπορούν να σχεδιαστούν έτσι ώστε το χρώμα 0 να είναι πλήρης διαφάνεια, ενώ το χρώμα 1 να είναι ένα ημι-διαφανές μαύρο/γκρί, καθώς τα μονοχρωματικά γραφικά συνήθως χρησιμοποιούνται για σκιές οχημάτων και κτιρίων στις animations.

Έτσι, μπορεί κανείς να συνθέσει πολλές γραφικές παραστάσεις.

Τώρα φτάνουμε στην κορυφαία κατηγορία των τομέων μέσα στα φορμά δεδομένων του Outpost 2:
Στις κινήσεις.

Οι λίστες κινήσεων αρχίζουν με μια παγκόσμια κεφαλίδα, η οποία χρησιμεύει κυρίως για την επαλήθευση των δεδομένων. Ακολουθούν οι συγκεκριμένες ορισμοί κινήσεων, οι οποίοι διακρίνονται σε 3 επίπεδα:

1. Κίνηση
   Μια κίνηση είναι η ανώτερη οντότητα; αναπαριστά μια κίνηση μιας μονάδας, ενός κτηρίου ή μιας 'κίνηση σωματιδίων' (πτώση κομήτη, καιρός, έκρηξη) σε μια συγκεκριμένη αρχική κατάσταση.
2. Καρέ
   Ένα καρέ είναι μια μεμονωμένη εικόνα μέσα σε μια κίνηση. Μια κίνηση μπορεί να περιλαμβάνει ένα ή περισσότερα καρέ.
3. Υποκαρέ
   Ένα υποκαρέ είναι η πληροφορία ότι μια συγκεκριμένη bitmap θα πρέπει να σχεδιαστεί σε μια συγκεκριμένη θέση ενός καρέ υπό συγκεκριμένα κριτήρια. Ένα καρέ μπορεί να περιλαμβάνει ένα ή περισσότερα υποκαρέ.

Αμέσως μετά ακολουθούν οι συγκεκριμένες ορισμοί κινήσεων.

Τα δεδομένα της ανώτερης στρώσης, της κινούμενης εικόνας, είναι κυρίως διοικητικά δεδομένα - η Boundingbox αναφέρεται στις συντεταγμένες της σήμανσης γύρω από το όχημα/κτίριο, όταν αυτό έχει επιλεγεί και υποδεικνύει ταυτόχρονα ποια περιοχή θα πρέπει να είναι κλικαριστή.

Η μετατόπιση (offset) προσδιορίζει κυρίως το "σημείο μηδέν"; το σημείο που πρέπει να προστεθεί ή να αφαιρεθεί στις εσωτερικές συντεταγμένες του παιχνιδιού. Θα μπορούσε κανείς να πει και μαθηματικά: η μετατόπιση αναφέρεται εδώ στην προέλευση των συντεταγμένων.

Όσον αφορά τα παράθυρα (Windows), όπως και η μετατόπιση, πρόκειται για 4 τιμές uint(32) ανά παράθυρο, οι οποίες υποδεικνύουν μια περιοχή που θεωρείται χρήσιμη για επιμέρους υποπλαίσια. Εκτός των παραθύρων δεν επιτρέπεται, αν δεν έχει προβλεφθεί κατάλληλα για την bitmap, να σχεδιαστεί.

Έτσι μπορούμε τώρα να συνθέσουμε μεμονωμένα καρέ, καθώς και ολόκληρες κινούμενες εικόνες, όπως θα δείξουμε εδώ με ένα πιο σύνθετο παράδειγμα, την κινούμενη εικόνα με τον δείκτη 500.

Η Animation 500 δείχνει πώς ένα Plymouth-μεταφορέας, που είναι φορτωμένος με συνηθισμένο μέταλλο, ξεφορτώνεται. Πρόκειται για μία από τις λίγες αναπαραστάσεις που αξιοποιούν τη λειτουργία παραθύρων.

Έτσι μπορεί να συνδυαστεί η πλήρης αναπαράσταση.
Δυστυχώς, υπάρχει ακόμα ένα πρόβλημα με την άνω πλευρά φόρτωσης, καθώς το αντίστοιχο bit στην πληροφορία τύπου γραφικών δεν έχει οριστεί.

Εδώ είναι μερικά ακόμα πανέμορφα κινούμενα sprites από το παιχνίδι:

Τώρα λείπει το περιβάλλον χρήστη του παιχνιδιού, το οποίο έχει σχεδιαστεί με την εμφάνιση βουρτσισμένου μετάλλου.

Αλλά και εδώ είναι σαφές ότι Dynamix δεν χρειάστηκε να εφεύρει τον τροχό εκ νέου; εδώ δεν χρησιμοποιούνται απλώς οι APIs User32 και GDI32 που παρέχονται από τα Windows - ιδίως χρησιμοποιείται και η διαχείριση πόρων από το User32.

Αυτά μπορούν να εξαχθούν, για παράδειγμα, μέσω προγραμμάτων όπως το Resource Hacker, που έχει αναπτυχθεί από τον Angus Johnson ως freeware, ή - αν κάποιος διστάζει να χρησιμοποιήσει το Wine σε Linux / Mac OS - με τη βοήθεια του wrestool που περιλαμβάνεται στο icoutils.