#31 RE: Dimensione degli xnb / schifezza del dtxcompression / limiti di pubblicazione

(22-03-2011 12:28)Aster ha scritto:  tadan! beccato il problema.
fai una prova, salva l'immagine .png con magenta e con alpha. Il rapporto è come minimo 1 a 10.

Ho provato. La png tiene di meno, ma convertita xnb continua ad occupare lo stesso spazio, anche se la salvo png a 8 bit senza trasparenza. Boh ?!?!? In pratica sembra che con qualsiasi combinazione uno provi, l'xnb riporta sempre e comunque tutto al raw 32bit.
Un'immagine 1280x720 in xnb senza compressione mi viene sempre da 3601 Kb.

#32 RE: Dimensione degli xnb / schifezza del dtxcompression / limiti di pubblicazione

allora, premesso che sul piano grafico in quanto a conoscenze sono quasi arrivato al limite (purtroppo per entrambi: disegnatore cercasi), ti chiedo

hai provato a salvare .png 24bit? Che programma usi di grafica?

=> ti spiego, per il gioco che sto facendo
http://www.indievault.it/forum/showthread.php?tid=3281

l'albero è un .png 24bit che salvato con trasparenza sta circa sui 300kb (vado a memoria) mentre salvato con colore bianco circa la metà.

Se salvi uno sfondo che non ha trasparenze in .jpg (da .png) ti soddisfa?

#33 RE: Dimensione degli xnb / schifezza del dtxcompression / limiti di pubblicazione

Guarda, ho provato persino ad aprire con paint, che toglie tutte le trasparenze e a risalvare col bianco. Poi ho riaperto col photoshop e ho salvato 8bit no alpha channel. Effettivamente perde di peso, ma niente da fare quando la converte in xnb, sfonda sempre l'hard disk. 1280x720 = 3601Kb, da lì non riesco a fuggire.

Qui se vuoi vedere un pò di grafica (è praticamente tutto in parallasse su 5-6 livelli)...
http://www.indievault.it/forum/showthread.php?tid=3354

#34 RE: Dimensione degli xnb / schifezza del dtxcompression / limiti di pubblicazione

Come giaddissi sopra, XNB converte automaticamente il tutto in DXT per risparmiare VRAM... se non vuoi che lo faccia, mi sa che devi scrivere la tua Content Pipeline e farti anche carico di scompattare le PNG che hai messo nel pack, prima di usarle a runtime.


EDIT:
è più facile di come pensassi, non serve che scrivi la tua Pipeline

Citazione:TextureProcessor
A parameterized processor that outputs textures as a TextureContent Class object.

Available parameters:

Color Key Color - Any valid Color. Magenta is the default value.
Color Key Enabled - A Boolean value indicating if color keying is enabled. The default value is true.
Generate Mipmaps - A Boolean value indicating if mipmaps are generated. The default value is false.
Resize to Power of Two - A Boolean value indicating if a texture is resized to the next largest power of 2. The default value is false.
Texture Format - Any valid SurfaceFormat value. Textures are either unchanged, converted to the Color format, or DXT Compressed. For more information, see TextureProcessorOutputFormat.

Puoi configurare il texture processor per
-non resizare a PO2
-non generare le mipmaps
-lasciare il formato inalterato

In questo modo dovresti avere le tue immagini uguali uguali nel pack. Ti rimane da capire come ficcare una PNG dentro un buffer DX però.

Altrimenti c'è la Pass Through Pipeline che si limita a schiaffare i file che gli indichi dentro al pack, senza modifiche. Forse ti conviene usare quella?

#35 RE: Dimensione degli xnb / schifezza del dtxcompression / limiti di pubblicazione

Nessuna di quelle impostazioni cambia le dimensioni delle xnb che vanno a generarsi tranne che la dtxcompression, la quale però è penosa in confronto alla compressone png, in quanto genera artefatti improponibili.
Dò un'occhiata alla pass through.

#36 RE: Dimensione degli xnb / schifezza del dtxcompression / limiti di pubblicazione

Sta storia delle xnb mi ha preso abbastanza alla sprovvista... ^^;

Su 4.0 è stato introdotto questo:

http://blogs.msdn.com/b/shawnhar/archive...o-4-0.aspx

Provandolo sembra funzionare bene... Se a quanto dice il buon Shawn gira anche sulle altre piattaforme, potrei pensare di aver risolto... ?