Dunque, se non ti annoio troppo, io attualmente sto usando due strategie di hiring (alias due "modelli World": un tipo P (Partition) e un tipo R (Rectangle). Il tipo P effettivamente usa una Hires Map già inizializzata come suddivisa in più "parti" ed io effettivamente prelevo ora una parte ora un'altra. Ho dovuto "inventarmi" la seconda strategia perchè se il centro del campo puntato P capita sul bordo della sua partizione mi ritrovo il campo in dettaglio spostato rispetto alla linea visuale (è antipatico e inevitabile). Volendo mantenere il campo in dettaglio centrato sulla retta View della mia Camera devo "spostare" la partizione di quel tanto che basta, ma con partizioni "fisse" questo non posso farlo e allora devo ricorrere a partizioni "variabili" e cioè appunto a Rectangle prelevate con Graphics.Draw dalla HiresMap. Questo mi permette di prelevare, sempre e comunque, il Rectangle centrato su P ma come ben tu capisci non ho più partizioni fisse costruite all'inizio una volta e per sempre. Questo metodo va molto bene, non ha praticamente difetti se non quello (ahime) che per evocare graphics.Draw devo avere in memoria la HiresMap... allora sto prendendo la terza via: lascio la Hires su disco ed eseguo un graphics.Draw sul suo file di bytes (che io chiamo raw), tanto funziona lo stesso. Al modello non interessa tanto l'immagine quanto i dati numerici di colore che poi modulano le altezze delle montagne e dei crateri di quel mondo. Se voglio che il mio portatilino funzioni come se fossi alla NASA devo fare così... e come premio non ho limiti sulle dimensioni delle png se non eccedono il mio HD, e posso lavorare anche senza immagini tanto partendo da piccoli dati byte le immagini le creo io. Unica seccatura: per creare il raw di una 10000x10000 il portatile ci mette una notte intera, ma tanto io dormo....a meno che non decido di usare bmp per le heightmap e mi riservo le png per le textures (che spesso devono essere trasparenti) e le bmp sono già in raw....
Rispondi quotando