BASIC-Code beschleunigen/optimieren

Jeek du willst also sagen das RKSoft peeken mal testen koennte?

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?

Zitat von RKSoft

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.

Zitat von Fröhn

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

Zitat von JeeK

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.

Zitat von RKSoft

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.

Ich teste das mal für die Kollisionsabfrage mit PEEK. Glaub aber auch nicht, daß es was bringt.

Sagt er nicht, in welcher Zeile der Fehler ist? Ich schätze, es ist die erste: ti$="000000" müsste es richtig heißen

Integer in einer For-Next-Schleife ist nicht erlaubt.

Gruß, Gerd

PS: die Doppelpunkte bei der TI$-Zuweiseisung müssen auch weg.

Ü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.