Hallo Besucher, der Thread wurde 6,4k mal aufgerufen und enthält 44 Antworten

letzter Beitrag von Hexworx am

Einzelne Zeichen aus String

    Zitat von TheRyk

    Nur ein Hinweis: Bei String-Operationen läuft die Garbage Collection allmählich voll und BASIC wird irgendwann sehr langsam, siehe auch:
    https://www.c64-wiki.de/index.php/Garbage_Collection

    Warum bitte speziell bei solchen Trivialanfragen immer das Schreckensgespenst der GC herauf beschwören? Bei den meisten Programmen, ist das überhaupt keine Thema. Der Verlust an Komfort reines BASIC zu programmieren im Vergleich zu den PEEK/POKE/SYS-Orgien (die man faktisch nicht verinnerlichen kann und immer nachschlagen muss) steht in keinem Verhältnis! Auch wenn viel String-Müll entstehen sollte, solange - wie schon gesagt - die String-Anzahl gering, sagen wir mal < 100, wird es im Programmablauf keine nennenswerten Überraschungen geben.
    In solchen Fällen, wo man wirklich massiv mit vielen Strings hantiert, ja dann ein ordentlichen GC-Ersatz nehmen. Ich lass mir doch die Bequemlichkeit eines BASICs nicht von einer Bad-Ass GC vermiesen und mich in einen Bad-Ass-Programmierstil bestehend PEEK/POKE/SYS-Schwall drängen. Manche mögen das belächeln, aber aus meiner Sicht ist eine doch weitgehend ungehinderte Erfassung der Programmlogik ein Anliegen - das mag schon schwer genug sein, dann sich aber auch noch mit C64-Spezifischem herumschlagen ist braucht man wirklich nicht mehr (außer einer Person hier vielleicht). :D

    Zitat von JeeK

    Warum bitte speziell bei solchen Trivialanfragen immer das Schreckensgespenst der GC herauf beschwören? Bei den meisten Programmen, ist das überhaupt keine Thema. Der Verlust an Komfort reines BASIC zu programmieren im Vergleich zu den PEEK/POKE/SYS-Orgien (die man faktisch nicht verinnerlichen kann und immer nachschlagen muss) steht in keinem Verhältnis! Auch wenn viel String-Müll entstehen sollte, solange - wie schon gesagt - die String-Anzahl gering, sagen wir mal < 100, wird es im Programmablauf keine nennenswerten Überraschungen geben.
    In solchen Fällen, wo man wirklich massiv mit vielen Strings hantiert, ja dann ein ordentlichen GC-Ersatz nehmen. Ich lass mir doch die Bequemlichkeit eines BASICs nicht von einer Bad-Ass GC vermiesen und mich in einen Bad-Ass-Programmierstil bestehend PEEK/POKE/SYS-Schwall drängen. Manche mögen das belächeln, aber aus meiner Sicht ist eine doch weitgehend ungehinderte Erfassung der Programmlogik ein Anliegen - das mag schon schwer genug sein, dann sich aber auch noch mit C64-Spezifischem herumschlagen ist braucht man wirklich nicht mehr (außer einer Person hier vielleicht).

    +1


    JeeK, Du sprichst mir aus dem Herzen. :)


    In dem angehängten Spiel (für VC-20 mit +16K RAM) war ich mir z.B. nicht zu schade, die Geometriedaten für die Regionen in Zeichenketten zu packen. Abgesehen von der Befehlserweiterung für hochauflösende Grafik ( :bgdev ) ist das Hauptprogramm komplett in BASIC geschrieben und die gelegentlichen POKEs machen nichts anderes, als Farben umzuschalten und gelegentlich mal den Tastaturrepeat umzustellen.


    Der "heiße" Teil zur Darstellung der Regionen befindet in den Zeilen 100 bis 170:

    Code
    1. 100 R$=R$(R,0)
    2. 110 IFR$=""THENRETURN
    3. 120 X=ASC(MID$(R$,1,1))-64:Y1=ASC(MID$(R$,2,1))-64:Y2=ASC(MID$(R$,3,1))-64
    4. 130 @IC,X,Y1TOX,Y2:R$=MID$(R$,4):GOTO110
    5. 140 R$=R$(R,1)
    6. 150 IFR$=""THENRETURN
    7. 160 X=ASC(MID$(R$,1,1))-64:Y1=ASC(MID$(R$,2,1))-64:L=ASC(MID$(R$,3,1))-64
    8. 170 @IC,2*X,Y1TO2*(X+L),Y1+L:R$=MID$(R$,4):GOTO150

    Die Befehle mit vorangestelltem @ sind genau die von der Befehlserweiterung, hier sieht man das Äquivalent vom BASIC 3.5/7-DRAW-Befehl in Aktion. :)

    In jedem Fall kann auch der Basic-Programmierer dafür sorgen, daß keine GBC-GarbageColletion auftritt.
    Durch Speichern und Setzen des Stringgrenzen-Zeigers(51/52) kann man selbst bestimmen, welchen String sich der C64 merkt und was er vergißt.
    Man kann also gewissermaßen selbst den Stringspeicher aufräumen.
    Zeile 50: Zeiger speichern
    Zeile51: Zeiger rücksetzen = letzte Strings wieder vergessen.


    Quellcode:
    10 :gosub55:gosub50:rem--zeiger speichern
    11 :a$="a"+"":b$="b"+"":gosub55:rem--strings anlegen
    12 :c$=a$+b$:gosub55: rem--strings addieren
    13 :gosub51:c$=c$+"":printc$:gosub55:rem--strings packen
    14 :gosub51:gosub55:end: rem---zeiger zurücksetzen
    19 :
    50 :poke3,peek(51):poke4,peek(52):return: zeiger speichern
    51 :poke51,peek(3):poke54,peek(4):return:-zeiger rueckholen.
    55 :printpeek(51)+peek(52)*256:return:-zeiger ausgeben


    Schönen Gruß.

    @Vernunftsmensch:
    Ich glaub, das ist eine Wissenschaft für sich.
    Mein Listing zeigt jedenfalls, wie man das auch in Basic programmieren kann.


    1. Merk man sich den Stringgrenzenzeiger
    2. Man führt die Stringaddition durch
    3. Man setzt den Zeiger zurück
    4. Man kopiert den String an die alte Zeigerposition,
    sofern man ihn später noch braucht.


    Schönen Gruß.

    Ach was, das Forum ist robust. Musst Dich nur entscheiden, welche Antwort Du weiter verfolgen willst. BIFs Antworten sind imho dann nützlich, wenn Du auf Assembler wechselst.


    (wieso kennt mein Wörterbuch Assembler-Einzeiler? Das ist ja noch fieser als ich)

    Zitat von Tale-X

    BIFs Antworten sind imho dann nützlich, wenn Du auf Assembler wechselst.

    Wie das denn? Wer auf Assembler wechselt, braucht den umständlichen und fehlerträchtigen BIF-Quark noch weniger als ein Basic-Programmierer.

    Zitat von c64 junior

    ich glaube ich "zerstöre" mi dieser frage langsam aber sicher das Forum

    Nein, sei beruhigt, das bist nicht du.
    Am besten ist es eine Schachtel :popcorn: zu nehmen und die BIF-Show zu geniessen :odo

    Die Nahrungskette sieht da so aus (Achtung, Dramatisierung ;)):
    Basic-Neuling:
    Kennt die Sprache noch nicht. Freut sich über 10 PRINT"HALLO" 20 GOTO 10. Lernt flott Grundlagen (einfache Schleifen, Goto-Labyrinthe, einfache Disk-Operationen). Merkt irgendwann dass es da Grenzen gibt, wird zum:


    Basic-Erfahrenen:
    Schreibt komplette Programme, vermeidet größere Grafikaktionen / Soundspielereien etc. - nicht weil er es nicht programmieren könnte, sondern weil er gelernt hat dass Basic dafür nicht wirklich gut geeignet ist. Mangelndes Interrupthandling, miese Geschwindigkeit. Dennoch kommt hübsches dabei herum. Für die meisten kommt dann:


    Assembler-Neuling (aka Basic-Würzer):
    Schüttelt den Kopf über die blöde Assembler-Syntax. Wer soll sowas lesen können. Macht dennoch ein paar Versuche damit, weil es ja *schnell* sein soll. HUCH! Plötzlich kann das Basic-Spiel mehrere Sprites flüssig anzeigen, und im Hintergrund dudelt nach einer Weile ein geklautes SID-Stückchen. Der Player-Code wird interessiert beäugt. Zunehmend mehr Routinen in Assembler ziehen ein. Still und heimlich mutiert der Programmierer zum


    Assembler-Nutzer (und Versteher):
    He, das ist ja gar nicht so doof mit den Opcodes. Wenn man erst mal Assembler denkt, klappt das mit der Entwicklung ganz gut. Wozu ist eigentlich dieses Register da? *Bazong* *Neustart* Ah, dafür! So geht das! Okay, okay, die Verantwortung für den Code steigt rapide, es gibt mehr Fallstricke. Aber: Entdecke die Möglichkeiten. Die Maschine ist das Limit, nicht mehr der Code.



    Keinen BIF gefunden? Das liegt daran dass der irgendwo zwischendurch abgebogen ist, auf einen kleinen holprigen Seitenweg. Sie verlassen die Interstate 66, adieu Interpreter. Kennt das ROM-Listing (steht zumindest zu vermuten), weiß um diverse Routinen die es da gibt. Das große Ganze jedoch wird als gottgewolltes Konstrukt gesehen, welches mit lästerlichen Dingen wie eigenem AssemblerCode auf keinen Fall verbessert werden kann. Dafür hat Commodore doch supergeheime Funktionen im Rom hinterlegt, die abgeschaltet wurden. Überhaupt ist Basic, wenn es nur aus genug Pointer-Arithmetik besteht (wir biegen ein paar Zeiger hin, ein paar Andere her, springen wild und willenlos in den Routuinen herum und kümmern uns nicht um Nebenwirkungen) sowieso das schnellste und beste überhaupt, jawoll.
    Wenn mal irgendein Kleingeist auf die Idee kommt die eigenen Entdeckungen (aka Tricks) kritisch zu hinterfragen hat man natürlich die passende Strategie bereit: Logik abschalten, alles Unliebsame auf dass man keine (noch so abstruse) Antwort findet ignorieren, eigene "Fachbegriffe" einführen (unvergessen: das See-only-Memory) und behaupten man hätte Dinge widerlegt die niemand angefochten hat, mit Code den keiner wollte und ohne jede Erläuterung. Die ist auch unnötig, dafür hat man doch Doppelpunkte. Possierliche kleine Tierchen.


    In Mittelerde hätte jemand auf diesen Abzweig mit Blut "Mordor" gekritzelt, und im Hintergrund hörte man lwimmernd den gesunden Menschenverstand, der leise vor sich hin weinte.

    BladeRunner:
    Also meine Programme funktionieren gewöhnlich sehr gut und zuverlässig.
    Wovon sich jeder der es ausprobiert selbst überzeugen kann.


    Auf deine Code-Beiträge warte ich immer noch vergeblich,
    obwohl du ja schon zugegeben hast, daß du keinen fehlerfreien Code
    produzierst.
    Basic ist ansonsten schon für viele Fälle sehr gut.
    Auch für die Spieleprogrammierung.


    Schönen Gruß.