Wobei Cross Compiler Anfang der 90er jetzt nicht mehr so wirklich selten waren. Auch sonst gab es schon reichlich leistungsfähige Tools.

Allerdings hast Du grundsätzlich recht. Heute gibt es für alle möglichen Dinge spezielle Hilfsmittel. In der Demoszene nutzt man den Cross-Compiler nach persönlicher Vorliebe, Respositories oder auch speziell angepasste Frameworks... und so wirklich vergleichen kann man das mit Spielen sicher nicht (wobei da oftmals Spiele-Programmierer an Demos coden).

Ich muss Doc Sockenschuss zustimmen. Beim C64 war Scrolling wirklich recht einfach. Interessanterweise stimmte dann die Auflösung nicht mehr bzw. es waren ein paar Pixel weniger. Man aktiviert in einem Register, dass jeweils links und rechts (und/oder oben und unten) 4 Hires-Pixel nicht mehr angezeigt werden. Dann gibt es ein Verschiebe-Register wo man den Links/Rechts- bzw. Oben/Unten-Versatz angeben konnte. Je nachdem wie schnell das Spiel scrollen sollte hat man dann nur jeden 2. Frame ein Pixel verschoben (langsames Scrolling bei 25Hz), bei jedem Frame 1 Pixel verschoben (normal Scrolling bei 50hz) oder 2, 3, etc. (schnell, etc. bei 50Hz).

Man hat ja fast immer Charactergrafik, also veränderte Zeichensätze, gescrollt und keine Bitmaps. Also musste man, wenn man am Ende des Verschieberegisters angekommen war, es zurücksetzen und ausserhalb des gerade sichbaren Bildbereiches das Bildschirm-RAM, im Falle eines Scrollings von rechts nach Links, in 25 Zeilen alle 39 Zeichen von rechts eine Position nach links kopieren und sich dann das neue 40. Zeichen holen. Das sind dann 1K Kopieraufwand. Das selbe musste man dann noch für das Farbram machen wo pro Zeichen die Farben definiert wurden und ob das Zeichen ein Hires-Zeichen mit 8x8 oder Multicolor-Zeichen mit 4x8 Pixel ist. Insgesamt musste man allso bei normaler Geschwindigkeit alle 8 Frames 2K Kopieren und in den 7 Frames dazwischen immer nur ein Register Incrementieren oder Decrementieren.

Wie bist Du denn drauf? Es klingt niedlich aber nicht unterwürfig. Und mit heutigen Maschinen willst Du unsere geliebten Homecomputer doch nicht vergleichen oder in einen Topf werfen oder?

Heute kann man sich jeden illegal Opcode, jedes noch so geheime Register und sonstige technischen Daten aus dem Netz ziehen. Heute hast Du die feinsten Crosscompiler und Emulatoren wo Du völlig gefahrlos rasend schnell entwickeln kannst. Heute hast Du Tools für Grafik und Musik ohne Ende. Alleine Crosscompiler waren damals schon eine Seltenheit und teuer (siehe Exolon Bericht in der aktuellen RG).

In der Demoszene versucht man heute viel mehr an die Grenzen zu gehen als bei heutigen Indiespielen, die aufgrund der heute eingesetzten Technologien aber auch geschliffener und technisch ausgereifter sind als ihre 80er Jahre Konkurenten. Schau Dir die RGCD Competition für den C64 an. Die machen heutzutage Spiele für 16K Cartridges und nicht für eine doppelseitige Diskette mit 340K!

Es gibt eine Demo von Crest auf dem C64 mit 144 Sprites. Auch beeindruckend, dafür dass es regulär nur 8 sind. Aber das braucht alle Resourcen und ich glaube nicht, dass da noch irgendwelche Taktzyklen für Spiellogik übrig sind.

Respekt haben alle verdient, die heute noch für die alten Systeme entwickeln, ob sie dabei an die Grenzen gehen oder nicht ist mir da ehrlich gesagt egal, solange der Inhalt stimmt.

Dein 50HZ CPC Spiel kannste gerne mal verlinken.

Ansonsten gilt immer noch, was ich damals gamersince1984 schrieb!
Kommentar wurde am 02.03.2015, 15:36 von nudge editiert.

@Anna L: So im Detail weiß ich das auch nicht, bzw solche Dinge 'wie Hardware-Scrolling' hatte ich eigentlich immer als gegeben hingenommen. Bei einigen Systemen stehen von der Rechner-Architektur Techniken bereit, welche das Verschieben des Bildinhaltes übernehmen bzw vereinfachen.

Also, so ein schlichter Befehl wie 'Scroll links' ist es sicher nicht, allerdings von der Logik her geht es schon in die Richtung. Jetzt mal ein System wie den Atari ST vor Augen, bei dem solch eine Technik fehlt. Da muss man via Code erstmal eine Methode haben, wie überhaupt der Bildinhalt verschoben wird. So als Ansatz würde ich zb etwas wie Double-Buffering sehen (wobei keine Ahnung, ob das jetzt ein realistisches Beispiel ist): Während des ersten Frames wird die Grafik entsprechend der Verschiebung in einen Zwischenspeicher kopiert und im zweiten Frame eingeblendet, dann wieder kopiert und so weiter... man hat eine Grundlage für eine stabile Framerate, ist aber gleichzeitig auf 25fps festgenagelt.

Bei den Bitmap Brothers bin ich immer davon ausgegangen, dass die Coder sich eine Art universelle Engine für 68000er Prozessoren programmiert haben, um relativ schmerzfrei mit wenig Personal die Spiele umsetzen zu können. Da wäre dann der Atari ST die Leit-Plattform und Hardware-Scrolling konzeptionell ausgeschlossen.
Kommentar wurde am 26.02.2015, 17:33 von v3to editiert.

Ist eigentlich ein schönes Spiel bis auf das Scrolling,das ist so Heftig das man nach längerem Spielen Kopfschmerzen von bekommt.
Das die Bitmaps das in keinem Spiel so richtig hinbekommen haben ist ja kein Geheimnis,war aber bei anderen Titeln nicht ausschlaggebend.
Leider ist das bei Magic Pockets schon etwas anderes hier macht es sich in der Motivation deutlich bemerkbar und drückt den gesamteindruck merklich.
Finde ich schon Schade denn davon abgesehen ist es ein tolles Spiel.

Ich habe das Spiel damals sehr gerne gespielt, aber eher zwischendurch als ernsthaft. Das Intro fand ich cool, da es stylistisch so wunderbar zum Rest des Spieles passte.

Schade fand ich, dass man im Spiel keine Musik hatte....naja, der sehr schöne, aber ultrakurze Introsong hätte auch nicht gereicht, um ihn sich das ganze Spiel über reinzuziehen.

Auf dem Achimedes gespielt - war schon ganz spaßig, und so schwer habe ich das gar nicht in Erinnerung. Allerdings ist das schon ein paar Jahre her... Ein wirklich solider Titel.