Mb/superm/frozen Bav

[ice00]

 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  

[iAN CooG]

 Evvai, gli do' subito un occhio.

[ice00]

 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.

[iAN CooG]

 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)
 

[ice00]

 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)

[iAN CooG]

 

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.

Codice: [Seleziona]

     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?

[ice00]

 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

[ice00]

 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.
 

[ice00]

 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

[ice00]

 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 :
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)

[ice00]

 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

[ice00]

 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
 

[ice00]

 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

[iAN CooG]

 

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?

Codice: [Seleziona]

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:

Codice: [Seleziona]

     cli; <-- mi raccomando!
intLoop:
      (etcetc)
      jmp  intLoop


[ice00]

 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")