Hello, Guest the thread was called1.3k times and contains 17 replays

last post from AW182 at the

Wie viele "true arcade/coin-op ports (not arcade conversions) und welche, hat C64 bekommen?

  • Wir haben zahlreiche threads in C64 forums darüber gesehen,

    wie viele/beste/schlechteste C64-"Arcade-Ports" es gibt.


    Aber in diesen threads geht es immer um Arcade"conversions"" und nicht um not "true ports" .


    Was meine ich mit "True arcade port"?

    Es portiert zumindest die Arcade game logic , so dass es wie (oder sehr nahe) mit der Arcade spielt,

    obwohl es vielleicht etwas langsamer ist / noch mit genau der gleichen Grafik & dem gleichen Sound.


    Das hätte man machen können

    - Verwendung von arcade "source code" während der Entwicklung der video game

    -oder vollständig/teilweise emulation e.t.c.

    -oder durch Reverse Engineering



    Zum beispiel

    3 verschiedene Möglichkeiten, wie Developers einen "true arcade port" erstellt haben


    1) Durch laufende emulation/software layer

    Steve Hayes/Atarisoft im "Ms. Pacman(C64)" Fall.

    "Where he used a software layer to emulate the arcade hardware just played the games right off an image of the ROMS"

    https://www.gamesthatwerent.com/gtw64/ms-pac-man-v1/


    2) durch partielle Emulation

    wie N.Kehrer in seinem "Sprint1" & "Asteroids" Emulator

    https://csdb.dk/release/?id=116895

    https://csdb.dk/release/?id=141676


    3) Wie "Peiselulli" im Fall "Donkey Kong(C64) 2016"

    https://ready64.org/smf/index.…ic=4865.msg32520#msg32520

    "the oxyron version was ported directly from the arcade - by code.

    Peiselulli patched Mame from Z80 to 6502 and rebuilt the code until the version run like the original. After that he built a c64 version with that basis.

    so... there are even the bugs of the original arcade included. "

    https://www.lemon64.com/forum/…e79e256c1eea3461ee#756827



    So ,wie viele ""true arcade/coin op ports"(and not arcade conversions)

    und welche

    hat C64 bekommen?

  • Das hätte man machen können

    Hätte, hätte, Fahrradkette. So hat man damals aber nicht gedacht und auch nicht gearbeitet.

    Im Rahmen meiner Recherchen zur C64 Spielzeit stoße ich immer wieder auf die gleichen Vorgehensweisen in den 1980ern:

    Ein Arkade Spiel soll auf einen Heimcomputer portiert werden. Also bekommt irgendeine Software Bude den Zuschlag. Damals wurde sogar teilweise der Auftrag zweimal vergeben: einmal für eine Umsetzung in Europa und einmal für Amerika. Sowas kann man sich heute gar nicht mehr vorstellen. Daher gibt es von einigen Spielen heute mehrere Versionen.

    Meistens gab es extremen Zeitdruck und nur ein geringes Budget.

    Niemand hat sich da die Mühe gemacht und den Originalcode analysiert und als Vorlage benutzt. Da wurde meistens versucht das Game "originalgetreu" umzusetzen, nach besten Wissen und Gewissen und was die jeweilige Maschine so hergibt.


    Heutzutage haben wir leicht reden mit unseren CrossCompilern und den modernen Möglichkeiten.


    Vielleicht müsste man ein Auge darauf werfen, welches Arkade Spiel auf dem C64 am wenigsten vom Original abweicht bzw. am nächsten dran ist.


    Auf jeden Fall ist es aber eine interessante Fragestellung von dir.

  • Heutzutage haben wir leicht reden mit unseren CrossCompilern und den modernen Möglichkeiten.

    Mal davon abgesehen gab es damals keinerlei standardisierte Geräte Driver.


    Dasselbe Spiel auf zwei unterschiedliche 8 Bitter -- das ist kein portieren sondern immer gänzlich neu machen.

    Selbst dann, wenn es dieselbe CPU drin hat.


    Allein Sound und Bildschirm sind derart unterschiedlich in der Anwendung.

    Jede Maschine hat Schwächen und Stärken, und man musste die Stärken nutzen.

    Dann das Farbschema ist ein Limit.



    Das Hauptproblem dürfte aber sein, dass man für jeden Computer ein ganz eigenes Experten Wissen aufbauen musste.

    Nur ganz große Firmen können sich für jede Plattform eigene Programmierer leisten.



    Das ist heute zum Glück ganz anders.

    Ein Source Code -- eine standardisierte Engine pro Endgerät.


    Und ganz nebenbei, die Endgeräte sind heute auch alle sehr ähnlich.

  • Niemand hat sich da die Mühe gemacht und den Originalcode analysiert und als Vorlage benutzt. Da wurde meistens versucht das Game "originalgetreu" umzusetzen, nach besten Wissen und Gewissen und was die jeweilige Maschine so hergibt.

    Also wenn ich so die Artikel zu dem Thema lese, dann klingt das eher so, dass man den Originalcode meistens nicht bekommen hat, und deshalb selbst analysieren musste. Gibt auch Fälle wo man zwar den Code bekommen hat, aber nicht soviel damit anfangen konnte, weil er z.B. in Japanisch war.

    Oft hat man die Maschine hingestellt bekommen und musste die selbst durchspielen, damit man weiss was man implementieren muss. Oder es gab eine Videokasette mit einem Playthrough.

    Also wenn die Entwickler den Code gehabt hätten, dann hätten die durchaus da auch reingeschaut.

  • Hm, japanischer Quellcode aus den 80ern ... das wirft so viele Fragen auf ;)

    War bestimmt alles in Dolittle programmiert. :D


  • Ich denke nicht dass der Source selbst in japansich ist, da der Assembler oder Compiler wohl kaum japansiche Zeichen zu der Zeit unterstützt hätte. Der wird wohl in normalen ASCII geschrieben sein, aber die Kommentare können trotzdem in japanisch sein, auch wenn sie nicht unbedingt die korrekten Zeichen verwenden.

    Jedenfalls wird das in den Artikeln zu Ports in diversen Zeitschriften immer wieder erwähnt, weil da nicht nur geschrieben wird was umgesetzt wurde, sondern halt auch wie die das gemacht haben und unter welchen Umständen.


    Kann natürlich alles gelogen sein, ich bin sicher die Foris hier wissen das besser.


    Jedenfalls sind die Automaten ja meistens aus dem japanischen Raum, also wäre es auch total abwegig dass die ihre Muttersprache benutzen, für etwas das nicht notwendeigerweise dafür geplant wird in die Welt zu exportieren (den Source, nicht die Automaten). Gibt ja auch keine Automaten die in Japansich sind, die verwenden alle brav Hochdeutsch, nicht wahr? :S:rolleyes:

  • Sorry, ich wollte Dich nicht veräppeln!


    Ich halte es für unwahrscheinlich bis ausgeschlossen, dass japanischer Quellcode oder Kommentare darin aus der Zeit japanische Schriftzeichen enthalten hat. Aber man kann japanische Worte auch in ASCII schreiben, und dann sind die Kommentare oder eventuell auch Variablennamen für Personen, die kein Japanisch beherrschen unverständlich. So etwas habe ich selber schon gesehen und es wird wohl auch damals vorgekommen sein. Der Code sollte damit immer noch generell verstehbar sein, aber es ist halt schwieriger ohne die Kommentare.

  • Sorry, ich wollte Dich nicht veräppeln!

    Schon gut. Hab das auch ein wenig in den falschen Hals bekommen. ;)

    Quote

    Ich halte es für unwahrscheinlich bis ausgeschlossen, dass japanischer Quellcode oder Kommentare darin aus der Zeit japanische Schriftzeichen enthalten hat.

    Davon gehe ich mal aus. Denke nicht dass die spezielle Assembler oder Compiler gehabt haben.

    Quote

    Aber man kann japanische Worte auch in ASCII schreiben, und dann sind die Kommentare oder eventuell auch Variablennamen für Personen, die kein Japanisch beherrschen unverständlich. So etwas habe ich selber schon gesehen und es wird wohl auch damals vorgekommen sein. Der Code sollte damit immer noch generell verstehbar sein, aber es ist halt schwieriger ohne die Kommentare.

    Ich denke dass das so gemeint ist. Steht halt nicht so exakt drinnen in den Artikeln.

    Wird dann wqhl eher so gewesen sein dass da z.B: steht

    Code
    1. LDA #$10 ; Konichiwa yokohama

    Oder sowas in der Art. :)

  • Japaner benutzen unser Alphabet (Romaji) eigentlich ungern bzw. nur für westliche Eigennamen. Wenn Kanji (also die aus dem chinesischen importierten komplexen Schriftzeichen) nicht gehen, benutzen sie normalerweise Kana (Silbenschrift). Die alten 8bit-Codepages für Japan scheinen Katakana definiert zu haben. Also würde ich erwarten, daß die Quellcodekommentare in Katakana geschrieben sind, die aber in westlichen 8bit-Zeichensätzen vermutlich irgendwelche grafischen Sonderzeichen waren.

    Der eigentliche Quellcode war sicher in "normalen" Zeichen programmiert.