Posts by M. J.

    Ich habe ja hier auch gefragt, weil ich keine vernünftigen Versionen finde. Nur irgendwas mit Cracktros davor oder so möchte ich nicht haben.

    Hmmm... Also ohne Cracktros wirst Du auf dem C64 kaum etwas bekommen, es sei denn, Du greifst auf die g64-Disketten zurück, welche die Originaldisketten mit Kopierschutz konservieren. Dann könnte das aber den Nachteil haben, daß beim Kopierschutz illegale Opcodes verwendet werden oder es Probleme mit dem (Schnell)Lader gibt, weil die Kommunikation mit dem Diskettenlaufwerk bei einer Beschleunigerkarte aus dem Tritt gerät. Bin jetzt aber kein Kenner für Kopierschutzverfahren. Da müßte man mal die Experten hier im Forum fragen.

    Also ich hatte zumindest Stunt Car Racer mal auf der Flash 8 laufen, das hat auch keine Grafikfehler gezeigt.

    Spezifisch zu "Stunt Car Racer" könnte ich nichts sagen, weiß nicht einmal, ob es davon nicht inzwischen eine speziell angepaßte (gepatchte) Version gibt. :nixwiss: Gut also, daß Du von Deinen Erfahrungen berichtest (s.u.).

    Auf YouTube gibt es auch ein Video von Test Drive auf der SuperCPU, und die müßte ja mehr als doppelt so schnell sein wie die Flash 8.

    Nicht unbedingt. "Test Drive" bzw. "Test Drive II" gehört zu den wenigen Spielen, die intern über eine Bremse verfügen, d. h. egal wie schnell der Prozessor läuft, das Spiel an sich (d. h. die Spielmechanik) wird nicht schneller, sondern lediglich die Grafik flüssiger. Bei "Test Drive II", meine ich, braucht es 6 Interrupts um die Berechnungen für alle Objekte durchzuführen. Die Animation wird daher niemals schneller laufen als mit 50 / 6 = 8,333 fps.

    der Sound ist ja auch nicht acht mal schneller.

    Sound wird standardmäßig über den Interrupt abgespielt. Dafür sind folglich von Natur aus keine Anpassungen notwendig. Es geht tatsächlich nur um das Verhältnis zwischen Animation und Grafikmalen. Diese beträgt (bis auf wenige Ausnahmen wie das erwähnte "Test Drive") in der Regel 1:1, d. h. auf eine Animationsphase folgt eine Grafikphase immer schön brav abwechselnd. Beschleunigt man das Programm, wird die Animation eventuell so stark beschleunigt, daß das Spiel unspielbar wird. Bei extrem langsam programmierten Titeln wie "Driller" mag das nicht auffallen, bei anderen wie "Elite", "Mercenary", "Space Rogue"... aber schon. So kann ich mit Hilfe meines AppleII-Emulators z. B. ein Spiel wie "Elite" oder "Space Rogue" stufenweise beschleunigen auf 2, 4 oder 8 Mhz usw. Schon bei 2 Mhz wirkt die Steuerung im Weltraum leicht hektisch und überdreht. Bei 4 Mhz läßt sich das eigene Schiff nicht mehr vernünftig spielbar kontrollieren.

    Ich habe eine Liste von Spielen gefunden die illegale Opcodes verwenden sollen.

    Die Liste kann so eigentlich nicht stimmen, denn die Spiele "Arctic Fox", "The Bard's Tale", "Rescue on Fractalus" laufen bei gleicher Codebasis auch auf einem 65c02 AppleII. Sollte sie dennoch illegale Opcodes aufweisen, würde ich eher darauf tippen, daß diese bei der Portierung in C64 spezifische Routinen eingebaut wurden oder in Crackerintros, -Packern oder sonstigen Crackerpatches Verwendung finden. (Den Code für "Arctic Fox" und "The Bard's Tale" hatte ich mir außerdem vor Jahren mal angeschaut und keine illegalen Opcodes darin gefunden.)

    Nebenbei: Wenn ich mich recht erinnere, verwendete "Test Drive II" noch mindestens einen anderen illegalen Opcode (LAX?) und das leider völlig unnötig. Man hätte die Grafikroutinen mit legalen Opcodes sogar schneller gestalten können. :(


    Eine Bitte: Wenn Du die diversen Programme austestet, wäre es vielleicht möglich, daß Du hier im Forum von den Ergebnissen berichtest? Es wäre nämlich gut, wenn es eine verläßliche Zusammenfassung gäbe, was auf realer Beschleunigungshardware gut läuft und was nicht, anstelle von Spekulationen.

    Komm schon und gib dir nen Ruck, du weißt das du es fertig machen willst.

    Ja, ich würde es gerne fertig machen wollen, aber habe momentan leider gar keine Zeit dazu, da ich meine Freizeit nahezu vollständig darauf verwende, ein für mich wichtiges Projekt durchzuführen. Ich will daher nicht ausschließen, daß ich mich irgendwann noch einmal mit dem Elite-Code beschäftige, halte es aber für die nächste Zeit für nicht wahrscheinlich. :(

    - Space Rogue



    Nebenbei: Die Spiele mit der Freescape-Engine ("Driller" etc) sind deswegen so langsam, weil sie soweit ich weiß

    a) für Multiplikationen keine Tabellen und nicht einmal loop-unrolling verwenden, sondern alles schön brav in einer gemütlichen Schleife erledigen,

    b) kein echtes Double-Buffering betreiben, sondern die Grafik zwar in einen linear aufgebauten Hintergrundpuffer zeichnen, aber diesen dann umständlich in die Anzeigebitmap kopieren.

    Hätte man die einzelnen Orte auf Diskette ausgelagert und bei Bedarf nachgeladen, hätte man ausreichend Platz gehabt für schnelle Multiplikationsroutinen und Double Buffering. Aber nein, das Spiel mußte ja unbedingt wieder ein Onefiler sein und komplett in den Speicher geladen werden...


    Und noch was nebenbei:

    Die meisten der hier genannten Spiele werden mit einer Beschleunigerkarte nicht zurecht kommen, d. h. sie sind mit der Flash8 (oder SCPU) praktisch nicht spielbar. Das hat hauptsächlich zwei Gründe:

    a) Die Spiele werden zu schnell, besonders in der Steuerung. Die Schrittweiten in der Drehung sind angepaßt an die niedrige Framerate bei 1 Mhz. Erhöht man die Prozessorgeschwindigkeit, drehen sich die Objekte (besonders das eigene) viel zu schnell. Die wenigsten Spiele (wie "Test Drive II") wurden so entwickelt, daß sie intern über eine Bremse verfügen oder andere Maßnahmen, um die Prozessorgeschwindigkeit so zu verteilen, daß allein die Grafik beschleunigt wird, aber nicht die Spielmechanik. Das Grundprinzip der alten Spiele lautet in der Regel: "abwechselnd malen und Objektbewegungen berechnen" und nicht "einmal pro Frame Objektbewegungen durchführen und die Grafik irgendwie so schnell wie möglich parallel ausgeben".

    b) Bei Spielen mit Rasterinterrupt (z. B. "Mercenary") werden diese ebenfalls beschleunigt, was zu unschönem Flackern auf dem Bildschirm führt. Bei "Test Drive II" verschwinden gar Sprites vom Bildschirm. In solchen Fällen sollte man die Beschleunigung per Rasterinterrupt nur innerhalb des vertikalen Rahmens anschalten. Bei der SCPU ist dies über $c070 möglich, und die verbleibende Zeit reicht immer noch für einen starken Geschwindigkeitszuwachs. Sollte dies mit der Flash8 nicht möglich sein (kenne die Karte leider nicht), muß man in vielen Fällen kaputte Anzeigen in Kauf nehmen.

    Daneben gibt es natürlich auch das Problem, daß Programme illegale Opcodes enthalten können, die dann auf einem 65816 nicht mehr funktionieren. "Test Drive II" z. B. ist voll davon. Und zuletzt ist der 65816 auch bei "legaler" Nutzung im Kompatibilitätsmodus nicht wirklich 100% kompatibel zum 6502. All dies sollte man mitbedenken, wenn man eine Beschleunigerkarte auf Basis des 65816 am C64 einsetzen möchte.

    Gedanken an eine "Grafikkarte" gab es tatsächlich schon. Sie scheitern aber an Folgendem:


    1.) Die Bitmap-Grafik beim C64 ist tile-basiert. Pro Tile (= Kachel) stehen nur 4 Farben zur Verfügung. Möchte man in eine Bitmap sowohl Hintergrundgrafik als auch bewegliche Objekte einfügen, darf die Anzahl der Farben pro Tile nicht 4 überschreiten. Dies führt zu erheblichen Colour-Clashes, sofern man sich nicht von vornherein auf 4 Farben beschränkt, wie dies in den meisten 3d-Spielen der Fall ist (einzig mir bekannte Ausnahme: "Space Rogue").


    2.) Der DMA ist sehr langsam. Um eine vollständige Bitmap-Grafik ohne Farbram zu übertragen, braucht man schon 8000 Zyklen. Sehr, sehr grob geschätzt (ohne Bad-Lines etc) verfügt man pro Frame über 65 * 280 = 18200 Zyklen, d. h. fast die Hälfte geht bereits drauf zum Kopieren der Bitmap-Grafik. Wichtig: In dieser Zeit ist der Prozessor lahmgelegt. Er kann weder die Grafikkarte mit neuen Daten füttern, irgendwelche Berechnungen ausführen oder einen Interrupt bedienen (Ade Rasterinterrupt).


    3.) Es reicht nicht aus, nur das Malen der Polygone zu beschleunigen. Ein Großteil der Rechenarbeit steckt in der Animation der 3d-Objekte, d. h. die Bewegung durch den Raum, die Rotation der Objekte und die Kollisionserkennung. Ein Blitter kann diese Vorgänge nicht beschleunigen. Schaut man sich dir Grafik in einem 3d-Spiel wie "Elite" an, so sieht man zudem, daß die Polygone nur äußerst selten wirklich groß sind, z. B. wenn man sehr nahe an die Raumstation heranfliegt. Daraus ergibt sich auch, daß im Normalfall des Fluges durch den Raum der Einsatz eines Blitters kaum Beschleunigung ergeben kann. Für eine echte 3d-Beschleunigung ist es unausweichlich, auch andere Berechnungen per Hardware auszuführen.


    Aus den genannten Punkten ergibt sich jedoch, daß

    a) die Grafikdaten nicht umständlich in den Speicher des C64 kopiert werden können, weil dies zu viel Zeit beansprucht. Es ist vielmehr notwendig, der "Grafikkarte" einen eigenen Bildschirmspeicher mitzugeben mit gesondertem VGA-/HDMI-Anschluß.

    b) die Grafikkarte über einen eigenen Prozessor verfügen muß, um 3d-Berechnungen zu übernehmen. Da es sehr, sehr viele Möglichkeiten gibt, 3d-Daten zu berechnen ("Rescue on Fractalus", "Elite", "Driller", "Stunt Car Racer" etc funktionieren alle komplett anders in ihren Berechnungen.) kommt man mit einer einfachen Punktberechnung über Matrizen nicht weit. Es gibt einfach zu viele weitere komplizierte Berechnungen, die den Einsatz eines Prozessors erfordern.


    In Summe hätte man dann eine "Grafikkarte", welche über ihr Ram eigene Bilder erzeugt, einen ARM-Prozessor verwendet für die Berechnungen und den C64 nur gebraucht als Stichwortgeber. Es mag jeder für sich entscheiden, ob das dann noch ein C64 ist.

    Was mir jetzt noch einfiel: Kannst du sagen, was ergänzt wurde?

    Der reguläre Lösungsweg ist identisch, jedoch enthielt die erste Version einen gravierenden Fehler, der dazu führte, daß ein großer Teil des Spiels ungewollt übersprungen werden konnte. Dieser Fehler wurde korrigiert. Außerdem wurden Texte erweitert und die Wortwahl der Beschreibungen vereinheitlicht. Auch einige Tipfehler wurden ausgemerzt. (Es gibt, glaub ich, jetzt "nur" noch zwei Tipfehler im Spiel... ;( ) Hinzugekommen sind hauptsächlich neue Objekte und Beschreibungen, d. h. man erhält auf Aktionen, die nicht unbedingt zielführend sind, trotzdem Antworten. Erkennbar ist dies bereits am Anfangsort: In der ersten Version erschien nur die Ortsbeschreibung; in der neuen Version hingegen findet sich auch der Hinweis auf das Objekt "Marktplatz". Zuletzt gibt es auf www.c64games.de auch die überarbeitete Anleitung als pdf-Datei, in der die Eingabemöglichkeiten des Parsers aufgelistet sind. Kurz gesagt: Es sind schon einige sinnvolle Veränderungen, so daß man sich die erste Version nicht mehr antun sollte. ^^

    ein Baby nach der Geburt erstmal noch kein Bewusstsein haben dürfte

    Ich denke, man kann davon ausgehen, daß Kleinkinder bis ca. 1 1/2 Jahre (sehr grob geschätzt) noch nicht sehen, wie ältere Menschen, d. h. es existiert kein vollständiges farbiges Bild im Kopf. Auch die ersten Wahrnehmungen des Sehens beschränken sich lediglich auf einen kleinen Ausschnitt aus dem Gesamtfeld, der aus irgendeinem Grunde einer näheren Beobachtung unterzogen wird. Der Rest drumherum wird nicht bewußt wahrgenommen. Das "Ich" entwickelt sich erst langsam zusammen mit dem Sprechen und dem Sehen bis zu einem Alter von ca. 2 Jahren, was man auch daran erkennen kann, daß kleine Kinder nicht in Bildern träumen, sondern in Mustern. Der Wechsel vom Musterträumen zum Bilderträumen ist ein Sprung, der ungefähr (wieder nur grob geschätzt) ab dem 2. Lebensjahr stattfindet, und da das Gedächtnis stark mit der (bewußten) visuellen Verarbeitung verknüpft ist, können die meisten Menschen sich nicht an Ereignisse erinnern, die vor ihrem 2. Geburtstag stattgefunden haben.

    Danke für die neue Version!

    Das Problem war banal und selbstgemacht. Der Bereich von $0334 bis $03FF ist nach dem einschalten des C64s mit Nullen gefüllt.

    Hmm... Speicher nicht ordentlich zu initialisieren und auf Einschaltwerte zu vertrauen, halte ich aber eher für einen Fehler des Spiels. Sowas ist ganz schlechter Programmierstil... :yellowcard:

    - Man kann/muß tauschen.

    Die Reifen.


    - Wenn man nicht richtig tauscht, hat es fatale Folgen.

    Tauscht man einen kaputten Reifen nicht rechtzeitig, macht es "Boing", und man bleibt auf der Strecke liegen.


    - Wer schneller tauscht, ist klar im Vorteil.

    Schnelligkeit ist bei einem Rennen immer wichtig.


    - Wer beim Tauschen parallel agiert, fährt besser.

    Der Trick liegt darin, gleichzeitig die Reifen zu wechseln und aufzutanken. Damit fährt es sich besser.


    - In diesem Spiel wird nicht nur getauscht, sondern - ein Novum - auch was geteilt.

    Das Spiel war eines der ersten mit einem Splitscreen für zwei Spieler.


    - Die englische Grube spricht im Deutschen laut.

    Das englische Wort für "Grube" ist "pit", was in diesem Fall im Deutschen mit "Box" übersetzt wird, was auch "Lautsprecher" bedeuten kann.


    - Es kann nur nach bestimmten Abschnitten getauscht werden.

    Einmal pro Runde.


    - Zu häufiges Tauschen sollte man meiden.

    Da ein Stop im Pit sehr viel Zeit kostet.


    Die Antwort lautet also:


    Pitstop II



    Da es davon aber 2 Teile gibt, läßt sich auch nicht sagen welcher Teil es dann wäre

    Nur der zweite Teil verfügt über den Splitscreen, aber so kleinlich wollen wir mal nicht sein.

    Freu Dich, Du bist dran. :D ( :bgdev )

    Wenn jetzt der letzte Tipp nicht wäre, hätte ich Paradroid geraten.

    Tut mir leid, das ist es auch nicht. :/



    - Man kann/muß tauschen.

    - Wenn man nicht richtig tauscht, hat es fatale Folgen.

    - Wer schneller tauscht, ist klar im Vorteil.

    - Wer beim Tauschen parallel agiert, fährt besser.

    - In diesem Spiel wird nicht nur getauscht, sondern - ein Novum - auch was geteilt.

    - Die englische Grube spricht im Deutschen laut.

    - Es kann nur nach bestimmten Abschnitten getauscht werden.

    - Zu häufiges Tauschen sollte man meiden.