Ready64 Forum
Commodore 64 => Programmazione, Grafica e Musica => Topic aperto da: ice00 - 09 Gennaio 2007, 20:56:58
-
No, il titolo ancora non è scelto e alla fine potrebbe diventare qualcosa ancora diverso dai 3 proposti.
In ogni caso si tratta del prossimo 4KB minigame che durante una settimana nelle nevi ho previsto di sviluppare per la prossima combo (ovviamente mi prendo in anticipo...).
In ogni caso si tratta di fare un porting di Frozen Bubble sul C64 (spero che lo conosciate, così potete seguire la descrizione tecnica che segue).
Ho avuto modo di giocarci pure su telefonino, oltre che su pc, e direi che come giocabilità è uno dei migliori.
Lo schermo prevede al max 12 palline in orrizzontale e 12 in verticale (una riga con 12 e una con 11), pertanto usando char di 2x2 ottengo l'area di 24x24 char.
Rimane una riga vuota per mettere la barra verticale sopra che scende al tempo stabilito. In orrizzontale, la schermata va centrata (o tenuta a sinistra), in modo comunque da non superare i 255 bits per la posizione dello sprite (così da risparmiare sul codice).
I caratteri saranno multicolore e (abbozzati su carta), direi che ho il modo di rendere pure l'effetto Frozen che avviene quando si perde.
La pallina che si muove sarà fatta con uno sprite multicolore, che verrà rimpiazzato da caratteri appena la pallina entra nelle griglia fissa.
Un problema è quello di far cadere le palline che sono state colpite. Questo potrebbe implicare l'utillizzo di 1 sprite multiplexor per far cadere le palline in contemporanea (facendo cadere al max 8 palline su una riga, le altre 4 farle cadere in ritardo dopo).
Ho però escluso questa possibilità perchè il codice verrebbe troppo oneroso.
Penso invece che un effetto che andrebbe bene sia far esplodere la pallina (con una animazione). In mente avrei pure l'effetto che la pallina (supposta un disco), ruoti e si veda che diventa una linea (lo spessore del disco), prima di scomparire. Purtroppo questo verrebbe bene solo riuscendo aa disegnare in simil 3d quando ruota e senza provare sul editor grafico a mente non so se potrebbe risultare bene.
A questo punto il bordo inferiore deve essere aperto e sotto si vedrebbe 4 sprites: il cannone che ruota, il disco da sparare e il prossimo da sparare (non ho cacolato se ci starà come spazio, spero di si), e in fianco il pinguino che spara.
Per quanto riguarda la musica, già gli effetti sonori (sul telefonino) sono già molto buoni (se poi si riesci a fare l'effetto NOOOO di quando si freeza sarebbe il massimo).
In caso di spazio ci starebbe un motivetto da mettere in sottofondo.
Adesso sto scaricando la versione java del gioco, poi scarico la versione in C per telefonino, più quella originale in Perl, in modo da partire col vedere come realizzare in assembler l'algoritmo di collisione e rimozione palline che è la parte cruciale del gioco.
Nel contempo parto con disegnare la grafica (appena ho qualcosa di pronto posto il link ai sorgenti).
-
Per quanto riguarda i colori, la scelta che mi sembra più appropriata (considerando che i primi 8 colori sono da riservare come colore primario della pallina), sono:
15 di sfondo (è un grigino). Forse era meglio il 14 (che è ad esempio quello sui telefonini, ma poi l'unico carattere per il frozen sarebbe il 13, un pò bruttino).
14 colore secondario 1 per l'effetto forzen (è un azzurrino)
12 colore secondario 2 per l'effetto 3D (ombra)
Sto sperimentando come mettere l'ombra: tutto intorno (ma è un pò pesantina quando le palline sono allineate), oppure solo sul lato destro inferiore (fermo restando un cerchietto pure sull'interno).
Posterò un immagine dei più promettendi da scegliere, appena abbozzo altre 2-3 palline
-
(http://utenti.lycos.it/ice00/test/ball.png)
Ecco come appaiono le palline normali e in frozen sull'editor grafico.
L'effetto frozen però è da migliorare
-
Chiassa perchè ero convinto che fossero 12, ma in realtà sono solo 8 le palline in orrizontale (per 9 o 10 a seconda dell'implementazione in verticale).
Questo significa che idealmente con uno sprite multiplexor sarebbe già più semplice realizzare la cascata di palline quando colpite.
In ogni caso procedo con la grafica a caratteri.
Le posizioni del cannone sono ben 40 (quindi idelmente 20 sprite da specchire), il che comunque è un bel gruzzolo di bytes.
-
Alcune considerazioni tecniche, relativa al movimento della pallina
La pallina può partire con un angolo tra 0 e 180°, ma limitiamoci a vedere solo 90°, per l'atra direzione basta invertire il segno della spostamento in x.
La barra può spostarsi di 5° (18 valori), detto @ l'angolo di sparo rispetto all'asse x, abbiamo che:
Sx=V*Cos(@)*t e Sy=V*Sen(@)*t
dove V è la velocità con cui è sparata la pallina e t è il tempo di 1 frame.
Posto V=4 pixel per frame, otteniamo i valori Sx e Sy di spostamento della posizione della pallina da dare ad ogni frame.
Il problema è che tale spostamento è un numero decimale:
4*cos(50°)=2,57115044
Per ovviare a questo bisogna prevedere un tabella di valori di spostamento per correggere il movimento.
Ovviamente dobbiamo risparmiare spazio. Innanzi tutto bisogna sfruttare le relazioni tra seno e coseno per ridurre il calcolo a una sola tabella per entrambi.
Dopo di che proverò a partire con 2 valori per lo sparo e aumentare fino a 4 sperando che siano sufficenti a garantire il movimento corretto, es:
2,57 può essere approssimato da questi valori per i casi con 2, 3, 4 valori da usare:
-> 2 3 (2+3)/2=2,5
-> 3 2 3 (2+3+2)/3=2,33
-> 2 3 2 3 (2+3+2+3)/4=2,5
Ovviamente questa è solo teoria, poi bisogna vedere se il movimento sarà effettivamente coerente o l'errore intrinseco porterà a traettorie errate.
-
Non conosco questo Frozen bubble, ma dalle descrizioni direi che si tratta a sua volta di un clone di Bust-a-move/Puzzle bobble. Ben venga una versione C=64 :D
-
In effetti è la versione Open Source per Linux (e quindi piena di pinguini e ghiaccio) di Puzlle Bubble
-
Ciao ragazzi, mi sbaglio o non c'è ancora nulla del genere per Commodore 64? Qualche anno fa avevo appunto cercato il gioco e non avevo trovato nulla, quindi mi fa doppiamente piacere che la scelta per la prossima competizione 4K sia caduta su questo gioco.
-
Nel frattempo il lavoro procede nella grafica:
disegnato lo sprite della pallina come da caratteri e iniziato a disegnare il cannone dello sparo.
Dato che il cannone cambia direzione e "ruota" attorno alla pallina (ovvero non ruota sul suo baricentro, ma su quello della pallina), in uno sprite ci starebbero le animazioni di un semisfero 0-90° (8bits metà palline + 10 bits cannone), per l'altro emisfero (90-180°) i sprite andranno mirrorati e posizionato spostati in x della giusta qunatità.
In questo caso GIMP è assolutamente essenziale per disegnare il cannone che ruota: ho riprodotto il cannone e la pallina, poi applicando rotazioni di 4,5° alla volta, disegno il risultato sullo sprite.
Nota che bosigna utilizzare un palette bianco e nero (lo psrite sarà monocolore per avere maggior risoluzione), altrimenti gimp metterebbe l'antialiasing.
In caso di gioco non vincolato a 4KB, l'ideale sarebbe utilizzare 2 sprite sovrapposti e utilizzare una palette di 2 colori, in modo da avere un minimo di antialiasing.
Appena disegno il tutto, poi posto i sorgenti che ormai cominciano a crescere.
-
In caso di gioco non vincolato a 4KB
Io faccio apertamente il tifo per un gioco senza limitazioni a 4Kb :)
Le limitazioni, se da una parte costituiscono una sfida per il programmatore, dall'altra mettono in mano all'utente finale un prodotto frutto spesso di rinunce e compromessi (grafici, sonori e di giocabilita') e quindi con una cura ed un fattore di (ri)giocabilita' piu' basso.
Quali sono al momento le probabilita' che tu possa realizzare una versione "piena"?
PS
Nemmeno io conoscevo Frozen Bobble. Avevo capito che si trattava di Puzzle Bobble dalla descrizione.
-
Quali sono al momento le probabilita' che tu possa realizzare una versione "piena"?
Diciamo che ci avevo pensato alla versione full, e in effetti, una volta che l'engine di gioco è funzionante (in 4KB), l'estensione consisterebbe in:
-grafica con antialiasing per cannone, con tanto di parte posteriore (che in 4KB sarà evitata)
-animazioni di Tux quando si spara e si vince
-effetti sonori come da originale con tanto di parlato
-riproduzione su Sid della traccia originale (o quantomeno un bel brano appropriato)
-multiplexor per simulare caduta di tutte le palline (max 8 per riga)
E' chiaro che tutto dipende da quanto tempo libero avrò a disposizione (ad esempio al momento ho disegnato solo metà degli sprite per il cannone, nonostante siano settimane che ho iniziato questo task).
L'ideale sarebbe stato avere la Jum competition appena dopo la fine della minigame compo (invece sembra inizierà tra pochi giorni), così da poter lavorare in parallelo sulla versione 4K e unsize.
Comunque se qualcuno volesse nel frattempo lavorare sugli sprite per Tux, sulla musica, ecc, per una versione full... magari al momento buono potrebbero tornare utile ;)
-
Ho finito la creazione sprite per cannone e h oappena creato i caratteri per l'animazione pallina che sparisce (quando colpita). Adesso si tratta di inserire tutto il codice degli sprite e caratteri nel sorgente.
(http://utenti.lycos.it/ice00/test/anim.png)
-
Un pò a rilento, comunque il lavoro avanza.
Qui la bozza dell'arena di gioco con tanto di simil iglu come nell'originale.
Qui risulta un pò più piccola in y, dato che sto usando l'editor di LSS 2 per crearla (che usa 20 caratteri)
http://utenti.lycos.it/ice00/test/back.png (http://utenti.lycos.it/ice00/test/back.png)
modificato [IMG] in [URL] perche' l'immagine e' troppo grande
-
io conosco pure fB.
Se ci riesci sei un grande... tifo per te.
io avevo cominciato a realizzarne una versone per cellulare tramite Java ME, ma mi sono bloccato nel farmi le seghe mentali sugli algoritmi per incastrare le palline...
-
Sembra che la mia scelta dei colori sia stata poco felice: dovendo aprire il bordo per poter visualizzare la seconda pallina, il risultato è quello in figura.
Le alternative sono sue: ridisegnare tutta la grafica invertendo i colori sfondo (i due grigi) in modo da avere colori sfondo scuri.
Oppure creare due irq "abbastanza" stabili che cambiano il coloro del bordo superiore e inferiore nel modo giusto. Il timing deve essere abbastanza preciso, altrimenti ci sarebbe flichering sul colore bordo
(http://utenti.lycos.it/ice00/test/superm1.png)
-
Ho optato per il doppio interrupt e non c'è nessun sfarfallio.
Intanto ecco i sorgenti a questo link:
http://utenti.lycos.it/ice00/test/superm.tar.bz22 (http://utenti.lycos.it/ice00/test/superm.tar.bz2)
-
Evvai, gli do' subito un occhio.
-
Diciamo che ancora non c'è molto.
Aggiunto un hack per vedere se funzionano gli sprite del cannone: premendo Left del joystick, il cannone si muoverà (a super velocità) verso sinistra e poi ripartirà dal centro. Adesso mi concentro sul rendere il movimento del cannone completo.
-
Un consiglio, visto che includi nel sorgente parecchia roba, dovresti usare qualche compressore migliore tipo 7zip (che e' free al contrario di rar, da linuxaro immagino che lo vuoi evitare), o al limite tar.bzip2, dato che entrambi abbiamo il 56k risparmiamo un bel po' (43k con 7zip) ;)
-
Corretto il link per tar.bz2
Adesso (seppur veloce), funziona il movimento del mirino a destra e sinitra. Permane un problema sul mirroring degli sprite (che a volte sono scomposti)
-
Permane un problema sul mirroring degli sprite (che a volte sono scomposti)
Fai il mirror mentre l'irq e' attiva, e qualcosa - non ho indagato - interferisce con i puntatori in zp mentre esegue il mirror.
sei
jsr MirrorHiresSprite
cli
risolve, potresti addirittura spostarla piu' in alto mentre l'irq non e' ancora attiva, tanto la devi fare una volta sola, vero?
-
Si viene eseguito una volta sola, quindi si può mettere all'inizio.
Adesso mi devo concentrare sulle routine di posizionamento palline iniziali e traettoria sparo
-
Inserita la routine di movimento palla in base a direzione, con relativi rimbalzi suli bordi laterali.
Attenzione, una volta sparato, la palla non si ferma più e va oltre allo schermo.
Creata la routine di disegno dello schermo con le palline sfasate di una riga e con relativi colori.
Ci sono ancora delle imperfezioni, quali ad esempio la pallina nera che è gialla.
Dato che mi baso sulla routine del kernal per stampare stringhe, non ho ancora verificato se per disegnare i 72 blocchi sullo schermo viene impiegato un tempo superiore ad un frame (in tal caso ci sarebbero problemi, quali l'impossibilità di avere un frame rate di 50Hz.
-
La routine di disegno è ora in grado di disegnare anche i caratteri congelati e quelli della pallina che scompare. Il passo sucessivo è aggiungere tutte le animazioni dei caratteri
-
Inserita la routine che crea il frozen.
Il problema è che ho appurato che effettivamente il disegno dello schermo fatto col kernal si mangia diversi frame (direi almeno 8):
una alternativa è di ridisegnarlo solo quando modificato (e in quel frangente c'è il rallentamento), oppure riscrivere tutto per farlo da programma calcolando le posizioni da inserire (un lavoraccio)
-
Dopo vari studi su come implementare la colisione con palline (nel sorgente originale ci si basa sulla reale posizione x/y in pixel delle palline e si calcola la distanza, qui invece rapporto la posizione alla griglia in memoria 8x10), è stato inserito la prima parte di codice.
Questa testa la colisione con soffitto e le palline che stanno ai lati nella stessa riga. Purtroppo ad occhio la collsione non sembra efficace
-
Sto cercando di riscrivere la routine di disegno schermo senza ricorrere al kernal: utilizzo ancora parti del kernal per settare gli indirizzi, ma anche riducendo queste chiamate si risparmieranno poche istruzioni, che non saranno compensate da quelle che attualmente mancano per la scelta pallina (infatti ora stampo sempre lo stesso blocco).
Cercando di vedere i tempi, sembra però che si mangi poco più di un frame, per cui la soluzione sarebbe di avere due routine di stampa schermo che agiscono su 5 righe invece che 10 e chiamarle 1 si e 1 no.
A meno che non trovi una soluzione che possa ridurre almeno del 10% l'attuale esecuzione della routine.
Nota: dopo un pò lo schermo va in crash, presumo per la sovrapposizione dei frame, oppure una collisione indirizzi in memoria pagina zero
-
Ultimato il restaling del motore grafico per disegnare una riga si e una no alternativamente. Purtroppo l'utilizzo di raster è ancora abbondante e rischia di lasciare poco spazio alle routine di collisione e gestione gioco. Permane pure il crash del sistema dopo qualche secondo per il conflitto che ancora non ho individuato
-
Permane pure il crash del sistema dopo qualche secondo per il conflitto che ancora non ho individuato
abbi pazienza, ma questo non e' un abuso dello stack bello e buono?
intLoop:
inc 53280
jsr drawScreen
(etcetc)
jsr intLoop
rts
appena parte questo loop, lo stack si riempie e loopa, persino. L'rts non viene mai raggiunto. Non mi stupirei del random crash ;)
Fix:
cli; <-- mi raccomando!
intLoop:
(etcetc)
jmp intLoop
-
Infatti controllavo sempre le subroutine e mai nel main, per cui non avevo notato.
Ma il cli si trova già prima del mainLoop, quindi non dovrebbe servire in quel punto.
Nel frattempo, inserita la gestione dei livelli e per provare la routine, messo un loop (che dopo 8 livelli, prende dati "cauali")
-
Ottimo, sta prendendo lentamente forma. Piuttosto, facciamo qualcosa per il nome prima della final? SUPERM sa' tanto di giapponesizzazione di Sperma :ciapet:
-
Era da intendersi come SUPER-EMME, ma è troppo lungo. Per il nome allora sentiamo i suggerimenti ( piccolo sondaggio): non più di 6 caratteri sennò non c'è spazio.
Comunque non ho preventivato di finirlo per questa edizione del minigame, ma solo quando sarà completo (=giocabilità come da originale). Richard Bayiliss si è già offerto per le musiche per la versione full (visto che con 4KB ci arà l'engine funzionante, aggiungerci musica e qualche effetto per avere la versione full dovrebbe essere semplice
-
Per il nome allora sentiamo i suggerimenti ( piccolo sondaggio): non più di 6 caratteri sennò non c'è spazio.
icebob/icebub <- ice team bobble, ice bubble
frosty
puzbob
bobbly
-
Era da intendersi come SUPER-EMME, ma è troppo lungo. Per il nome allora sentiamo i suggerimenti ( piccolo sondaggio): non più di 6 caratteri sennò non c'è spazio.
Io ho pensato a
PILA (singolare) oppure PILAE (plurale?)
1) sarebbe palla/palle in latino
2) lo scopo del gioco è fare una pila di palloni (più o meno)
3) Visto che il gioco è italiano diamogli almeno un nome che abbia le nostre radici