High memory consumption Trouble

#1 Well, uncompressed images take up a lot of space. Convert all your GIFs/PNGs/JPEGs to uncompressed BMP and
see how much the total is. Then consider the possibility that the current audio functions might load the
uncompressed Ogg files into memory, rather than properly stream small chunks :/

#2 Hmm ok ronny i'll try your idea , how about your game ? does it take a huge memory usage too? , i try the fish demo tutorial and it used up 150 mb
wowwwww amazing

#3 I've just started using TGB, but I've done a lot of low level performance work at my real job. I haven't profiled the performance of TGB because I don't care about performance at this point, but from my experience I can tell you what's probably happening.

I bet if you create a game with just a single small sprite attached you'll see over a 100 mb used. Most likely a big chunk of that is from the engine and a big chuck from the OpenGL driver.

The thing is that most of that memory isn't accessed very often and modern operating systems like XP do a very good job at managing virtual memory. Ideally every app would use the minimal amount of memory, but in the real world if an app doesn't use memory it allocates then performance isn't going to be hurt. The number one rule of fixing performance is to spend time improving those things that slow your app down.

#4 If running on Linux, you have access to such tools as Valgrind to look for memory leaks,
and it reports semi-accurately on most memory. Running the editor tools with the checkers demo,
which doesn't have many images, uses around 35MB.

The engine itself doesn't use a lot of memory. The screen(s) will use (width x height x 3) bytes on a
24-bit display. I'm not sure if TGB operates with one or two canvases, but that's usually the largest
single chunk of memory. 800x600 = 1.4 megs, 1024x768 = 2.3 megs and so on. But sound and
tiles/textures are where most of your memory goes.

If there isn't a way to get memory usage statistics in TGB, that should be made a resource :)
Could help people keep an eye on their habits, like loading fully when streaming is better.

I can't think of any optimisations other than hacking the C++ source to only unpack images as they
are drawn, rather than storing the uncompressed version. Perhaps adding S3 texture compression
is an alternative, but both seem like major undertakings.

You might also notice that virtual memory/cache usage could affect total memory used.
The ordinary memory listings don't tell the whole story. Remember that the screens you see
are allocated in graphics memory on your graphics card, not just in RAM, and with double buffering,
that's one screen on and one off the card that's counted towards totals.

If the GG folks had a full answer for this, I'm sure it would be a FAQ of its own :)

#5 If you use windows you can find lots of different tools to track memory leaks (like purify). However I find the following code works good enough for for finding and fixing almost all memory leaks. This only works with visual studio 2003 or 2005.

static void EnableMemoryLeakDetection ()
{
   // Retrieve the state of CRT debug reporting:
   uint32 nCurrentDbgFlag = _CrtSetDbgFlag ( _CRTDBG_REPORT_FLAG );
   
   // Append custom flags to enable memory leak checks:
   nCurrentDbgFlag |= _CRTDBG_DELAY_FREE_MEM_DF;
   nCurrentDbgFlag |= _CRTDBG_LEAK_CHECK_DF;

   // Update the run-time settings:
   _CrtSetDbgFlag ( nCurrentDbgFlag );
}

// Then add the following code to main or dllmain
// This mode of memory tracking never frees memory so you can exceed the 2gb virtual space easily
#ifdef _DEBUG
   EnableMemoryLeakDetection();

   // If you want to figure out where a memory leak reported by the CRT debug output
   // comes from, uncomment the _CrtSetBreakAlloc call and give it the ID of the memory
   // block. Example:
   //
   //   {127} normal block at 0x003F6968, 12 bytes long.
   //   Data: <  ?   ?     > C0 A1 3F 00 C0 A1 3F 00 CD CD CD CD 
   //
   //_CrtSetBreakAlloc( 127 );
#endif

#6 There are three really easy ways to get rid of a huge amount of memory overhead in TGB. First, use GuiChunkedBitmapCtrl instead of GuiBitmapCtrl in your guis. If you reference large images, you'll eat that chunk the second you exec the gui with GuiBitmapCtrl. Second, use streaming audio by setting "isStreaming = true" on your audio profiles (you'll need the source to fix the streaming audio memory leak though... check the report bugs forum for source). Third, go through your datablocks.cs and set preload="0" and allowUnload="1" on all your t2dImageMapDatablocks. Also, go through your datablocks.cs and make sure you're not referencing anything you're not using. These are generalizations, but start there and see how much you gain. Beyond these you'll have to start profiling your memory footprint.

#7 Excellent advice! Cheers :)

#8 I used to convert images with the help of other 3rd party tools. Are there any differences between them?

#9 @arronlee - Please stop reviving old threads with a topic of image processing. Final warning.