I was trying different values to the framerate limiter, to match the gains I got by adding another SDL_Delay() call. The lower the framerate limiter is set, the more 'jerky' everything got. I had to go below 10 to achieve the same results. With it at 10, it responds very poorly.

Checking results in the profiler showed pretty much that after atmos.c, the next ones that ate up most of the CPU time was the drawing code. With that code (mostly) disabled, besides looking like crap if there is text still being displayed, and the menu issues, it still didn't achive a good result in lowering CPU time.

I will do some more tests though.

This patch is needed mostly for notebook users, since wasting CPU cycles eats up battery life for no good reason, but it also is good for everyone else.

Inline profiling results:

atmos.c is still a massive CPU hog
This is mainly because of:
#define MAX_ATMOS_PARTICLES (MAP_MAXWIDTH * MAP_MAXHEIGHT)

When paused, it still executes that horrible loop.
When condition for paused is check, at least we don't execute that loop anymore.
This resulted in limited savings for CPU cycles though.

However, we are still executing the mainloop & gameloop @ whatever framelimiter is set to when paused.

I think it is set to 60 for default.

Even by not doing many of the drawing routines, we are still wasting CPU cycles
when paused. I pretty much stopped all drawing routines when paused, and it didn't help much either, which does make sense when you look at how this loop operates, and just what the lone
SDL_Delay() is used for.

Tried to set the framelimiter to a lower value when paused, and restore it when unpaused, that resulted in choppy menu animation, and overall was not satisfied with the results at all.

Next added a SDL_Delay(30) call when the pause menu is up. This worked nicely, and is a huge improvement.

I also modified display3d.c to not execute some routines when paused, and came across this:
/* This is done here as effects can light the terrain - pause mode problems though */

I didn't notice a problem when I did:
if ( !gamePaused() ) // Don't bother drawing/updating when paused!
{
processEffects();
atmosUpdateSystem();
}

Can someone shed some light on what the issue is(was?)? I did NOT include that in this patch.