I had a look at the XNA version of the Torque 2d engine and noticed that it converted 4mb worth of png files into over 60mb of xna files; Is this a Torque issue or xna as its a massive increase and would make releasing any games online a virtual impossibility.
TorqueXNA
Hot Topic
- Add Framework?
- Major Game and GameComponent class refinement ideas
- error C2061: syntax error : identifier 'IDirectXFileData'
- Calculating normals for large mesh with no vertex to triangle info
- Creating a render target texture with alpha?
- Converting to and from a view matrix.
- Spacewar game does not compile
- Putting a hole in a sprite
- Rants on XNA 1.0
- Visual Stuido pro
Game Technologies
- SWM Model Component
- DirectX 10-Vista
- texture coordinates?
- how to draw other language type in the XNA?
- XNA GSE and Vista
- Problem with "How To: Animate a Sprite" Tutorial
- Sprite is not transparent
- What tools do I need to write sprite-based games?
- Microsoft's future policy for redistributing Xbox 360 games?
- Tint programatically a Texture2D with another Texture2D
TorqueXNA
yhong
DearME
Going from 10 to 87 megabytes suggests that the output files are being stored in 32 bit uncompressed format, which is obviously going to take up a lot of space. That is by no means neccessary, though, for instance by default the content pipeline will choose the DXT1 compressed texture format for textures.
Directly reading game data from formats like .png isn't such a good idea, especially on Xbox, because those formats need a lot of processing before they can be rendered by a 3D graphics card. Xbox isn't so good at doing that kind of processing, so if games read data directly from these formats, XNA titles would all end up with terribly slow load times.
Adjustedrace
The default processor for non-model (e.g. sprite) textures doesn't use DXT. I just converted my previously mentioned texture to DXT1 and got a 512KB dds file. The same file converted by the content processer to xnb is 4MB.
Arnie Rowland
rankorn
If you want to compress your textures, use the ModelTextureProcessor, which does DXT compression.
Also, bear in mind that size is not the only important characteristic to measure here. Which would you prefer: 1 meg of data which takes 10 seconds to load, or 2 meg of data which can be loaded in less than a second Sometimes it can be worth doing a bit of precalculation and sacrificing a bit of disk space, if that makes our games run fast and not have to sit around for ages on the loading screen.
we3dyz
I think you missed my point. We aren't converting them to any format. We are using the default Texture processor provided with XNA. If it chooses a compressed format by default, then it has chosen a poor one. My .pngs total 6MB if stored as 32-bit uncompressed bit data. One of my images is basically 50% black and 50% transparent and would be 4MB if stored as pure 32-bit uncompressed data. The .xnb file is 4MB. That's not very compressed.
Saman Attarian
It's not Torque that's doing it. It uses the default Texture (Sprite, 32bpp) content processor for images.
I have a non-Torque XNA project with 116KB of .png images. The converted .xnb files total 6MB. That's rediculous. We shouldn't have to create our own custom processor just to reduce the size of image files that we already reduced by using .png in the first place.
SharePointing
If you're using the 32 bit one, then obviously you won't get any compression. If you are concerned about size on disk, it's easy to change this to use the DXT processor.
My point is that the content pipeline is optimised for loading speed, rather than for size on disk. That means we store data directly in the same format that the GPU wants to consume, so we don't have to do any slow conversions in the loading code. This limits our choice of compression formats to the ones that are actually supported by current graphics hardware, which is unlikely to give such good results as formats like PNG or JPG that are free to do anything they like.
It sounds like you disagree with the tradeoff we made here. Is saving disk space more important for you than getting fast loading times
davfddfed
This brings up an important point. Reading through the forums since the beginning of beta, I've noticed that file compression is a common complaint. Both in the mandatory use of WAV files and on the conversion of PNG to XNA files.
In case anyone hasn't noticed, Microsoft prefers to use their proprietary file types (.bmp, .wav, .x, etc). But most people use other types (.png, .mp3, etc) for various reasons, file compression being one of the biggest in my mind. I don't think it's that people have something against MS and want to use another file type to spite them, its just that the other types are superior in certain aspects.
Going with Microsoft's admirable turn towards a customer-centric mindset, I wouldn't be surprised if this is already on the "to-do" list. Microsoft did an amazing job with the 360 in finding out what the customer wants and putting it all together in one package, but it seems things like WAV and BMP compression and features have been neglected for a long time.
Can someone from MS comment on whether or not the file compression/size issue is going to be addressed in a future version
Petru66
jules_newbie
zhihao
This is obviously still not as good as the compression ratios you can get from non-hardware-oriented formats, but it is the smallest format directly supported by 3D graphics cards.
MrZap
David d48701
Hey Jim,
I think he means releasing on XBLA... since there is a limit of 50MB on Arcade games...