All'epoca dello sviluppo di
Flight Simulator 2002, gli sviluppatori si sono accorti che il
meccanismo di caricamento di texture sulla scheda video, di
caricamento dal disco fisso e quello di elaborazione
richiedono una grande potenza di processore e sono i
responsabili principali delle famose micropause che
affliggevano FS2000 e FS98. Si tratta di cali improvvisi nel
frame rate istantaneo che di fatto rallentano per un attimo la
fluidità della simulazione.
Il problema è stato alleviato usando diverse tecniche.
Anzitutto tutti i caricamenti da disco fisso di qualunque cosa
(tranne che dei suoni) avvengono in modo asincrono, ossia
quando il processore ha un po' di tempo a disposizione. Questo
è molto comodo quando si ha una CPU multi core, in
quanto questa parte viene totalmente gestita dal secondo core
in parallelo e non causa ritardi.
Si è poi identificato un secondo meccanismo che portava
alle micropause: il caricamento di texture dalla memoria
principale alla memoria video; questo intasa la banda del bus
AGP o PCI-X impedendo di passare i dati dei vertici e quindi
creando un improvviso rallentamento del frame rate. L'occhio
umano, abituato dopo un po' ad una certa fluidità, nota
benissimo i cali di frame rate. Da questo è nata l'idea
di bloccare il frame rate ad un certo valore massimo, come
abbiamo già discusso. Quando la CPU/GPU hanno potenza
sufficiente per generare un frame rate eccessivo, questa non
viene sfruttata. Il frame rate bloccato permette di notare
molto meno gli improvvisi decrementi di velocità e
quindi dà l'apparenza di un simulatore più
fluido.
Se tutto questo non bastasse, la quantità di texture
caricabile per ogni frame è limitata: per ciascun
frame, prima del passaggio dei dati dei vertici, possono
essere caricati soltanto certo numero di byte. Tale numero
viene regolato da un parametro che si chiama TextureMaxLoad e
che va aggiunto alla sezione [display] dell'fs9.cfg (non
è presente di default). Il suo default è 3, il
che significa che per ogni frame possono essere caricati sulla
scheda video soltanto un numero di byte equivalenti a 3
texture di landclass (che pesano circa 43 kB l'una). Per cui
il caricamento massimo è limitato a circa 129 kB per
ogni frame; nota che 129 kB è il limite di caricamento
di TUTTE le texture, siano esse di landclass, aereo, nuvole,
oggetti vari ecc ecc... Qualora si usi la limitazione al frame
rate (e solo in quel caso), questo valore massimo può
variare: il valore di TextureMaxLoad (ovviamente convertito in
byte) è moltiplicato per il parametro
texture_bandwidth_mult, che si trova nel file di
configurazione, e diviso per target frame rate.
Facciamo un paio di esempi.
Supponiamo di avere il multiplier a 40, il frame rate bloccato
a 30. Allora possiamo caricare 172 kB per ogni frame. Se siamo
a 30 fps, in un secondo carichiamo fino a 5 MB di texture.
Supponiamo di proporre il multiplier a 400 e mantenere 30 fps
di blocco e velocità. Significa che, per ogni frame
possiamo caricare 10 volte più di prima. Quindi 50 MB
al posto di 5. A titolo di esempio lo scenario di Roma Lago
conta circa 150 MB di texture... significherebbe caricare in
memoria video tutto lo scenario in 3 secondi.
Ma il simulatore di che banda ha bisogno? Meglio 50 MB o 5 MB?
Beh, poiché si vola ad una velocità tutto
sommato contenuta rispetto alla varietà di texture da
caricare e poiché le texture che si usa sono alla fine
sempre quelle, allora 5 MB al secondo sono in genere
più che sufficienti, anzi, sovrabbondanti. Quando si
inizia a caricare uno scenario nuovo, allora serve più
banda, tipo 20 MB al secondo. Oppure uno aspetta 4 secondi e
si accontenta di vedere gli oggetti non texturizzati per quei
4 secondi; siccome i medesimi in genere sono molto lontani,
è un'approssimazione assolutamente tollerabile.
C'è di peggio. Settando ad esempio il multiplier a 400,
come visto, è possibile caricare fino a 1.7 MB per
frame. Supponiamo di dover caricare 2 MB. Il lavoro
sarà portato a termine nei primi 2 frame. Con il
moltiplicatore a 40 invece il lavoro richiede 12 frame circa.
Ma non sarà manco trascorso un secondo! Questo cosa
vuol dire? Che abbiamo appesantito a sproposito i primi 2
frame (e quindi li abbiamo rallentati) al posto di dilatare il
lavoro in un tempo più lungo. Abbiamo creato una
possibile micropausa. Per cui aumentare quel valore fuori
dalle impostazioni di default, rischia per lo più di
creare micropause senza dare evidenti benefici. Siccome, come
vedremo, il simulatore elabora al massimo una texture per
frame, può essere utile sono quando si hanno texture
molto grandi, oppure quando la memoria video è scarsa e
quindi è necessario caricare e ricaricare di continuo
texture già elaborate. Nel caso contrario, meglio non
giocare con quel valore; per caricare più texture la
scelta migliore è paradossalmente aumentare il frame
rate!