My game take too much CPU!!

Moderator
Posts: 508
Joined: 2002.09
Post: #1
Allright, I am working on my first finished, SDL based, game and I'm nearing completion but I have just found something.

My game can take up to 80% CPU on a G5!! That's quite unacceptable. Ofcourse there is a bunch of for loops and so on, but I don't think that's why it takes so much CPU.

I think I will need to write some time functions to prevent my game from running too fast on fast machines and too slow on slow machines. But I don't know how to do this in SDL.

Can somebody help me out. You'll all be enlisted in beta testing Smile

Thanks
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #2
employ a timer that only runs at 60 or 120fps
Quote this message in a reply
Moderator
Posts: 508
Joined: 2002.09
Post: #3
Would that be better than using the delay function?
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #4
Sync to VBL so your draws only occur as fast as they need to.

Get real familiar with Shark to see what's taking up all the time.
Quote this message in a reply
henryj
Unregistered
 
Post: #5
What does your profiler say is using up all the cpu?
Quote this message in a reply
Moderator
Posts: 508
Joined: 2002.09
Post: #6
I didn't use any profiler, I just used top to check the CPU %. If you wonder why i was using top, well I was tracking down a memory leak, which I then found with MallocDebug Smile

Isn't Shark one of the CHUD tools? I think I better get those.
Quote this message in a reply
Moderator
Posts: 508
Joined: 2002.09
Post: #7
OK, after checking with Shark, it seems my game takes most of it's CPU power from the blitting functions. I have 3 of those to blit parts of the screen.

In some of these function I use double buffering, could this be the problem?
Quote this message in a reply
Moderator
Posts: 437
Joined: 2002.09
Post: #8
Sounds like you are making progress, but I will just point out that if a full-screen game uses 80% CPU, possibly noone will notice or mind. They are more likely to mind if it runs in a window.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Moderator
Posts: 508
Joined: 2002.09
Post: #9
Hehe, currently, it runs in a window Smile

I might make it fullscreen though.
Quote this message in a reply
Member
Posts: 156
Joined: 2002.10
Post: #10
Here are a few ideas that I have used in the past:

1) Run a timer, set to fire off at the framerate you want e.g. 50 fps which is 20ms between firings. Then each time your timer goes off, read events using SDL_PollEvents(), handle them, and redraw your screen. In the event that the computer can't execute the routine in 20ms, then you will get lower framerates, but on faster CPUs it will max out at 50fps, leaving you spare processor power.

2) Have the event loop run as fast as possible, checking for events etc. BUT - only redraw the screen once every 3 times round the loop. This means that you will get an more accurate physical response in your game world (as deltaT between cycles is smaller), and you save time by only blitting once every 3 cycles. The user will probably not notice this. I found that in a normal game loop, about 75% of the time was in drawing routines, if you only draw every 3 frames, your framerate will only drop to 66% of what it was, but you will be 3 times more responsive.

Worth thinking about?

- Iain
Quote this message in a reply
anarchie
Unregistered
 
Post: #11
Run the event loop as fast as possible, and check the time elapsed since the last frame drawn on each pass. Compare this to the interval for the desired framerate, and then call your drawing routine and update the last-frame time appropriately. This is probably the most CPU-hoggish solution of them all, since your event loop never goes to sleep, and then keeps bugging the OS about the current time.

Course, this is just off the top of my head, so the one guy who actually tried it is going to come by and reply "OMG NO You'll crash your network stack!"
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #12
I found this handy:
SDL_GFX

Among other things, it has a nice, easy and powerful framerate limiter. It compiles fine under Xcode. You'll have to fix all the filepaths however, the PB project provided has all absolute paths. (and I'm guessing that you don't have the same username)

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 508
Joined: 2002.09
Post: #13
Cool, I'll check it out.
Quote this message in a reply
Moderator
Posts: 702
Joined: 2002.04
Post: #14
If this hasn't already been suggested, I assume you call SDL_DisplayFormat? (or SDL_DisplayFormatAlpha?)

Mark Bishop
--
Student and freelance OS X & iOS developer
Quote this message in a reply
Moderator
Posts: 508
Joined: 2002.09
Post: #15
Well, I use SDL_SetVideoMode for my main surface (the one which receives all the drawings).

Then I have some surfaces which are indeed created with SDL_DisplayFormat.
But for some classes, which have their own drawing functions, I simply send the main surface as an argument.

Like so:

Code:
//*** main drawing function

player->draw(mainSurface);

SDL_Flip(mainSurface);
Quote this message in a reply
Post Reply