Huhu - gibt es da eine raffinierte Methode, festzustellen über welcher Cursorposition sich ein Sprite befindet?
Ich möchte ein Zeichen im Textmodus per Mauszeiger auswählen.
Dabei würde ich GERNE auf Kommazahlen verzichten.
Gibt es da einen Trick?
In ASM ist ok - ich werde es in C für den CC65 bzw. inline-ASM anwenden :o)
Für jede Idee wäre ich dankbar
Ciao,
enthusi
Hallo Besucher, der Thread wurde 3,5k mal aufgerufen und enthält 18 Antworten
letzter Beitrag von Lysosom am
Spriteposition auf Cursorposition umrechnen?
- enthusi
- Erledigt
-
-
Hi!
Folgende Idee:
Die X- und Y-Koordinate des Sprites hast Du ja zur Hand. Von der X-Koordinate ziehst Du den linken Rand und von der Y-Koordinate den oberen Rand ab. Hab jetzt aber nicht die genauen Randbreiten zur Hand. Den Wert den Du dann jeweils erhälst teilst Du durch 8 (da der Charset 8x8 Pixel breit ist) mit 3xLSR. Dann solltest Du die Charsetposition haben. Klar soweit?
-
Info:
der sichtbare Bereich (also der nicht-Rand Bereich) fängt links bei Pixel 24 ($18 ) an, für die X-Koordinate und oben bei Pixel 50 ($32) für die Y-Koordinate bei 40 Spalten und 25 Zeilen
Bei 38 Spalten und 24 Zeilen sinds 31 ($1F) für X und 54 ($36) für Y
-
Zitat
Original von enthusi
Huhu - gibt es da eine raffinierte Methode, festzustellen über welcher Cursorposition sich ein Sprite befindet?
Ich möchte ein Zeichen im Textmodus per Mauszeiger auswählen.
Dabei würde ich GERNE auf Kommazahlen verzichten.
Gibt es da einen Trick?
In ASM ist ok - ich werde es in C für den CC65 bzw. inline-ASM anwenden :o)
Für jede Idee wäre ich dankbar
Ciao,
enthusi
Hallo,keine Ahnung, wie Du zu den Sprite-Koordinaten kommst, aber könnte man nicht alle 8 Pixel in y/x Richtung einen Zähler hochzählne, der entsprechend inkrementiert oder dekremnentiert wird, je nachdem, wohin sich das Sprite bewegt? Ist imho schneller, als das ganze auszurechnen ...
Kommt natürlich drauf an, was genau Du machen willst.
Ciao,
Lysander -
hallo, bischen spät, aber hier ein kleiner Lösungsvorschlag, vielleicht hilfts ja noch
;umrechnen von Spriteposition auf Screen-Pointer
;Die X-Koordinate soll in XL und XH abgelegt sein (16bit), XH entspricht dabei dem Inhalt von v+16
;die Y-Koordinate kann direkt aus dem VIC-Register gelesen werdenv=53248 ;VIC-Register
scr =$f8 ;Zeropage-pointer auf Bildschirm-RAM
lda v
sta xl
lda v+16
sta xhlda xl ;linken Rand von x-koord. abziehen (16-bit-Subtraktion)
sec
sbc #24
sta xl
bcs bp1
dec xhbp1 lsr xh ;dieser Wert (0-319) nun geteilt durch 8
ror xl ;ergibt die Spalte
lsr xl
lsr xl
sta scr
lda #$04 ;HiByte des Pointers ist $04
sta scr+1lda v+1 ;y-koord. lesen und -50
sec ;(oberen Rand abziehen)
sbc #50
lsr a ;und /8
lsr a ;ergibt die Zeile
lsr atay ;Zeile nach .Y
beq done ;den bisherigen Pointer jetzt noch +40*Zeile
loop lda scr
clc
adc #$28
sta scr
bcc bp2
inc scr+1
bp2 dey
bne loopdone lda #"x"
sta (scr),y ;(.Y ist noch #0!), Ausgabe eines X an der BIldschirmposition
rtsxl .byte 0
xh .byte 0 -
-
Ich buddel hier mal 'ne Leiche aus, aber falls jemand irgendwann - genau wie ich - bei der Suche nach dem Thema diesen Thread findet, so sollte doch erwähnt werden, dass der Code von hannez oben ein paar Fehler enthält.
Nämlich: ein lsr zu wenig bei der X-Koordinate und vor allen Dingen darf unter dem ror xl nicht lsr xl stehen.
SO ist es richtig:Code- sprite_to_screen_pos:
- lda sprite_x
- sta xlow
- lda sprite_x+1
- sta xhigh
- lda xlow
- sec
- sbc #$16
- sta xlow
- bcs +
- dec xhigh
- +
- lsr xhigh
- ror xlow
- lsr
- lsr
- lsr
- sta screenpos
- lda #>vidmem0
- sta screenpos+1
- lda sprite_y
- sec
- sbc #$31
- lsr
- lsr
- lsr
- tay
- beq .back_rts
- -
- lda screenpos
- clc
- adc #$28
- sta screenpos
- bcc +
- inc screenpos+1
- +
- dey
- bne -
- .back_rts
- rts
- xhigh
- !byte $00
- xlow
- !byte $00
sprite_y, sprite_x und sprite_x+1 sollten bereits die Werte aus den VIC Registern enthalten.
screenpos sollte ebenso wie in hannez Beispiel ein ZP-Pointer sein.
vidmem0 ist bei mir eine feste 16-Bit Variable, die die Videomemoryadresse enthält.EDIT: achso, nicht über das von mir verwendete Offset wundern. Bei den sbc muss man ja die X/Y Koordinate wählen, die Koordinate Null entspricht. Das kann ja je nach Sprite variieren.
-
Alles zu kompliziert.
Das geht mathematisch viel einfacher.
Aber warum kommt es bei Dir so auf Schnelligkeit bei so einer zeitunkritischen Routine an?
Edit: Es geht sogar völlig unmathematisch. Du schnapst Dir ein unbenutztes Sprite und läßt den VIC alle Berechnungen durchführen.
-
Ja, man kann durch die Wurzel von $44 teilen, das ist eine gute Naeherung. Wenn man das mit 16 bit macht, faellt das keinem auf.
-
Aber warum kommt es bei Dir so auf Schnelligkeit bei so einer zeitunkritischen Routine an?
Wenn Du verstärkt Demos codest, freust Du Dich irgendwann SEHR über Schnelligkeit. "Zeitunkritische" Sachen werden schnell kritisch, wenn man noch dies und das und jenes nebenbei im gleichen Frame erledigen will. Mir sind schnelle Sachen mittlerweile auch lieber als RAM-sparende. -
Man könnte sich überlegen, ob man da nicht schneller eine Tabelle draus machen kann.
Statt:Codewäre schneller (und vor allen Dingen immer konstant schnell):
Code@edit
ZitatMir sind schnelle Sachen mittlerweile auch lieber als RAM-sparende.
Besonders wichtig sind mir inzwischen Funktionen, die möglichst konstant schnell laufen. Damit erspart man sich die Sonderfälle wie "Jetzt läuft es mal langsamer, deshalb geht X oder Y in die Hose"
-
Zitat
Besonders wichtig sind mir inzwischen Funktionen, die möglichst konstant schnell laufen
hast du mal ein atan2 zur hand? =P -
-
die gängigen lösungen kenne ich natürlich alle .... für 200+ partikel keine option =D
-
Für die unmöglichen Sachen ist Roland zuständig ...
-
Edit: Es geht sogar völlig unmathematisch. Du schnapst Dir ein unbenutztes Sprite und läßt den VIC alle Berechnungen durchführen.
Das ist "unmathematisch". Das ist simples "Rechnen" Das mit dem unbenutzen Sprite will ich mal überhört/überlesen haben... =PSonst: Danke für die weiteren Vorschläge. Schnelligkeit ist nicht sooo wichtig. Hab noch reichlich Rasterzeit übrig.
Früher oder später fliegt die Routine ohnehin wieder raus, weil ich den Pointer ja direkt mit der Spritebewegung verknüpfen kann.
Momentan versuche ich allerdings noch so viele voneinander unabhängige Subroutinen wie irgendwie geht zu benutzen. Ist mein erster (ernsthafter) Versuch in Sachen Gamecoding und so ist es erstmal übersichtlicher, wenn irgendwas nicht läuft, wie gewünscht, heraus zu finden, wo der Fehler liegt. -
Da bin ich mal gespannt, zeigst du uns dann das fertige Produkt?
-
Ich hab das meistens mit Spritekoordinaten als 8.3 Bit Fixedpointwerte gelöst, wobei der Vorkommateil dann so ziemlich direkt Reihe/Spalte entspricht. Je nachdem wie man die Werte für die Borderoffsets wählt und wann man die dazumixt kriegt man dann sogar noch ne einigermassen passable Rundung für lau. Die Bewegungsberechnungen werden allerdings geringfügig aufwendiger:
-
Geht das nicht in Basic besser und schneller? :klappe halten: