Skip to main content
GameDev.net gamedev.net
🔒 Locked

SDL cpu usage

Started by Feidias Jan 7, 2006 at 2:02 PM 11 replies 5k views
Original Post
Feidias
Feidias
Is there a way to drop 100% cpu usage to minimum while the program is not doing anything? For games with constant frame rate this would not been an issue, but it's not acceptable with the editor I'm working on.. I did read some threads about this, but didn't find anything useful. I guess placing SDL_Delay(some_value) to the event loop is not really the correct way.. or is it?
rip-off
rip-off
yes, SDL_Delay(), or any sleep funtion, can be used to reduce the amount of time your program sits on the cpu. but if you are not doing other things in the background, you'll find that your program will get most of the cpu time anyway...
Feidias
Feidias
Quote:
Original post by rip-off
[q]you'll find that your program will get most of the cpu time anyway...


But only when it is active and doing something. I want to drop the cpu usage when the program is not active. SDL doesn't do that by itself.
I was testing with Photoshop to see how it works. After starting it the cpu usage is down to nothing. When you draw something, it will shoot to 100% and then lower back to 4% or something like that.
SDL works different way. It's always 100%, no matter if it's active or not. And it's slowing down other programs.
rip-off
rip-off
Quote:
Original post by Feidias
Quote:
Original post by rip-off
[q]you'll find that your program will get most of the cpu time anyway...


But only when it is active and doing something. I want to drop the cpu usage when the program is not active. SDL doesn't do that by itself.
I was testing with Photoshop to see how it works. After starting it the cpu usage is down to nothing. When you draw something, it will shoot to 100% and then lower back to 4% or something like that.
SDL works different way. It's always 100%, no matter if it's active or not. And it's slowing down other programs.


well, you can detect when your program loses the focus, and sleep for longer periods of time. remember, it is your prgram that uses 100% of the cpu, not SDL. there is an SDL_Event, that tells you when this occurs. use that and some testing to see how long your program should SDL_Delay for...
nprz
nprz
If you have nothing new to draw to the screen, don't draw anything (and you can also add in a millisecond delay). Make a bool that is set to true if you do anything on the screen, click, click+mouse-move, key press. After drawing you can set the bool so it won't draw again until something else is done.
Feidias
Feidias
Quote:
Original post by rip-off
remember, it is your prgram that uses 100% of the cpu, not SDL.


Incorrect. You can write a test program with no other events than SDL_QUIT and see what happens. SDL_PollEvent will take 100% of cpu time, not my program.

Quote:
there is an SDL_Event, that tells you when this occurs. use that and some testing to see how long your program should SDL_Delay for...


I don't quite understand. Besides I tried ActiveEvent and it doesn't seem to work at all. Maybe you got it working and could share us how you did it.

However, it seems that simpy placing SDL_Delay(10); right after SDL_PollEvent loop does the trick. But I'm not sure will 10 be the "magic" number to work in all computers.
Feidias
Feidias
Quote:
Original post by nprz
If you have nothing new to draw to the screen, don't draw anything (and you can also add in a millisecond delay). Make a bool that is set to true if you do anything on the screen, click, click+mouse-move, key press. After drawing you can set the bool so it won't draw again until something else is done.


My program isn't drawing anything at constant rate. It's drawing only when mouse or keyboard events happen. When no events happen SDL will still take 100% cpu time. If I'm correct the outer while loop (enclosing SDL_PollEvents) is the reason for this and that is why placing SDL_Delay() inside it will do the trick.
Feidias
Feidias
The problem with SDL_WaitEvent() is that it completely hangs the program. I guess it takes more than just replacing Poll with Wait, but I don't know what.
rip-off
rip-off
Quote:
Original post by Feidias

Incorrect. You can write a test program with no other events than SDL_QUIT and see what happens. SDL_PollEvent will take 100% of cpu time, not my program.



who calls pollevent? you do. so if your program chooses to spend all its time checking if something has occured thats its problem.

EDIT: sorry if i sound very defensive, but youre putting this as a "SDL problem", whereas sdl is not to blame.

waitevent is implemented as pollevent + a 10 second SDL_Delay, so it is almost the same as what you are doing.

i made a program once that waited on events:

this is old code, but my program, while im not moving the mouse, uses 0%-2% of cpu. while i move the mouse or genereate input, it goes to ~30%
SDL_Event Game::get_useful_event(){    SDL_Event event;    while(1){        if( !SDL_WaitEvent( &event ) )            continue;        update_screen();        if(event.type == SDL_QUIT)            end_game();        switch( event.type ){            case SDL_KEYDOWN:                switch( event.key.keysym.sym ){                    case SDLK_ESCAPE:                        end_game();                        break;                    // handle other input                    default:                        break;                }            case SDL_KEYUP:            case SDL_MOUSEBUTTONDOWN:            case SDL_MOUSEBUTTONUP:            case SDL_MOUSEMOTION:                return event;                break;            default:                continue;                break;        }// end switch( event.type )    }}


as for active event, sorry, for some deranged reason i thought you were talking about your program using loads of cpu time when it wasnt the active window. it isnt relevant here.

good luck!
Feidias
Feidias
Quote:
Original post by rip-off
EDIT: sorry if i sound very defensive, but youre putting this as a "SDL problem", whereas sdl is not to blame.


Well, it's quite easy to think that it's a problem related to SDL, because I was just using the example code found practically in all tutorials. I had no idea that PollEvent was using all cpu time and why it does that. However the source example above seems to handle the situation without any subtle SDL_Delay with "magic" number. Thanks!
rip-off
rip-off
Quote:
Original post by Feidias
Quote:
Original post by rip-off
EDIT: sorry if i sound very defensive, but youre putting this as a "SDL problem", whereas sdl is not to blame.


Well, it's quite easy to think that it's a problem related to SDL, because I was just using the example code found practically in all tutorials. I had no idea that PollEvent was using all cpu time and why it does that. However the source example above seems to handle the situation without any subtle SDL_Delay with "magic" number. Thanks!


id guess and say that 99% of those tutorials are designed with games that do processing even without input in mind...

you're welcome.
Xeee
Xeee
100% CPU usage is normal, I mean it happens *unless* you prevent it.
normally your program is a while loop polling for SDL event and drawing + some game logic, so the while loop will run as fast as the machine can, and you'll get a high frame-rate and high CPU usage, the solution is to limit the frame-rate by putting an SDL_Delay in the event loop, the time slept by SDL_Delay should be variable(i.e. dont use SDL_Delay(30)).
for example, if you want to achieve a framerate of 30, then the time spent in each frame is 1000/30 ~= 33 ms. if the time spent in drawing + game_logic = 5, then you should sleep 33 - 5 = 28 ms, and so on.
here are the steps:
1- calculate frametime from the desired frame rate(frametime = (1000/fps) ms).
2- calculate time spent each frame.
3- sleep alittle so that the time spent in the whole frame = desired frame time(SDL_Delay(frametime - time_spent_this_frame)).

I hope my explaination was clear.
you can do it yourself as I explained, or you can use a library such as sdl_gfx (I know it seems odd, but sdl_gfx contains a frame-limiting module).

[Edited by - Xeee on January 26, 2006 5:17:02 PM]
xee..

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.