Kapittel 3 The fun starts
Introduksjon I dette kapittelet vil jeg prøve å gjøre ting på en annen måte. Siden vi nå skal begynne å faktisk lage noe, tenkte jeg at jeg vil gjøre det slik at kapittelet blir delt opp i deler der hver del tar for seg noe nytt. Vi kommer til å jobbe på det samme spillet/programmet, og i hver del utvider vi det litt med ny funksjonalitet, eller optimaliserer. Jeg kommer til å referere til saker og ting vi har gjennomgått før, i kapittel 1 og 2, så du bør ha de tilgjengelige. Lykke til!
Del 1 Regnbuens farge Vakkert. Å få farge på skjermen er egentlig ikke så vanskelig. Som du leste om paletten i kapittel 2, er første sprite-palett-byte bakgrunnsfargen. Det vil si byte nr. 16, eller $10 i hex. Siden paletten starter i adresse $3F00 i PPU-ens adresseområde, betyr altså det av $3F00 + $10 = $3F10 er adressen til bakgrunnsfargen. Legger vi en verdi her, vil vi få den tilsvarende fargen på skjermen. Jeg minner om dette bildet: Legger vi $16 i $3F10 får vi altså en rød bakgrunn. Videre må vi også stille inn PPU-en for å forsikre oss om at den oppfører seg riktig (om den viser farger som den skal, for eksempel.) Husk at CPU ikke kan aksessere PPU-ens adresseområde og omvendt, så vi må skrive til VRAM via $2006 (PPU-ens adresseregister) og $2007 (PPU-ens dataregister).
Det koden vår kort sagt skal gjøre: 1. Sette adresseregisteret til PPU-en til $3F10 slik at det vi skriver til $2007 havner i den adressen i VRAM (i paletten med andre ord.) 2. Sende fargen vi vil ha som bakgrunn til $2007 (som blir fraktet til $3F10 i VRAM.) 3. Stille inn PPU. 4. Kjøre en evig loop. Koden finner du her. Etter vi har stilt inn PPU-en er det ikke mer vi har å gjøre, annet enn å entre en uendelig loop. PPU-en vil da vise den samme fargen hver eneste frame. Oppgave for denne delen: Lag et NES-program som viser grønn bakgrunn.
Del 2 Mr. Sprite Søtt. Forrige del var i grunn nokså kjedelig. I denne delen skal vi vise et smilefjes på skjermen. I tillegg til koden fra forrige del, skal vi nå også si til PPU-en at den skal rendere en sprite midt på skjermen. Til dette må vi selvsagt fortelle den hvilket tilenummer spriten har, og hvor den skal stå. I tillegg må vi gi den et sett med farger i paletten. Det første å gjøre er å endre palettlastingen. I forrige kapittel var det bare én byte i paletten bakgrunnsfargen vi brydde oss om. Men siden vi nå skal laste inn tre bytes til, kan vi like godt lage en kode som laster en hel palett, dvs. 32 bytes inn, fra et sted i PRG-ROM: lda #$3F ; først den høye delen av palettadressen sta $2006 ; send til adresseregisteret, $2006 lda #0 ; så lav del av palettadressen sta $2006 ; send til adresseregisteret ; $2006 har nå fått adressen i VRAM hvor vi vil lagre data vi sender ; til $2007 ldx #0 LastPalett: lda palett, x sta $2007 inx cpx #32 Bne LastPalett ; vi skal bruke X som index i paletten ; A = palett + x ; send til VRAM ($3F00 og utover) ; øk X med 1 slik at vi får neste farge ; har vi kopiert alle fargene i paletten? ; nei, vi hopper opp igjen Husk at VRAM-adressen i $2006 øker med 1 hver gang vi skriver til $2007.
Denne koden kan du godt bite merke i, da den vil forbli så og si uendret. Selve paletten kan godt se slik ut (husk, dette må på slutten av koden for å ikke komme i «konflikt» med selve koden): palett: ; De første 16 bytene er for bakgrunnsgrafikk, som vi ikke bruker.db 0, 0, 0, 0.db 0, 0, 0, 0.db 0, 0, 0, 0.db 0, 0, 0, 0 ; Her er det mer interessant:.db $11, $2E, $28, 0 ; bakgrunn og sprite 0.db 0, 0, 0, 0 ; sprite 1.db 0, 0, 0, 0 ; sprite 2.db 0, 0, 0, 0 ; sprite 3 Når du skal tegne smilyen, åpner du Tile Layer Pro, åpner.chr-fila du vil tegne i, og så velger du tile nr. 2, altså den andre fra begynnelsen. Dersom du tegner med svart blir pikselen gjennomsiktig bakgrunnsfargen tegnes i stedet. Tegner du med grønn får du fargen etter bakgrunnsfargen, altså $2E i eksempelet over, tegner du med blå får du farge $28 i eksempelet over, og tegner du med hvit får du 0 i eksempelet over. Kort sagt: fargene i Tile Layer Pro matcher bytene i paletten. Hvilken av linjene som «gjelder» for spriten, bestemmer vi i attributtbyten som vi skal se nærmere på senere. For å få vist spriten på skjermen, må vi inkludere.chr-fila i koden (dette ser du i skjelettfila og fila fra forrige del). Det andre vi må gjøre er definere spriten: vi må fortelle PPU-en hvilket tile nummer som skal brukes for spriten og hvor den skal plasseres. Denne informasjonen må legges i SPR-RAM. Siden SPR-RAM ikke er en del av VRAM/adresseområdet til PPU-en, må vi bruke en annen metode, nemlig $2003 og $2004. Dette kan du lese om i kapittel 2, men kort sagt holder $2003 offseten i SPR-RAM, mens $2004 gis data som skal legges i SPR- RAM, i adressen som $2003 holder. lda #0 ; sprite nr. 0 sta $2003 ; sett SPR-RAM offset til 0 lda #100 ; sett Y-verdi til 100 sta $2004 ; send til SPR-RAM lda #1 ; tile nummer 2 (1 fordi det nummereres fra 0) sta $2004 ; send til SPR-RAM lda #0 ; ingen fancy flagg nå sta $2004 ; send til SPR-RAM
lda #100 ; sett X-verdi til 100 sta $2004 ; send til SPR-RAM Etter disse to trinnene, palett og sprite-data, er gjort, er det ikke mer å gjøre. Da er det bare å hoppe inn i en uendelig loop. Koden finner du her. Oppgaver for denne delen: Lag et program som viser to sprites på skjermen, på forskjellige steder, og med forskjellige farger.
Del 3 Epilepsianfall Samme skjermbilde som del 2 Til tross for den (som alltid) lekende tittelen, skal vi introdusere en rekke viktige konsept i denne delen, bl.a. hovedloopen og vblank-venting. Dette skal vi gjøre ved å lage et enkelt program som skifter bakgrunnsfarge hele tiden. Vi bygger videre på koden fra forrige kapittel, så det vil vises en sprite på skjermen (men det gjør vel ingenting?) Først litt teori: Hvordan bytter vi i det hele tatt farge på bakgrunnen fortløpende? I palett-byte nr. 16 finner vi bakgrunnsfargen, så det er egentlig bare å bytte denne fortløpende. Det kan vi gjøre i en løkke (loop). Den enkleste måten er uten tvil å inkrementere den hele tiden. Siden 6502 vil nullstille en verdi når den inkrementeres fra $FF, vil det bety at vi går om og om igjen i fargene. Dette er i grunn veldig enkelt å gjøre. Vi modifiserer koden fra forrige kapittel, og finner frem til labelen Ferdig: det er her vi før har kjørt en uendelig løkke fordi vi ikke har mer å gjøre. Men nå har vi det; vi vil inkrementere bakgrunnsfargen hele tiden. Siden vi nå ikke er ferdige likevel, gir vi labelen et nytt navn; hovedloop: Planen er å bruke X til å holde den nåværende fargen. Hver gang loopen kjøres, øker vi X med 1 og legger den nye verdien til X inn i palettbyten. Det er i midlertid et par ting utenom å oppdatere fargen i paletten vi må gjøre. Vi må passe på at PPU-en er i vblank når den mottar data. Hvis ikke risikerer vi å så og si fucke opp skikkelig. Å vente til PPU-en er i vblank gjør vi ved å hente inn statusen i statusregisteret, fra adresse $2002. Dette gjør vi helt til bit 7 ikke er satt, som indikerer at vi ikke er i vblank lenger. Det andre vi må gjøre er å sette $2006 til å peke til bakgrunnsbyten i paletten, slik at det vi skriver til $2007 havner der i VRAM. Vi får følgende kode: ldx #0 ; vi begynner på farge 0 hovedloop: lda $2002 ; hent statusbitene bpl hovedloop ; hopp opp igjen om bit 7 = 0 lda #$3F sta $2006 lda #$10 sta $2006 stx $2007 inx jmp hovedloop ; høy del av palettadressen ; sett i adresseregisteret ; lav del av palettadressen ; send til adresseregisteret ; lagre fargen i palettbyten ; inkrementer til neste farge ; hopp opp igjen
Kort sagt setter vi X til 0 før hovedloopen, og inni der vil X økes og skrives til palettbyten for bakgrunnsfargen hver gang loopen tar en runde. Før dette skjer, venter vi på vblank, siden det bare er da PPU-en kan ta i mot data. Dette gjør vi ved å hente statusbitene fra $2002 om og om igjen til bit 7 er satt. En oppfriskning: Instruksjonen BPL står for Branch if PLus og betyr i grunn at den hopper bare dersom pluss-flagget (bit 7) er usatt (0). Ergo vil den vente (laste fra statusregisteret) om og om igjen til bit 7 er satt, for da vil ikke BPL hoppe opp igjen lenger. Merk at vi ikke trenger å gjøre noe som helst med initialiseringskoden (det som er før hovedloopen) annet enn å sette X til 0. Den komplette koden finner du her Oppgaver for denne delen: - Se hva som skjer når du utelater vblank-ventingen (anbefales!) - Skriv et program som endrer en farge i spriten. - Skriv et program som endrer en eller flere farger i spriten og i tillegg bakgrunnsfargen.
Del 4 Mr. Sprite reloaded Nå skal vi avansere programmet vårt. Vi fortsetter på koden i del 3. Vi skal laste og vise to sprites, og i tillegg flytte dem opp og ned. Mens den ene spriten flytter seg oppover, flytter den andre seg nedover. Når de treffer toppen og bunnen, skal de bytte retning, og bakgrunnsfargen skal skifte. I tillegg skal spritens tile bytte, slik at den har en sur munn når den går nedover, og en glad munn når den går oppover. Vi skal også gjøre flere endringer enn bare de visuelle koden skal struktureres på en annen måte. Vi skal ta i bruk følgende nye tekniske metoder: DMA-overføring av sprite-dataene en NMI-rutine for grafikkoppdatering variabler i RAM DMA-overføring av sprite-dataene vil si at vi vil bruke DMA-kontrolleren til å frakte en page med sprite-data (i samme format som før X, Y, tile og attributter) fra minnet og inn i SPR-RAM. Dette har en rekke fordeler over å gjøre det manuelt i en loop: Det er raskere, sikrere, og enklere. Ved å lage en NMI-rutine (som blir kjørt hver gang PPU-en entrer vblank), vil vi for det første slippe å sjekke manuelt, og vil også være sikre på at vi alltid får oppdatert grafikkdataene. NMI-rutinen vår skal utføre følgende: Sette i gang sprite-dma-overføring fra page 3, dvs. adressene $0300- $03FF. Sette $2006 til adressen til bakgrunnsfargen i paletten, i tilfelle bakgrunnsfargen skal oppdateres Sjekke om sprite 1 har nådd toppen eller bunnen. Hvis ja, endre et retningsflagg som forteller hvilken retning den har. I tillegg skal
bakgrunnsfargen økes med 1, og spriten skal endre tile slik at den har sur munn om den går nedover og glad munn når den går oppover. Sjekke sprite 2 på samme måte som med sprite 1. Oppdatere koordinatene til sprite 1 og 2 (legge til 1 om retningsflagget er 1, som betyr nedover, eller trekke fra 1 om det er 0, som betyr oppover) Retningsflagget og bakgrunnsfargen, som må ligge i RAM siden de er variable, må vi definere i koden vår, om vi vil ha noe annet enn en adresse å referere til. I tillegg, siden vi skal bruke en annen del av RAM til sprite-data, kan det være lurt å også gi de forskjellige spritedataene (Y, X, tile osv.) egne labeler. Vi endrer litt i bank 0:.bank 0.org 0 ; Starten av RAM retning_spr1:.db 0 ; Retning til sprite 1 retning_spr2:.db 0 ; Retning til sprite 2 bakgrunn:.db 0 ; Bakgrunnsfarge.org $0300 spr1_y:.db 0 spr1_t:.db 0 spr1_a:.db 0 spr1_x:.db 0 spr2_y:.db 0 spr2_t:.db 0 spr2_a:.db 0 spr2_x:.db 0.org $8000 Start: ; kode... ; Starten av page 3 der vi skal ha sprite-data ; Sprite 1s Y-koordinat ; Sprite 1s tilenummer ; Sprite 1s atributter ; Sprite 1s X-koordinat ; Samme som over ; Starten av PRG-ROM Ved å bruke.org 0 forteller vi at labeler etter.org 0 skal baseres på adresse 0, som er starten av RAM. Siden det ikke er noe foran retning: vil den være en label til adresse 0. Det samme gjelder.org $0300 som forteller at labelene etter der, som spr1_y vil baseres på den adressen. Siden vi skal bruke en NMI-rutine, må vi også oppgi adressen dens. Det gjør vi ved å endre på bank 1, som inneholder adressevektoren:.bank 1.org $FFFA.dw NMI, Start, 0 ; sett NMI til adressen til NMI-labelen
Initialiseringsprosessen blir også litt annerledes. Den må utføre følgende: Slå av PPU-ens rendering Vente to vblank-er Sette alt minnet vi skal bruke til 0 (dvs. page 0 og page 3) Laste paletten Sette startkoordinater og tilenummer til spritene i $0300 Sette retningsflaggene til hver sprite, den ene til 1 (ned) og den andre til 0 (opp) Stille inn PPU, med NMI-biten (bit 7) satt til 1 i $2000 Gå inn i en evig loop som ikke gjør noe som helst (nå blir alt tatt hånd om i NMI-rutinen i stedet) Grunnen til at vi slår av renderingen er at initialiseringsprosessen vil ta litt tid. I de forrige eksemplene, gikk den stort sett ut på å laste inn paletten og skrive et par bytes til SPR-RAM. Nå skal vi gjøre mer, og da er det like greit å slå av hele renderingen, for ikke å «forstyrre» PPU-en. Når PPU-en akkurat har startet og renderingen er slått av, må vi vente et par vblank-er før vi foretar oss noe med registrene dens. Grunnen til at vi benytter en loop som setter alle bytene fra 0 til $FF og $0300- $03FF til 0, er at vi for det første ikke kan vite hva minnet inneholder når NESen slås på. Dermed kan ting vi antar er 0 fra før, slik som atributt-byten til hver sprite i $0300, faktisk ha andre verdier enn 0, og dermed gi uønskede hendinger. Det andre er at gamle verdier i minnet henger igjen når NES-en restartes, som også kan lede til uønsket oppførsel. Det nest siste vi gjør i initialiseringsprosessen er å sette startkoordinater til spritene, tilene de skal ha, og sette retningen deres. Til slutt slår vi på rendering, ved å stille inn PPU-en som normalt, og setter bit 7 i $2000 til 1, slik at NMIrutinen blir kjørt når PPU-en starter vblank. Deretter går vi inn i en uendelig loop. Den endelige koden kan lastes ned her Oppgaver for denne delen: Legg til en tredje sprite Skriv om programmet slik at spritene går på samme X-koordinat, og når de koliderer med hverandre i Y-koordinatet skal de skifte retning, osv. slik som før. Det samme skal skje når de når toppen / bunnen.