Outpost 2 Dosya Formatları · bei.pm

Outpost 2 tarafından kullanılan veri formatları JFIF / PNG'yi andıran bir yapıya sahiptir - bireysel veri blokları her zaman 8 baytlık bir başlığa sahiptir. Bu nedenle, ilgili spesifik yerlerde bireysel başlıkları belgelemekten kaçınıyorum ve sadece sapmaları belgelemeye karar verdim.

Format her zaman aşağıdaki gibidir; asıl veri iç içe yerleştirilmiştir:

Volume'lar, oyuna ait bir veri konteyneridir ve Tarball gibi arşiv formatlarına benzer. En azından Outpost 2'de bu format yalnızca dosyaları tanır - klasör yoktur. Bunlar, muhtemelen ilgili dosya adlarıyla simüle edilebilir.

Bir Volume, Volume başlığı ve belirli dosyalara karşılık gelen birden fazla Volume bloğundan oluşur.

"Volumes", oyun dizinindeki 'vol' uzantısına sahip dosyalardır.

Hacim Başlığı kendisi herhangi bir kullanıcı verisi içermez.
Sadece bir konteyner olarak hizmet eder.

Hacim Başlığındaki ilk veri, hacim dizgileri olmalıdır; ardından hacim bilgileri gelmektedir.

Volume Strings, hacim içinde bulunan dosya adlarının bir listesidir.

Hacim bilgileri, dosyalarla ilgili daha ayrıntılı bilgileri alır. Bu, bir nevi FAT dizin girişi gibidir (FAT = Dosya Dağıtım Tablosu).

Dosya sayısı, blok boyutunun dizin girişlerinin uzunluğuna - 14 Bayt'a bölünmesiyle elde edilir.

Bireysel dizin girişleri ise şu yapıya sahiptir:

Volume bloğu, dosyaları barındıran bir kapsayıcıdır. Sadece blok formatı nedeniyle dosya boyutunu tekrar - redunant olarak - içerir ve ardından doğrudan kullanım verileri gelir.

Tiles, Outpost-2'ye özgü bir Bitmap grafik formatıdır. 13 Tileset'e yayılmaktadır, "well" olarak adlandırılan (well0000.bmp ile well0012.bmp), maps.vol dosyasının içinde bulunmaktadır.

Tilesetler / Wells aşağıdakileri içermektedir:

Verimli bir uygulama için, verilerin henüz işlenmesi gerektiğinden ve çok fazla veri oluşacağından, karoların önceden render edilip önbelleğe alınmaması tavsiye edilir.

Karolar, her biri 32x32 piksel çözünürlüğünde endeksli paletle 8bpp grafiklerdir ve birbirlerinin üzerine yerleştirilmiştir. Ancak, böyle oluşan bir karo setinde çok daha fazlası olabilir.

Ana konteyner, head ve data olmak üzere 2 bölümden oluşmaktadır.

Bu bilgilerin ardından, standartlaştırılmış RIFF formatında bir palet dosyası sunulacaktır. Tam spesifikasyon, paletlerin başka yerlerde de ortaya çıkması nedeniyle Paletler altında bulunmaktadır.

Sonunda, soldan yukarıdan sağa aşağıya doğru satır satır piksel verileri geliyor.
Genelde 8bpp bitmap olarak bulunan grafiklerdeki veri değeri, renk paletindeki rengin indeksine karşılık gelir.

Oyun motoru, karoları *muhtemelen* talep üzerine çiziyor.
Bu, 32 farklı karonun bulunduğu gün-gece döngüsüne bağlı gibi görünüyor. Görünüşe göre, her seferinde parlaklık değerinden 'biraz' düşülüyor. Kesin değerler henüz belirlenemedi, hesaplama temeli üzerinde çalışıyorum.

v *= (daylight / 48) + 0.25;

Piksellerin HSV verileri ile birlikte, burada daylight 0-31 arasında bir değerdir ve v 0-1 arasında bir değerdir. Ayrıca, haritada her iki tarafa da 16 karodan oluşan bir kenar bulunduğunu dikkate almak önemlidir (bu, birimlerin görünmez bir şekilde doğmasını sağlamak için gereklidir).

Ayrıca, gün-gece döngüsü her oyun döngüsünde haritanın yalnızca bir sütununu güncellemektedir.
İleriye alınmış bir gün-gece döngüsü şu şekilde görünmektedir:

PRT tam olarak ne anlama geliyor bilmiyorum; örneğin 'Palette and Resource Table' olması düşünülebilir - çünkü bu dosya, op2_art.prt olarak maps.vol içinde bulunuyor ve bu, bir palet tablosu olduğu için veya işlevini iyi tanımlayabileceği için böyle bir isimlendirme mantıklı olabilir.

Bu dosya, paletlerin bir listesini, kullanılan tüm bitmap'lerin bir tablosunu, tüm animasyon tanımlarını ve ayrıca bir dizi bilinmeyen veriyi içermektedir. Şu ana kadar kullanılan konteyner formatına kısmen uymaktadır, çünkü tüm kayıtlar bu şemaya uymamaktadır.

CPAL bölümü (muhtemelen palet konteyneri anlamına geliyor) yalnızca palet verilerini içermekte, her biri genellikle 1052 byte boyutunda olan 8-bit paletlerin ne kadarının mevcut olduğunu belirtmektedir.

1052 byte'lık tanım bağlayıcı olarak kabul edilmez, çünkü palet formatı potansiyel olarak farklı palet boyutlarını içerebilir. Bu, sadece Outpost 2 ile birlikte sunulan veri seti için geçerlidir.

Palet listelerinden sonra hemen ve önceden bir başlık olmadan, bitmap'lerin listesi gelir; ardından animasyon listeleri hemen devam eder.
Her biri, kayıt sayısını içeren bir uint(32) (veya tekrar uint24+uint8 bayrakları?) ile başlar.

Palet bilgileri oldukça kolay bir şekilde okunabilir.
Her biri bir başlık ve bir veri segmentinden oluşur.

Veri bölümü, bireysel palet kayıtlarını alır. Palet kayıtlarının sayısı, blok uzunluğu / 4 ile belirlenir.

Bireysel kayıtların basit bir yapısı vardır;

Paletler hakkında söyleyebileceğim tek şey, animasyonlarda kullanılacak paletler için aşağıdaki kuralların geçerli olduğudur:

• İlk renk HER ZAMAN şeffaftır, orada belirtilen değere bakılmaksızın.
• Palet girişleri 1-24, palet 1-8'de oyuncu rengi olarak değerlendirilmektedir.
  Renklerin oyuncu 1 dışında tam olarak nereden geldiği belirsiz.
  Diğer renklerin sabit kodlandığını tahmin ediyorum.

PRT dosyasının bu veri yapısı, sprite'lar için kullanılan bitmap'lerin nasıl yapılandırıldığını belirtir. Bu bitmap'ler, bir sprite'ın animasyon karesi için bir araya getirilen birçok parçadan biri olarak hizmet eder.

Belirli resim verileri ise oyunun dizininde bulunan op2_art.BMP dosyasında gizlidir.
Neden bu bitmap dosyası (genelde doğru olan) bir RIFF bitmap başlığına sahip olduğu belirsizdir. Muhtemelen Outpost 2, bu başlığı geçici olarak alarak ve ilgili değişken alanları üst üste yazarak grafiklerin yüklenmesi için sistem API'lerini kullanıyor.

Piksel verileri BMP dosyasında, BMP dosyasında 0x000A adresinde bulunan uint32 ofseti ile ofset toplamında, bulunabilir - ve bu, yukarıdan sola doğru aşağıya sıralı düzenlemeye karşılık gelir.

Monokrom 1bpp grafikler, renk 0'ın tam saydamlık ve renk 1'in yarı saydam siyah/gri olacak şekilde çizilebilir, çünkü monokrom grafikler genellikle animasyonlarda araç ve bina gölgeleri için kullanılır.

Böylece birçok grafiği bir araya getirmek mümkündür.

Şimdi Outpost 2 veri formatları içindeki disiplinlerin kraliyet sınıfına geliyoruz:
Animasyonlar.

Animasyon listeleri, öncelikle veri doğrulama amacı taşıyan bir küresel başlık ile başlar. Bunun ardından üç aşamada yapılandırılmış somut animasyon tanımları gelir:

1. Animasyon
   Bir animasyon en üst düzeydeki varlıktır; bir birimin, bir binanın veya bir 'parçacık animasyonu'nun (kuyruklu yıldız çarpması, hava durumu, patlama) belirli bir başlangıç durumundaki animasyonunu temsil eder.
2. Çerçeve
   Bir çerçeve, bir animasyon içindeki tek bir görüntüdür. Bir animasyon bir veya daha fazla çerçeve içerebilir.
3. Alt Çerçeve
   Bir alt çerçeve, belirli bir bitmap'ın belirli kriterler altında bir çerçevenin belirli bir konumuna çizilmesi gerektiği bilgilerini içerir. Bir çerçeve bir veya daha fazla alt çerçeve içerebilir.

Bundan sonra doğrudan bireysel animasyon tanımları geliyor.

Üst katmanın, animasyonun verileri öncelikle yönetim verileridir - Boundingbox, aracın/binanın etrafındaki işaretlemenin koordinatlarını belirtir; bu, seçildiğinde gösterilir ve aynı zamanda hangi alanın tıklanabilir olduğunu belirtir.

Offset, öncelikle "sıfır noktasını" belirler; oyun içindeki koordinatlarla hesaplanması veya çıkarılması gereken noktadır. Daha matematiksel bir ifadeyle, offset burada koordinatların kökünü belirtir.

Windows, offset gibi, her biri 4 uint(32) değeri olan ve belirli alt çerçeveler için kullanılabilir olan bir alanı belirtir. Windows dışında, bitmap için uygun olduğu sürece çizim yapılamaz.

Bununla şimdi tekil kareleri ve aynı zamanda tamamı animasyonları uygun şekilde bir araya getirebiliriz. Burada, 500 indeksine sahip daha karmaşık bir animasyon örneği ile gösterilmektedir.

Animasyon 500, sıradan madenle yüklü bir Plymouth taşıyıcısının nasıl boşaltıldığını gösteriyor. Bu, pencereleme işlevselliğini kullanan az sayıda animasyondan biridir.

Ve böylece tam animasyonu birleştirebiliriz.
Maalesef, üst yükleme kapağıyla ilgili bir sorun var, çünkü burada grafik türü bilgilerinde ilgili bit ayarlanmamış.

Oyundan birkaç başka güzel animasyonlu sprite daha burada:

Artık oyunun fırçalanmış metal görünümüne sahip kullanıcı arayüzü eksik.

Ama burada da Dynamix'in tekerleği yeniden icat etmesi gerekmiyor; burada yalnızca Windows'un sağladığı User32 ve GDI32 API'leri basit bir şekilde kullanılmıyor - özellikle User32'nin kaynak yönetimi de kullanılıyor.

Bunlar, örneğin Angus Johnson tarafından geliştirilmiş olan Resource Hacker gibi programlar aracılığıyla veya Linux / Mac OS'ta Wine kullanımından kaçınıyorsanız, icoutils içinde bulunan wrestool yardımıyla çıkarılabilir.