My 2D game (C#) has 2 characters with 3500 unique frames each. On any scene, I could have as much as 100 characters displayed on the screen. I tried loading all my dds (DX1) frames using textureloader and my memory usage jumps to just over 100MB. I then tried putting my dds files into 27 large texture sheets (2048x2048) and get about the same memory usage. Next, I tried loading the dds frames I needed for the scene and then dispose of them after the scene, however, it takes x amount of milliseconds to load a texture, giving me around 5 FPS. I then tried doing the same thing, but load all the textures with it's own thread, which created a huge CPU spike (makes sense). A C++ game uses these same 7000 (bmp format) files in an archive and is able to produce low CPU and 45MB memory with WinG. http://en.wikipedia.org/wiki/WinG I was told to create a few large texture sheets and only load the textures sheets I needed for the scene, however, it is easily possible that I will need all sheets for the scene. What do I do? Is there a faster way of loading textures? (note: I have permission to use these graphics.)

If I did away with Direct3D and went with DirectDraw, I could reduce my graphics to 100x100. Maybe that would help..

Three small points / questions.

1. Is 100MB a problem? Thats not that much memory these days.
2. What are you doing the graphics with XNA or SlimDX?
3. Have you checked if you are creating MIP levels automatically when loading the textures ie you may have multiple sizes of each texture. (On most texture loaders if you use 0 it creates a full set of mip levels)

Quote:Original post by kal_jez
Three small points / questions.

1. Is 100MB a problem? Thats not that much memory these days.
2. What are you doing the graphics with XNA or SlimDX?
3. Have you checked if you are creating MIP levels automatically when loading the textures ie you may have multiple sizes of each texture. (On most texture loaders if you use 0 it creates a full set of mip levels)

Thanks for your reply :)

1. Not really, but if a C++ game can do it in 45MB, I must be doing something wrong..?

2. Microsoft DirectX SDK (November 2008)

3. OMG, you're right! I replaced 0 with 1 and was able to bring it down to 87MB and get greater loading speeds.


Thank you so much with that. You're awesome!

The only thing I can think that would cause such a disparity is that the WinG program didn't load everything up front and instead did it as absolutely necessary, keeping loading to a minimum and memory usage down. That explanation would make loads more sense considering the time frame WinG was popular, memory didn't grow on trees like it does now. Now we can just throw everything into the fryer and not really worry about memory.

Quote:Original post by Flimflam
The only thing I can think that would cause such a disparity is that the WinG program didn't load everything up front and instead did it as absolutely necessary, keeping loading to a minimum and memory usage down. That explanation would make loads more sense considering the time frame WinG was popular, memory didn't grow on trees like it does now. Now we can just throw everything into the fryer and not really worry about memory.

Makes sense. Do you think WinG had a way to load bitmaps much faster?

I tried using bitmap.fromfile and was able to load 100 BMPs (100x100) in 100 milliseconds or less, allowing me roughly 10 FPS. 10 FPS shouldn't be noticable, however, I could increase that number with multithreading..

<<3. OMG, you're right! I replaced 0 with 1 and was able to bring it down to 87MB and get greater loading speeds.>>

With large 2048x2048 sheets, I was able to bring it down another 8MB (79MB).

Well, loading image data has pretty much always been something the developer needs to do himself, and simply supply the raw pixel data to whatever interface (this was true even in DirectX until D3DX came around making it simpler)

Are you using GDI+ or something to render your game? (I ask because you mention Bitmap.FromFile) or are you using XNA?

Either way, should you decide to load any image data while executing your gameplay, I would strongly urge you to do it in another thread, otherwise your game will stutter horribly. To be honest though, since memory really isn't a problem, it would probably just be worth it to take the 80-100mb path and keep everything loaded at startup with the little extra loading time. You're just going to complicate things more for yourself when the memory usage isn't really a problem in in the first place by making premature optimizations.

Quote:Original post by Flimflam
Are you using GDI+ or something to render your game? (I ask because you mention Bitmap.FromFile) or are you using XNA?

No. I was considering Bitmap.FromFile had I made the change to DirectDraw. I'm using Direct3D for rendering, since my computer does not support XNA (pixel shader 1.1+).

Quote:Original post by Flimflam
To be honest though, since memory really isn't a problem, it would probably just be worth it to take the 80-100mb path and keep everything loaded at startup with the little extra loading time. You're just going to complicate things more for yourself when the memory usage isn't really a problem in in the first place by making premature optimizations.

You're absolutely right. I am going to take your advice. Thank you for all your help. :))

Load up all the textures into a compressed format ( vector quantization and simple RLE, etc.. ) which gives u reasonable compression ratios but more importantly super fast decompression. That's how the games of old stored their bitmap animation data, since they couldn't load it off the disk fast enough for real time ( and still can't ) random realtime playback.

See this link :

http://www.gamasutra.com/features/20010416/ivanov_01.htm

It's possible to get down to 3 bits per pixel, or 10:1 compression, so raw 7000 128x128 (~432 megs) can be compressed down to ~43 megs which correlates closely with the original C++ application.

This is just my guess.

Good Luck!

EDIT: It is better and simpler now to just load it all in memory. That's the best way, imo too.

-ddn