Eggland Mystery Project

Diskussioner om programmering

Moderatorer: Fanta_gbg, e5frog, stonan, Zlasher, hollowman

Eggland Mystery Project

Inläggav Staffan » 21 augusti 2013, 20:59

Hejsan!
Jag håller på att programmera lite för mig själv men stöter som alla nybörjare på lite problem.
Jag tycker att böckerna och nätet är lite svårt att förstå ibland. Tex så satt jag en hel kväll med att försöka ladda bitmap mode.
Detta för att boken sade att man skulle sätta BMM biten till 1 i register $11 för att det skulle fungera.
Tog ett tag innan jag fattade att $11 betydde $D011, och att BMM var 5:e registret. Anyway nu är det gjort ialla fall och jag är fast på nästa punkt...

I bitmap mode så fylls genast skärmen med skräp. Det är helt normalt vad jag fattat det som. Jag har även lyckats ändra färg på de satta pixlarna i en 8x8 ruta genom att flytta värden till registren kring $0400.
När jag däremot skall ändra vilka pixlar som är satta uppstår problem. Jag vet inte vart jag skall skriva. har försökt med lite olika.
I nån bok läste jag $2000, i min nuvvarande bok $D800, men inget verkar fungera :(.
$D800 står ju som video memory, utan att kunna bättre så har jag börjat testa genom att köra:
LDA #$00
STA $D800
STA $D801
.
.
STA $D8013
bara för att testa. Det verkar inte fungera.

Sen undrar jag om någon kunde skriva en exempel kod, som tar och lägger 0 på 500 minnesadresser i rad. Det skulle jag också ha nytta av :)
Hoppas höra från er.
Senast redigerad av Staffan 11 januari 2014, 22:48, redigerad totalt 1 gång.
Staffan
Erfaren lärling
Erfaren lärling
 
Inlägg: 141
Blev medlem: 14 augusti 2013, 08:41
Ort: Hammarö

Re: Problem i bitmap mode

Inläggav carlsson » 22 augusti 2013, 10:53

Med standardkonfiguration kommer VIC-II att arbeta i banken $0000-3FFF (har för mig att den kallas bank 3, men jag kanske minns fel och det är ändå inte så viktigt). En högupplöst skärm tar 8000 bytes grafikdata + 1000 bytes färgdata. Normalt lägger man den högupplösta skärmen på $2000. Det har bl.a. innebörden att programkoden måste börja efter dess, eller hoppa förbi själva skärmen. I maskinkod är det inget större problem, lite knöligare om man arbetar i Basic och vill ha program som är större än 6 kB.

Så här skulle jag göra för att sätta skärmen i högupplöst läge med start på $2000:

lda #$3b
sta $d011
lda #$18
sta $d018

Sedan måste du förstå hur pixlarna adresseras. Varje byte motsvarar åtta pixlar i sidled, och åtta pixelrader läggs efter varandra. Har du någonsin gjort egendefinierad textgrafik förstår du tanken:

x0-x7 y0
x0-x7 y1
...
x0-x7 y7
x8-x15 y0
x8-x15 y1
...
x8-x15 y7
x16-x23 y0
...
x312-x319 y0
...
x312-x319 y7
x0-x7 y8
...
x0-x7 y15

osv

Färgdatat i högupplöst läge fungerar som två nybbles (4 bitar) i varje byte, där ena halvan specifierar bakgrundsfärg 0-15 och andra halvan förgrundsfärg 0-15. Utan rastertricks och annat kan du bara ha en kombination av bakgrund och förgrund i varje 8x8 ruta. Detta färgdata läggs in på $0400, alltså det som i textläge är skärmminne. Färgminnet på $d800 används inte i högupplöst läge.

Du kan också arbeta i högupplöst multicolourläge:

lda #$18
sta $d016

Då sänks upplösningen från 320x200 till 160x200. Du kan ha fyra färger varav en (?) är fast för hela skärmen ($d020 om jag minns rätt) och övriga väljs per 8x8, även om rutorna bara har 4x8 pixlar. Där används $d800 för att specificera den tredje färgen på varje ruta. För att välja färg på varje pixel använder man par av bitar: 00, 01, 10 eller 11 som representerar bakgrund eller en av de tre förgrundsfärgerna.

För att rensa eller fylla minnet kan man göra på flera snarlika sätt. Enklast är något likande det här:

ldx #$00
txa
loop:
sta $2000,x
sta $2100,x
inx
bne loop

Det bygger på att inx kommer att slå till Z-flaggan när den väl blir noll på nytt. Genom att lägga till fler sta-instruktioner kan du rensa/fylla större mängder minne på en gång.

En del håller också på med självmodifierande kod:

ldy #$20
sty loop+2
ldx #$00
txa
loop:
sta $2000,x
inx
bne loop
inc loop+2
dey
bne loop

Här gäller det att känna till vilken byteordning (endian) processorn har, så man modifierar den byte som innehåller höga delen av adressen till sta. Denna variant ska rensa 8K på ett bräde om jag gjort rätt.

Tredje varianten är att använda zeropage, kanske överdöd i detta fall men är en mycket nyttig adresseringsform att känna till:

ldx #$20
stx $fe
ldy #$00
sty $fd
tya
loop:
sta ($fd),y
iny
bne loop
inc $fe
dex
bne loop

Här gäller det att använda de fåtalet register som finns på rätt sätt. Adresseringen ($nn),y hämtar en 16-bitars adress som finns på adress $nn + $nn+1 och lägger till offset y. Den snarlika adresseringen ($nn,x) skulle istället hämta den 16-bitars adress som finns på adress ($nn + x) och efterföljande byte.

När det gäller zeropage, används en hel del av operativsystemet. Om du helt skippar Basic har du det mesta till förfogande. Adresserna $fb-$fe är garanterat oanvända, men det finns många fler man kan använda om man vet vad de annars skulle användas till.

Allt med risk för felaktigheter och saker jag glömt eller blandat ihop.
Användarvisningsbild
carlsson
VIC-20 Guru
VIC-20 Guru
 
Inlägg: 2357
Blev medlem: 10 oktober 2007, 16:24
Ort: Västerås

Re: Problem i bitmap mode

Inläggav Staffan » 22 augusti 2013, 20:34

Tänk att det finns så snälla folk som tar sig tid att skriva sådana svar gratis på ett forum :)
Nu har jag gjort framsteg och försöker skriva en putpixel funktion, bland annat tack vare inlägget ovan :)

Mitt mål är att porta spelet "lolo" från nes. Stor chans att det blir nerlagt innan det blir klart, men just nu är det planen iaf.
I nuvarande hastighet lär det ta minst ett års tid :)

Har skrivit spel osv förut men då var det i DOS.
Staffan
Erfaren lärling
Erfaren lärling
 
Inlägg: 141
Blev medlem: 14 augusti 2013, 08:41
Ort: Hammarö

Re: Problem i bitmap mode

Inläggav carlsson » 22 augusti 2013, 23:44

Du vet väl om att du kan definiera om tecknen, så du inte måste använda högupplöst läge? Begränsningen ligger i att ett typsnitt består av maximalt 256 tecken, så variationen av grafik är begränsad till kombinationer av dessa tecken. Just Lolo är väl i väldigt hög grad baserad på "brickor" som återkommer på skärmen, så för det projektet kanske teckengrafik + sprites skulle duga alldeles utmärkt. Du kan ha teckengrafik i multicolour också, då gäller att tre färger är fasta för hela skärmen och fjärde som är olika för varje tecken.

Fördelen är att det förmodligen går snabbare att scrolla skärmen med teckengrafik än högupplöst, i den mån skärmen ska scrollas alls.
Användarvisningsbild
carlsson
VIC-20 Guru
VIC-20 Guru
 
Inlägg: 2357
Blev medlem: 10 oktober 2007, 16:24
Ort: Västerås

Re: Problem i bitmap mode

Inläggav Staffan » 23 augusti 2013, 06:01

Jag räknade efter och för att kunna visa lolos alla 11*11 rutor så måste jag tyvärr ha det.
Får se hur det går.
Staffan
Erfaren lärling
Erfaren lärling
 
Inlägg: 141
Blev medlem: 14 augusti 2013, 08:41
Ort: Hammarö

Re: Problem i bitmap mode

Inläggav carlsson » 23 augusti 2013, 10:07

Du kanske kan förenkla grafiken en smula? Jag har inte spelat det eller detaljstuderat alla "tiles". Om olika uppsättningar tiles förekommer på olika skärmar/nivåer, skulle du kunna ha flera fasta uppsättningar teckengrafik som du byter mellan. Med rastertricks kan man förstås byta mitt under en skärmuppdatering också. Förutom att det blir något enklare att arbeta med, så sparar du en del minne, mängden beroende på hur du i leveldata lagrar tiles. Sedan är jag osäker på hur kollissionsdetektion med sprites fungerar i högupplöst läge, eller om du ändå måste ha levlar lagrade i något logiskt format för att jämföra positioner osv, och ev. plotta varje skärm till minnet istället för att ha färdiga högupplösta skärmar att kopiera in. Med 8 kB grafik per skärm blir även 64:ans gigantiska minne ganska snabbt fullt om man ska ha grafiken färdig i minnet.. eller väldigt segt att spela om man skulle ladda bilder från diskett med jämna mellanrum.
Användarvisningsbild
carlsson
VIC-20 Guru
VIC-20 Guru
 
Inlägg: 2357
Blev medlem: 10 oktober 2007, 16:24
Ort: Västerås

Re: Problem i bitmap mode

Inläggav Metalux » 23 augusti 2013, 19:19

Staffan skrev:Nu har jag gjort framsteg och försöker skriva en putpixel funktion, bland annat tack vare inlägget ovan :)

En sådan rutin gör du så här: http://codebase64.org/doku.php?id=base: ... l_graphics
Metalux, assembler, C64, Amiga.
Användarvisningsbild
Metalux
Erfaren lärling
Erfaren lärling
 
Inlägg: 140
Blev medlem: 2 maj 2007, 18:40
Ort: Lund

Re: Problem i bitmap mode

Inläggav Staffan » 23 augusti 2013, 20:08

Hej igen!
Jag är lite orolig för grafikminnet eller för att jag skall koda in mig i ett hörn och få koda om allting, men den som lever får se. Om ni följer länken nedan så kan ni klicka på next och previous och därmed se att det är ganska återkommande grafik i detta pusselspel. Mitt kommer inte se likadant ut eftersom jag inte kan rita lika många färger på samma ställe, dock så kommer det ha samma upplösning (om det blir klart)
http://www.gamefaqs.com/nes/587073-adve ... s_screen-2


Jag har kommit en bit på min putpixel funktion. Den påminner lite om metalux exempel faktiskt. Radnumret slår jag bara upp. Sen använder jag mig av indexregister y för att lägga till den xcoordinat jag vill ha. Har även 8 olika bitmasker som körs i en case sats så man vet vilken pixel i "rutan" som skall lysa.

Än så länge kan min funktion bara plotta i 256*256, men det löser jag säkert senare. :)
Inte så sugen på att göra om något. Det gör jag först när jag märket att något blir för söligt för spelet eller så.
Staffan
Erfaren lärling
Erfaren lärling
 
Inlägg: 141
Blev medlem: 14 augusti 2013, 08:41
Ort: Hammarö

Re: Problem i bitmap mode

Inläggav Staffan » 23 augusti 2013, 20:10

låt oss säga föressten att jag MOT FÖRMODAN får ihop något. Måste jag oroa mig för NIntendo då? Eller måste jag döpa om spelet?
Lär ju vara uppenbart att man bara programmerar som hobby på C64?
Staffan
Erfaren lärling
Erfaren lärling
 
Inlägg: 141
Blev medlem: 14 augusti 2013, 08:41
Ort: Hammarö

Re: Problem i bitmap mode

Inläggav Metalux » 23 augusti 2013, 20:35

Staffan skrev:
Än så länge kan min funktion bara plotta i 256*256,
Du menar 256x200?
Metalux, assembler, C64, Amiga.
Användarvisningsbild
Metalux
Erfaren lärling
Erfaren lärling
 
Inlägg: 140
Blev medlem: 2 maj 2007, 18:40
Ort: Lund

Re: Problem i bitmap mode

Inläggav Staffan » 24 augusti 2013, 09:23

Nej, jag menar att jag jobbar i highres mode, men eftersom ett register bara kan hålla ff = 256, och jag bara vet hur man anvönder ett index i taget så når jag inte pixlarna längst till höger på skärmen :(
Staffan
Erfaren lärling
Erfaren lärling
 
Inlägg: 141
Blev medlem: 14 augusti 2013, 08:41
Ort: Hammarö

Re: Problem i bitmap mode

Inläggav Metalux » 24 augusti 2013, 09:25

Jo precis, men du når ju max 200 i höjdled.
Metalux, assembler, C64, Amiga.
Användarvisningsbild
Metalux
Erfaren lärling
Erfaren lärling
 
Inlägg: 140
Blev medlem: 2 maj 2007, 18:40
Ort: Lund

Re: Problem i bitmap mode

Inläggav Staffan » 24 augusti 2013, 09:43

Ja det har du rätt i
Staffan
Erfaren lärling
Erfaren lärling
 
Inlägg: 141
Blev medlem: 14 augusti 2013, 08:41
Ort: Hammarö

Re: Problem i bitmap mode

Inläggav e5frog » 24 augusti 2013, 20:54

Om man jobbar i teckenläge blir det kanske enklare att definiera mot vilka tecken det är stopp för spriten samt andra funktioner.

Sen är det snålare på minne med om man kan återanvända tecken, det är väl så man brukar jobba.

Om du har bestämt att det är bitmap det ska vara så går det att göra konverteringar från originalet till färdig C64-grafik som t.ex. Koala Painter format.
Det finns en online här t.ex. http://alex.kazik.de/2/c64-converter/
http://csdb.dk är säkert full med andra varianter.

Jag har förstått det som så att det är brukligt att använda omdefinierade tecken som placeras i färdiga mönster, s.k. tiles, och sedan ritar man upp hela bilden med dessa tiles som kan vara 2x2 tecken eller andra konfigurationer. Om man jobbar i hires och tycker det blir fattigt på färg så går det väl att peta in sprites för att bättra på detta, även rasterlinjer som ligger bakom grafiken.

Jag försökte få till Bruce Lee II men än så länge har jag inte lyckats med mer än ett icke funktionellt intro och första skärmen som multicolor bitmap vilken är gjord i split med vanligt (hires) textläge överst för att där ha information och antal liv, möjligen poäng. Jag har förstått att det kanske blir enklare med "multicolor char" men då det finns EasyFlash som format så gör det kanske inte så mycket, man har gott om plats där och det går fort att ladda.
Kolla in mitt Fairchild System bild-galleri:
fairchild fairchild fairchild Bild fairchild fairchild fairchild
Användarvisningsbild
e5frog
Moderator
Moderator
 
Inlägg: 2764
Blev medlem: 8 augusti 2007, 18:16
Ort: Älvängen

Re: Problem i bitmap mode

Inläggav e5frog » 25 augusti 2013, 19:47

Om man skulle köra en konvertering rakt av till multicolor-läge så skulle det kunna se ut så här:

Bild

I originalet verkar de större objekten vara 2x2 tecken, bakgrunden med trägolvet verkar vara bara ett tecken.
Bild

... men jag har bara kikat på första spel-skärmen.
Kolla in mitt Fairchild System bild-galleri:
fairchild fairchild fairchild Bild fairchild fairchild fairchild
Användarvisningsbild
e5frog
Moderator
Moderator
 
Inlägg: 2764
Blev medlem: 8 augusti 2007, 18:16
Ort: Älvängen

Nästa

Återgå till Programmering/prog.-verktyg

Vilka är online

Användare som besöker denna kategori: Inga registrerade användare och 1 gäst

Banners

BOA Japon Mediapalatset Nostalgibutiken
Quartex Retro Overlays Retroplay Spel och sånt
Super Motaro Söders Serie & Skivhandel vintagegames.se RG 2016
cron