Hallo Besucher, der Thread wurde 12k mal aufgerufen und enthält 86 Antworten

letzter Beitrag von JeeK am

Wer hat Lust ein Text-Adventure zu programmieren? (C64 Basic 2.0)

    Zitat von detlef

    (fast) nie war die Garbage Collection ein Problem

    Stimme zu. Habe früher auch ein recht umfangreiches Adventure in Basic geschrieben (mit Graphik), das nahezu den ganzen Basic-Speicher ausfüllt. An Stringvariablen jedoch habe ich nur zwei benötigt: 1.) für die vollständige Satzeingabe. 2.) zum Lesen eines Zeichens von der Tastatur oder für das aus dem Satz extrahierte Wort für die Wortsuche im Lexikon. Ernsthafte Probleme mit der GC gab es da keine.
    Nebenbei: Die Adventureprogrammierung bietet einen guten Anlaß für den Einstieg in Assembler, denn gerade bei Adventures ist es sehr lohnenswert, wenn man sich kleine Routinen in Assembler schreibt und diese dann bei $c000 in den Speicher legt. Nützliche Routinen wären z. B. die Stringeingabe oder die Satzzerlegung. Nicht nur schreibt sich sowas in Assembler sehr leicht, auch der Spielfluß profitiert enorm von dem Riesenzuwachs an Beschleunigung. Nicht zuletzt sollte man auch daran denken, daß der Basic-Speicher nicht sonderlich groß ist. Ein Assemblerprogramm könnte z. B. auch auf den Speicher unter dem Basic-Rom zugreifen, um dort ein größeres Wörterbuch etc zu hinterlegen. Daher würde ich trotz aller Bedenken stets den Rat geben, zumindest später mal zu versuchen, einzelne Basic-Routinen in Assembler umzuschreiben.

    Ja, und?

    Zitat von Mac Bacon

    Dummerweise macht der Standard-Basic-V2-Programmierer aber genau das:

    Code
    1. 1000 get a$:if a$ = "" then 1000

    Ja, und? Was soll da passieren?

    Zitat von M. J.

    Nebenbei: Die Adventureprogrammierung bietet einen guten Anlaß für den Einstieg in Assembler, denn gerade bei Adventures ist es sehr lohnenswert,

    Eigentlich nicht. Assembler habe ich immer eingesetzt, wenn es um Geschwindigkeit ging.
    Was ist an einem Adventure zeitkritisch? Minutenlang wartet man auf Benutzereingaben um dann blitzschnell in Sekundenbruchteilen einen neuen Screen zu präsentieren?

    Zitat von Mac Bacon

    Na, bei jedem Tastendruck wird der String neu angelegt.

    Ja, aber hast du mal getestet, ob dabei die Garbage Collection zuschlägt?

    Zitat von M. J.

    Der Parser. Es macht einen großen Unterschied, ob man die Satzzerlegung und Wortsuche in Assembler schreibt oder in Basic, besonders dann, wenn es ein Mehrwortparser sein soll.

    Das erste Basic-Programm, das ich abgetippt habe, war Eliza. Das hat englische Sätze analysiert und versucht, passende Antworten zu geben. Ohne merkliche Verzögerungen.
    Für ein Adventure reicht das allemal. Hast du es mal in Basic ausprobiert?


    Es hat sich hier anscheinend in den Köpfen festgesetzt, dass man in Basic gar nicht vernünftig programmieren kann. Zum einem weil das ja viel zu langsam ist und zum anderen wegen der bösen Garbage Collection. Mich würden mal praktische Beispiele interessieren, wo Basic tatsächlich zu langsam ist. Und wo ein Programm auf Grund der GC nicht einsetzbar ist.


    Zum Glück gab es damals kein Internet und keine Foren. Sonst wären viele meiner Basic-Projekt von vorne herein zerredet und nicht realisiert worden. Von Leuten, die es vermutlich nicht mal selber ausprobiert haben. :D

    Zitat von detlef

    Ja, aber hast du mal getestet, ob dabei die Garbage Collection zuschlägt?

    Die schlägt zu, wenn kein Platz mehr frei ist, und ihre Laufzeit hängt quadratisch von der Anzahl benutzter Stringvariablen ab.

    Zitat von detlef

    Hast du es mal in Basic ausprobiert?

    Wie ich schon schrieb, habe ich bereits ein recht umfangreiches Adventure in Basic geschrieben.

    Zitat von detlef

    Eliza

    Das klassische Eliza verfügt über keinen echten Parser. Das Programm täuscht ein Verstehen nur vor, indem es nach reinen
    Buchstabenmustern in einer Eingabe sucht. Dieser Ansatz ist meilenweit davon entfernt, aus einem Satz die Wörter und auch Satzzeichen zu extrahieren, diese in einer Wortliste zu suchen, daraus zu bestimmen, um welche Wortart es sich handelt und am Ende dann die Essenz des Satzes in Form von "Verb Objekt" oder noch "Objekt2" (in der einfachsten Form ohne Berücksichtigung von Adjektiven oder Adverbien) zu ermitteln.

    Zitat von Mac Bacon

    Die schlägt zu, wenn kein Platz mehr frei ist, und ihre Laufzeit hängt quadratisch von der Anzahl benutzter Stringvariablen ab.

    Genau, von der Anzahl der benutzten Stringvariablen. Deswegen ist die von dir als Beispiel genannte Zeile ziemlich irrelevant.

    Zitat von M. J.

    Das klassische Eliza verfügt über keinen echten Parser. Das Programm täuscht ein Verstehen nur vor, indem es nach reinen
    Buchstabenmustern in einer Eingabe sucht. Dieser Ansatz ist meilenweit davon entfernt, aus einem Satz die Wörter und auch Satzzeichen zu extrahieren, diese in einer Wortliste zu suchen, daraus zu bestimmen, um welche Wortart es sich handelt und am Ende dann die Essenz des Satzes in Form von "Verb Objekt" oder noch "Objekt2" (in der einfachsten Form ohne Berücksichtigung von Adjektiven oder Adverbien) zu ermitteln.

    Und das geht dann in Assembler besser als in Basic?


    Konkrete Beispiele für eine schnelle Assemblerimplementierung bitte - nicht immer nur Theorie.

    Zitat von detlef

    Genau, von der Anzahl der benutzten Stringvariablen. Deswegen ist die von dir als Beispiel genannte Zeile ziemlich irrelevant.

    *hochscroll*
    Die von mir als Beispiel genannte Zeile bezog sich ja auch auf

    Zitat von detlef

    Die schlägt nur zu, wenn man wie blöd ständig neue Strings anlegt.

    Fisch gefällig?

    Zitat von M. J.

    Wie ich schon schrieb, habe ich bereits ein recht umfangreiches Adventure in Basic geschrieben.

    Und da hattest du Probleme mit der Garbage Collection? Oder mit der Geschwindigkeit? Du kannst das Programm ja mal posten. Dann schauen wir mal, wo das Problem liegt. Denn natürlich kann man Probleme auch provozieren.

    Zitat von Mac Bacon

    *hochscroll*
    Die von mir als Beispiel genannte Zeile bezog sich auf

    Fisch gefällig?

    Aber es ging ja um Beispiele mit Relevanz für die Garbage Collection.


    Und danke für den Fisch. :D

    Zitat von detlef

    Genau, von der Anzahl der benutzten Stringvariablen. Deswegen ist die von dir als Beispiel genannte Zeile ziemlich irrelevant.

    Stringvariablen sind "bessere" Pointer in den String-Heap. Ich vermute fast, dass GET da durchaus jedesmal neuen "Content" anlegt und "nur" die Daten der Variable (Pointer und Länge) ändert....


    Tja, "zuschlagende" GC ist ja sowas von 1985, zum Glück ist das in modernen Sprachen alles viel besser gelöst. Hatte mal einen Kollegen, den einzigen mit dem ich je hart aneinandergeraten bin (aber das aus nochmal einem anderen absurden Grund), der hielt es in .NET für eine gute idee, die GC direkt anzuprogrammieren. Wir sind ihn losgeworden, das war gut so ;) Egal, ich schweife ab....


    Kann mir jemand die Frage von oben beantworten? Hat der BASIC Programmierer auf dem C64 denn überhaupt eine vernünftige Möglichkeit, die Eingabe zu kontrollieren, ohne Zillionen an Strings zu erzeugen? :)

    Zitat von zrs1

    Kann mir jemand die Frage von oben beantworten? Hat der BASIC Programmierer auf dem C64 denn überhaupt eine vernünftige Möglichkeit, die Eingabe zu kontrollieren, ohne Zillionen an Strings zu erzeugen?

    Klar, genauso wie immer: Am Basic vorbei die Kernalfunktionen direkt mit SYS aufrufen. Aber echtes/reines "BASIC V2" und "vernünftig" schließt sich halt aus.

    Zitat von zrs1

    Tja, "zuschlagende" GC ist ja sowas von 1985, zum Glück ist das in modernen Sprachen alles viel besser gelöst.

    Dachte ich auch, bis ich in C# auf die Nase gefallen bin und gelernt habe, dass man für exzessives Stringhandling besser den StringBuilder verwendet. ;)

    Zitat von detlef

    Konkrete Beispiele für eine schnelle Assemblerimplementierung bitte - nicht immer nur Theorie.

    Hier

    Zitat von detlef

    Und da hattest du Probleme mit der Garbage Collection?

    Würdest Du bitte mal lesen, was andere Leute geschrieben haben, bevor Du postest?

    Zitat von M. J.

    Stimme zu. Habe früher auch ein recht umfangreiches Adventure in Basic geschrieben (mit Graphik), das nahezu den ganzen Basic-Speicher ausfüllt. An Stringvariablen jedoch habe ich nur zwei benötigt: 1.) für die vollständige Satzeingabe. 2.) zum Lesen eines Zeichens von der Tastatur oder für das aus dem Satz extrahierte Wort für die Wortsuche im Lexikon. Ernsthafte Probleme mit der GC gab es da keine.

    Zitat von zrs1

    Kann mir jemand die Frage von oben beantworten? Hat der BASIC Programmierer auf dem C64 denn überhaupt eine vernünftige Möglichkeit, die Eingabe zu kontrollieren, ohne Zillionen an Strings zu erzeugen?

    Wie oben schon geschrieben entscheidet die Anzahl der Stringvariablen und die Länge der Strings.
    Bei einer selbstgeschriebene Input-Routine mit GET ist die Garbage Collection nicht relevant.