Jump to content
  • Advertisement
Sign in to follow this  
Sangha Im

PNG vs BMP.. Too SLOW!!

This topic is 3908 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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!