NECs kleiner Zauberkasten gilt bis heute als die beste Konsole für Shooter-Fans, und die Umsetzung von R-Type ist ein eindrucksvoller Nachweis, warum das so ist. Diese Version ist auch deutlich gnädiger, als die Arcade, und man hat eine faire Chance, das Ende zu sehen.

Stimmt total. Bei Lemmings hat noch kaum eine Sau (also auch ich) gedacht, was für ein technisches Meisterwerk es doch sei. Weil ist ja eh nur so aus der Quasi-Knobel-Ecke, wo es ja auf die inneren Werte ankommt. Ich denke, die Vielzahl an Lemminge plus die vielen Plattformen müssen gut in den Code integriert werden.

Bei Lemmings war es wichtig und ist auch bekannt dafuer dass es so genau gemacht wurde, auf allen Plattformen, das ist ganz und gar nicht selbstverstaendlich und einfach.

Lemmings war, wie ja damals typisch Psygnosis, auch technisch ein Meisterwerk, nur faellt es nicht so auf, weil nicht In-Your-Face-Geprotze.

Eigentlich dürfte eine unsichtbare Masken-Linie ähnlich wie in "Defender" ausreichen für einen Kollisionsabfrage, denn weiter in die Landschaft rein kommt das Sprite ja eh nicht, wenn es oben zerschellt. Weit komplexer dürfte das bei einem Jump and Run sein. Alles muss definiert sein. Dass das Sprite einen Berg hochrennen kann, dass es auf Plattformen springen kann.
Kommentar wurde am 26.02.2026, 07:24 von Edgar Allens Po editiert.

Super geile Antworten. Ich check den Link jetzt mal.


EDIT: Eine Collision Map also. So ein Spiel ist eine aufwendige Sache. Umso mehr würdige ich gute Spiele und deren Programmierer.
Kommentar wurde am 24.02.2026, 21:18 von Edgar Allens Po editiert.

Bob Pape hat ein Buch über seinen Spectrum port von R-Type geschrieben, das es auf seiner Website zum Herunterladen gibt.

Link

Auf Seite 48 geht er genauer darauf ein, wie er die Kollisionsabfrage gestaltet hat.

maskierung meist weniger das problem auf konsolen mit hardware-sprites und -layers, alles was nicht farbe 0 (transparent) ist toedlich.

kollisionsabfrage im detail dann in der tat das was CPU-aufwaendig ist, und kommt dann drauf an, wie komplex man die gestalten will.

einfach nur tiles/sprites gegen andere tiles/sprites ("hitboxes" wuerde man heute im 3d-engine-jargon sagen) checken geht am schnellsten, aber kann fuer das menschliche auge ungenau sein. (aber selbst viele modernere 3d-games sind hier ungenau mit ihren "hitboxes").

wenn man die genauen formen der objekte miteinbeziehen will wird's beliebig aufwaendig.

also durchaus ein aspekt der mit dazu beitragen kann wenn ein spiel auf konsolen ruckelt oder nicht die vollen 50/60fps schafft.
aber der entwickler haette hier spielraum und koennte manchmal die fuenfe grade sein lassen wenn's effizienter ist.

Wenn in einem Ballerspiel wie "R-Type" eine komplexe Landschaft vorbeiscrollt, die aus Vertiefungen, einzelnen Rohren, die hervorstechen, und so weiter besteht, ist das für die Kollisionsabfrage des Spielersprites nicht eine aufwendige Sache beim Programmieren? Scrollt da noch eine "Maske" mit der Landschaft mit, die dem Spielersprite sagt, das es explodieren soll bei Berührung?

Mit Anti-Aliasing koennte man es noch sanfter hinkriegen und quasi halbe Pixel bewegen / scrollen. Das wuerden 3D-Engines von heute quasi implizit so machen, wenn man so einen 2D-Shooter damit programmieren wuerde. Aber mit der Technologie damals unmoeglich.

Aber mit dem "natuerlichen" "Anti-Aliasing" der Bildschirme damals fiel dieses (ominoese) "Ruckeln" sicher noch weniger auf.

Was meinst Du mit "Es gibt auch immer wieder kleine Slowdowns, dann ruckt es noch mehr" gelegentlich senkt sich die Geschwindigkeit, mit der das Schiff scrollt, aber das sind keine Slowdowns, der Rest des Spiels läuft doch normal weiter. Was Du als Rucken wahrnimmst ist eine Bewegung um die kleinstmögliche Einheit 1 Pixel. Die siehst Du, weil das Schiff sich langsam bewegt. Das ist alles. Wenn die Auflösung des Spiels höher wäre, dann würdest Du es nicht sehen, aber sie ist nun mal 384*256, da siehst Du Bewegungen in Pixelschritten, wenn sie langsam genug sind.

Es gibt da auch keine Diashow, das Spiel läuft durchgängig mit 55FPS, das heißt pro Sekunde werden 55 neue Frames erstellt. Das hat erst mal nichts mit der Geschwindigkeit der Objekte auf dem Bildschirm zu tun. Wenn das große Schiff in einer bestimmten Geschwindigkeit bewegt wird, verändert es seine Position nicht mit jedem Frame. Um es zu veranschaulichen, wenn Du 1 Pixel pro Frame Veränderung auf der vertikalen Ebene hast, dann bedeutet es, wenn das Schiff nach unten einen Drittel Bildschirm frei hat, dass es diesen Raum in in ungefähr 1,25 Sekunden ausfüllen würde, wenn es einfach gerade nach unten fliegt. Wenn Du Dir ansiehst, wie groß das Schiff ist und in welcher Geschwindigkeit das Spiel abläuft wird schnell klar, dass das viel zu schnell wäre. Das heißt die Bewegung des großen Schiffes kann nicht mit jedem einzelnen Frame erfolgen.

Weder ruckt da was, noch gibt es Slowdowns. Die flüssige Bewegung bei einem Objekt entsteht bei dieser Auflösung durch die Geschwindigkeit, mit der sie erfolgt. Wenn Du eine Analog-Uhr hast, auf der ein Sekundenzeiger ruckartig jede einzelne Sekunde misst siehst Du jeden Schritt, wenn Du das auf Video aufnimmst und mit fünffacher Geschwindigkeit abspielst, dann sieht es flüssig aus. Genauso ist es hier.
Kommentar wurde am 22.08.2025, 13:00 von Christian Keichel editiert.

Wenn ein Spiel mit 50 Bildern läuft, wieso sollte es nicht möglich sein, das Rieseschiff flüssig zu bewegen, auch wenn es langsam ist? Und was hat das mit der Landschaft zu tun? Die bewegt sich schneller, ja, doch wenn man das Schiff "dramaturgisch" (Grumbler) langsamer haben will, dann bilden das doch 50 Bilder immer noch locker ohne Dia-Show ab.


Gerade nochmal geschaut bzw. läuft gerade. Auch bei vertikaler Bewegung bewegt es sich "Stück für Stück". Es gibt auch immer wieder kleine Slowdowns, dann ruckt es noch mehr.

Was für eine Auflösung bietet das Arcade-Original?


Kommentar wurde am 22.08.2025, 11:48 von Edgar Allens Po editiert.

So wie das Level gebaut ist, musst Du das Gegnerschiff an vielen Stellen sehr langsam auf der vertikalen Achse bewegen, das lässt sich nicht vermeiden, denn die horizontale Geschwindigkeit wird durch das permanente Scrolling des Untergrunds vorgegeben, das Gegnerschiff scrollt immer in einem festen Verhältnis dazu (es gibt Momente, wo es aufhört zu scrollen, aber die Maximalgeschwindigkeit des Scrollings in immer langsamer, als die des Untergrunds). Das vertikale Scrolling ist das deshalb einzige, was beeinflusst werden kann und das eben nur in einem sehr geringen Maße, weil das Schiff sehr groß ist.

An vielen Stellen ist der Platz zwischen dem großen Schiff und dem Untergrund etwas mehr als eine Spieler-Schiff-Höhe, das ist ja auch gewollt, es soll ja eine Herausforderung für den Spieler sein in dem engen Raum zu manövrieren. Das bedeutet dann aber, dass jede Bewegung auf der vertikalen Achse viel langsamer sein muss, als auf der horizontalen, weil der Spieler ansonsten viel zu schnell keinen Platz mehr hätte. Dazu muss das Schiff auch so bewegt werden, dass die Kanonen für den Spieler nur an bestimmten Stellen erreichbar sind, weil es sonst zu einfach wäre. Diese langsame Bewegung heißt aber, dass eine wirkliche Diagonalbewegung an vielen Stellen nicht möglich ist, weil dazu auch die Geschwindigkeit der X-Achse verändert werden muss und die ist wie oben erklärt zum großen Teil fix. Da gibt es keinen Weg drum herum.

Die einzige Lösung für dieses Problem wäre, dass das Spiel das Schiff als ganzes Objekt bewegt, sozusagen als Supersprite, der links und rechts und oben über den Bildschirm hinausragt. Auf diese Weise wäre eine andere Art von Diagonalbewegung darstellbar, denn dann wäre das Schiff nicht mehr an die feste Scrollgeschwindigkeit auf der horizontalen Ebene gebunden. Aber das würde eine komplett andere Hardware vorraussetzen, als in den 1980ern verfügbar war. So wie das Spiel funktioniert (feste Scrollgeschwindigkeit des Gegnerschiffs) ist es nun mal so, dass bei einer Auflösung von 384*256 nur Bewegungen in einem bestimmten Winkel (45 Grad) sowohl eine Veränderung von 1 auf der X und Y Achse produzieren. Bei allen anderen Winkeln klappt das nicht. Da die Geschwindigkeit des Schiffes auf der X-Achse aber fest ist und sie sehr langsam ist, sind die Winkel, in denen das Schiff sich bewegt oftmals nicht 45 Grad und deshalb muss zum Beispiel 3 Pixel auf der X-Achse bewegt werden und 1 Pixel auf der Y-Achse. Wenn das Scrolling auf der X-Achse aber weiter pixelgenau sein soll, musst Du diese 3 Pixel erst mal durchscrollen lassen, bevor Du 1 Pixel auf der Y-Achse scoilen kannst.

Ich tue mich auch nach wie vor schwer das als Ruckeln zu bezeichnen, denn für mich ist Ruckeln eine ungleichmäßige Bewegung die in größeren Schritten erfolgt, als die Auflösung es zulässt und das ist hier ja nicht der Fall, aber das ist eben eine Definitionsfrage.
Kommentar wurde am 21.08.2025, 23:25 von Christian Keichel editiert.

Ein vertikales 1 Pixel Scrolling muß nicht ruckeln. Problematisch ist hier wohl das multi-direktionale Scrolling eines zu großen Objektes.

Der Fisch in Apydia bewegt sich ungefähr 3x so schnell auf der vertikalen Achse, wie das große Schiff bei R-Type und im Gegensatz zu R-Type scrollt er dabei nicht ununterbrochen horizontal, was das langsame, pixelweise Bewegen auf der Vertikalachse bei R-Type so sichtbar macht. Das ist ein komplett anderes grafisches Szenario, auch weil bei R-Type permanent am unteren und oberen Bildschirmrand Grafik mitscrollt, die ein Grundtempo vorgibt. Der Fisch nimmt auch einen weniger großen Teil des Bildschirms ein, weshalb er sich ja auch schneller bewegen kann, was zu einem flüssigeren Eindruck führt. Entsprechend verlangsamt würde die Bewegung genauso aussehen, wie bei R-Type.
Kommentar wurde am 21.08.2025, 20:53 von Christian Keichel editiert.

Der Riesenfisch in Apidya scheint sich aber total flüssig zu bewegen. Machbar ist es bei so großen zusammengesetzten Objekten auf jeden Fall. Aber wahrscheinlich einfacher umzusetzen, weil er schneller scrollt als das Raumschiff in R-Type.
Kommentar wurde am 21.08.2025, 18:21 von Retro-Nerd editiert.