Spritepad E La Creazione Di Data

[COMMODORO]

 Salve.
Sto provando ad utilizzare CBM Prg Studio per scrivere i miei primi programmi per C64, ma questo mi sembra indifferente.
Uso SpritePad per disegnare gli sprite ma non ho capito come 'passarli' a CBM prg Studio o qualsivoglia altro assembler poiché Sprite pad mi consente di creare dei files .raw, oppure .prg con i miei sprite. Ma come faccio poi nella pratica a usare i dati così creati per essere usati on l'assembler???
In SPritepad esiste anche l'opzione per creare un file .bmp che può essere letto dall'editor di sprite compreso nel pacchetto di CBM prg studio e che vorrei usare per creare dal .bmp i dati degli sprite utiizzabili col mio assembler.
in realtà l'editor file di quest'ultimo non riconosce bene il file.bmp e quindi mi ritrovo al punto di partenza..
Cosa mi consigliate?  :specchio:  

[Flavioweb]

 Io uso 64tass, che è un compilatore cross-assembler con sintassi compatibile ed espansa dell'originale TurboAssembler che si usava nativamente su C64.
Per includere dei files ".raw" o ".prg" in un codice che stai scrivendo, devi usare una direttava simile a ".BINARY" (controlla il manuale dell'assemblatore... troverai una cosa simile).
Ad esempio, per includere i files del tuo sprite che hai realizzato per il tributo a Paolo Villaggio, ho usato questo codice:

Codice: [Seleziona]

COMMODORO_01
    .BINARY "../bin/sprites/COMMODORO.RAW", $0000, $0040
COMMODORO_02
    .BINARY "../bin/sprites/COMMODORO.RAW", $0040, $0040
COMMODORO_03
    .BINARY "../bin/sprites/COMMODORO.RAW", $0080, $0040
COMMODORO_04
    .BINARY "../bin/sprites/COMMODORO.RAW", $00C0, $0040
COMMODORO_05
    .BINARY "../bin/sprites/COMMODORO.RAW", $0100, $0040
etc... etc...
che mi permette di avere una label per ogni "fotogramma" (sprite) che compone l'animazione, anche se non è realmente necessario.
La differenza fra ".raw" e ".prg" è che il primo NON contiene i 2 byte con il load address dei dati che, nel caso fossero presenti (e quindi sarebbe un ".prg"), NON vanno importati come dati.
Nel caso de 64tass, l'esempio di prima ma con ".prg" diventerebbe

Codice: [Seleziona]

COMMODORO_01
    .BINARY "../bin/sprites/COMMODORO.PRG", $0002, $0040
COMMODORO_02
    .BINARY "../bin/sprites/COMMODORO.PRG", $0042, $0040
COMMODORO_03
    .BINARY "../bin/sprites/COMMODORO.PRG", $0082, $0040
COMMODORO_04
    .BINARY "../bin/sprites/COMMODORO.PRG", $00C2, $0040
COMMODORO_05
    .BINARY "../bin/sprites/COMMODORO.PRG", $0102, $0040
etc... etc...


[COMMODORO]

 Grazie Flavio!
Provando a smanettare seguendo i tuoi consigli sono riuscito a combinare qualcosa! Per piacere ogni tanto passa in zona così se ho altri dubbi ( e ne ho tanti) magari mi dai una mano!  
Ciao!

[Flavioweb]

 Chiedi pure.
   

[COMMODORO]

 Salve a tutti!

Riutilizzo questo Topic per fare una domanda a chi ha voglia e conoscenze per rispondermi.
Che tecnica si usa per visualizzare in maniera convincente i vari frames di uno sprite?
Per esempio un omino che cammina in un labirinto verso sinistra che abbia due soli frames di animazione, tipo uno con la gamba sinistra e il braccio destro avanti e nell'altro frames con l'altro braccio e gamba in avanti.
Si crea un ciclo di ritardo proporzionato alla velocità di spostamento dello sprite? O si lega il cambio di frame alle coordinate dello schermo? O cos'altro?
Qualcuno può spiegare, anche solo a livello teorico, come si opera in maniera corretta (ovviamente un esempio sarebbe benvenutissimo..)?
Grazie!

 

[Flavioweb]

 Io credo che la mianera più convincente per farlo sia, come dici anche tu, di utilizzare un delay proporzionale alla "velocità di spostamento", cambiando il puntatore dello sprite al "nuovo" frame dopo ogni countdown...
Logicamente, ad ogni cambio di direzione il contatore va azzerato e va usata una nuova serie di "valori" per il puntatore ai vari frames...
Così... a grandi linee.
Ma non dovrebbe essere un grosso problema implementarlo...

[COMMODORO]

Io credo che la mianera più convincente per farlo sia, come dici anche tu, di utilizzare un delay proporzionale alla "velocità di spostamento", cambiando il puntatore dello sprite al "nuovo" frame dopo ogni countdown...
Logicamente, ad ogni cambio di direzione il contatore va azzerato e va usata una nuova serie di "valori" per il puntatore ai vari frames...
Così... a grandi linee.
Ma non dovrebbe essere un grosso problema implementarlo...

Grazie Flavio per la disponibilità!
I consigli che mi dai sono in linea con l'idea che mi ero fatto. Ho trovato in giro parecchi esempi riguardanti sprites ma niente che mostri come appunto si possa muovere uno sprite con relativi frames di animazione che cambiano con lo spostamento.
Ciao!  

[pippo79]

 
Stai lavorando in assembly? La tecnica più usata per un movimento fluido e regolare è usare le IRQ, ossia delle routine che vengono chiamate regolarmente una volta (o più se si vuole) per ogni percorso completo del raster. In questo modo il cambio di frame avviene sicuramente senza sfarfallii e il movimento è assolutamente temporizzato. Nulla vieta comunque che si possa fare anche da codice principale, semplicemente facendo avvenire il cambio di frame o il movimento quando delle variabili counter hanno raggiunto dei determinati risultati, come avevi proposto tu.  

[COMMODORO]

Stai lavorando in assembly? La tecnica più usata per un movimento fluido e regolare è usare le IRQ, ossia delle routine che vengono chiamate regolarmente una volta (o più se si vuole) per ogni percorso completo del raster. In questo modo il cambio di frame avviene sicuramente senza sfarfallii e il movimento è assolutamente temporizzato. Nulla vieta comunque che si possa fare anche da codice principale, semplicemente facendo avvenire il cambio di frame o il movimento quando delle variabili counter hanno raggiunto dei determinati risultati, come avevi proposto tu.

Grazie Pippo!
E'da mesi che mi sto studiando l'assembly, diciamo che le basi sono piuttosto semplici da capire.
Diventa più complesso quando si inizia a maneggiare la grafica, il sonoro e gli interrupt, che chissà perché sono gli argomenti che vengono trattati meno in profondità nei testi sull'assembly in italiano presenti anche in questo sito.
Se qualcuno cerca notizie da questi testi consiglierei 'Commodore 64 I segreti del linguaggio macchina' che ha molti begli esempi. Poi studiare gli esempi su Internet tipo qui sul Forum. E direi che se non si conosce bene l'inglese si é quasi tagliati fuori perché in inglese la trattazione dell'argomento é molto più vasta e approfondita, sia a livello di vecchi testi scannerizzati che Siti e Forum ricchi di contenuti tipo Codebase64.org o il Forum di Lemon 64. Chiusa parentesi.

Riguardo l'uso delle IRQ nel mio esempio, come andrebbero usate?
Del tipo: omino che cammina in una direzione, ogni tot cicli interviene un interrupt( più volte in 1 secondo) che fa svolgere il compito di controllare se si é variata la direzione dello sprite. Se si , vengono caricati i data del frame legati alla nuova direzione, se no, dopo tot cicli si attiva un altro interrupt che richiama i data dell'altro frame dello sprite relativi alla stessa direzione. Sono sulla buona strada?
 

[COMMODORO]

 Ho trovato molti spunti interessanti da questo Topic sul Forum di lemon:

Forum Lemon

Aspetto altri suggerimenti!    

[Flavioweb]

 Concettualmente la strada é giusta, nel senso che devi avere un irq in cui controlli il joy ed in base ai dati letti, attivi la parte di animazione che ti interessa.
Poi devi avere un'altra porzione di codice in cui aggiorni i puntatori agli sprites per creare l'animaziobe vera e propria.
Generalnente, cambiare frame all'animazione ad ogni quadro video e, quindi, ad ogni raster irq, risulta essere troppo veloce. Perció devi inserire un contatore che ritarda il cambio ogni X frames... il valore di X dipende dall'effetto finale che vuoi ottenere.
Comunque la strada é questa...

[COMMODORO]

Concettualmente la strada é giusta, nel senso che devi avere un irq in cui controlli il joy ed in base ai dati letti, attivi la parte di animazione che ti interessa.
Poi devi avere un'altra porzione di codice in cui aggiorni i puntatori agli sprites per creare l'animaziobe vera e propria.
Generalnente, cambiare frame all'animazione ad ogni quadro video e, quindi, ad ogni raster irq, risulta essere troppo veloce. Perció devi inserire un contatore che ritarda il cambio ogni X frames... il valore di X dipende dall'effetto finale che vuoi ottenere.
Comunque la strada é questa...

Molte grazie Flavio!