Sto ponendo questa domanda perché non ho trovato una risposta definitiva ad essa.
Consentitemi innanzitutto di dire alcune cose sul gioco e su ciò che ho già fatto. Il gioco sarà un set RTS in un mondo generato proceduralmente usando il rumore Simplex. Il mondo è composto da blocchi di dimensioni 16 x 16 fatti di sprite di 64 x 64. Sono riuscito a caricare e scaricare blocchi in modo dinamico, il che funziona bene. Il mondo assomiglierà un po 'a Rimworld, quindi dall'alto verso il basso con diversi strati di folletti (terreno prima, folletti di transizione, alberi, decalcomanie ecc.). I mondi appena generati possono contenere entità che possono influenzare l'ambiente (ad es. Un villaggio che è diventato una città) e quindi il pezzo. Sono sicuro che questo può essere calcolato usando una sorta di funzione, ma è qualcosa da prendere in considerazione.
Il problema principale che ho è quando eseguo lo zoom indietro, vengono disegnate sempre più tessere che influiscono gravemente sulle prestazioni. A circa 30000 sprite, la sezione di disegno richiede 8 ms, che è la metà di ciò che è necessario per funzionare a 60 FPS. E questo è solo il terreno. Sto usando atlanti di texture per limitare i conteggi dei sorteggi (30000 sprite disegnati in 6 conteggi).
L' obiettivo è riuscire a rimpicciolire dal livello di città / villaggio / città fino a poter vedere un intero paese. Questo deve essere fatto in modo dinamico (ad es. Non facendo clic sull'icona di una minimappa, ma semplicemente scorrere indietro come in Supreme Commander).
Ho letto molti articoli su questo problema, ma non ho trovato o visto un chiaro esempio di dove funzionerebbe. Ecco un elenco di tecniche che ho scoperto che dovrebbero funzionare:
- Rettangoli sporchi, come descritto qui , dove si disegna solo roba nuova e si tiene il resto nel backbuffer. Questo ha molto senso, ma non ho idea di come implementarlo in Monogame.
- La mia scelta preferita: fare ampio uso di RenderTarget, come descritto qui , dove si disegna su un RenderTarget e quindi lo si salva come trama. Nel mio caso un pezzo 16 x 16 composto da 64 x 64 creerebbe una trama 1024 x 1024. Dubito davvero che funzionerà in termini di prestazioni, ma il risultato consisterebbe in trame molto dettagliate ed è anche ottimo da usare considerando il fatto che la maggior parte è statica (terreno / alberi ecc.) E non cambia molto. Ma questo significa anche che ogni volta che viene apportata una modifica a un blocco, Texture2D deve essere modificato utilizzando SetData, che da quello che ho sperimentato richiede una notevole quantità di CPU. Tuttavia, se le trame fossero 16 x 16, potrebbe effettivamente funzionare e ridurrebbe anche la memoria e l'utilizzo del disco.
- Finisci le trame specificando SourceRectangle in SpriteBatch. Per grandi praterie / oceani questo è un vantaggio, poiché viene disegnato solo uno sprite. Tuttavia, per terreni dettagliati con colori e sprite diversi mescolati insieme (biomi e transizioni di biomi) temo che non farà una grande differenza.
- La mia soluzione, che compromette i dettagli, era quella di utilizzare una tessera bianca standard 64 x 64, dargli il colore delle 4 tessere circostanti e quindi ridimensionarla in modo da coprire le 4 tessere precedenti. La differenza qui (oltre alla piastrella che ha un colore semplice) è che il paesaggio è visibilmente cambiato. Vorrei anche ricordare che le foreste devono ancora essere disegnate individualmente poiché non sono perfettamente quadrate.
Se qualcuno ha qualche idea su come affrontare questo problema, anche se ciò significa compromettere determinate cose (come i dettagli o l'utilizzo di 16 x 16 sprite), mi piacerebbe ascoltarlo.