Wow, diese Version sieht wirklich gut aus!

Mega! Dabei war der originale Port für den Amiga schon sehr ordentlich, jetzt noch einen draufgesetzt. Nur die Musik finde ich am Amstrad CPC besser.




Dir ist der unbedingte Wille verloren gegangen.

JOTD portiert das Spiel gerade für AGA Amigas. Da es bei ihm (wie immer) nur ein Transcode des Arcade Originals ist muß das Spiel in den NTSC 60Hz Mode forciert werden (per WHDLoad Tooltype im Icon). Dann läuft es fast so flüssig wie in der Spielhalle. Wobei man auch sagen muß, das selbst das 1985 Arcade Original kein 100% flüssiges Scrolling hatte. Sehr schöne Amiga Version.

Noch besser wäre natürlich ein nativer Amiga Port mit den Arcades Assets, aber das hier ist schon deutlich besser als der alte Amiga Port von Elite Systems damals. Ist allerdings noch leicht buggy im Grafikbereich. Aber komplett durchspielbar ist es problemlos.

Ghosts'n Goblins AGA
Kommentar wurde am 25.02.2026, 05:33 von Retro-Nerd editiert.

Ahaha, keine Chance.
Das war vor fast 40 Jahren und nach einer Million Versuchen. Heute hätte ich weder den Nerv, noch die Reaktionszeit für so was.

Dann sei mutig und probier jetzt auf dem C64 Ghosts'n Goblins Arcade aus.

"Wow, sieht das scheisse aus auf dem C64" dachte ich mir ... war aber dann doch das C16 Video.

Ich hab's geschafft. Aber nur mit der C64-Version, die nicht mal die Hälfte des Original-Spieles enthält.

Wow, Project FX-64 sieht ja nicht nur gut aus, sondern spielt sich auch gut. Das ist wirklich eine Empfehlung für die Engine.

Die SEUCK Engine war gar nicht schlecht gemacht, sie hat das Ergebnis hervorgebracht, das erwartet worden war. Die gesamte Entwicklung von SEUCK hat ein einzelner Programmierer gemacht.

Der hat nicht nur die grundlegenden Routinen der Engine geschrieben, sondern auch den Editor, der bei so einem Programm ja genauso wichtig ist, wie die Engine. Um im Bild zu bleiben, er hat vergleichbar zu einem Auto sowohl den Motor entworfen, als auch die Karosserie, als auch den Innenraum gestaltet, als auch die Lenkung konzipiert und danach die gesamte Elektrik eingebaut.

Zu dieser Zeit gab es keine Updates für Engines, wie es heute Standard ist, dafür< war das Produkt dann von Anfang an sehr ausgereift und brauchbar. Die 16-Bit Versionen haben es noch einmal verbessert.

Und das ganze in die 64KB des C64 gequetscht. Natürlich ist da nicht zu erwarten, dass so etwas wie Uridium herauskommt, denn bei Uridium musste Braybrook keinen Editor entwerfen, mit dem ein 15-jähriger Schüler ohne Programmiererfahrung zurecht kommt, sondern konnte sich auf das Spiel selbst konzentrieren.

Wenn man alle Möglichkeiten von SEUCK genutzt hat, war es möglich Titel zu erstellen, die sich hinter gängigen Shoot'em'Ups nicht verstecken mussten. Die Dutzendware war auf jeden Fall möglich zu erstellen. Mit entsprechendem Aufwand war eine ganze Menge möglich, ich finde jeden dieser Titel durchaus ansprechend und sie hätten sich m.M. nach auch bei Mastertronic, Firebird oder Codemasters so wiederfinden können.

https://www.youtube.com/watch?v=H204YrK_ixw
Kommentar wurde am 19.03.2025, 07:50 von Christian Keichel editiert.

nee nich unbedingt, damals musstest du einfach jedes bit dreimal umdrehen und alles handoptimieren, wenn du dich von der konkurrenz abheben wolltest mit noch mehr power, mehr sprites, mehr lametta

das kann man mit einer wollmilchsau-engine einfach nicht abbilden. zwar kann man auch so eine engine optimieren, und das teil von micronics hatte sicher noch viel verbesserungspotenzial ... aber die entwicklung und das fine-tuning muss halt auch erst mal jemand zahlen.
Kommentar wurde am 18.03.2025, 19:38 von Grumbler editiert.

Super Antwort. Danke!

Dann sind Sachen wie SEUCK also einfach nur eher schlecht programmiert?

Die Engine ist die Gesamtheit aller Ein- und Ausgaberoutinen eines Spiels, also alles bis auf die reinen Grafik- und Sounddaten. Insofern hat jedes Spiel eine Engine, auf der es läuft.
Je nachdem, mit wieviel Vorausschau diese Routinen geschrieben wurden, lassen sie sich besser oder schlechter in Module unterteilen, die auch für weitere Spiele genutzt werden können.
Das machten Programmierer von Anfang an. Sid Meier hat die Grafikdarstellungsroutinen, die er 1982 für Hellcat Ace geschrieben hat sicher in der einen oder anderen Form für Spitfire Ace wiederverwendet und Rob Hubbard hat die Abspielroutinen für seine Musik auf dem C64 sicher nicht für jedes Spiel neu geschrieben.

Genauso war es bei den Famicom Titeln von Micronics. Die haben sich nicht hingesetzt und eine Engine geschrieben, um dann später Spiele mithilfe dieser Engine umzusetzen. Sie haben für ihre erste Konvertierung Grafik-, Sound- und Inputroutinen entwickelt um das Spiel mehr oder weniger adäquat umzusetzen. Beim nächsten Titel haben sie geschaut, welche dieser Routinen sie weiterverwenden können und wo sie Veränderungen vornehmen müssen.

Ob das schon eine Engine beschreibt, die vergleichbar ist mit dem, was Unity oder Unreal bieten (jetzt nicht auf den Leistungsumfang gemünzt, der ist natürlich grundverschieden, sondern auf das Prinzip), weiß ich nicht.

Um auf deine Frage noch einmal genau zurückzukommen, bei Unreal und Unity hast Du ein im besten Fall gut optimiertes Werkzeug, dass, wenn Du Dich innerhalb dem Rahmen bewegst, für den es entworfen wurde, wenig bis keinen Overhead hat. Programmierer könnten, wenn sie entsprechend Zeit investieren, sicher bessere Ergebnisse erzielen, wenn sie eine Engine entwerfen, die 100% auf das Spiel ausgelegt ist, das sie machen, einfach weil sie dann passgenauer arbeiten können. Aber, die gängigen Engines heute sind gut optimiert und auch dann, würden sie eine eigene Engine programmieren, die wiederum aus einem bestimmten Satz an Routinen und Algorithmen besteht. Auch das, wie der "blanke Code", wie Du es beschreibst, bildet am Ende eine Engine.

Kann denn eine Engine theoretisch genauso effizient laufen wie direkt mit blankem Code programmiert, oder schluckt eine Engine immer was?