Durante le vacanze di Natale, ho passato il "tempo libero" a scrivere delle routines di scrolling che mi potessero servire per "spostarmi" all'interno di una ipotetica mappa di gioco.
Alla fine sono arrivato alla conclusione che sia utile impiegare 2 mappe video (che siano interscambiabili al fine di evitare spiacevoli sfarfallii, specie in sistemi non PAL) e che ci siano 2 tipi possibili di routines di scroll, ognuna purtroppo con pregi e difetti.
Ecco allora che ho pensato di descrivervi le 2 alternative perchè vorrei sapere da VOI cosa ne pensiate, se avete idee su come superarne "i difetti e limiti" o altrimenti se esistano altre possibili modalità di scrolling della mappa video.
1) ROUTINE CENTRATA SUL CARATTERE:
===========================
Ok, ammetto che il titolo non rende bene l'idea, ma non sapevo come altro chiamare questa routine.
In pratica questo tipo di routine dovrebbe essere simile a quella impiegata da Manfred Trenz nei vari Turrican I e II (vedi il mio avatar :D ).
Immaginiamo di realizzare uno scrolling da sinistra verso destra. Ovviamente dovremo impiegare il registro 53270. In pratica questo registro nei suoi 3 bits meno significativi può variare tra 0 e 7. In condizioni di "riposo", cioè nessuno scroll richiesto, questi 3 bits ci restituiscono un valore pari a 3 (ci troviamo, in un certo senso, nel punto di mezzo di un carattere).
Allorquando venga richiesto uno scroll, le fasi che si susseguono sono grosso modo queste:
- 1° ciclo raster: viene incrementato il registro 53270 (da 3 passa a 4)
- 2° ciclo raster: viene incrementato il registro 53270 (da 4 passa a 5) e viene copiata la 1° mappa video, opportunamente traslata di una colonna di caratteri, in una 2° mappa video.
- 3° ciclo raster: viene incrementato il registro 53270 (da 5 passa a 6)
- 4° ciclo raster: viene incrementato il registro 53270 (da 6 passa a 7)
- 5° ciclo raster: viene realizzato lo scroll della mappa colore, scambiate le 2 mappe video modificando $D018, e il registro 53270 viene resettato (cioè da 7 passa a 0 nei sui tre bits meno significativi)
- 6° ciclo raster: viene incrementato il registro 53270 (da 0 passa a 1)
- 7° ciclo raster: viene incrementato il registro 53270 (da 1 passa a 2)
- 8° ciclo raster: viene incrementato il registro 53270 (da 2 passa a 3)
Ovviamente lo stesso procedimento andrà applicato, in maniera inversa, per uno scroll da destra verso sinistra; inoltre con le opportune modifiche (cioè impiegando il regsitro 53265) potremo realizzare delle routine di scrolling verticale.
VANTAGGI
- Lo scroll è straordinariamente fluido, senza nessun tipo di sfarfallio!
- (è la mia preferita; ops, non è un vantaggio)
SVANTAGGI
- Sono possibili solo 4 DIREZIONI. In pratica le 4 direzioni diagonali verrebbero "realizzate" a zig zag (esempio: dignonale in basso a destra --> scroll in basso, poi scroll a destra, scroll in basso, poi scroll a destra e così via) a meno di non creare altre ulteriori 4 routines appositamente per le diagonali (il che significa sprecare tanta bella memoria che potrebbe essere usata da un gioco per altro: esempio blocchi, caratteri, mappa).
- Durante gli 8 cicli raster che ho descritto NON si potrebbero poi eseguire altri scroll (una volta che uno scroll comincia deve finire prima che possa avvenirne un altro, il che significa dover attendere 8 cicli raster: tanto tempo sprecato?)
2) ROUTINE "FREE-DIRECTIONAL"
======================
Anche in questo caso mi scuso per il terribile nome di questa routine.
In pratica volendo ricollegarci all'esempio fatto sopra di uno scroll da sinistra verso destra, in questo tipo di routine (impiegata da MW?) non ci interessa affatto il valore contenuto nei 3 bits meno significativi di 53270. Semplicemente:
- 1° ciclo raster: non appena il valore in essi contenuto diviene pari a 6 copiamo la 1° mappa video nella 2° traslata di una colonna
- 2° ciclo raster: incrementiamo 53270 a 7
- 3° ciclo raster: eseguiamo lo scambio delle mappe video, scrolliamo la memoria colore, azzeriamo i 3 bits di 53270.
VANTAGGI
- Possiamo spostarci liberamente in tutte e 8 le direzioni usando solo 4 routines di scroll (notevole risparmio di memoria)
- Minore impiego di cicli raster
SVANTAGGI
- in soli 3 cicli raster e per di più uno di seguito all'altro dobbiamo far fare alla CPU un casino di cose, cui dobbiamo aggiungere nel caso di un gioco, altri fattori (sprite multiplexing, controllo joystick, enemies, musica, ecc ecc) per cui "penso" sia possibile la comparsa di tremendi sfarfallii da "sovraccarico".
- teoricamente (in realtà tutto quello che scrivo deriva da mie supposizioni) in un eventuale gioco si noterebbe un rallentamento ogni volta che si verifica uno scroll del video (quindi paradossalmente avremo un gioco fluido che rallenta quando c'è uno scroll, che ridiviene fluido finito lo scroll, che rirallenta... e così via)
Io ho pensato 1 soluzione per ciascun tipo di routine che ne riduce notevolmente i difetti di entrambi, ma sono curioso di sapere da qualcuno di voi:
- le vostre idee in materia di "scroll".
- alternative a queste 2 ipotetiche routine che vi ho scritto
- insomma, consigli.
Io ho costruito le 2 routine di cui vi parlo. Funzionano tutte e 2 alla grande: ma ovviamente temo che vadano in crash non appena inizierò ad inserire i sopracitati sprite multiplexing, musica, controllo collisioni, punteggi, controllo ingresso uscita nemici, paralasse ecc ecc.
Spero che qualcuno di voi risponda (anche dolo per dirmi "non ho capito bene..."). Almeno posso decidere se devo continuare su questa strada o intraprenderne una nuova.
Grazie per l'attenzione.
P.S.
Mi scuso in anticipo per eventuali errori e per eventuali "frasi incomprensibili".
P.P.S.
Molte delle cose che ho sviluppato sono frutto della lettura dei rants di Lasse Öörni.
