[zxspectrum] Re: TAP di esempio per Mouse Kempston
- From: Luca Alimandi <luca.alimandi62@xxxxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Fri, 19 Feb 2016 00:57:52 +0100
Il 18/02/2016 20:22, Enrico Maria Giordano ha scritto:
Il 18/02/2016 19:57, Luca Alimandi ha scritto:
Di quei 9158 bytes, 6912 sono dedicati allo swap della schermata prima
di "tirare giù" le tendine dei menu, per poi ripristinare tutto com'era
prima una volta chiusi i menu stessi.
Ti consiglio di salvare solo la parte presente sotto i menu stessi e
non l'intera schermata. Tra l'altro questo rallenta lo scorrimento.
Inizialmente avevo fatto così, ma mi risultava pi laborioso e lento (una
cosa è fare un solo LDIR di 6915 bytes una volta per tutte all'inizio e
restorare sempre quella parte, un'altra cosa è dover fare tanti piccoli
LDIR di 10 - 15 bytes ogni volta che scende una tendina... E poi è un
po' lungo far capire perché, in quanto la gestione che faccio dei menu,
per essere generalizzata, è un po' complessa... E poi avrei dovuto
gestire uno stack per le situazioni di menu annidati. Ma magari ci
riproverò ed eventualmente potremo fare un confronto tra le due soluzioni...
Dunque, in pratica, al momento i veri bytes di programma sono *meno di
2K*...
Solo per i menu? Mi sembra troppo lo stesso.
Come dicevo, ci sono anche altre routine, come la stampa a 64 caratteri
per riga, che gestisce anche i colori, l'inverse e il sottolineato (così
è già pronta per un eventuale utilizzo come word processing), ecc. Però
c'è sempre spazio per studiare soluzioni alternative, anche se ti
assicuro che ho già lavorato molto in modo da rendere più corto
possibile il codice, riutilizzando e condividendo pezzi del programma,
utilizzando, dove possibile, dei loop, ecc. Comunque tutto si può sempre
migliorare (almeno in generale...)
Sto però pensando di procedere con lo sviluppo passando al 128K, in modo
da sfruttare, ad esempio, la pagina RAM 5 (se non erro è già pensata
come area video alternativa), in modo da sfruttare meglio lo spazio RAM
rimanente... Ed avrei anche intenzione di inserire la gestione del RAM
Disk da GUI...
Mi sembra una buona idea ma non dev'essere una scusa per non cercare
di ottimizzare il codice. :-)
EMG
Ehi, stai parlando ad un "maniaco" dell'ottimizzazione del codice! :-D
L'idea di usare la RAM Page 5 mi è venuta proprio perché è una tecnica
che ho visto usata da molti giochi per velocizzare e fluidificare
l'esecuzione dei programmi. Non per niente nel progetto del 128K avevano
pensato di agganciarla alla zona bassa della memoria (da 16384 a 32767).
Semmai (ma è un'eventualità alquanto remota) sembra che creando un
grandissimo numero di piccoli file nel RAM Disk, lo stack che ne
conserva la tabella dei nomi e le informazioni di start e lunghezza di
ciascun file, scendendo verso il basso potrebbe cominciare ad invadere
la schermata (io non l'ho mai sperimentato, ma è quello che si legge
nella documentazione che si trova in Internet riguardo l'organizzazione
del RAM Disk). In pratica non è stato realizzato un controllo per
limitare il numero dei file in modo che lo stack non sconfini al di
sotto della locazione 23296, entrando praticamente nell'area finale
degli attributi dello schermo (ovviamente della pagina 5, ma comunque
sporcandola! :-( ).
Ma questo è un problema secondario. Come dicevo, proverò a riesumare il
codice originario, in cui gestivo la sovrapposizione come suggerivi tu
(solo per le parti occupate realmente dai menu), ma già so che mi
complicherò la vita... Dovrò valutare se ne vale veramente la pena... E
non è un fatto di pigrizia! ;-) Anzi, credo che uno sfruttamento
intelligente delle potenzialità dell'hardware sia comunque una forma di
ottimizzazione del software, almeno in certi casi... :-)
--
|_ /-\
Other related posts:
