Grafica FS2004
file:///C:/Documents%20and%20Settings/arrex/Documenti/arrexhomepage/newhome/arrexvfr/Template.html
Le Micropause



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!