Auf diese Frage antworte der DocSockenschuss nicht.
Er hätte sagen können: "Sorry ey, bin ich Jesus?"
Aber er sagte nichts.

Das muss ich jetzt erst mal verdauen. Vielen Dank.

Doch wie funktioniert das bei Spielen, wo ständig viel neue Landschaft kommt? Alles nur kleine Bestandteile, die hintereinander abgespult werden?

Und beim CPC gibt es ja noch CRTC-(Pseudo?)-Hardwarescrolling, womit man schon auf 50fps kam (siehe Relentless) . Wie ist das zu verstehen? Auch kein "echtes Scrolling"?

Dein Bruder hat ja einen CPC, vielleicht weißt du auch was dazu?
Kommentar wurde am 08.10.2015, 22:37 von Anna L. editiert.

ja ne iss klar

Ach ja, ich rede im vorigen Beitrag übrigens nur von horizontalem Scrolling. Vertikales ist wesentlich einfacher, da man keine einzelnen Bits manipulieren muss, sondern gleich mit ganzen Bytes hantieren kann. Aber auch hier müsste man beispielsweise bei einem Shooter wie "1942", wo man nach oben fliegt, beim Verwenden regulärer Befehle den Inhalt von Zeile 2 in Zeile 1 kopieren, dann den von Zeile 3 in Zeile 2 usw. - mit den normalen Kopierbefehlen nicht zu schaffen, genau: zu langsam. Hierzu kann man die PUSH/POP-Befehle ebenfalls zweckentfremden.

Vom zusätzlichen Rechenaufwand für die nötigen Software-Sprites sowie dem kritischen Timing all dieser Aktionen, um kein Tearing zu erzeugen, haben wir jetzt noch gar nicht gesprochen. Muss auch nicht sein. Ist auf jeden Fall viel, viel schwieriger, ein scrollendes Spiel zu machen, als auf Hardware wie dem C64 mit ihren custom chips, die das alles übernimmt.
Kommentar wurde am 08.10.2015, 17:51 von Doc Sockenschuss editiert.

Ich kann dir das schon erklären, warum die wenigsten Spiele auf dem Speccy oder CPC tatsächlich gescrollt haben. Jeder Maschinensprachebefehl dauert eine gewisse Zeit (in Mikrosekunden), bis er vom Prozessor abgearbeitet wurde. Es gibt beim Z80 die Befehle RL bzw. RR (=Rotate Left, Rotate Right), mit denen man die Bits eines Registers oder einer Speicherzelle um eine Position nach links oder rechts rotieren kann. Was am Rand "rausfällt", geht ins sogenannte Carry Flag und wird beim nächsten Verschiebungsbefehl (vorzugsweise in ein benachbartes Byte) wieder eingeschoben. Allerdings ist dieser Befehl so langsam, dass es schon beim Speccy mit seinem 6 KB-Bildschirmspeicher nicht möglich ist, auf diese Weise in einem Frame (=1/50 Sekunde) den kompletten Bildschirm um 1 Pixel zu verschieben. Am CPC mit 16 KB, trotz des etwas schneller getakteten Z80, geht es also erst recht nicht.

Also mussten die Programmierer sich etwas anderes ausdenken. Irgendwann muss halt jemand herausgefunden haben, dass sich mit den Befehlen PUSH und POP, die eigentlich dazu gedacht sind, Registerinhalte auf den Stack zu legen, gleich 2 Bytes auslesen bzw. schreiben lassen, und das verhältnismäßig schnell. Außerdem springt der Stackpointer praktischerweise auch gleich noch 2 Bytes weiter, so dass man nicht mal mehr irgendeinen Zeiger erhöhen muss, wie das beim regulären, echten Scrolling mittels der RL/RR-Befehle vonnöten ist.

Nun hat man einfach mehrere "vorgescrollte" Versionen einer Grafik im Speicher abgelegt, die jeweils gewünschte in ein Registerpaar (z.B. DE) geschreiben, den Stackpointer auf den Bildschirmspeicher zeigen lassen und dann mehrmals hintereinander den Befehl PUSH DE ausgeführt. So kommt mit Sicherheit auch das Scrolling in Sub Hunter zustande, das ja doch etwas weniger komplex ist als das in Cobra, welches ebenfalls exzessiv den PUSH-Befehl verwendet.

Sehr technisch, das Ganze, aber ich kann's halt einem Nicht-Coder nicht so leicht erklären.
Kommentar wurde am 08.10.2015, 17:39 von Doc Sockenschuss editiert.

Wobei: Wenn sogar der Heinrich von "Scrolling" spricht, kommt man kaum auf Idee, dass es eigentlich gar kein Scrolling ist. Aber diese Teile-Verschiebung kenne ich vom CPC zum Beispiel von "Commando". Das läuft sogar sehr flüssig ab, würde es nicht langsamer werden, wenn auf dem Screen was los ist.

Kennst du "Sub Hunter" auf dem CPC? Dort werden geloopte Blöcke verschoben, sehr gut und in verschiedenen Ebenen. Das sind aber wohl keine Tiles, sondern Blöcke. Na ja, bin da auch nur Laie.

Boah, jetzt hast du mich aber auseinandergepflückt. Aber danke für den Beitrag und den Link.

Der Speccy hat hier ganz sicher nicht den C64 emuliert, schließlich ist das bei Cobra nur 25 fps. Und außerdem wird gar nicht wirklich überhaupt gescrollt. Es wird "lediglich" der gesamte Spielbereich jedesmal mittels zweckentfremdeter Stackpointer-PUSH-Befehle neu aufgebaut, dabei besteht der Hintergrund aus einer gewissen Anzahl "Tiles", die in diversen Versionen, sogenannten "Pre-Shifts", im Speicher abgelegt sind. Gab ja auch 'ne Menge anderer Spiele, die das so gemacht haben, auch am CPC.

Ansonsten kann man den "256*192*1 BPP"-Modus des Speccy mit dem "320*200*2 BPP"-Mode 1 des CPC nicht wirklich vergleichen, von daher ist dieser Satz ...

... irrelevant. Ich wollte zwar noch mehr dazu schreiben, aber das hat mit dem Spiel hier nichts zu tun, von daher belasse ich es hier dabei.

Interviews des Programmierers der ZX-Version, Jonathan Smith: Hier, hier ... gibt vielleicht noch mehr, aber ich hab nicht lange gesucht.

Super Scrolling auf dem Spectrum! Da hat der Speccy mal eben die 64er-Hardware emuliert. Klasse gemacht. Ist aber im 320*200 Mode auch deshalb flüssig, weil beim Pixel-Scrolling kleine Pixel verschoben werden. Die sind ja im 160*200 Mode logischerweise größer. Da muss man beim CPC zum Beispiel Double Buffer machen, damit es weicher wird. Wobei der 64er auch im 160*200 Mode mit einer Auflösung von 320*200 scrollt, wenn ich richtig informiert bin.

Die Peking-Ente letztens ist mir nicht gut bekommen http://www.youtube.com/watch?v=RNNCEt8tDtE

Das Spiel ist rotz. Steuerung und Kollisionsabfrage machen das Dingen fast unspielbar auf dem C64. 3/10 - und das ist noch ziemlich gnädig.
Kann mich erinnern das Spiel trotzdem immer wieder hervor gekramt zu haben, weil die Musik super war. Dumm,dass das Spiel zu keinster Weise dessen Level erreicht.