Posts by M. J.

    Ich wollte hier mal einstreuen, das mir brauchbare Programmierumgebungen für den C64 fehlen

    Leider paßt das von Dir genannte Beispiel nur gar nicht zu den 8 Bit-Rechnern und mag daher auch ein Grund sein, warum es die von Dir gewünschte Basisbibliothek nicht gibt. Erlaube mir, das Beispiel aufzugreifen, um anhand dessen stellvertretend die Gründe zu erläutern.


    Die Bestimmung der Farbe erfolgt beim C64 doppelt indirekt: zunächst über das Bitmuster als Index in die Farben des Farbrams, dann über das Farbram in die eigentliche Palette des C64. Um eine Farbe zu setzen, müßte man also mindestens zusätzlich angeben, mit welchem Bitmuster diese Farbe gemalt werden soll. Das führt aber höchstwahrscheinlich schnell zu einem Chaos, denn dazu gehört, daß man als Programmierer genau mitverfolgen muß, in welcher Kachel jetzt welche Farbe mit welchem Bitmuster gemalt wurde, zumindest sofern man mehr als vier Farben anzeigen möchte.

    Beim C64 hat man zusätzlich eine Hintergrundfarbe für die gesamte Bitmap, die man irgendwie gesondert setzen muß. Beim C16 sind es sogar zwei, und beim VC20 gar drei. Um die dadurch entstehende Begrenzung in der Farbauswahl zu umgehen, ist es eine übliche Praxis, mehr Farben über Rasterinterrupts zu erzeugen. Doch woher soll die Bibliothek wissen, an welcher Zeile der Farbwechsel stattfindet?

    Was den AppleII als weitere 8 Bit-Plattform anbelangt, scheitert das RGB-Modell schon daran, daß der AppleII zwei Arten von Schwarz und Weiß kennt. Malt man mit dem falschen Schwarz eine Linie über einen grünen Untergrund, verfärbt sich dieser links und rechts der Linie orange usw. Hier muß man die Farben also anders auswählen, doch nicht über Bitmuster, denn die ändern sich je nach gerader oder ungerader Spalte, sondern allein über abstrakte Farbnummern. Hinzukommt, daß beim AppleII Farben gerne gedithert werden, z. B. eine Mischung aus Blau und Weiß ergibt Hellblau. Aber wie diese Mischung genau aussehen soll, ist eine Kunst für sich, da es hierfür zig Möglichkeiten gibt. Eine einfache Umrechnung von RGB auf Mischung kann da nicht gelingen.


    Lange Rede, kurzer Sinn: Die Hardwareeigenschaften der verschiedenen 8 Bit-Rechner sind viel zu verschieden, als daß man sie alle über einen Kamm scheren könnte. Selbst auf einer Plattform gibt es schon Probleme, wenn diese mehrere verschiedene Anzeigemodi vorsieht wie z. B. HiRes und Multicolour. In der Praxis benötigen Programme jeweils maßgeschneiderte individuelle Lösungen. So habe ich z. B. im Laufe der Zeit viele verschiedene Linienroutinen geschrieben in Abhängigkeit von HiRes/Multicolour, Größe der Malfläche, Bitmap/Zeichensatz, Geschwindigkeit vs. Kompaktheit usw. 8 Bit-Rechner sind nun einmal keine PCs, und sie lassen sich daher auch nicht wie PCs programmieren.

    Hmm... Wenn ich kurz mal meinen Senf zu den Rätseln geben darf... Ich fand das letzte Rätsel von Telespielator ziemlich schwierig, weil die Hinweise extrem um die Ecke gedacht waren, also gleich um mehrere Ecken. Das wurde noch dadurch erschwert, daß es das von Shmendric genannte Spiel

    "Gestern ging ein Hobbit in den Puff"

    tatsächlich gibt (s. angehängte Programmdatei), auch wenn das Spiel - völlig unverständlich - bisher nicht im C64-Wiki erfaßt worden ist.:nixwiss:


    Wenn das Niveau hier weiterhin so hoch bleibt, werde ich wohl nie mehr selber Hinweise geben können...:cry:(Mir fällt auch beim neuen Rätsel keine Antwort mehr ein...)

    Ich dachte immer dass der kompatibel zum Z80 ist

    Ja, ist er, aber die Assemblersprache ist anders. Zilog hat bei Einführung des Z80 die Syntax (sinnvoll) überarbeitet. So wurde z. B. aus "mov m, a" ein "ld (hl), a" und aus "ana a" ein "and a" wie auch aus "ani 3" ein "and #3" usw.

    Ok, muss mich jetzt erst mal mit Ghidra etwas vertraut machen, aber hier mal ein Listing in pdf.

    Danke, allerdings würde ich eine reine Textdatei bevorzugen, da man diese auch beliebig bearbeiten kann. Nebenbei: Du kannst auch oobdoos Disassembler nehmen. ^^


    Ach, weißt Du was, schick mir doch bitte einfach die Romdatei, dann kann ich das Disassembly selber anfertigen. (Hab meinen eigenen Disassembler, der auch gleich eine reassemblierbare Programmdatei ausspuckt.)

    Wenn ich das richtig verstehe, bleibt die Anzahl unterschiedlicher Chars gleich (256), nur muss man die zu jeweils 32 Chars sortieren, die sich eine ColorRAM-Farbe teilen.

    Zwar hat man pro Farbe 32 Zeichen, aber davon sind 16 Multicolour und 16 HiRes. Das kann man sich jedoch zunutze machen, indem man z. B. als Hintergrundfarbe grün definiert und die Linien zu anderen nicht grünen Flächen, die aus einer Vordergrundfarbe ($d800) bestehen, mit HiRes zeichnet, was u. U. sogar besser aussehen könnte. Andersherum lassen sich z. B. Zeichen, die nur aus einer einzigen Farbe bestehen, sowohl als Multicolour als auch als HiRes definieren. Man muß da bei der Verteilung eventuell etwas tricksen.

    Als schwierigen Farbübergang bei der ISO-Darstellung würde ich zur Zeit den Wechsel von Gelb (Strand) nach Blau (Meer) sehen, da hier zwei potentielle Vordergrundfarben aufeinander treffen. Eventuell müßte man eine von ihnen dann einer Zusatzfarbe zuordnen. Das hängt natürlich gleichzeitig sehr davon ab, wie man andere Objekte wie Häuser oder Bäume gestaltet. Eine Aufgabe für den gewieften Grafiker halt.

    Wie gross sollte denn die Map sein? Und ist die Spielwelt flach mit Grenzen oder eine Kugel?

    Puh... Das ist jetzt auch schon ca. 15 Jahre her, daß ich Virus disassembliert habe... Ich meine, die Map besteht aus 256x256 Höhenangaben, und gehandhabt wird sie mit Wraparound, d. h. fliegt man links raus, kommt man rechts wieder rein.


    Nebenbei: Normalerweise wird ein Scrolling mit Farbram so organisiert, daß im ersten Frame nur die Zeichen in einen zweiten Puffer gescrollt werden (double-buffering). Da hierbei keine Rücksicht auf den Rasterstrahl genommen werden muß, geht dies sehr schnell. Erst im 2. Frame, wenn ein Überlauf stattfindet im Scrollregister, wird auch das Farbram gescrollt und anschließend der Textzeiger auf den jeweils anderen Puffer umgestellt. Bei dieser Methode gibt es aber ein Problem bei einer freien Bewegung in alle Richtungen:


    Beispiel:

    X = 0 .. 3

    Bewegt sich der Spieler nach rechts, sollte jetzt vorausschauend ein Umkopieren des Textspeichers vorgenommen werden, denn bei

    X = 7

    mit der Geschwindigkeit 1 wäre es bereits zu spät, da nur noch 1 Frame fürs Scrolling verbleibt. Ähnliches ergibt sich bei X = 6 und der Geschwindigkeit 2, X = 5 und der Geschwindigkeit 3 sowie X = 4 und der Geschwindigkeit 4.

    Es gilt also, daß zur aktuellen X-Position die X-Geschwindigkeit addiert werden muß. Befindet sich diese dann in der anderen Hälfte (bei einer Bewegung nach rechts 4..7 in Abhängigkeit zur Geschwindigkeit), muß der Textspeicher umkopiert werden. Gleiches gilt für das vertikale Scrollen.


    Daraus ergibt sich aber auch ein Konflikt, wenn z. B. zuerst erkannt wird, daß X gescrollt werden muß, aber im nächsten Frame plötzlich auch Y im Scrollregister einen Überlauf erhält, d. h. das Umkopieren für die X-Koordinate überschneidet sich mit dem Umkopieren für die Y-Koordinate. Dafür muß eine Lösung gefunden werden, z. B. indem man das Y-Scrolling um einen Frame verzögert, oder indem man anstelle des Y-Scrollings den Y-Wert für das Sprite ändert.


    Ein üblicher Trick, um das Scrollen mit Farbram zu erleichtern und den Platzbedarf für die Tilemap zu reduzieren, ist, als Vordergrundfarbe für das $d800-Ram einfach die unteren 4 Bits des Zeichens zu nehmen. Das beschränkt zwar die Farbwahl für das einzelne Zeichen (es gibt z. B. nur 8 Zeichen mit dunkelblauer Zeichenfarbe im Multicolourmodus), läßt sich aber bei geschickter Organisation des Zeichensatzes kaschieren. Die Kopierschleife des Farbrams bestände dann lediglich darin, den aktuellen Textspeicher in das Farbram zu kopieren.


    Alternativ könnte man jedoch auch mal schauen, wieviel Rechenzeit es kostet, den Textspeicher zu kopieren und das Ergebnis gleichzeitig ins Farbram zu übertragen. Sollte dies während eines Frames möglich sein und weiterhin genügend Rechenzeit zur Verfügung stehen für weitere Aufgaben (Musik, Spritemultiplexer etc), könnte man auf das Double-Buffering verzichten. Man soillte jedoch bedenken, daß auf NTSC-Systemen erheblich weniger Zeit pro Frame vorhanden ist. sofern man kein Nur-PAL-Spiel haben möchte.

    Ach, verflixt, warum kann ich bloß meine Klappe nicht halten Finger nicht stillhalten... ;(


    Okay, diesmal drücke ich mich nicht herum. Dafür mache ich es einfach.


    1. Der Typ hat sicherlich Persil genommen.

    Hab zwar schon eine Idee für ein Spiel, doch ist es jetzt schon etwas spät und noch nicht Freitag. Falls also irgendwer anders ein schönes Spiel kennt, möge er/sie bitte einfach den ersten Hinweis posten.