LOCATE in GRAPHICS 0

[Sleepy]

Hi,

mir ist bei der Anweisung LOCATE gerade eine kleine Eigenheit aufgefallen:

Normalerweise übergibt LOCATE x,y,farbe den Farbwert des Punktes an Position x,y. In den Textmodi (GRAPHICS 0-2 sowie 12 und 13) wird der ATASCII-Wert des Zeichen an der angegebenen Position übergeben.

Das klappt in GRAPHICS 1,2,12 und 13 auch wunderbar.

Folgendes Beispiel in GRAPHICS 0:

10 GRAPHICS 0
20 POSITION 10,5:? "ABC"
30 LOCATE 11,5,WERT
40 POSITION 10,8:? CHR$(WERT)

Hier wird das gelesene Zeichen gelöscht und in der dem letzen PRINT-Befehl folgenden Zeile wird der Cursor am Linksanschlag "eingebrannt":

LOCATE.jpg (6.47 KiB) 9673-mal betrachtet

Das "Einbrennen" des Cursors kann man mit POKE 752,1 verhindern, aber warum wird das gelesene Zeichen vom Bildschirm gelöscht?

Der Effekt tritt sowohl in ATARI- als auch in Turbo-BASIC auf.

Absicht oder ein Bug?

Sleeπ

[kfischer]

Hi Sleepy,

gib mal ein:
35 POSITION 11,5:PRINT CHR$(PEEK(763))

Das letze Zeichen, was vom Cursor verdeckt wird, und das ist der Fall, wenn du LOCATE im Textmodus ausführst, wird in Adresse 763 gespeichert.

Gruß
Klaus

[Sleepy]

Ja, dass ich das gelesene Zeichen wieder an die Stelle schreiben kann ist klar; das hätte ich mit...

35 POSITION 11,5:PRINT CHR$(wert)

...gemacht.

Mich hat jetzt mehr gewundert dass das Zeichen überhaupt verschwindet. Bei den anderen Text/Grafik-Modi bleibt das gelesene Zeichen / Pixel stehen, was ja auch zu erwarten ist da ja nur der Inhalt an der betreffenden Stelle des Bildschirmspeichers gelesen werden soll.

Sleeπ

[kfischer]

Ich kann mir das nur so erklären, dass es in den anderen Modis keinen Cursor gibt, der was verdecken könnte. Streng genommen sind GR. 1 und 2 ja auch Grafikmodis, von daher denke ich mal dass das kein Bug ist.

[Cash]

Ich hab's spaßeshalber in ACTION! probiert und da ist es das selbe Phänomen.

[slx]

Ich hab's spaßeshalber in ACTION! probiert und da ist es das selbe Phänomen.

Was dafür spricht, dass es eine Eigenheit des Screen Handlers ist.

[Sleepy]

Es scheint tatsächlich so zu sein - der Effekt ist auch in "Mein ATARI Computer" dokumentiert.

Sleeπ

[kfischer]

Hi Sleepy,

welche Seite? Ich will das auch mal nachlesen, weil es mich interessiert!

Gruß
Klaus

[Sleepy]

Seite 11-36 der deutschen Ausgabe "Neue Version 600 und 800XL enthalten".

Sleeπ

[kfischer]

Also, wenn man dem Glauben schenken soll was in der blauen Atari-Bibel unter LOCATE steht, dann soll der PRINT-Befehl nach LOCATE für dieses Phänomen verantwortlich sein. So ganz plausibel war das für mich nicht und ich habe deshalb mal folgendes ausprobiert:

10 GRAPHICS 0:DIM A$(3):A$="ABC"
20 OPEN #1,8,0,"E:"
30 FOR I=1 TO LEN(A$)
40 POSITION 9+I,5
50 PUT #1,ASC(A$(I,I))
60 NEXT I
70 CLOSE #1
80 LOCATE 11,5,WERT

Auch hier verschwindet das Zeichen. Nimmt man den S: Händler statt E:, passiert das gleiche. GR. 0 bleibt ein Sonderfall für LOCATE.

[Rockford]

Ist mir tatsächlich auch noch nie aufgefallen, obwohl ich schon einiges in Gr.0 programmiert habe, auch Spiele. Vermutlich ist mir das auch irgendwie schon untergekommen, und ich habs dann einfach mit dem vorherigen Wert wieder hergestellt.

[Rockford]

So hab grad mal in einem alten Spielelisting von mir nachgesehn:

Bei der Bewegungs und Kollisionskontrolle hatte ich damals folgendes gemacht:

1.Bewegung über Stick abgefragt, entsprechend gleich in X/Y Position addiert/abgezogen. Über eine Variable Herkunftsort gemerkt (1..4)
2.Locate X,Y,L
3. Wenn z.B. L=32 (Also Leerzeichen), dann dort Spielfigur hingeprintet.
4. Wenn nicht leer, dann:
- Gelesenen Zeichenwert wieder printen
- Anhand Variable Herkunftsort wieder X/Y auf die Position vor der Bewegung zurück restauriert.

Ist sogar unter Ataribasic schnell genug.
So habe ich für Spiele in Gr.0 dieses Phänomen umschifft.

Grund dieses Phänomens ist wohl, dass in Gr.0 ein Zeilenumbruch nach dem Locate ausgeführt wird, dabei wird die letzte Position des Cursors mit der Aktion wohl gelöscht.

[kfischer]

Grund dieses Phänomens ist wohl, dass in Gr.0 ein Zeilenumbruch nach dem Locate ausgeführt wird, dabei wird die letzte Position des Cursors mit der Aktion wohl gelöscht.

Nee, glaub ich nicht! Schau dir mal das Beispiel von mir mit PUT'# an. Da bleibt der Cursor rechts neben C stehen ohne dass ein Zeilenumbruch stattfindet und trotzdem wird B gelöscht nach LOCATE.

Ist schon irgendwie seltsam, aber gut zu wissen, dass es dieses Phänomen gibt!

[Sleepy]

Ist schon irgendwie seltsam, aber gut zu wissen, dass es dieses Phänomen gibt!

Das habe ich mir auch gedacht und deshalb kurzfristig noch ein (erfreulicher Weise sehr kurzes) Kapitel "Bug und Besonderheiten" in das TB-Buch eingefügt.

Sleepy

[kfischer]

Hi Sleepy,
ich freu mich auf das Buch wie ein kleines Kind

Übrigens, ich hab mal nachgedacht. Könnte es nicht sein, dass das von den Entwicklern so beabsichtigt war? Die Frage ist doch, wann benutze ich im Textmodus LOCATE? Zu 95% wohl für BASIC-Spiele um eine Figur zu lokalisieren. Da macht es doch Sinn die Figur immer danach zu löschen und auf einer neuen (oder gleichen) Position zu schreiben, um eine Bewegung zu simulieren. Ist doch eigentlich praktisch

Gruß
Klaus

[Sleepy]

Wenn ich die Spielfigur von der gelesenen Position lösche müsste ich danach irgendein anderes Zeichen/Hintergrundelement dort hin schreiben; dabei würde die Spielfigur sowieso überschrieben.

Wenn das Zeichen vorher automatisch gelöscht wird wären das zwei Schreibvorgänge.

Wenn ich den Status eines Spielfeldelements einfach nur überprüfen will (was wahrscheinlich genauso oft wenn nicht sogar öfter vorkommt wie das Bewegen der Spielfigur) habe ich zwei unnötige Schreibvorgönge (Leerzeichen + Feld wiederherstellen).

Das ganze würde auch voraussetzen dass die Spielfigur nicht per PM, sondern auch als Zeichensatz-Grafik definiert ist. Obwohl, das ist ja auch beim ATARI nicht unüblich.

In jedem Fall kostet es unnötig Rechenzeit.

Wenn dieses Verhalten wirklich Absicht ist erkenne ich den Sinn noch nicht.

Sleepy

[kfischer]

Ja stimmt, hast recht! Mein Denkfehler!

[GoodByteXL]

Wenn ich die Spielfigur von der gelesenen Position lösche müsste ich danach irgendein anderes Zeichen/Hintergrundelement dort hin schreiben; dabei würde die Spielfigur sowieso überschrieben.

Wenn das Zeichen vorher automatisch gelöscht wird wären das zwei Schreibvorgänge.

Wenn ich den Status eines Spielfeldelements einfach nur überprüfen will (was wahrscheinlich genauso oft wenn nicht sogar öfter vorkommt wie das Bewegen der Spielfigur) habe ich zwei unnötige Schreibvorgönge (Leerzeichen + Feld wiederherstellen).

Das ganze würde auch voraussetzen dass die Spielfigur nicht per PM, sondern auch als Zeichensatz-Grafik definiert ist. Obwohl, das ist ja auch beim ATARI nicht unüblich.

In jedem Fall kostet es unnötig Rechenzeit.

Wenn dieses Verhalten wirklich Absicht ist erkenne ich den Sinn noch nicht.

Sleepy

Hm, wenn ich mich richtig erinnere, hat LOCATE doch eine ganz andere Funktion:
In Graphik-Modi die Farbe eines Bildpunktes feststellen, in Textmodi den ATASCII-Wert des Zeichens feststellen, jeweils an der per Koordinaten vorgegebenen Position. Bei beiden wird ein Wert geliefert.

Wenn also diese Funktion für andere Zwecke "umgewidmet" wird, sind die Auswirkungen ggf. anders als erwartet.

[Sleepy]

Hm, wenn ich mich richtig erinnere, hat LOCATE doch eine ganz andere Funktion:
In Graphik-Modi die Farbe eines Bildpunktes feststellen, in Textmodi den ATASCII-Wert des Zeichens feststellen, jeweils an der per Koordinaten vorgegebenen Position. Bei beiden wird ein Wert geliefert.

Genau das geht in GRAPHICS 0 ja nicht ganz korrekt.
Wenn man, wie in dem Bsp aus dem Eingangspost, ein Zeichen mittels LOCATE liest wird dieses anschließend gelöscht.

10 GRAPHICS 0
20 POSITION 10,5:? "ABC"
30 LOCATE 11,5,WERT
40 POSITION 10,8:? CHR$(WERT)

Die Ideen drumherum waren jetzt um diesen Effekt zu beseitigen.

Sleeπ

[GoodByteXL]

Die Ideen drumherum waren jetzt um diesen Effekt zu beseitigen.

Ja, hatte mich von "Spielen'" irritieren lassen. Wenn meine Notizen von früher stimmen, hängt das am OS, da das in all den Hochsprachen auftrat, die ich mal probiert hatte; wenn Graphics 0 verwendet wird.