Sign in to follow this  

PNG vs BMP.. Too SLOW!!

This topic is 3663 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Photo Sharing and Video Hosting at Photobucket This was to compare the loading speed of BMP and PNG. The size of image file in pixel was 864 x 1782. Bytewise, BMP file was about 1.46MB, and png was about 146kb. I created each texture using D3DXCreateTextureFromFile function. Basically what the application does is, it calculates the time used to create a texture from each file. And... as you can see, PNG takes a lot longer to load into memory. I'm working on my 2D game project using D3DXSprite class. I have about 40 MB of character texture bitmaps to load. It takes from 5 to 8 seconds to load them all on my macbook (2.0GHZ dual core, 1GB Ram.) That is definitely too long for 2D RPG game. The reason I did this test was I thought I might be able to speed up the loading process wiht PNG files(which miserably failed.) Is there any faster way to load the textures?

Share this post


Link to post
Share on other sites
Have you tried the advice in the documentation

Quote:
For the best performance when using D3DXCreateTextureFromFile:

1. Doing image scaling and format conversion at load time can be slow. Store images in the format and resolution they will be used. If the target hardware requires power of two dimensions, create and store images using power of two dimensions.
2. Consider using DirectDraw surface (DDS) files. Because DDS files can be used to represent any Direct3D 9 texture format, they are very easy for D3DX to read. Also, they can store mipmaps, so any mipmap-generation algorithms can be used to author the images.

Share this post


Link to post
Share on other sites
Straight up this is not even lOOSELY supprising. PNG is a LOSSLESS file format, and it doesent store a bit per bit of an image like a BMP does. PNG must first be loaded and converted. You can try something like devIL to see if that increases time a bit , it might shave 100ms or so. Most of the time loading a PNG is compression overhead, so decompressing all your pngs together might help? Also, if your not using alpha channels, lose them.

That being said, how is 6-9 seconds really that bad? Are you REALLY planning on loading up all those images at once to start? You said you have a 2d rpg here, which im going to presume is tile based. Load the tilesets and images you need on a map-per-map basis, usualy that will bring it down to <2 seconds just fine. Dont want loading times? Work on a background loading mechanism.

EDIT: just noticed you said it was per charactor. try using devil and such first, but you also could load the resource of a sprite only when it enters proximity of the viewport, ive done that in a few of my demos, its really not that difficult at all.

Share this post


Link to post
Share on other sites
A roundabout answer is to use smaller textures, 864x1782 sounds rather large. 1024x1024 which is usually a common maximum is about 2/3 the size of the texture in your example. 256x256 and 512x512 are much more common sizes.

Share this post


Link to post
Share on other sites
Do you really need to load them all at once? Many games decrease the (apparent) loading time by loading only what they need to get started and then loading in the remaining stuff in the background during gameplay.

Share this post


Link to post
Share on other sites
Try making your textures power of two. Your hardware may not appreciate non-power of two textures, and may be converting it to power of two automatically after loading it, which would add extra time.

Otherwise yeah, use smaller textures wherever possible.

Share this post


Link to post
Share on other sites
THe only reason to use PNG is because it holds an alpha value. And the guy talking about compression is right. The data is smaller but it has to run each pixel through some math to get the right pixel color (de-compressing). Try using TGA if you want a bit extra speed with an alpha channel. TGA isn't compressed.

Share this post


Link to post
Share on other sites
Quote:
Original post by dpadam450
THe only reason to use PNG is because it holds an alpha value. And the guy talking about compression is right. The data is smaller but it has to run each pixel through some math to get the right pixel color (de-compressing). Try using TGA if you want a bit extra speed with an alpha channel. TGA isn't compressed.


Actually tga can be uncompressed or compressed. But an uncompressed tga is as big as a bmp, which is a big con to many. Personally I'd rather use a somewhat slower loading but WAY smaller compressed image than a gigantic uncompressed one.

Sangha Im, try comparing to the load time of a power of two texture before choosing formats. Compression or not, your load times seem way too long unless you have a really slow computer.

Share this post


Link to post
Share on other sites
If you don't mind lossy, go for DDS all the way.

After all you are already using HW acceleration for a 2D game, if you expect the game to run with those huge textures, you'd expect the system to have a GPU capable of loading and using DDS.

I really don't see the need for such big textures to begin with, I'd rather go vector than use those sizes in a 2D RPG game.


Share this post


Link to post
Share on other sites
Definitely use DDS. Note that DDS doesn't have to be compressed at all - DXT compression is optional, you can choose to just use a straight R8G8B8A8 surface format instead if you want - so lossy compression isn't necessarily a problem, but DDS can contain pregenerated mipmaps, which saves some time at load.

DXT compression, if you can accept the quality loss, is a great option for compression because consumer graphics cards can work with it directly - Direct3D doesn't need to decompress the file on loading it, it just hands it straight to the hardware. The result is faster loads, faster texture transfer across the bus, and less memory usage overall.

Share this post


Link to post
Share on other sites
Quick question along the same lines as the OP.

I'm using XNA currently. Because the content pipeline compiles my graphics data to its own format at build time (XNB format I believe), does it matter at all what type of image I use for texture data, since it's gonna be converted anyway?

Share this post


Link to post
Share on other sites
Photo Sharing and Video Hosting at Photobucket

ok, so I converted the 1.46mb bmp file into dds file using directx texture tool. Now the texture is 5.87 mb (omg) and it takes even longer to load. What did I do wrong? I saved it in X8R8G8B8 format.

Share this post


Link to post
Share on other sites
superpig - that was great, thanks :)

Quote:
Original post by Sangha Im
ok, so I converted the 1.46mb bmp file into dds file using directx texture tool. Now the texture is 5.87 mb (omg) and it takes even longer to load. What did I do wrong? I saved it in X8R8G8B8 format.


Hehe yup, you're doing something wrong :D

I tried an 800x600 image, here's my results:

BMP - 1,407KB
PNG - 392KB
DDS - 1,876KB
DDS(DXT1) - 235KB

DDS stores more information than the BMP format.
And DXT1 uses compression (lossy).

Share this post


Link to post
Share on other sites
Loading time for these things is usually irrelevant. It's either a one-time delay at startup or loaded in the background during the game. Loading files from disk is an inherently slow operation and will vary a lot from system to system.

If you're in a situation where the speed of this operation matters you should either a) reconsider your design or b) stop worrying about it, because it's not a problem (if it's loaded once at the start or in the background, it's not a problem.)

Share this post


Link to post
Share on other sites
As I explained, an uncompressed DDS is usually larger than a BMP because the DDS also contains the mipmaps for the BMP image, which for a BMP would have to be generated at runtime.

You've still not fixed the size of the image to be power-of-two sized, have you? You really need to do that before continuing to experiment with this stuff.

Edit: Also, if your sprites don't use translucency, only pure 1-bit transparency, you should probably be using DXT1 format instead of X8R8G8B8. Don't color-key, it doesn't work when your textures are filtered.

Share this post


Link to post
Share on other sites

This topic is 3663 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this