PC Engine Version VS Mega Drive Version

    ganz einfach. die AC arbeiten nach dem laden aller notwendigen daten autonom wie ein equivalänter festspeicher, da während des spiels ja nichts mehr von der cd geladen werden kann, dies wegen des red book audio access. dank den grosszügigen 2MB können einzelne levels so prächtig gestalltet werden, was sonst für ein kompletes spiel auf modul an speicher verbraten würde.

    Zitat

    Original von Retro-Nerd
    Sind die großen Sprites der SNK Spiele dann auch vorgerendert, oder nur einige Animationen/Backgrounds?


    die sprites haben nichts mit prerender zu tun, da diese ja von hand gezeichnet/erstellt wurden. die AC hilft hierbei lediglich die vielen animationsstufen der grossen sprites zu puffern, da auch hier während der levels kein direkter CD zugriff mehr stattfinden kann.

    Deswegen wäre theoretisch ein laden von einer HuCard Variante auch ohne Extracard möglich, allerdings dürfte dann die CPU Belastung höher sein.

    Retro-Nerd
    Dürfte nur die Backgrounds sein, denn der Rest muss flexiebel bleiben.

    gut, das die Hucard schneller ist, ist ja klar.
    Was mir beim vRam zu denken gibt, in dem Speicher liegen ja quasi alle Informationen, die auf dem screen angezeigt werden müssen. Er dient als framebuffer, und beinhaltet auch die Daten wie eben die Bitmap Grafiken, welche dann vom Programm im eigentlichen Main ram aufgegriffen werden.

    Ist es da wirklich das gleiche die Daten einfach nur sehr schnell von der Hucard in die 64K zu kopieren, wie wenn ich den VRam auf 2MB erweiter ?

    Einmal editiert, zuletzt von Black Sun (6. Januar 2010 um 19:43)

    Nicht ganz, die Daten wäre ja immernoch direkt von der Hu-Card lesbar, nichts anderes macht ja die AC.
    Die AC ist quasi wärend des SPiel sozusagen ein HuCard nur mit den Video Daten. Es wäre aber natürlich auch möglich ein Hu-Card mit allen Daten herzustellen
    3 Probleme ergeben sich nur.
    Zum einen muss dann die Konsole Video und Audio von der Hu-Card laden, das KÖNNTE die CPU überfordern.
    2.Die Hu-Card hätte dann locker 48Mbit und soweit ich weis kann die PCE solche grössen nicht ansprechen, wäre aber mit bakswitching möglich.
    Und zum schluss ein altes Lied: "Wer soll das bezahlen......".

    EDIT:
    Habe gerade gesehen, einen kleinen Denkfehler hast du.
    Die AC ist keine Ramerweiterung, die Hardware kann NICHT direkt daraufzugreiffen wie auf den System Ram.

    Einmal editiert, zuletzt von ONOX2 (6. Januar 2010 um 19:48)

    Habe noch das hier gefunden:

    Zitat

    I wrote the Arcade Card libraries that Hudson distributes to it's developers, so I know what this baby does!

    There are four ports to access the memory from the CPU. Each port is one word. Each port can point to a separate address in the arcade card memory. Settings for the ports are also completely independent. The addresses are determined by a "base address" (3 bytes) and an "offset" (2 bytes). Reading and writing is possible from all ports, and each can be set to auto increment or decrement the offset or the base address. Also, there is a bit one can "hit" that causes the base and offset to be added, with the result being stored in the base. This COULD be used as a fast 3 byte adder. There is also a 4 byte read/write barrel roller. Basically, you can store any 4 byte value in this register(s) and write the number of times you wish to shift or roll to a 5th register and you can read the result immediately. This is very limited, but a good hacker could find some tricky little application. I was able to optimize division and multiplication routines, also optimized a run length decoder using this feature... (I would have rather had a real multiplier and divider, or floating point, or something, but costs were prohibitive.)

    Quelle

    Zitat

    Nicht ganz, die Daten wäre ja immernoch direkt von der Hu-Card lesbar, nichts anderes macht ja die AC.


    richtig

    Zitat

    Zum einen muss dann die Konsole Video und Audio von der Hu-Card laden, das KÖNNTE die CPU überfordern


    logisch war mein beispiel ohne sound gedacht und nur auf die grafik bezogen, da bei CD games der redbook ohnehin direkt ab CD gelesen wird und die FX über den CDrom internen 64k audio-ram (ADPCM) bezogen werden.

    Zitat

    2.Die Hu-Card hätte dann locker 48Mbit


    mein beispiel war ja auf einzelne levels begrenzt, also hätte die Hucard nicht mehr als 16Mbit benötigt = OK.

    Zitat

    Und zum schluss ein altes Lied: "Wer soll das bezahlen......".


    wie gesagt, es war nur ein theoretisches beispiel um zu zeigen, dass auch die uralt pce von '87 mit der grafik eines sapphires auch ohne add-ons auskommen würde :)

    http://www.pcedaisakusen.net
    the home of your individual pc engine collection!!
    PCE Shmups countdown: 110/110 (clear!!)
    PCE Games countdown: 673/735 (62 to go)

    2 Mal editiert, zuletzt von Tatsujin (6. Januar 2010 um 19:55)

    OK, aber ich wollte nur mit dem ganzen Game sozusagen Rechnen.
    Spätesten der SOund wäre eh ein Problem, den den Sound bekommt die PCE nur über CD hin da die Sampler für ein normale Hu Card zu gross sind, aber das ist wieder ein anderes Thema.

    Um aber auf den Punkt zu kommen, es ist möglich, nur damals auf die weise einfacher zu realisieren.


    Demnach sind die Bilder links PCE und rechts MD!?

    Die Sphinx bei Forgotten Worlds sieht ja rechts erbärmlich aus...... Wusste gar nicht das es auch eine PCE-Version davon gibt!

    Also über die Raidenumsetzung braucht man grafisch nicht diskutieren.Die ist auch grafisch unterirdisch gemacht selbst für die etwas schlechtere Farbpalette.Dafür ist es technisch einiges besser gemacht.Flüssigeres Scrolling und flüssigere Bullets.

    Das die Forgottenworldumsetzung kleinere Sprites hat liegt sicher auch nicht am MD.Farben ist klar PCE wieder besser.

    PCE Shmupcountdown: 108/109 1 to go !