I have a huge game with tons of textures that are not power of 2 at all, but i would really love to take advantage of the dxt compression to finally drop shipping actual png with my game.
The biggest problem i foresee in this is that resizing the textures in the pipeline would lose the original width x height of the texture…
Is that correct, or the resized texture will still keep as width-height the ones of the original png, do you happen to know if same goes with Texture2D.Bounds?
1 Like
Strictly speaking, DXT only needs to be a multiple of 4 in width and height. It is PVR that has a power of two requirement. If our content pipeline is requiring power of two for DXT, we should fix that.
Thanks konaju, i didnt know that… I still use pvrt for ios so i guess resize to power of 2 is a must anyway. Reading my own post did notice it’s unclear what i am asking… When i Read the property Texture2d.width Will it Return the original size or the enlarged size? If it returns the enlarged size How can i access the original size? Do i need to create a special pipeline For that?
Yes, you need something custom for that. For example something that handles spritesheets so you can save space.
Unfortunately i’m working on a full blown rpg now and i have over 450 textures, spritesheets are already used through the game but htey are nor sqare nor power of 2…
Then redo the spritesheets 
Hahah don’t be silly XD
If you set the GraphicsProfile to HiDef in the content project, your texture dimensions should only need to be a multiple of four rather than power of two.
That would not work on ios if i want, and i do, use pvr… as you stated above.
I also use a game editing tool that use predefined texture sizes that i cannot change( RPG-Maker).
My problem is that most of the game relies on the width and height of the objects to create source rectangles for animations (there are a fixed number of frames in width and height). The easiest path should be a custom processor that records the size of the picture between the read and the process, storing them in some public static and then before write, or after process, writes them in the tag of the texture.
The easiest path should be a custom processor that records the size of
the picture between the read and the process, storing them in some
public static and then before write, or after process, writes them in
the tag of the texture.
A spritesheet does just that. All you have to do is expand the size of your spritesheets to power of two.
Ok, let’s just drop this thing of the spritesheets, i know what they are and i cannot change my content in a way that will smartly fill a bigger texture. I might be able to do them at runtime, but this wouldn’t solve the issue with getting the original height and width of the texture after it was resized by the content-pipeline…
1 Like
If you have a spritesheet then it tells you what sprite is found where (X, Y) and how big it is (Width, Height). The width and the height is what you are looking for.
Can we expand the .xnb to store the original W/H or at least original Aspect Ratio and make the value accessible from Texture2D? Will that break .XNB backward compatibility with XNA?
sorry for the offtopic… are you using RPG-Maker and then porting to MonoGame ?
Yeah, we do all the mapping and event scripting in rpg/maker, then we use them inside of Monogame with a custom engine.
wow, that’s interesting and quite lovely!
are the file formats public or you just figured them?
Are you using XP or VX/Ace?
(sorry for the inquisitorial questions, but a RPG is something I’ve wanted to do for a looooong time 
)
thanks a lot!
While we wouldn’t do this in the core library, it could easily be done by your own custom pipeline extension that builds on the TextureProcessor.
1 Like
Well you can actually unmarshal them to objects then use reflection in ruby to get the data structure.
1 Like