PocketMatrix

My current game project is nearing completion and I'm just doing final debugging and optimizing and all that jazz.

I am loading A LOT of images, and it's making startup time a lot longer than I'd like.

I believe all the calls to imgdecmp.dll are going slower than I'd like, and my question is this...

Is there a way to statically link the DLL to my executable (let's ignore the question of whether it's a good idea or not)?

If so, does anyone suspect that WOULDN'T make much of a difference in speeding things up?

Actually, one other question...

Has anyone benchmarked to see what the difference is, if any, between loading 10 10K images and 1 100K image? I ask because the other option I have is of course combining images and blitting sections. I didn't do that initially because (a) it's easier to work on the graphics when they are individual files and (b) I suspected blitting sections rather than a whole surface might affect performance. I didn't do any testing to verify this (yes, I SHOULD have!), it's just a suspicion.

Thanks all!

Well, you can always write your own imageloader. Shouldn't be that hard.

Hmm.. I might have said to much. The JPEG format was a bit more complex than I first though, but have a look at this library if you don't like the imgdecmp.dll.

http://www.aoi.it/midcximage.html

It's called CxImage and works for all platforms (and is freeware). Despite its name, it is NOT an MFC class. And it works for most common formats.

I havn't found a benchmark of the IMGDECMP.DLL but according to MSDN "Performance is very good.". But coming from MSDN this doesn't mean anything.

Check this thread where Sbl talks about the overhead in GapiDraw of using IMGDECMP.DLL to load images.



Pam

I tried to load 5 small jpgs on my E-125 while GameInit and something interesting occured: I got 5 jpg images a sort of "progressive jpg format for internet " it was 5 BIG PIXEL-LIKE SQARES. I tried also gifs the same size and they are OK!

Now I use this way - each time I call GameLoop I load ONLY one jpg
- it works.(I use it also for gif's)

I finally had time to do a little unscientific benchmark...

I took the title screen for Invasion: Trivia, a colorful 240x320 PNG file, 256-color optimized pallete, no transparency, non-interlaced . It's 40K.

I then took that image and broke it down into twelve 80x80 tiles and saved it in the exact same format as the original. The total size of all twelve files is 42K, so it's a reasonable comparison I think.

I wrote a simple test program to load all twelve individual pieces and blit them (although the fact that they are displayed doesn't matter for the sake of this discussion). I recorded tick count using PocketPC:GetTickCount() before I began loading the images, and immediately after. Obviously, the difference is how long it took to load them all.

Here are the results on my stock Casio E-125, all are in milliseconds of course:

1120, 1114, 1105, 1116, 1105, 1120, 1112, 1116, 1109, 1114
Average: 1113

Now, I changed the program to just load the one single image and blit that. Here are the results for that:

829, 828, 835, 830, 834, 833, 830, 830, 833, 828
Average: 831

So, while I admit I absolutely suck at math, if I'm even close to right, it seems reasonable to say that for a single image of size equal to the total size of a given number of smaller images, the load time should be around 25% better for the single image than all the individual images combined.

I think it's also reasonable to assume that as the number of individual images goes up, the percent difference will increase for the single image as well.

I also did the test with the files as JPG's. JPG's of course can't be palettized, so one would assume they take a bit longer to load (I should be fair and do a 24-bit PNG...) but in any case, here are the results for the 12 individual loads:

6452, 6439, 6428, 6439, 6437, 6440, 6441, 6439, 6438, 6438
Average: 6439

For the single file:

6111, 6112, 6112, 6114, 6115, 6117, 6113, 6114, 6115, 6116
Average: 6114

Looks like about a 6% improvement.

So, what I *think* we've learned here is actually two-fold...

(1) Most importantly, loading a single image is faster than loading a number of smaller images who's size equals the single image.

(2) Use PNG's!

Again, I did not compare a 24-bit PNG to JPG, it could be that that comparison would favor JPG. In addition, I didn't even bother with GIF, I view it as a dead format unless you need animated images, which doesn't apply to this discussion.

Anyone see any obvious flaws with my thought process here? I believe I remember Thierry stating that blitting a section of an image should be just about as fast (or maybe just as fast?) as blitting an entire image, which does stand to reason... That would have been my only reason for not using composite images... With that in mind, it seems clear that my original question about load times is answered by stating that you should combine as many images as possible into a smaller number of large images and just blit sections of it, and make sure you use PNG's, most definitely if you are dealing with a 256-color palettized image.