Posts by Bytebreaker

    Quote from yello

    (...) wegen ersten der Steuerung.
    Die finde ich matschig

    Finde ich gar nicht. Die ist genauso präzise wie beim Original.
    Ich spiele auf einem echten C128 mit einem echten Competition Pro Joystick. Überhaupt ist das eh toll gelöst, wie gut Mario mit einem Competition Pro lenkbar ist, inkl. "Speed Run" bei gedrückter Feuertaste.


    Ich würde keinen Emulator und USB-Joysticks als Referenz nehmen, sondern die echte Hardware, für die das Spiel geschrieben wurde.
    In puncto Slow Downs gebe ich Dir aber recht. Auf einem C64 von der Stange stören die Hänger. Hier zeigt sich eben, dass eine 100%-Portierung von einem stärkeren auf ein schwächeres System problematisch sein kann und man bessere Spielbarkeit hätte erzielen können, wenn man sich weniger getreu ans Original gehalten hätte (z.B. NES Sound Emulation statt natives eigenkomponiertes SID Gedudel). Andererseits ist es dadurch ein 100% C64-Port, was allein schon historisch von Bedeutung ist.

    Hallo,


    danke für die weiteren nützlichen Hinweise und Tips.


    Ich habe jetzt mal einen Vertikalscroller versucht, und zwar als "scrollbaren Brief" inkl. ColorRAM.
    Das Programm startet direkt per Basic-Zeile, lässt sich also starten per Drag 'n Drop in VICE.


    Die Steuerung ist wie bei der Vorgänger-Demo: Feuertaste stoppt den Scroll. Hoch / Runter = Richtungswechsel. Erst wenn man wieder Feuer gedrückt hat kann man die Richtung wechseln.


    Jetzt muss ich schauen, dass ich das enger und kleiner kriege und lauffähig, auch wenn ein regulärer Raster IRQ Musik abspielen will. Je nachdem wieviel Platz dann noch für Logik ist, kann man ein Spiel oder ein Intro um die Scroll-Routine machen. Ich denke um so Themen wie "25Hz Scrolling" werde ich wohl auf kurz oder lang nicht drum herum kommen wenn das ColorRAM weiterhin stets mitkopiert werden muss und da noch ein paar mehr Sachen am Schirm passieren sollen.

    Files

    • vscroll.prg

      (23.83 kB, downloaded 13 times, last: )

    Great job!


    There are rules how good intros work and you seem to follow them by instinct.
    It's not (only) about complexity, it's mainly about design, visual and acoustic harmony.


    To me it is a pain in the a** to see skilled coders waste their talent in badly designed intros. The C64 has no choice, it has to execute ugly design even though it's much better to keep the C64 occupied with beauty and elegance.


    So the more I'm relieved to not only see good coding basics, but also a naturally good arrangement of colors, movements and sounds. Thumbs up.

    @ bkn


    Danke für das Feedback und den 1.5 Frames Hinweis. Das ist ja im Grunde das „Hinter dem Strahl bleiben“ wovon Claus spricht. Den Hintergrund nehme ich wahrscheinlich sogar für das spätere Intro wenn mir nichts besseres einfällt.


    Ich bin eigentlich überhaupt kein Rasterstrahl Fan und beherrsche schlecht den Überblick über Zyklus-Verbrauch im Verhältnis zur Strahlposition. Aber wenn man den C64 mag muss man da durch.

    Hier ist das Ergebnis meines Projekts.


    Load „qt4.prg“,8


    Dann run.


    Die Scrollroutine (4scroll.prg, Start bei $3000) wird vom Basic Programm qt4.prg aus aufgerufen. Das Basic Programm baut auch einen Scrollbereich Vollbildschirm mit ColorRAM auf. In diesem Beispiel ist der Scrollumfang nur der eine Screen. Mein Programm ermöglicht aber das Nachladen von Scrolldaten.


    Mit dem Joystick eine Richtung wählen. Feuer stoppt das Bild. Erst dann kann man erneut die Richtung wechseln.


    Das stabil zu kriegen war schon alles ziemlich nah am Nervenzusammenbruch. Es ist zwar noch ein paar wenige Rasterzeilen Platz, aber für ein Spiel oder ein Intro müsste ich so oder so umbauen, denn Interrupts sind bis auf den NMI aktuell gesperrt. Schon allein Musikwiedergabe würde daher nicht ohne erneutes Anpassen gehen.


    Dennoch war es eine lehrreiche Übung.

    Files

    • 4scroll.prg

      (4.76 kB, downloaded 17 times, last: )
    • qt4.prg

      (865 Byte, downloaded 17 times, last: )

    Also ganz einfach gesagt:


    Eine Spalte bzw. Zeile am Scroll-Ende kann vom Rahmen per Bit-Schalter überdeckt werden. So kann man 8 Pixel per Register scrollen und wenn das erledigt erledigt ist, muss man, während der Rasterstrahl nicht dort ist wo man das Bild verändert, den gesamten Bildschirm um eine Spalte bzw Zeile zu 8 Pixel Breite, bzw. Höhe versetzen und kann den vom Rahmen verdeckten Bereich beschreiben, der dann pixelweise wieder herausgescrollt wird. Wenn dann das Scroll-Register wieder zurückgesetzt ist (mehr als 8 Pixel Versatz durch Register geht nicht) sieht der Beobachter das umkopierte Bild, als sei das Scroll-Register noch gesetzt. Das Scrollen per Register um 8 Pixel kann wieder losgehen. Dadurch entsteht die Illusion einer fließenden Bewegung.


    Man muss nicht die eigentliche Bitmap von Hand bewegen, aber immerhin 1000 Bytes ScreenRAM und in meinem Fall nochmal so viel ColorRAM. Das geht bei mir nur, indem man die 8 Frames Rasterzeit beim pixelweisen Scrolling zum Kopieren in Puffer und zweite Videobank nutzt.


    Es soll auch Leute geben, die zumindest ScreenRAM „one frame“ scrollen können, zu denen zähle ich aber aktuell nicht. ;-)

    So, kurzes Update:


    Ich bin letztlich Acorns Weg gegangen für das Scrollen nach unten und habe ca 7 Kiometer Speedcode dafür geschrieben. Die ersten 16 ColorRAM-Zeilen werden über eine x-dekrementierte Schleife kopiert, der gesamte Rest per lda sta Folge.


    Zumindest mal ist die Scrollgeschwindigkeit bei allen 4 Richtungen nun gleich, auch wenn das Abwärtsscrollen am meisten Platz verbraucht. Eine Idee für ein Intro habe ich schon, danke für die Tips, dafür kommt ihr in die Greetings. :-)

    Zwischenstand:


    Scrollen nach oben geht jetzt, da habe ich wirklich nur Acht geben müssen, dass im letzten Frame vor dem Video-Bankwechsel das Kopieren des FarbRAMs dem Rasterstrahl hinterherläuft und der Rasterstrahl somit nirgends "querläuft".


    Am Scrollen nach unten bin ich noch dran. Noch möchte ich den Code dafür nicht wegschmeißen und neu machen, weil 3 von 4 Scroll-Arten ja nun schon gehen und das Abwärtsscrollen ohne ColoRAM ja auch schon geht. Die 4 Scrollarten sollen später in einem Stück verwendbar sein und es soll daher viel ähnlichen / herauskürzbaren Code ergeben.


    Im Moment neige ich dazu, einen eigenen ColorRAM Buffer und Speed Code zu verwenden, auch wenn Claus' Lösung die elegantere ist. Dazu müsste ich aber das ganze Ding neu schreiben. dies tue ich vielleicht sogar ein andermal, aber noch nicht jetzt.


    In den nächsten Monaten plane ich dann, 4 Wege Full Screen Scrolling in einem Intro zu verwenden. Die genauen Ideen dafür fehlen mir aber noch. Danke für die guten Hinweise.


    Edit:


    Ich habe in dem zusammenhang auch das Spiel "Fort Apocalypse" auf C64 Wiki als 4 Wege Scrolling Beispiel gesehen. Das war 1982. Und da flackert nix! Alle Achtung. Es sei denn, im Multicolor Text Mode ist eine Farbe immer gleich, und das könnte der schwarze Hintergrund sein, der ist immer gleich und kann vom ColorRAM kommen. Trotzdem gut hinbekommen.

    Quote from IntyMike

    wenn man dann in einem Test schlechter bewertet weil man das Spiel ja auch kostenlos bekommen könnte

    wenn du den Test gelesen hättest dann wüsstest du, dass ich genau das im Test überhaupt nicht erwähnt habe.


    Wenn Dir 50 Dollar für ein uraltes unverändertes Spiel mit ein paar Papier-Reprints preiswert erscheinen dann kauf es. Ich gebe meine 50 Dollar lieber Psytronik oder RGCD für echte Entwicklungsarbeit statt ein bisschen schlampiges Marketing Recycling.


    Auch wenn es kein frei beziehbares ADF gäbe, fiele mein Urteil gleich aus und so steht es auch im „offiziellen“ Test. Zugegeben, hier auf Forum 64 schreibe ich privat dazu was ich mir nebenher noch gedacht habe.

    Wenn man etwas von 1988 frei googeln und offen auf ordentlich sortierten Archivseiten herunter laden kann ist es also wirklich eine Raubkopie?


    Was ist dann csdb?


    Ich dachte immer die „echten“ Raubkopien laufen nur über dubiose Torrents und Darknet und dass alles was offen googlebar ist, doch sofort verklagt werden müsste. Daher hielt ich es für rechtlich unbedenklich ADFs von uralten kommerziellen Spielen herunter zu laden.


    Ich möchte ausdrücklich der Retro Szene nicht finanziell schaden, daher habe ich Neuerscheinungen wie Sams Journey stets gekauft. Es wäre Verrat für mich, heimlich zu versuchen mir das zu erstehlen worin Retro Fans unzählige Arbeitsstunden versenkt haben um die Fans zu erfreuen.


    So oder so bleibt Rocket Ranger Reloaded sowohl vom Kaufpreis als auch vom Gameplay her für mich hoffnungslos überbewertet.

    Rocket Ranger Reloaded habe ich in einer der letzten Amiga Future Ausgaben getestet und leider für Müll befunden, auch wenn der Sven offenbar ein sehr geschätzter Typ ist der sich in der Szene verdient gemacht hat - auch der Amiga Future Chefredakteur schätzt ihn.


    Der Grund für den Verriss war, dass Rocket Ranger Reloaded in der Hauptsache ein Emulatorpaket auf E-UAE-Basis ist. Unter Windows spielt sich Rocket Ranger daher überall da schlecht, wo es um Timing geht (WinUAE wäre besser gewesen). Hinzu kommt, dass sie meiner Testversion auch noch die falsche (!) Code-Tabelle beigelegt haben und ich die richtigen Codes mühsam googeln musste. Bis auf ein simples Intro und die auf der CD eingerichtete Fähigkeit, die dort vorhandenen ADF-Dateien an einem echten Amiga, bzw. CD32 zu mounten und zu starten, gibt es gar nichts Neues - wir haben es mit dem unveränderten Spiel von 1988 zu tun, das einem als adf-Datei im Internet auch kostenlos in den Schoß fällt. Und dann noch wegen einer Pappschachtel und Papierbeilagen einen happigen Vollpreis von 50 Dollar zu verlangen ist imho eine echte Frechheit - auch wenn noch weitere Emulator-Images wie z.B. von NES und C64 dabei sind. Das ist - bei allem Respekt für Sven - aus meiner Sicht Nepp.

    @ kbr


    Verstanden! Und das hast Du super umgesetzt! Dein Assemblerprogramm ist ein track-weiser Töne-zu-Track-Konverter der auch trackweise Disketten beschreibt. Auf diese Art bringst Du images auf echte DSKs.


    Geil! :ilikeit:


    Ich selbst benutze sowohl für meinen 464 als auch meinen 6128 Hardware-Floppy-Emulatoren von so einem brillianten Typ aus Polen (DDI3-Geräte von einem Typen namens zaxon, gibt es auf sellmyretro.com), der die Dinger selber baut und verkauft. So kann ich Images von USB-Träger direkt mounten und verwenden.

    Huhu,


    mal eine Frage an alle, die sich schon mit Scrolling herumgeschlagen haben:
    Gibt es eine gängige Technik, das ColorRAM ohne Bild-Flackern mit dem Textbildschirmin alle 4 Richtungen mitzuscrollen?


    Das Scrollen des Textbildschirms geht mit Double Buffering und man hat ja 8 Frames Zeit, den Screeninhalt auf eine andere Videobank zu bewegen.


    Diese Zeit hat man aber nicht, um das ColorRAM zu verschieben. Horizontal habe ich es in beide Richtungen hinbekommen, das ColorRAM flacker- und zitterfrei mitzuscrollen.
    Vertikal gelingt es mir weder nach oben noch nach unten, nur das ScreenRAM lässt sich weich scrollen. Einen wirklich systematischen Ansatz habe ich bei alledem auch nicht, ich habe so lange herumprobiert, bis die Mischung aus abgearbeiteten Zyklen und abgewarteter Rasterzeile nicht zu Bildschirmschrott geführt hat.


    Vielleicht können wir hier ja eine kleine Diskussion darüber beginnen, ob es überhaupt gute Konzepte für ColorRAM Scrolling gibt und ob das überhaupt verbreitet war (Im Multicolor Textmodus hat man ja eigentlich genug Farben. dass eine dann immer gleich ist, ist dann eigentlich nicht so sehr auffällig).

    @ kbr


    Du hast Disk Images auf Disk geschrieben mittels Tape Port? Oder hast Du Disk Images auf Tape geschrieben über PC-Soundkarte und CPC Tape Port? Ich wusste gar nicht, dass man Disketten auch über Töne beschreibt, ich dachte immer, Disketten werden nicht über Töne magnetisiert.