Hello, Guest the thread was called5.5k times and contains 70 replays

last post from detlef at the

BASIC-Code beschleunigen/optimieren

  • Danke für die Tipps! Ich werde das ganze mal PEEKen. Was ist da schneller? vi ist die Adresse des Videochips (beim TED halt 3072). ro ist die Spaltenanzahl, also 40.

    • a=vi+x+ro*y:ifpeek(a)=0thenprint"ok"
    • ifpeek(vi+x+ro*y)=0thenprint"ok"

    Welche Variante würde schneller sein? Denke die 2. oder? Bei der ersten müßte erst wieder eine Variable der Wert zugewiesen werden, was ja mehrarbeit bedeuten würde, oder irre ich mich da?

  • Danke für die Tipps! Ich werde das ganze mal PEEKen. Was ist da schneller? vi ist die Adresse des Videochips (beim TED halt 3072).

    Bei Adresse 3072 ($0C00) liegt lediglich die Video Matrix, die allerdings auch an andere Adressen gelegt werden kann. Den TED findet man ab Adresse 65280 ($FF00).

  • Danke für die Tipps! Ich werde das ganze mal PEEKen. Was ist da schneller? vi ist die Adresse des Videochips (beim TED halt 3072). ro ist die Spaltenanzahl, also 40.

    • a=vi+x+ro*y:ifpeek(a)=0thenprint"ok"
    • ifpeek(vi+x+ro*y)=0thenprint"ok"

    Welche Variante würde schneller sein? Denke die 2. oder? Bei der ersten müßte erst wieder eine Variable der Wert zugewiesen werden, was ja mehrarbeit bedeuten würde, oder irre ich mich da?

    Die 2. ... Wenn man a nicht ein 2. Mal sonst wo braucht, dann bringt die Zwischenvariable nix.


    Ich würde aber hier versuchen generell alles schon als Adresse zu führen und nicht über x,y auszurechnen. Mit dieser Herumrechnerei verschenkt man den Vorteil von PEEK, dann ist ar(x,y) wieder flotter. Das ist so, als würde man 2-Dimensionale Arrays mit BASIC (es gibt ja durchaus BASIC-Dialekte, die nur eindimensionale Arrays kennen) rechnen müssen, also ar(y*ro+x). Die Rechnung geht deutlich langsamer, als dies der Interpreter in Integer rechnen würde.
    D.h. die Position sollte z.B. erstmalig mit p=vi+x+ro*y festgelegt werden. Bewegungen dann aber nur mit p=p-1, p=p+1, p=p-40, p=p+40 für links, rechts, oben, unten durchführen.

  • Bei Adresse 3072 ($0C00) liegt lediglich die Video Matrix, die allerdings auch an andere Adressen gelegt werden kann. Den TED findet man ab Adresse 65280 ($FF00).

    Den Bildschirmspeicher mein ich halt ;)


    Die 2. ... Wenn man a nicht ein 2. Mal sonst wo braucht, dann bringt die Zwischenvariable nix.
    Ich würde aber hier versuchen generell alles schon als Adresse zu führen und nicht über x,y auszurechnen. Mit dieser Herumrechnerei verschenkt man den Vorteil von PEEK, dann ist ar(x,y) wieder flotter. Das ist so, als würde man 2-Dimensionale Arrays mit BASIC (es gibt ja durchaus BASIC-Dialekte, die nur eindimensionale Arrays kennen) rechnen müssen, also ar(y*ro+x). Die Rechnung geht deutlich langsamer, als dies der Interpreter in Integer rechnen würde.
    D.h. die Position sollte z.B. erstmalig mit p=vi+x+ro*y festgelegt werden. Bewegungen dann aber nur mit p=p-1, p=p+1, p=p-40, p=p+40 für links, rechts, oben, unten durchführen.

    Dann müßte ich ja 3 Variablen verwenden; einmal X und Y für den CHAR Befehl und eine weitere für das PEEKen. Dadurch wirds doch erst langsamer oO. Ich benutze den CHAR Befehl ja, weil die Figur so a) schneller angezeigt wird und b) 2x2 Zeichen groß ist. Bei POKE müßte ich einmal 4 POKEs setzen für die Zeichen und 4 POKEs für die Farbe, was langsamer wäre.

  • Dann müßte ich ja 3 Variablen verwenden; einmal X und Y für den CHAR Befehl und eine weitere für das PEEKen. Dadurch wirds doch erst langsamer oO. Ich benutze den CHAR Befehl ja, weil die Figur so a) schneller angezeigt wird und b) 2x2 Zeichen groß ist. Bei POKE müßte ich einmal 4 POKEs setzen für die Zeichen und 4 POKEs für die Farbe, was langsamer wäre.

    Das ist dann blöd. Da würde ich dann beim Array bleiben.

  • Über welches Basic reden wir den hier? Commodore Basic?
    Dann verwendet auf keinen Fall %-Variablen, die machen die Ausführung langsamer.
    Das Commodore-Basic kennt keine Integer-Arithmetik.
    Die %-Varablen gibt es nur, um bei Arrays Speicher einzusparen.


    Deswegen sind die wohl auch in FOR-Schleifen verboten. Das würde das ganze Stack-Handling durcheinanderbringen.