letzter Beitrag von JeeK am
Der Scott Adams der da erwähnt wird ist übrigens der Dilbert-Zeichner, wusste gar nicht dass der mal für den C64 programmiert hat.
Nein. https://en.wikipedia.org/wiki/Scott_Adams_(game_designer) vs https://en.wikipedia.org/wiki/Scott_Adams
Der erste Scott ist der bekannte Adventure Scott Adams.
Nein. https://en.wikipedia.org/wiki/Scott_Adams_(game_designer) vs https://en.wikipedia.org/wiki/Scott_AdamsDer erste Scott ist der bekannte Adventure Scott Adams.
Ups, da habe ich mich von dem Link auf die https://en.wikipedia.org/wiki/Scott_Adams - Seite verleiten lassen, danke für die Aufklärung! Ist auch spannend zu lesen, dass der Game Designer Scott Adams in letzter Zeit wieder was gemacht hat.
Kein Problem, ich war auch schon mal darüber gestolpert und hatte das dann eben auch nachgeschaut.
Seine Adventures kann man z.B. hier runterladen: https://archive.org/details/Th…sTextAdventureCollections
Offizielle Webseite: http://www.msadams.com/
Hier noch eine Link Collection: http://pdd.if-legends.org/
Bei GET LAMP (sehenswürdige Doku) wurde er auch interviewed:
Hmmm...
Nehmt mal den BasicBoss-Compiler.
Ist mein Lieblinkscompiler. Kann da auch mein Basicdialekt verwirklichen.... kann mich davon nicht trennen, gehört einfach zum C64.
Ich möchte nichts mit Sub und den modernen Zeugs.
Mit dem BasicBoss kann man die Wünsche die hier Auftreten beseitigen.
Ich mag auch kein ASM-Advanture schreiben, ist grässlich.
demo.prg einfach in den Vice ziehen oder auf DSK für den echten C64.
Gruss
Alles anzeigenDie Eingaberoutine ist der Teil von Zeile 20 bis 70, ich hatte im ursprünglichen Code noch die Steuerzeichen herausgefiltert, sodass die Eingaberoutine "cooler" als INPUT ist.
Das erzeugt jedenfalls ordentlich temporäre Strings, Zeile 20 gibt das nach jeder Eingabe aus. FRE() habe ich hier bewusst nicht verwendet denn dass hätte jedesmal eine Garbage Collection getriggert. Zeile 10 ist übrigens nur zum Speicherplazverbrauchen da, damit nur wenig mehr als 2K überbleiben.
Nach und nach werden die 2K weniger, aber wenn man lange genug herumtippt kommt es zu einer automatichen GC, die aufgrund des kleinen Stringspeicherbereichs nicht viel zum aufräumen hat.
Langer Rede kurzer Sinn:
1. Aufpassen mit derartigen Eingaberoutinen, Formel in Zeile 20 hilft, Speicherfresser zu entdecken
2. ansonsten spricht meiner Meinung nach generell nichts gegen ein Textadventure in BASIC
Ad Müllvermeidung: Ein Vergleich mit CHR$(13) ist z.B. so immer schlecht. CHR$() erzeugt immer einen temporären String. Besser wäre es, das Zeichen in eine Variable abzulegen. Wie gesagt, ist der Nutzen von FRE() recht beschränkt. Man steuert lediglich den Zeit, wann ein Maximum an freiem Speicher zur Verfügung steht und könnte so ein Maximum an Zeit heraus schinden, bis eine GC erneut (automatisch) zuschlägt. Zu mehr nützt es nichts.
Zeile 10 für Speicherplatz verbrauchen - das sind Strings genau das Allerschlechteste. Die GC muss sich in jedem Durchlauf durch 12.000 Deskriptoren (auch wenn sie leer sind und nicht berücksichtigt werden müssen) wälzen. Wenn das Programm so schon sagen wir 100 nichtleere Strings hätte, dann multipliziert sich 12.000 mit 100, das heißt also 120.000 Durchläufe die dann ihre Zeit brauchen ...
Besser wäre es die Speicherplatzverknappung mit einem Float- ode Integer-Array zu machen: Statt DIMA$(12000) also DIMA%(18000), entsprechend größer, da Integer nur 2 Bytes brauchen. Da wird gleich das ganze Array in einem Schritt übergangen und nicht wie im String-Array alle Elemente relative zeitraubend "angesehen".
Der Conclusio schließe ich mich an, dass generell BASIC für Textadventures geeignet ist. Das zeigt ja auch die Vielzahl der vorhandenen Umsetzungen.
Ergänzend nur um einen Irrglauben zu entgegnen: Wenn die Anzahl der Strings im Programm in 100er-Bereich ist, dann ist die normale GC verkraftbar. Dabei ist es aber kontraproduktiv, den freien Speicher künstlich zu verringern. Damit löst die GC nur nur öfter aus - unnötigerweise. Es kommt nämlich nicht auf die Menge des produzierten Mülls an, sondern *nur* auf die Anzahl der aktiven Strings an. Da sich diese aus dem Programm mehr oder weniger zwangsläufig ergibt, ist es eher besser, wenn viel freier Speicher vorhanden ist, weil dann die GC weniger oft auftritt. An der Laufzeit der GC selbst ändert das nichts.
Wenn es Strings im 1000er-Bereich sind, dann ist die Verwendung einer alternative Implementierung, wie die SuperGC erwähnt im C64-Wiki stark anzuraten. Da geht dann nichts mehr mit "Herumtricksen" ...
Zeile 10 für Speicherplatz verbrauchen - das sind Strings genau das Allerschlechteste. Die GC muss sich in jedem Durchlauf durch 12.000 Deskriptoren (auch wenn sie leer sind und nicht berücksichtigt werden müssen) wälzen. Wenn das Programm so schon sagen wir 100 nichtleere Strings hätte, dann multipliziert sich 12.000 mit 100, das heißt also 120.000 Durchläufe die dann ihre Zeit brauchen ...
Besser wäre es die Speicherplatzverknappung mit einem Float- ode Integer-Array zu machen: Statt DIMA$(12000) also DIMA%(18000), entsprechend größer, da Integer nur 2 Bytes brauchen. Da wird gleich das ganze Array in einem Schritt übergangen und nicht wie im String-Array alle Elemente relative zeitraubend "angesehen".
Hast recht, im konkreten Fall wollte ich aber einen Belastungstest schaffen. Hätte ich DIMA%() genommen, würde ich es der GC ja leichter machen.
Mein Beispielprogramm sollte nur zeigen, dass eine EIngaberoutine so wie ab Zeile 30 ein Speicherfresser ist - bitte nicht nachmachen!
Dabei ist es aber kontraproduktiv, den freien Speicher künstlich zu verringern.
Verkleinerung im Demoprogramm war nur drin um ein Beispiel zu schaffen, dem der Stringspeicher ausgeht.
Mein Beispielprogramm sollte nur zeigen, dass eine EIngaberoutine so wie ab Zeile 30 ein Speicherfresser ist - bitte nicht nachmachen!
Ja, das stimmt. Aber das an sich stört ja auch nicht, wollte ich nur klarmachen. Selbst wenn man CHR$(13) vermeidet, hat man immer noch s$=s$+a$ ... so etwas produziert auch immer String-Müll. In diesem Fall aber nur, wenn wirklich eine Taste gedrückt wird.Das ist ja nichts Böses - in erster Linie. Die Vermehrungsrate ist ja nicht allzu extrem. Natürlich, je schneller Müll produziert wird, desto eher wird der freie Speicher aufgebraucht und umso eher wird die GC aufgerufen. Die testweise Speicherplatzverknappung zeigt das hier ganz gut.
