Hallo Besucher, der Thread wurde 10k mal aufgerufen und enthält 58 Antworten

letzter Beitrag von Diddl am

Prince of Persia Disk Version ?

    mrsid: Vielen Dank für die ausführliche Erklärung.
    Eine Sache hat mich allerdings überrascht. Den Originalcode für den AppleII kenne ich zwar nicht, hätte aber vermutet, daß solche Dinge wie Gitterstäbe als Shapes plus Maskenshape abgelegt sind und für jeden Frame über die Figur gemalt werden, sofern sich die FIgur innerhalb des Shapes aufhält. Das hat den Vorteil, daß man keine ganze Bitmap für die Maske benötigt. Der Einsatz von Sprites macht die Sache natürlich etwas komplizierter, da man die Masken dann fürs Sprite passend zurechtschneiden und shiften muß, aber generell sollte es möglich sein, oder?

    Zitat von Vernunftmensch

    PrinceOfPersia und TrapThem64 haben die selben Probleme. Nur ich habe die Mühe einer Diskettenversion gemacht.


    Ja, auch ich habe eine REU Version ausprobiert. Nur kann ich es nicht selber testen außer im Emu. Der Trick ist wie eine Diskette die REU nutzen, nachdem sie im REU endlich geladen ist.

    An einer REU bzw SCPU Ramdisk arbeite ich seit gestern


    Die SCPU-Ramdisk (im moment nur für sektorbasierende lader zu gebrauchen) funktioniert. Einfach das d64 in das SCPU-Ram ab $020000 laden.


    Den Code habe ich in "Borrowed Time" eingebaut.


    Vernunftmensch: Kannst du bitte aufhören, diesen Thread zu verhunzen.


    Zitat von Ernie76

    Kann man nicht die Animations phasen halbieren ? Sieht dann nicht mehr so smooth aus, aber das würde am Spielfluss ja nix ändern .


    Dazu hat mrsid auch was geschrieben: Schau mal in den Beitrag ganz unten Prince of Persia Disk Version ?

    Zitat von C=Mac


    Aber gleich im 80 Zeichenmodus - O.K. der VDC kann keine Sprites, schon Problem 1 - und mit 2 MHZ. ^^

    Nicht wirklich ein Problem, der Apple II kann das ja auch nicht. Vorausgesetzt das Schreiben ins VDC RAM geht schnell genug, sollte es kein grosses Problem darstellen.


    Zitat von Klaus Scheuer


    Diese Routine kopiert nun per mvn befehl (bedeutend schneller als die REU)
    die entsprechenden Bänke aus dem SCPU-Ram ab $020000 nach $8000-$bfff

    Vergiss nicht das Schreibzugriffe ins ROM im RAM darunter landen müssen, und das man das ROM mit $01 ausblenden kann. Letzteres ist essentiell wichtig um aus der Bitmap darunter zu lesen, beim maskieren.


    Zitat von M. J.

    mrsid: Vielen Dank für die ausführliche Erklärung.
    Eine Sache hat mich allerdings überrascht. Den Originalcode für den AppleII kenne ich zwar nicht, hätte aber vermutet, daß solche Dinge wie Gitterstäbe als Shapes plus Maskenshape abgelegt sind und für jeden Frame über die Figur gemalt werden, sofern sich die FIgur innerhalb des Shapes aufhält. Das hat den Vorteil, daß man keine ganze Bitmap für die Maske benötigt. Der Einsatz von Sprites macht die Sache natürlich etwas komplizierter, da man die Masken dann fürs Sprite passend zurechtschneiden und shiften muß, aber generell sollte es möglich sein, oder?

    Hier mal ein Beispiel der Maske für den ersten Raum:


    Der Bildschirm wird mit Painter Algorithmus gezeichnet. Für die Elemente die den Spieler verdecken, wird nach dem Layer auf dem der Spieler ist die Maskenversion des Elements gezeichnet, und danach die Vordergrund Version des Elements.
    Nach dem Zeichnen des Raumes rauszufinden welche Maske man an der Stelle des Spielers braucht (der Raum wird ja nur einmal gezeichnet) würde bedeuten das man das meiste davon jedes Frame nochmal durchlaufen lassen müsste. Es schien mir wesentlich einfacher den ganzen Schirm als Maske zu speichern. Shiften muss man das dann auch noch.


    Zitat von Ernie76

    Kann man nicht die Animations phasen halbieren ? Sieht dann nicht mehr so smooth aus, aber das würde am Spielfluss ja nix ändern .

    Ja klar, siehe CPC version. Ich find's scheisse, aber manche haben andere Meinungen. Es wird dann immer noch sauknapp, aber wer's versuchen will...

    Danke für die Info. Das richtige setzen von $01 habe ich schon bei anderen Projekten vergessen. Ergebnis = Grafikmüll oder Abstürze.


    Das SCPU-Projekt war eigendlich nur eine fixe Idee von mir.


    Nun denke ich, das ich es doch mal versuchen werde. Mehr als scheitern kann ich auch nicht.


    Ich habe gerade alle Bänke des EasyFlash Moduls ausgelesen. Von Bank 00 bis Bank 31 (Dezimal).


    wobei die letzte Bank wohl Savestates sind.


    Alle Bänke zusammengelinkt ergibt ein Ramfile von 2065 Blocks das liegt dann ab $020000 im SCPU-Ram


    Gruß: Stephan

    Also ich habe mir gerade mal die CPC Version angesehen, die ja deutlich weniger Animations Phasen hat, aber ich finde das es immer noch gut Spielbar aussieht. Könnte man nicht wie bei Sams Journey die Kostüme einige sachen bei bedarf reinladen / rauswwerfen. Das geht ja bei Sam selbst bei der Disketten Version verdammt flott.
    Ich Persönlich könnte schon mit abstrichen leben, wenn es dafür auf einem Vanilla Cevi von Diskette laufen würde.
    Das ist jetzt natürlich nur die Meinung von einem Pixel Schubser, der vom Programmieren null Ahnung hat. ( Habs echt Probiert, ich bin zu blöd für alles oberhalb von Basic )


    [Externes Medium: https://www.youtube.com/watch?v=TQpbCCUquFY]

    Sag, wieso möchtest Du denn ne SuperCPU Version machen ? Du machst Dir mehr Arbeit als Nutzen, da die meisten hier automatisch ne Reu haben als SuperCPU.

    Ach, einfach so aus Spass.


    Ich mache da jetzt nicht den großen Aufriss


    Ich wollte einfach mal wissen ob das wirklich zu realiaieren ist.


    und zudem noch ob eine EasyFlash mittels SCPU emuliert werden kann.


    Die SCPU hat das BasicRom ab $01a000 stehen und den Kernal ab $01e000.


    Wenn man dort etwas verändert,sagen wir mal den "ready promp", bleibt das solange bis man die Hardware neustartet.


    Die EasyFlash ROM-Bänke kann man einfach nach $018000-$01BFFF kopieren.


    Ich habe einen Artikel dazu auf einer US-Seite gelesen. Es ging allgemein darum Module zu Emulieren.



    Lade und starte mal die Datei "pppatch" mittels SCPU von dem angehangenen D64


    und kopiere mittels paste & copy das kleine Programm in den Bildschirm


    nun sagt dir der C64 "HALLO"



    10 poke 107384,72
    20 poke 107385,65
    30 poke 107386,76
    40 poke 107387,76
    50 poke 107388,79

    Zitat von Klaus Scheuer

    An einer REU bzw SCPU Ramdisk arbeite ich seit gestern

    :thumbsup:



    Zitat von mrsid

    Nicht wirklich ein Problem, der Apple II kann das ja auch nicht. Vorausgesetzt das Schreiben ins VDC RAM geht schnell genug, sollte es kein grosses Problem darstellen.

    Wenn das fehlen von Sprites kein Problem darstellen, könnte man Prince of Persia auf den C128 portieren.
    Wäre doch ein Projekt für C128-Programmierer, mit 64KB-VDC-RAM sollte man doch was anstellen können.
    * Träum *


    Gruss C=Mac.

    Zitat von Klaus Scheuer


    Ich habe gerade alle Bänke des EasyFlash Moduls ausgelesen. Von Bank 00 bis Bank 31 (Dezimal).

    Ja, die letzte LOROM bank hat die Speicherstände. Anbei die ganze Bankbelegung, falls es hilft...


    Zitat von Unseen

    Gepatcht oder EAPI für UC-2 geschrieben?


    Ein Patch war meine erste Idee.

    Aber das war zu kompliziert (für mich).

    Bin wohl zu doof dafür ...


    Dabei geht es viel einfacher.

    Einfach ein neues Jedec für den CPLD.

    Jetzt verhält sich diese UC-2 wie ein EF mit 512K Flash. :)