Gå til innhold

Guide: Nintendo NES-programmering


Anbefalte innlegg

  • 1 måned senere...
Videoannonse
Annonse
  • 5 måneder senere...

Har begynt på en ordentlig guide nå i mangel på andre ting å gjøre på fritiden, hehe. Skal strukturere ting mye bedre denne gangen. Når jeg ser over de gamle kapitlene er det mye som er dårlig formulert og krøkkete forklart.

 

Laga forresten en såkalt metatile-motor for noen måneder siden. En metatile er en tile (blokk) som er satt sammen av flere 8x8-tiles (de grunnleggende elementene i NES-grafikk.) Motoren kan tegne et map på 16x12 blokker, med blokkstørrelse 16x16 piksler (samme som i f.eks. Mario-spillene.) I tillegg fungerer kollisjonstesting mellom en 16x16-sprite og blokkene. For interesserte ligger koden og grafikken her (filene med 'labyrint' i navnet.)

Lenke til kommentar
  • 1 år senere...

Begynner å bli en god stund siden jeg lovet en ny guide, men nå er den på vei :)

 

Prøver å skrive den nye guiden/"boken" mer pedagogisk, og forhåpentligvis noe enklere å forstå. Jeg setter veldig pris på tilbakemeldinger om ting som er feil eller dårlig forklart. Tar også gjerne i mot ønsker om ting den bør ta for seg. Jeg kommer til å droppe en del av forsøkene på å forklare ting helt fra bunnen av. Denne guiden kommer til å forutsette at du kan programmering, helst i C eller lignende. Den kommer ikke til å forklare i dybden hvordan tallsystemer og så videre fungerer. Det finnes det flere gode forklaringer på andre steder.

 

Tror jeg kommer til å la den gamle guiden fortsette å ligge oppe, siden den foreløpig er mye mer "komplett".

 

Det jeg har skrevet på den nye kan du til en hver tid følge med på her.

Lenke til kommentar
  • 10 måneder senere...

Nesten et år siden forrige post :p

 

Vel, har skrevet så smått på guiden i det siste. Som utdpyet i førsteposten så har jeg byttet kompilator fra NESASM til ca65 pga. NESASMs mange feil og mangler. ca65 er noe tyngre, men det jeg merket da jeg skrev om delen som handler om kompilering er at kodefilene blir mye ryddigere og mer logiske. Koden deles nå opp i segmenter i stedet for de ulogiske bank-definisjonene til NESASM.

Lenke til kommentar

Jeg vil følge denne guiden; kanskje vente litt til den er litt mer utfylt, så jeg slipper å tråkke feil med NESASM (har nettopp lest gjennom en guide kalt Nerdy Nights, som bruker NESASM.. og så finner jeg ut fra flere kilder at denne assembleren ikke er så bra), og da heller begynne på CA65.

 

Hvordan vil guiden fortsette videre? Kan du gå i dybde hvordan du lagde Chip's Challenge porten din? Eller noe sånt. Steg for steg, med forklaringer om hvordan en scroller horisontalt / vertikalt.. hva som skjer bak teppet med nametables osv. :dribble:

Endret av sju4sju
Lenke til kommentar

Det er det jeg har i tankene ja. :) Aller først grunnleggende ting om 6502, PPUen og så videre, og så blir det å komme i gang med å lage ting. Det vil komme mer info om PPU og CPU etter hvert som det trengs. Planen er å ta for seg grunnleggende ting som paletter, plassere sprites på skjermen, lese av kontrollere, osv. først. Deretter blir det over på mer kompliserte ting der man kombinerer disse tingene. Jeg har tenkt litt på å etter hvert ta for meg Chip's Challenge, i alle fall deler av det, men da må jeg få ryddet opp i koden først :p.

 

Anbefaler deg aboslutt å hoppe over på CA65. Det kan by på mange avanserte funksjoner som NESASM mangler, som anonyme labels, avanserte makroer, osv. I tillegg syns jeg hvertfall det er penere å arrangere koden på den måten CA65 legger opp til, med segmenter osv. Men den viktigste grunnen er kanskje at NESASM ikke tolker f.eks. LDA $20 som en zero-page-instruksjon, selv om addressen bare er 8-bits. Du må eksplisitt oppgi dette ved å skrive LDA >$20. Dette er helt idiotisk når du har labels i stedet for addresser, for da må du drive å huske på hvilke labels som peker til zero page og ikke. Jeg var faktisk ikke klar over dette før jeg var kommet langt med Chip's Challenge. Etter at jeg portet til CA65 så ble hovedloopen mye raskere (siden de nesten alle variablene ligger i zero page ble det veldig mange instruksjoner som ble kortet ned med 2-6 klokkesykluser!), og kunne håndtere langt flere objekter i et map på en gang.

Lenke til kommentar
  • 2 uker senere...

Det kommer mer i påsken (antagelig), jeg har alt for mye å gjøre akkurat nå :/

 

Men hvis du allerede har lest Nerdy Nights så kan du jo prøve å lese litt dokumentasjon osv. og prøve deg litt frem selv? Jeg tror det går raskere enn å vente på dette :p

Lenke til kommentar

Man finner massevis av bøker om 6502-assembly programmering, og masse artikler på nettet også. Men de er veldig lite NES-spesifikke, siden 6502 sammen med Zilog Z80/Z81 var en svært populær CPU gjennom hele 80-tallet. Det blir bare masse prat om hex/desimal regning, og plussing og minus i registrer, ingenting om ting som kan lage grafikk og spill. Instruksjonssettet er ikke så veldig stort, det er mere å finne ut alle de spesifikke triksene for nevnte konsoll/datamaskin for å lage rask grafikk, scrolling og slikt. Da må man nesten bare snakke med andre utviklere tror jeg. Eller finne artikler på nettet som går spesifikt på dette.

 

Jeg er veldig interessert i gamle datamaskiner som ZX Spectrum, Commodore 64 etc, og da er 6502-CPU en gjenganger. Men jeg finner generellt lite info om programmering direkte for disse systemene, annet enn referanser til gamle utsolgte bøker fra 1983 og slikt, eller kjappe artikler om hvordan man endrer farge på border og skjerm på en C64 i assembly. Bøker som ble gitt ut omhandler oftest bare Basic-programmering også.

 

Jeg skulle gjerne visst hvordan man bruker ferdiglagde sprites og lager animasjoner med dem og slikt.

Og hvordan de tegnet sprites i det hele tatt.

 

Jeg beundrer karer som starta å jobbe i et eller annet utviklerfirma i 1983, fikk beskjed om å konvertere masse spill til diverse formater (spectrum/amstrad/c64) og bare lærte seg å kode til dem på noen få uker. Leser artikler om dem i Retro Gamer stort sett hver måned.

Endret av Bytex
Lenke til kommentar
  • 2 uker senere...

Det finnes i grunn mye dokumentasjon for å programmere NES (altså ting som er spesifikt for NES), men det meste holder et høyt teknisk nivå, og kan være vanskelig å følge. Det samme gjør det til C64 også. Men det krever ganske mye tålmodighet å lese teknisk dokumentasjon om f.eks. grafikkchippen i C64, få en oversikt over hvordan den fungerer, koble dette til selve assemblyprogrammeringen, og så til slutt være i stand til å skrive kode som produserer den grafikken man ønsker. Med nok pågangsmot så klarer man dette, men det tar lang tid. Dette er en av hovedgrunnene til at jeg syns det var nødvendig å skrive på denne NES-guiden; å gjøre det litt enklere å vite akkurat hva som må gjøres for å f.eks. få frem en figur, bevege figurer, animere, og så videre.

 

Når det gjelder bruk av sprites på C64 så finner du vel sikkert noe informasjon om dette på forskjellige forum (vil jeg tro). Men du har rett i at det finnes ganske lite nybegynnervennlig dokumentasjon til C64 (i alle fall tatt i betraktning at utviklermiljøet er ganske stort.) Kanskje dette kan ha med at det stort sett er demoscenen som er i live i dag. Jeg har et inntrykk av at holdningen der er at man skal lese seg opp til alt på egenhånd. NES-miljøet virker i alle fall mer åpent for nybegynnere.

Lenke til kommentar
  • 3 måneder senere...

Hei, tusen takk for denne guiden! Jeg kom over den for en uke siden og er skikkelig gira på å få til litt NES-programmering.

 

Jeg bruker ca65-kompilatoren, så det begynner å bli vanskeligere med det som kun er beskrevet i den første guiden. Mulig jeg har oversett noe i guiden, så håper jeg ikke spør om noe som allerede er besvart.

 

Jeg prøver meg litt fram å bruke sprites. Hvordan inkluderer jeg en .chr-fil med ca65?

 

Og hvordan henger fargene i fargepaletten sammen med fargene brukt i Tile Molester?

 

 

Gleder meg til å se mer av guiden hvis du fortsatt jobber med den!

Endret av 89erik
Lenke til kommentar

I ca65 er det forskjellige segmenter til forskjellige deler av koden (se beskrivelse i den nye guiden.) Hvis du tar å laster ned http://home.no/johan...nker_config.cfg så har du segmentdefinisjonene som trengs for enkle spill/programmer til NES. Under segmentet "GFX" legger du grafikk-filene. Det gjør du slik:

 

   .segment "GFX"
bg_tiles:
   .incbin "bakgrunn.chr"
spr_tiles:
   .incbin "sprites.spr"

 

Paletten består av 16 bytes. Disse er delt inn i 4 "blokker" på 4 bytes. En sprite kan kun ha farger fra én slik blokk. Hvilken blokk den skal ta farger fra velger du i koden når du legger sprite-dataene inn i SPR-RAM. Pikslene i figuren vil da få farger fra den valgte blokken. Hvilken farge hver piksel skal få er gitt ved et 2-bits tall (altså fra 0 til 3.) 0 vil si at pikselen skal få fargen gitt ved den første fargen i blokken. 1 vil si at den skal få fargen gitt i den andre i blokken, og så videre.

 

Det er denne informasjonen som ligger i CHR-filen. Fargene i Tile Molester tilsvarer en verdi mellom 0 og 3. Fargen lengst til venstre er 0, den neste er 1, og så videre. Det er derfor det er 4 fargevalg. Det har ingenting å si hvilke farger som velges i Tile Molester. Den muligheten er der kun for at du skal kunne sette opp farger som brukes i paletten, slik at du lettere skal kunne se hvordan figurene vil ta seg ut. Det eneste du må huske på er at de stedene der du f.eks. har brukt den tredje fargen i rekken (fra venstre), vil pikslene får den tredje fargen i palettblokken.

Lenke til kommentar

Gleder meg til å se mer av guiden hvis du fortsatt jobber med den!

 

Jeg har jobbet litt med den nå og da, men det går ikke så fort. Jeg har lastet opp en oppdatert utgave i dag, men det er ikke så veldig mye nytt. Jeg holder også på å porte eksemplene fra den forrige guiden over til ca65. Si fra om det er noe i guiden som er uklart og så videre, og spør for all del om det er noe mer du lurer på :)

Lenke til kommentar
  • 2 uker senere...

Jeg har litt problemer med bakgrunnen.. Grafikken er inkludert på følgende måte.

.segment "GFX"
spr_tiles:
.incbin "sprites.spr"
bg_tiles:
.incbin "bakgrunn.chr"

Problemet er at jeg kun får brukt den første fila. Nå som jeg bruker sprites.spr først, får jeg bruke spritesene som sprites, men sprite 0 blir også plassert ut over hele bakgrunnen. Ved motsatt rekkefølge blir spritene hentet fra bakgrunn.chr.

Jeg har lagt ved et screenshot. I sprites.spr har jeg tegna masse tall, så tile 0 sees i bakgrunnen, mens tile 3 er tegnet som en sprite (og flyter fint rundt på skjermen :3). Noe annet som jeg også syns er litt rart er at alle sprites som jeg ikke har satt er default den siste tilen i sprites.spr / pattern table 1 (et smilefjes).

 

Ser du hva jeg har gjort galt / ikke gjort?

 

Her er koden min, jeg har brukt din linker_config.cfg

post-277833-0-48693300-1341917378_thumb.png

Lenke til kommentar

Problemet ligger i instillingene du skriver til kontrollregisteret i $2000. Som du kan se i den gamle guiden eller eventuelt her så bestemmer bit 4 hvilken pattern table som skal benyttes for bakgrunnen. Når bit 4 er 0 vil det første pattern tablet fra $0000 - $0FFF, som her fylles med innholdet av filen "sprites.spr", benyttes for bakgrunnen. Og siden nametablene bare inneholder 0 så vil da den første tilen i dette pattern tablet fylle bakgrunnen. Hvis du i stedet gjør det slik:

 

lda #%00010000
sta $2000

 

så vil det andre pattern tablet ($1000 - $1FFF) (edit: som fylles av innholdet i "bakgrunn.chr") benyttes for bakgrunnen.

 

edit: jeg har forresten skrevet ferdig kapittelet om CPU-en nå. Det bør dekke det meste som trengs senere i guiden.

Endret av Jaffe
Lenke til kommentar

Noen andre små kommentarer til koden:

 

- Det er nok å skrive instillingene til $2000 og $2001 én gang. Det er vanlig å gjøre etter at du har lastet paletten, og ikke inne i loopen som kjører hver frame.

 

- I stedet for å flytte X og Y over til A og så lagre A i $2004, kan du heller bare skrive STX $2004 og STY $2004.

 

- Det er viktig å vente to vblank-perioder helt i starten før du begynner å laste paletten. PPU-en trenger omtrent 30000 pikselklokker før den kjører som normalt. Før det vil bl.a. adresser som skrives til $2006 ignoreres. Det lureste er å vente til det har gått to frames. Noen emulatorer lar dette kanskje gå, men det vil mest sannsynlig feile på en ekte NES.

 

- I lengden kan det bli vanskelig å huske på hvilke variabler som har hvilke adresser i RAM. Hvis du gjør følgende:

 

.segment "RAM"
x_vektor: .byte 0
y_vektor: .byte 0
; og eventuelle andre variabeldefinisjoner

 

så slipper du å holde styr på hvilke adresser variablene har. Da bytter du f.eks. ut

sta $0001

med

sta x_vektor

og så videre.

Endret av Jaffe
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...