Sprite mot bakgrund

[Redreamer]

Hej!
Försöker räkna ut var spriten befinner sig, vilken "character position" den är vid. Tänkte inte lägga upp hela min röriga kod här å nu men tänkte om någon kunde hjälpa mig med principen.
Säg att jag har räknat fram att jag befinner mig 10 character steg nedåt( yled ) och längst till vänster (x led). Jag tänkte mig att jag gör en loop för detta.
Utgångspositionen är $0400. hur gör jag enkelt en räknare som räknar fram till $0519?, positionen för 10 rader ner. Har lite alla möjliga idéer men jag tycker att alla mina idéer är för omständiga för att vara rätt

[bjonte]

Det enklaste är att göra en tabell med adresser för varje rad. Då kan du bara slå upp värdet på adressen utan krångel och addera x-positionen. Annars kan du göra en multiplikationsrutin om det inte är för snålt om CPU-cykler.

Kod: Markera allt

; sätter skärmadress i char_addr.
; X -> horisontell teckenposition
; Y -> vertikal teckenposition
set_char_addr:
  txa
  clc
  adc row_addr_low,y
  sta char_addr
  lda row_addr_high,y
  adc #0
  sta char_addr + 1
  rts

row_addr_low:
  .byte <[$0400 + 0*40]
  .byte <[$0400 + 1*40]
  .byte <[$0400 + 2*40]
  .byte <[$0400 + 3*40]
...
  .byte <[$0400 + 24*40]

row_addr_high:
  .byte >[$0400 + 0*40]
  .byte >[$0400 + 1*40]
  .byte >[$0400 + 2*40]
  .byte >[$0400 + 3*40]
...
  .byte >[$0400 + 24*40]


[bjonte]

Säg att jag har räknat fram att jag befinner mig 10 character steg nedåt( yled ) och längst till vänster (x led). Jag tänkte mig att jag gör en loop för detta.

Du bör inte behöva göra en loop. Det du behöver göra är att subtrahera den del av spriteintervallet som är utanför ramen och sedan dividera med 8, vilket är samma sak som att skifta åt höger tre gånger (det är billigt). Det krångliga är att sprites använder nio bitar för att beskriva x-positionen, annars är principen enkel. Till uppe till vänster börjar tecknen i spritekoorinater på (24,50) så för att ta det enkla fallet först så ska du räkna ut char_y = (sprite_y-50)/8.

Kod: Markera allt

  lda sprite_y
  sec
  sbc #50
  lsr
  lsr
  lsr


Nu har du y-teckenpositionen i a-registret.

För att lösa x så behöver du ha den nionde biten någonstans. Det finns en massa olika sätt att lösa detta på. Du kan lagra den biten i en separat byte, du kan minska upplösningen så att du lagrar bit 1-8 (istället för 0-8) , lagra bit 0 någon annanstans eller helt enkelt inte ha sprites till höger på skärmen. Det beror lite på kraven.

Om vi antar att du har den nionde biten i en separat byte så kan det se ut såhär:

Kod: Markera allt

  lda sprite_x
  sec
  sbc #24
  sta temp_x ; lagra undan subtraktionens resultat i temp_x
  lda sprite_x_8 ; den nionde biten som bit 0
  sbc #0
  sta temp_x + 1

  ; nu skiftar vi tre gånger
  lsr temp_x + 1 ; först nionde biten
  ror temp_x ; ner till temp
  lsr temp_x ; sedan bara temp eftersom temp_x + 1 nu ska vara 0
  lsr temp_x


Nu ska temp_x innehålla x-teckenpositionen.

[Redreamer]

Oj, ska svara på detta i morgon när ja kan tänka. ett par glas vin å min hjärna är fucked up (Semester)

[Redreamer]

Att dividera med lsr är ju genialt! Är inte så van med att tänka binärt på ett matematiskt sätt, fast det var ju ganska självklart när ja tänkte efter. Ja, en lsr är väl två cykler. Loopen jag gjorde för att räkna ut x pos fungerade men käkade glatt cpu cykler!

Ok, suttit och grunnat lite på det nu. Är nybörjare och har inte hållt på så mycket med carry å så, så jag fick ta hjälp av
http://www.6502.org/tutorials/compare_beyond.html
Men nu är jag med på det, mer eller mindre. Tack för hjälpen, nu tror jag att jag kan komma vidare med mitt experimenterande =)
Håller på och försöker utveckla rutiner som är användbara om jag vill göra enklare spel, fast har inget egentligt mål än så länge, experimenterar som sagt.

[Redreamer]

Detta är säkert lätt men jag har inte kunnat hitta riktigt vad jag söker... tack förresten Bjonte för de tidigare exemplen, har greppat dem nu fast lite osäker på SBC #0 som görs ibland, men jag antar att det är för att man inte vill dra bort något, endast få med carry bit från low byte delen.
Mitt problem då. När jag väl räknat ut en minnesposition så är det ju uppdelat på två bytes. Hur kan man sedan få in dessa i en LDA, eller måste man göra det på något "krångligt vis". Om det finns någonstans att läsa om så guida mig gärna. Varit inne och kikat på codebase lite men som sagt, vet inte riktigt vad jag letar efter. Ska kika i min bökiga utskrift av reference manual på 64'an under dagen.

[bjonte]

Detta är säkert lätt men jag har inte kunnat hitta riktigt vad jag söker... tack förresten Bjonte för de tidigare exemplen, har greppat dem nu fast lite osäker på SBC #0 som görs ibland, men jag antar att det är för att man inte vill dra bort något, endast få med carry bit från low byte delen.

Det stämmer bra det. Alternativet är att testa carrybiten och i ena fallet köra DEC eller något annat för att minska med ett och i andra fallet hoppa över detta, men jag tycker att det är mer tydligt med SBC #0 faktiskt. Då behöver man inte dribbla bort sig med om det ska vara BCC eller BCS. Det är en vanlig felkälla.

[bjonte]

Mitt problem då. När jag väl räknat ut en minnesposition så är det ju uppdelat på två bytes. Hur kan man sedan få in dessa i en LDA, eller måste man göra det på något "krångligt vis".

Det finns två sätt att göra det på som har lite olika fördelar. Ett sätt är att spara adressen på en zeropageadress och använda indirekt adressering. Typ såhär:

Kod: Markera allt

char_addr = $fb

  ldx #5
  ldy #10
  jsr set_char_addr

  ldy #0
  lda (char_addr),y ; ta adressen som ligger i char_addr och char_addr + 1, lägg till y och använd den adressen för att läsa en byte till a.


Nu har du tecknet på position (5,10) i a-registret.

Det andra sättet är att låta programmet modifiera sig själv och skriva om instruktionen som läser tecknet. Såhär:

Kod: Markera allt

  ldx #5
  ldy #10
  jsr set_char_addr

char_addr = * + 1 ; char_addr är nuvarande adress i minnet plus ett (där adressen ligger i minnet i nästa instruktion)
  lda $ffff ; vadsomhelst som är större än 255, annars blir det en annan instruktion. Adressen kommer att skrivas över av set_char_addr


Fördelar och nackdelar:

Indirekt adressering:
+ Det kostar mindre att uppdatera adressen för det tar färre cykler att ändra i zeropage.
+ Adressen kan läsas av på flera ställen
+ Koden går att köra direkt i en cartridge utan problem
- Det kostar mer när man faktiskt ska läsa av adressen (för att det är indirekt).
- Antalet olika adresser som kan hållas reda på är begränsat till 127 av zeropage-utrymmet och måste trängas med annat som lagras där.

Självmodifierande kod:
+ Det kostar mindre att läsa av adressen.
- Det kostar mer att ändra adressen.
- Det är mindre flexibelt för adressen kan bara läsas på ett ställe utan att den måste uppdateras på flera ställen.
- Koden går inte att köra i ROM eller cartridge.

[carlsson]

Om man ändå inte tänkt att multiplexa sina spritar, behövs väl högst 8 st minnesadresser = 16 bytes på zeropage. I praktiken testar man väl en sprite åt gången och hanterar kollision vartefter, så då behövs kanske inte så många pekare?

[bjonte]

Nej, det stämmer att i det här exemplet behövs bara en men ibland blir det fullt där i alla fall för att man vill lägga kod där eller variabler som används av cpu-intensiva delar av programmet.

[Redreamer]

Har varit dåligt med kodande ett tag nu, men kommit tillbaka till det lite den senaste veckan. Inte för att det hänt så mycket men idag på eftermiddagen släppte det. =) Satte mig med penna å papper och började krafsa lite i blocket. Ofta går det bättre med ett block om man sitter helt fast tycker jag, att ta till blocket och sedan gå över till en editor när man har fått ihop en grundidé.
Måste egentligen börja läsa andras kod för att se hur man egentligen ska göra saker, men nu har ja ett fungerande koncept iaf. Får ta och sno kod senare...

Har nu iaf en sprite som nu kan röra sig fritt och verkar kunna "fatta" när den stöter emot saker. (Kollar tre punkter mot bakgrund i den riktningen som spriten rör sig)
Börjar närma mig punkten att jag snart tror mig kunna skapa något som skulle kunna likna ett spel. =)
Jag hoppas på ett produktivt juluppehåll från jobbet

[bjonte]

Det var trevligt att höra. Jag hoppas också på ett produktivt uppehåll.

[Redreamer]

haha, ja, bara det är "rätt" produktiva uppehåll

[e5frog]

Går det inte att kollisionsdetektera mot bakgrunden?

[bjonte]

Det brukar ge ett skakigt intryck i och med att utritningen måste ske innan man kan detektera träff. Det gör också att man måste specialhantera diagonal förflyttning för att undvika att man fastnar i hörn.