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

Dieses Thema im Forum "Konsolenforum" wurde erstellt von Leonhart, 28. November 2019.

  1. Leonhart

    Leonhart
    Registriert seit:
    25. September 2018
    Beiträge:
    2
    Hallo und schöne Grüße,

    ich habe mal eine allgemeine Frage bezüglich alter Super Nintendo Spiele:

    Nehmen wir ein vergleichsweise großes Rollenspiel wie Secret of Mana ...

    Dieses Spiel beinhaltet
    - rund 50 Musiktracks
    - weitere kleine Sounddateien
    - die Texte des Spieles
    - die Programmierung des Spieles
    - Wertetabellen von Gegnern, Waffen usw.
    - alle Hintergrundgrafiken / Grafiken / Animationen

    Wie passt sowas auf 2049 Kilobyte?

    Ich verstehe durchaus was ein Bit, Byte und Kilobyte ist. Aber das erscheint mir einfach eben wortwörtlich "unglaublich"!

    Kann man sich die Programmierung von solchen Projekten anschauen?

    Besten Dank :)
     
  2. electric Ein M-A-S-S-I-V

    electric
    Registriert seit:
    25. Februar 2006
    Beiträge:
    32.024
    Ort:
    Mystery Babylon
    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.
     
    Zuletzt bearbeitet: 28. November 2019
    Hardkorn gefällt das.
  3. mike81

    mike81
    Registriert seit:
    12. September 2002
    Beiträge:
    49.383
    Mein RIG:
    CPU:
    core i7 3770k
    Grafikkarte:
    nVidia Geforce GT 1030
    Motherboard:
    ASUS P8Z68-V Pro
    RAM:
    16GB DDR3 Corsair
    Laufwerke:
    512GB Intel SSD + 2TB WD Blue Datengrab
    Soundkarte:
    ASUS Xonar Essence STX II
    Gehäuse:
    Chieftec Aegis
    Maus und Tastatur:
    "das Keyboard" und Logitech Maus
    Betriebssystem:
    Win10 64bit
    Monitor:
    27" Asus TFT
    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.
     
  4. electric Ein M-A-S-S-I-V

    electric
    Registriert seit:
    25. Februar 2006
    Beiträge:
    32.024
    Ort:
    Mystery Babylon
    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: :ugly:
    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
     
    Goof, Emet und acer palmatum gefällt das.
  5. Leonhart

    Leonhart
    Registriert seit:
    25. September 2018
    Beiträge:
    2
    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!
     
  6. Blutschinken

    Blutschinken
    Registriert seit:
    9. Juni 2005
    Beiträge:
    7.287
    Mein RIG:
    CPU:
    4× Cortex-A53 @ 1.2 GHz
    Grafikkarte:
    Broadcom VideoCore IV @ 400 MHz, shared memory
    Motherboard:
    Broadcom BCM2837
    RAM:
    1 GB DDR2
    Laufwerke:
    16 GB Kingston MicroSDHC (UHS 1, Class 10)
    Soundkarte:
    On Chip (PWM)
    Gehäuse:
    Vuller Tech Case (Stapelbare Zwischenplatte)
    Maus und Tastatur:
    Vortex Poker 3 (MX-Clears, O-Rings)
    TerraTec Mystify Razer Boomslang 2100
    Betriebssystem:
    Raspbian Stretch Lite (4.14)
    Monitor:
    Hannspree HP195DCB (18.5", 1366x768)
    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.
     
    t-6, Hardkorn und Boschboehrlie gefällt das.
Top