Pixelor

Klasse! Da kann man mal sehen, dass weniger als 16 KB reichen, um Spaß zu haben. Wenn ich hier einen großen Raum für mich hätte, hätte ich mir immer noch sofort den C16 zugelegt (dann aber mit 64 KB Speicher) - zusammen mit dem C64SD V4.0 Princess ULTRA... Mir juckt's echt in den Fingern. Böse!

Was man alles in so ein bischen Speicher pressen kann.

So, ich hatte gestern nicht die Muse, dass in Ruhe zu sehen. Jetzt habe ich das nachgeholt. Mal abgesehen vom - wie üblich - hervorragendem Informationsgehalt finde ich es auch total spannend, was die damals in so ein bischen RAM gespresst haben. Da gebe ich dem DengekiGamer vorbehaltlos Recht: 12 KByte RAM! Erstaunlich.

Allerdings waren die 16-KByte-Versionen der Atari-Computer - Atari 400 und Atari 600XL - ähnlich ärmlich dran. Wobei man hier bei geschickter Programmierung sogar 15,125 KByte RAM zur Verfügung hatte (boa ey!) ... für die Atari-8-Bit-Freaks: ab $0500 bis $3FFF und dann noch 128 Byte von $80 vis $FF in der Zero-Page.

Heute ist das Massiv an Speiche rin meinen AUgen eher ein kleines Problem. Wer nicht mehr drauf achten muss, kann auch mal unsauberen und unoptimierten Code laufen lassen. Hust"Assasions Creed Unity"Hust.........ich glaub das funktioiniert nur wenn man selber spricht.

Ja, ganz genau. Im harten Programmieralltag drückt sich das dann darin aus, das Unmassen an Software-Schnittstellen zwischen dem Spiel und der Computer-Hardware liegen. Es geht los bei der eigenen Programmierung, dann kommt eine wie auch immer geartete »Engine«, dann kommt das Betriebssystem und der Treiber für CPU/Motherboard/RAM/Grafik/Sound/sonstwas und dann landen die Daten irgendwann einmal dort, wo sie hoffentlich ankommen sollen. Zusammen gehalten wird das von einer oder mehreren Programmiersprachen (C, C++, Java, Lua, etcpp.). Und alle diese Ebenen müssen zum einen mit deren jeweiligen Schnittstellen korrekt angesprochen werden, was für sich schon ein unglaublicher Aufwand ist. Und dann haben die allesamt auch noch irgendwelche Bugs (Software hat IMMER Bugs). Und das kumuliert sich und dann kommen noch Terminschwierigkeiten dazu ... und ... BUMM!

Da waren sind die 8-Bit-Computer einfach sehr überschaubar. Und vor allem drücken sich Programmierfehler meistens unmittelbar aus und nicht erst dann, wenn der Spieler 100 Stunden investiert hat und jetzt beim Endgegner das Spiel abstürzt.

Doppelpost und bischen OT
Mann, bekomme ich gerade wieder Bock, für den Atari-8-Bit-Computer zu programmieren. Überhaupt ist das für mich wirklich ein echter Motivationsschub, wenn ich sehe, was auf den damaligen Kosten alles programmiert wurde und heute noch programmiert wird (siehe auch hier).

Retro-Spieleentwicklung ist auch hinsichtlich der Community ein dankbares Feld, kann ich dir sagen. Sowohl was Spieler und Entwickler angeht.

Na, ich bin mal gespannt. Ich lese ja oftmals im AtariAge-Forum im Unterzweig des Atari 800 mit. Und was da manchmal für Klugscheißer am Werk sind, die ein einigermaßen gutes Spiel deswegen runter machen, weil es nicht den neuesten Coder-Demo-Schnickschnack enthält ... das ist manchmal schon ein wenig abenteuerlich.

Ja, von der Sorte gibt es in Retro-Foren so Einige, wobei im Atari-Age-Forum auch richtig gute Leute unterwegs sind. Thomas '8Bitjunkie' Schulz fällt mir direkt ein, der die Dimo's Quest-Spiele programmiert hat (auch ein alter Hase, er war früher bei Infernal Bytes). Die meisten anderen Leute, dich ich aus dem Forum kenne, sind allerdings eher in der Demoszene oder auf dem VCS2600 unterwegs.

Wobei ich das allgemein nicht verstehe, wieso manche Leute Demoeffekte als Maßstab für Spiele nehmen. Es hat schließlich Gründe, dass man solche Tech-Projekte je Plattform an einer Hand abzählen kann.