Frage zur Datengröße eines Super-Nintendo-Spieles. Wie geht das?

https://github.com/LIJI32/superbomberman
edit: ganz kurz: snes Spiele wurde in Assembler geschrieben (daher auch die Endung .asm). Das ist nicht nur sehr effizient, sondern auch sehr klein, weil du (fast) direkt die Register der cpu ansprechen kannst.

 

Interessant, ich hab mit dem Sega Master System anno 1988/89 angefangen als kleiner Bub und die Kassetten damals hatten ja auch keine große Kapazität.

 

Es ist halt verdammt aufwendig, deswegen haben viele Projekte damals auch so lange gedauert. Assembler hat vieles nicht. Es hat zwar

Code:

loop<target>

vgl. mit goto in c, aber wirklich schön ist das nicht. Dazu kommt, dass du die gesamte Speicherverwaltung selber machen musst.

Ein "hello world" sieht in java so aus:

Code:

public class Main
{
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

in c++ so:

Code:

#include <iostream>
using namespace std;
int main()
{
    cout<<"Hello World";
    return 0;
}

und in assembler so:

Code:

section    .text
   global _start     ;must be declared for linker (ld)
  
_start:                ;tells linker entry point
   mov    edx,len     ;message length
   mov    ecx,msg     ;message to write
   mov    ebx,1       ;file descriptor (stdout)
   mov    eax,4       ;system call number (sys_write)
   int    0x80        ;call kernel
  
   mov    eax,1       ;system call number (sys_exit)
   int    0x80        ;call kernel

section    .data
msg db 'Hello, world!', 0xa  ;string to be printed
len equ $ - msg     ;length of the string

 

Besten Dank - ich habe mich mal durch Bomberman oben etwas geklickt, gerade die Grafikdateien kenne ich ja auch.
Das sieht wirklich anders aus, als ich es gedacht habe und scheint eine schöne fummelige Aufgabe zu sein!
Aber das Ergebnis kann sich teilweise echt sehen lassen!
Danke auf jeden Fall für die Antworten!

 

Das ist glaube ich einer der Hauptgründe.
Heutzutage hast du als Entwickler meist eine Entwicklungsumgebung wie Unreal oder Unity - oder zumindest eine Programmiersprache, wo du dir alles Mögliche einfach so fertig programmiert per Befehl dazuholen kannst, sodass du nicht alles selber machen musst - z.B. einen Zufallsgenerator. Dadurch ist in modernern Spielen natürlich auch immer viel Zeug dabei das eigentlich garnicht gebraucht wird aber auch nicht schadet. Selbst bei kleinsten Indiespielen kommt so schnell 200 MB zusammen.

Im Gegensatz zu früher wo du dir alles selber bastelst - und nur das was du tatsächlich brauchst.
Meist in kleinerer Form auf deinen speziellen Anwendungsfall zugeschnitten und gerne auch mit etwas unsichereren "Abkürzungen" um Platz zu sparen, die man in allgemeingültigen, "sicheren" Programmbibliotheken niemals nutzen würde.

Dazu kommt dass moderne Sprachen einfach abstrahierte Formen "älterer" Sprachen sind und dadurch praktisch automatisch größer. Der obige "Hello World" Assembler Code ist zwar als Text viel länger als der Java Code, aber beim Kompilieren wird dann Java sowieso vollautomatisiert zurückübersetzt, was meist mehr Platz verbraucht, als wenn man es per Hand machen würde.

Der größte Platzersparnis kommt aber durch Grafik und Sound.

Sound wird auf alten Systemen größtenteils programmiert. Das heißt du schreibst direkt was der Soundchip machen soll - etwa den Auftrag eine Sekunde eine Note spielen anstatt das du 8000x Wert für die aktuelle Klangfrequenz ausließt - was eine Sekunde Sound im PCM Format wär. In etwa vergleichbar als wenn man einen kurzen Text als Textdatei abspeichert (maximal ein paar KB) oder als Bild (wo selbst ein einzelner Buchstabe viele Pixel Informationen hat).

Tatsächliche Aufnahmen sind auf das allernötigste reduziert. Meist so, dass sie sich halbwegs mechanisch nachdem anhören was sie darstellen sollen um Platz zu sparen. Deswegen ist Sprachausgabe (wenn es sie überhaupt gibt) in alten Spielen so knarzig und blechern.

Grafik wird entweder auch programmiert (indem Pixel per Code herumgeschubst werden) oder ganz simpel in einem Rohdatenformat. Das ist zwar an sich ineffizienter als "moderne" komprimierte Datenformate wie Jpeg (ein rohes 16 Megapixel Bild ist riesig), aber bei sehr kleinen Bildern wie die alten Sprites, bei denen man die Pixel noch per Hand zählen kann, spart man dadurch sogar Platz, weil die Meta-Informationen über das Bild in einem echten Bildformat viel größer wären, als wenn man es einfach so direkt speichert. Dazu kommt noch, dass man eh meist mit einer mickrigen Palette arbeitet - also z.B. 16 vordefinierte Farben - Anstatt 3x 65536 bei RGB16. Spart natürlich auch immens Platz.

Das alles führt dann zu dem Paradoxon, dass selbst das Entwicklerlogo auf dem Startbildschirm heute größer ist als ein komplettes Spiel von vor 30 Jahren.