Ladda in bild och rendera (koala)

av **bjonte** » 4 juli 2016, 20:35

Det är du som skriver över bitmapbilden med skärmminnet på $4400. Lägger du bitmappen på $4000 så måste du lägga skärmminnet på $6000 eller senare eftersom bitmappen tar 8000 bytes.

av **carlsson** » 5 juli 2016, 09:53

Bilden du laddar in kommer att vara paketerad som följande:

Bitmap: $4000 - $5F3F
Förgrundsfärg: $5F40 - $6327 (ska in på $4400, $6000, $7000 eller liknande)
Extra färg: $6328 - $670F (ska in på $D800)
Ram- och bakgrundsfärg på $6710 (ska in på $D020, $D021)

Om du är klurig och först kopierar färgdata till $D800, kan du sedan kopiera förgrundsfärgen baklänges till $6000 - $63E7, och då delvis skriva över det inladdade data du inte längre behöver. Annars får du lägga skärmminnet på $7000 men då har du kastat bort rätt mycket minne.

Om du skapar ditt eget bildformat, eller efterbehandlar det format som bildkonverteraren spottar ur sig, kan du padda in 192 bytes tomrum mellan $5F40 och $5FFF, och sedan placera förgrundsfärgen på $6000. Då behöver du bara kopiera extrafärgen till $D800 och ändra på $D020 och $D021. Det kan tyckas lyx att slänga bort 192 bytes (eller 191 om du lägger ramfärgen där) men du slipper skyffla 1000 bytes i programmet.

av **ekman** » 5 juli 2016, 14:50

Ja just det. Tänkte inte på hur långt den sträcker ut sig i minnet.. :oops:

Men det är helt rätt, nu pekade jag skärmminnet till $2800 då min koala bild tar upp 2713 bytes, så det blir ett glapp på 87 bytes.
Det var intressant lösning carlsson, men så klurig är jag inte än

Då ska jag fortskrida med det här projektet och skriver igen om det blir problem. Tack för alla svaren!

av **ekman** » 5 juli 2016, 14:57

Kan ju iofs fråga direkt. Kan man dynamiskt ladda in bilder istället för att hård koda in dom i minnet?
För annars får jag väl bara plats med en bild i varje VIC bank?

Jag använder 64tass för att kompilera koden och denna kod snutt för att ladda in bilden i minnet i koden:

Kod: Markera allt: * = $3FFE ; aka $4000 - $2 load adress .binary "b0.kla"

av **bjonte** » 5 juli 2016, 20:26

Ja, det går att ladda in bilder dynamiskt. Du får anropa SETLFS, SETNAM och LOAD i kernal med lämpliga argument. De finns beskrivna i Programmers Reference Guide eller Mapping the C64 till exempel.

av **carlsson** » 5 juli 2016, 21:09

Ett tips kan ju vara att köra någon kompressionsalgoritm, ladda in bilderna på en annan plats i minnet och packa upp dem till önskad position. Det är väl lite mer avancerat, men du skulle kunna få rum med flera bilder i minnet samtidigt och snabbare laddningstider.

av **ekman** » 14 juli 2016, 23:10

ja det är lite för avancerat för mig just nu ialf.

just nu försöker jag få till det där med att ladda en bild dynamiskt. men har problem med att få till filnamnet till nästa bild som ska laddas in.

Jag har följt assembler koden från den här sidan http://codebase64.org/doku.php?id=base:loading_a_file för att ladda in på specefik adress.

jag har försökt att ändra så här:

Kod: Markera allt: start = "0" endf = ".kla" myfile = start .. endf ; Här sätter jag ihop dom två strängerna till 0.kla ..... ..... ..... fname: .TEXT myfile fname_end:

men problemetet är att jag kan inte ge START ett nytt värde, det blir fel om jag försöker skriva start = "1"
Säger att start då är specifierad 2ggr

hjälp

av **bjonte** » 15 juli 2016, 06:36

Vilken assembler använder du?

av **carlsson** » 15 juli 2016, 08:31

Den där syntaxen med två punkter för att sammanfoga strängkonstanter har jag aldrig sett eller använt. Men i vilket fall, får jag en känsla av att du redan vid assembleringstillfället känner till filnamnen på alla bilder du vill använda? I så fall skulle jag föreslå att du lägger in dem som konstanter, och använder någon indexfunktion för att plocka önskat filnamn när du laddar in dem.

Kod: Markera allt: ldx #filnummer lda fnaptr_lo,x sta ptr_filename lda fnaptr_hi,x sta ptr_filename+1 JSR SETNAM .. osv .. eller hur man nu definierar filnamnet, minns inte exakt men det har du ju redan kläm på fnaptr_lo: .byte #<fname1, .byte #<fname2, .byte #<fname 3 fnaptr_hi: .byte #>fname1, .byte #>fname2, .byte #>fname 3 ; skulle också kunna vara #<fname1, #>fname1, #<fname2, #>fname2 osv men då måste du multiplicera x ovan med 2 fname1: .text "0.kla" .byte 0 fname2: .text "1.kla" .byte 0 fname3: .text "2.kla" .byte 0

Ska du hämta filnamn dynamiskt får du väl läsa in katalogen och lägga in filnamn i minnet på liknande sätt, men fasta filnamn är klart enklare.

av **ekman** » 17 juli 2016, 13:00

Jag använder 64tass för att kompilera

efter många timmars knep och knåp så har jag gjort lite framsteg som jag tänkte visa. Det ser inte mycket ut och gifen har ökat hastigheten, men nu kan jag ladda in semi dynamiskt ialf!

Till stor del tack vare din kod carlsson, Tack!

Som det är just nu måste jag mata in varje bild manuellt i koden. Alltså skriva dit namnet och en HI och LOW adress pekare (om det heter så?). Och det kan bli lite drygt om det är mer än 20 frames.. Så kanske ska titta på att hämta filnamnen dynamiskt som du nämnde. Men ja, så här ser det ut nu

av **carlsson** » 18 juli 2016, 11:16

Är det där rätt färgattribut? Det ser lite grann ut som Hulk-Hitler.

Förresten finns det ju inte 20 buffrar åt VIC-II, så du lär väl ladda in bild i en av de minnesutrymmen som just nu inte visas, och sedan skifta när all kopiering är klar. Det torde sakta ner det till ett bildspel?

av **ekman** » 19 juli 2016, 06:03

Ja, eller jag tror det. Så bra jag kunde få till det i mitt program som jag gjort i visual basic för att konvertera gif till koala format. Jag har gjort en liten gif på programmet som syns nedan
Jo jag tänkte också på att dubbel buffra och spara en bild i en annan vic bank medans jag visar en annan. Det blir i framtiden, jag gillar lite att det glitchar lite så där :shock:

Det ska i slut ändan bli ett litet demo till ett super litet lan brorsan brukar arrangera varje år. Missade dock detta året då jag var för lat

http://i.imgur.com/HaPeYVA.gif

av **carlsson** » 19 juli 2016, 11:35

Coolt att du gjort ett eget verktyg. Du kan ju jämföra med något befintligt verktyg om de är bättre på att färgmatcha enstaka bildrutor. Ibland kan man behöva justera ljus och kontrast för att få vettigt resultat.

av **ekman** » 19 juli 2016, 20:37

Tack. Men jag testade nu att konvertera en bild med project one, och gud vad mycket bättre det såg ut. Min färgmatchning är helt fel också..

Tillbaka till skrivbordet med det programmet senare antar jag