Kartuş tabanlı oyunlar nasıl programlandı? [kapalı]

Sanırım bugün SNES, N64, Atari ... hatta DS gibi düşünüyorum.

SNES oyunları genellikle 4 MB'tan fazla yer kaplamaz ve N64 oyunları genellikle 32-64 MB'lık veri tutarıdır.

Bugünlerde zar zor "merhaba dünya!" 1.21 gigabayt üreten derleme olmadan program !! Verilerin (Bir kenara şaka yapıyorum, bugünkü dosyalar o zamanlar teknolojinin bir kısmına kıyasla tonlarca ve yer kaplıyor.)

Peki ... nasıl yaptılar?

• Bu oyunları ne programladılar? ASM? ASM'deki her şey ?!
• Grafikler nasıl oluşturuldu? Sprite levhaları ve bazı durumlarda (N64 gibi) 3D modeller oluşturmak için hangi teknolojiye sahiplerdi?
• Bu kartuşlardaki seviyelere, karakterlere, görevlere ve eşyalara nasıl uydular? Demek istediğim, SNES'teki Süper Mario Dünyası 1 MB civarında saatler ve 96 çıkışı var! Ocarina of Time, Banjo-Kazooie, DK64 ve diğer bir kaç oyun 64 MB'tan daha az yer kapladı ve çok büyük dünyalara, tonlarca içeriğe ve 3D modellere sahipti!

Üzgünüm, sorularım biraz dışarıda gözüküyorsa, bu kadar küçük bir depolama alanına sığacak kadar harika başlığın ortaya çıkmasına şaşırdım.

Bu beni etkiliyor çünkü en küçük ve en önemsiz dosyalar ve oyunlar bile en az bir kaç MB'ını bile alıyor.

Alan kaplayan sanat ve ses kaynakları, programlama dili seçimi donanımdan en iyi şekilde yararlanmakla ilgili daha fazla.

Örnek olarak N64 kullanıldığında, 3. parti oyunların çoğu 8, 12 veya 16 Mb idi. 32 ve 64Mb oyunları çoğunlukla Nintendo'dan geliyordu, çünkü herkes için bu kadar büyük olan arabalara göndermek çok pahalıydı. Kulağa küçük geliyor, ama o zaman sanat varlıkları ve son görsel çıktı. N64 oyunlarının çoğu, bugün 1280x760 veya daha fazla değil, 320x240'ta sunulduğunu hatırlamalısınız. Bu kadar küçük bir çıktı çözünürlüğü ile, dokular ve spritelar bugün olduğundan daha küçüktüler.

N64 üzerindeki küçük doku önbelleği nedeniyle, çoğu doku 4/8 bitlik bir palette (aka 16/256 renk) 32x64 pikseldir. Ekstra renk ayrıntısı genellikle dokular ve köşe renkleri karıştırılarak yapıldı. Banjo oyunları buna güzel bir örnek.

Bugün bir Unreal motor oyununda tek bir rock birden fazla 512x512x24bpp veya 32bpp'ye sahip olacak. Ayrıca, tek bir dağınık doku yerine, artık normal haritalarınız, speküler maskeler, yansıma maskeleri, yansıma küp haritaları ve daha birçok şey var. Bu yüzden, 4Kb dokuya sahip olan bir nesne şimdi birkaç MB veride ele alınmıştır.

Eski oyunlarda aynı zamanda büyük miktarda yeniden kullanım alanı vardır. Süper Mario Bros'daki çalılar, bulutlarla aynı sprite, tepeler de mantarlarla aynı. Farklı karakterler, aynı sanat kaynaklarının renk değiştiren sürümleridir. Tüm bunlar, el arabası üzerindeki doku veya sprite kullanımından daha fazla yararlandı.

Ses, modern oyunlar için bir başka büyük farktır. Eski günlerdeki neredeyse her şey sıralı izlerle yapıldı. Artık hem müzik parçaları, hem ses hem de ses efektleri çeşitli sıkıştırılmış ses formatlarında saklanıyor. Sıkıştırılmamış verilerden kesinlikle daha küçük olsalar da, sıralı eşdeğerlerinden hala önemli ölçüde daha büyüktürler.

NES'e gelince (ve SNES çok fazla), işte temel bir bakış. Herhangi bir NES oyunu yazmadım, ama bir NES öykünücüsü (Graybox) yazdım ve eski arabaları revize ettim.

Programlama dili gelince: evet, hepsi meclisti. NES'in programlanması, doğrudan donanım kesintileri, DMA portları, banka değiştirme vb. İle çalışmak anlamına geliyordu. Neyse ki, 6502'yi (ya da daha doğrusu 2A03'ü) programlamak oldukça kolaydır [1]:

• Çok az sayıda kayıt var: A, X ve Y temelde ikincisi sadece indeksleme ve yineleme için kullanılabilir
• komut seti küçük ve çoğunlukla basit
• çok fazla bellek yok: isteğe bağlı pille desteklenen 8KB uzatma özelliğine sahip ana RAM 2KB'dir. Bu 2KB'den, 256 bayt yığın için ayrılmıştır ve sayfa 0 (ilk 256 bayt) bazı özel adresleme modları nedeniyle en çok kullanılan işaretçilerinizi ve değerlerinizi saklamak istediğiniz yerdeydi.

Bu üç şey birlikte çalışırken, ezberlemek için yeterince kolay bir ortam sağlar. Evet, tüm hafızayı kendiniz yönetirsiniz, ancak bu esasen her şeyin yolunda gittiği bir harita oluşturduğunuz ve o haritanın çok büyük olmadığı anlamına gelir, çünkü sadece 2K için endişelenmeniz gerekir, böylece bunu bir parçaya koyabilirdiniz. grafik kağıdı. İşleri biraz daha fazla planlamak ve değişkenleri ve sabitleri RAM ve ROM (kartuştaki) konumlarına atamak zorundaydınız.

Kartuş verileriniz CPU'nun adreslenebilir sınırlarının ötesine geçtiğinde biraz kandırır. Bu, 32KB'nin altına taşlanmış ve her türlü donanım portuna ve RAM'e eşlenen 64KB'dir. Banka değiştirme işleminin devreye girdiği yer burasıdır, bu da ROM'un bir bölümünü yüksek 32KB adres alanına (bir kısmının) eşlemek anlamına gelir.

Bu, programcının istediği şekilde kullanılabilir, ancak örnek bir kullanım, kartuştaki ayrı 8KB bellek alanlarına sıkıştırılan her seviye için tüm seviye verileri, meta veriler ve kod içeren 3 seviyeli bir oyuna sahip olabilir. Seviye, örneğin başlatma, kare güncelleme başına vb. İçin geri aramalara sahip olabilir. "Seviyeyi" yüklemek, örneğin 8 KB'lik bellek öbeğini eşlemek anlamına gelir, örneğin 0xC000. Ardından, başlangıç ​​rutininin her zaman 0xC000'de olduğunu, çerçeve güncelleme yordamının 0xC200'de olduğunu ve düzey verilerinin 0xC800'de başladığını belirleyebilirsiniz. Oyunun ana kodu başka bir bellek öbeğine yerleştirilir ve ardından seviye doğru değişiklikleri yalnızca doğru öbek yerine geçerek ve uygun zamanlarda 0xC000 ve 0xC200 mutlak adreslerine atlayarak kontrol eder.

Grafik verilere göre: NES'in döşeme verileri 2-bit 8x8 piksel haritalardır. Arka plan için 1/4 çözünürlükte 2 bit katmanla birleştirilirler. Bu 4 bitlik değerler daha sonra 53 efektif renk seçeneğine inanıyorum. Sprite'lar ayrıca 2-bitlik piksel verilerini kullandı ve her bir sprite, yine bir 4-bitlik pal dizini oluşturan kendi 2-bitlik grup dizinini belirledi. Ekrandaki BG resmi 32x30 karo indeksi numara dizisidir.

Temel olarak, bir ton tekrar ve indeksler halinde indeksler oluşturarak verileri çok küçük tutabilirsiniz. Seviye verileri genellikle kiremit indekslerinin dikey çubukları olarak depolandı ve bu dikey çubuklar da tekrar kullanıldıkları için bunlar da indekslendi ve kartuşta yalnızca bir kez saklandı. Basit veri sıkıştırma teknikleri benzer şekilde çalışır. Bu, Mario 1'in 32KB veri (oda boş bırakılacak) ve 8KB bitmap veri olmasına izin verdi.

Dev ortamlara gelince, insanların çalışmak için EEPROM brülörlerine bağlı eski ve güvenilir bilgisayarlarda çalıştığı bazı fotoğraflar gördüm. Takım yardımlı hata ayıklama, SNES yaşından sonraya kadar bir olasılık değildi [2]. Bu, eski oyunların çoğunda "bariz" böceklerin bulunmasının ve Gameshark gibi şeylerin yaptıklarını yapabilmelerinin ana nedenidir; oyuncu sağlığı her zaman mem-X konumunda olacak, böylece her zaman 100 olması için zorlayabilirsin.

Bunları ilginç bulursanız, örneğin, http://wiki.nesdev.com/w/index.php/Nesdev_Wiki sayfasını incelemenizi öneririz . NES'in çevrimiçi olarak bulunabileceği bir kaç tane programlama kursu vardır.

Umarım bu basitleştirilmiş genel bakış 80'li yılların oyun gelişimi hakkında bazı bilgiler vermiştir.

[1] Göreceli olarak konuşuyorum. Ayrıca Graybox'ın kendisini% 85 PowerPC montajında ​​yazdığı için önyargılıyım. [2] FF6 makalesinin yapımına bakınız: http://www.edge-online.com/features/the-making-of-final-fantasy-vi/

İstediğiniz soruların hemen hepsinde birçok alt konu var. Optimizasyon başlı başına büyük bir alan ve keşfedilecek çok şey var.

Bu tür bir optimizasyonla ilgileniyorsanız, keşfedebileceğiniz şeylerden biri demosen . Demossen ve ilgili sanat kültürlerinden bazıları, mümkün olduğunca az yer kaplayan bilgisayarlar için karmaşık sanat yaratma çabası hakkında uzun süredir bir merak uyandırdı. Birçoğu "hilelerinin" bir kısmını veya tamamını nasıl yaptıkları hakkında bilgi sahibi olacak.

Genellikle bir oyuna veya türe özgü “hileler” ve “kesmeler” olmasına rağmen, sağduyulu sanatsal bir karışımı vardır. Çoğu zaman bir miktar "şans" söz konusudur ve çalıştığı limitleri bilen bir ekip (belki de süreç boyunca bu limitlere sürekli olarak vurarak), mevcut işlemlerini bilmeleri ve gerekli işlemlerin bir kısmını yapmaya istekli olmaları gerekir. -Senin sınırlarını karşılamak için görevliler ve fedakarlıklar

İşte bir ekibin küçük boyutlarda bir oyun almasına yardımcı olabilecek aklıma gelen bazı şeyler:

• Yapabileceklerinizi Yeniden Kullanın: aynı sprite'ları ve tek bir sprite görüntüsünden kolayca yapabileceğiniz varyasyonları (yansımalar, döndürmeler, palet kaymaları gibi) yeniden kullanmanız size yer kazandırır. Aynı şey, bir oyunda kod, müzik ve hemen hemen her şey için de geçerli.
• Neler Yapabileceğinizi Sıkıştırın: Orada bir dizi sıkıştırma programı vardır ve hangilerinin kullanılacağını bilmek çok fazla yer tasarrufu sağlayabilir. Çalışma boyu kodlama gibi bazen basit sıkıştırma şemaları bile şaşırtıcı bir fark yaratabilir. Sadece bu değil, aynı zamanda, genellikle kalite değişimleri olan bireysel dosya türleri için sıkıştırma planları (ve tam olarak sıkıştırma yapmayan alternatif biçimler) vardır. Örneğin, dalga / CD ses dosyaları, bir miktar marjinal bilgi kaybıyla MP3 dosyalarına sıkıştırılabilir. Ayrıca, MIDI ve örnekleyici tabanlı MOD gibi dosya biçimleri çok daha az yer kaplayan alternatif biçimlerdir, ancak müziği tamamen farklı şekilde kodlar ve iyi görünmelerini sağlamak için farklı beceriler gerektirir.
• İhtiyacınız Olanı Kaybetme: Daha ucuza yapabilir misiniz? Örneğin, bir karakterin "kişiliğini" hala daha az pikselde (veya çokgenler) bulabiliyor musunuz? Karoların yerleştirilmesinin bir tasarımcı tarafından tam olarak tanımlanması mı gerekiyor yoksa program kodunuzda rastgele oluşturulabilir mi?
• Kod Genellikle Daha Ucuzdur: Bir kod derlemesinin ne kadar yer kapladığına dair bir şaka yaptıysanız da, genellikle şimdi fikir alır (ve bu 'platformun yıllar içinde artmasının nedenleri ve kesinlikle ihtiyaç duyduğunuzda onu küçültmenin yolları vardır), ancak genel olarak algoritmik / prosedürel / kodlu bir şeyi kolayca yapabiliyorsanız, bu yaklaşımda ince ayar yapmak ve diğer benzer ancak farklı görünen / hissetmek için kullanılan varlıklar için yeniden kullanmak daha kolay olacaktır. Fraktallar, özellikle görülmesi kolay bir örnektir: onu oluşturan matematiksel formüle kıyasla çok fazla yer kaplayan karmaşık bir fraktal görüntüsüne sahip olabilirsiniz. Ek olarak, matematiksel formül benzer, ancak bazen şaşırtıcı derecede farklı görünen görüntüler oluşturabilen parametrelere sahip olabilir.

Her neyse, bu kadar büyük, yüklü bir soru seti için, yukarıda bahsettiğim konulardan bazıları, daha fazla bilgi edinmeniz için iyi bir başlangıç ​​noktası olacaktır.

Bir şey, hala N64 sonrası dönemde durup durmadığından emin değilim, ancak SNES ve N64 sık sık önemli ölçüde alan ve arka planların genellikle sahte olduğu önceden yapılmış sanattan tasarruf sağlayan diğer 3B nesnelerdeki dokuları tekrar kullandılar. Diğer bir püf noktası, sınır arka plan sisi kullanılacaktı.

San Francisco Rush N64 her zaman biraz sis gördü, ancak ayarlar San Francisco Rush arcade'inin bulunmadığı yoğunluğu değiştirebildi ve N64 sürümüne kıyasla Track 1'deki Golden Gate Köprüsü'nü görebiliyordunuz.

Ayrıca oyunlar genellikle Zelda Ocarina of Time gibi müzikleri tekrar kullanıyor, Banjo Kazooie / DK64'ün temalar içinde sıkça temaları olduğu gibi daha iyi bir iş yapıldığından sinir bozucu bulduğum müziği tekrar kullanıyor!

Zelda Ocarina, su altında giderseniz ya da Dükkan Temasındaki enstrümanların Kokiri Orman mağazası ve boynuzları için flüt ve kemanların kullanılacağı dış alanı yansıtmasını sağlarsa, Hyrule Overworld'e ve ardından temanın sualtı versiyonuna sahip olabilirdi. Hyrule Castle Town mağazası için trompetler ve Goron köyündeki davullar.etc

PC'nin 3B modülleri kütüphaneleri açmak için bir program kullanarak hızlıca erişmek için kütüphanelere derlenmiştir ancak ROM tabanlı Nintendo'da durumun böyle olup olmadığından emin değilim. Bilgisayarlar, her şeyin olması gereken yerde kalmadıkları dağınık bir odaya girmek gibi bir RAM'dir ve bilgisayarın bile başlayamayacağı noktaya bilgilerin üzerine yazılabilir!

Oyun Konsolları, her şeyin ayrılmış bir alanda depolandığı ROM'dur, bu nedenle oyunu her açışınızda, orada kalacaklarını garanti ederek o ayrılmış alanda bulunan dosyaları arayacaktır.