SFML community forums
General => General discussions => Topic started by: Pwndja on July 21, 2008, 09:34:53 pm
-
I was wondering how to idle a SFML program (or a C++ program) so that I am not using 100% of my CPU when I run my while loop which displays all my sprites and takes care of my inputs and such. Any help is much appreciated.
I play video games like supreme commander, oblivion and such and i rarely see the CPU continuously running at 100% so I know my simple programs should be able to run with much less CPU processing.
thanks in advance.
-
You might have a look at sf::RenderWindow::SetFramerateLimit().
-
I am using that but my program still peaks out one of my CPUs at 96-100% are there any other methods of coding to using less CPU processing power?
-
I would like to know that as well.
-
Using SetFramerateLimit (with a value which is below the actual framerate, of course) is usually enough, there might be something wrong in your code.
You can also use vertical synchronization (UseVerticalSync).
There might also be a chance that your application is not limitied by display, if you heavily use the CPU. In this case, we can't do much about it.
-
is there any way to do something like sf::RenderWindow::SetFramerateLimit() but not actually have a renderwindow object.
so when I have multiple threads, for things like receiving sent udp packets, which do not need nor have a window object, i still can put a cap on them?
example
void thread()
{
///set a some sort of limit or cap for this will loop here
while(1)
{
///receive and handle packets here
}
}
-
Ok so I found a fix that will work for now.
all I did was put this: sf::Sleep(0.01f); at the end of my while loops that were receiving and it took my CPU from 96-100% usage to 13-15% usage.
and everything runs just fine.
I think I might tune the sleep time in the loop by getting the delta of each loop and calculating how much time is needed to sleep in order to achieve a given "frame rate" or loop rate in this case since there are no frames being drawn.
-
Yep, that's the right solution :)
-
the right solution would be to use blocking calls for receiving network packets...
-
the right solution would be to use blocking calls for receiving network packets...
could you explain this in more detail why it would be the right solution... over the proposed solution?
I think I might tune the sleep time in the loop by getting the delta of each loop and calculating how much time is needed to sleep in order to achieve a given "frame rate" or loop rate in this case since there are no frames being drawn.
does blocking sit idle waiting for packets to be sent?
-
blocking calls cause the os to stop the thread until a packet is available. this means no CPU cost at all while waiting for the packet. if you use polling with sleeping (as proposed), you'll be checking & rechecking (wasting cpu power) and if you sleep too long, you'll get the packet later than you would have using a blocking call.
-
blocking calls cause the os to stop the thread until a packet is available. this means no CPU cost at all while waiting for the packet. if you use polling with sleeping (as proposed), you'll be checking & rechecking (wasting cpu power) and if you sleep too long, you'll get the packet later than you would have using a blocking call.
Did he say his game is networked?
-
Did he say his game isn't networked?
If you wait for packets it should be networked.....
-
Did he say his game is networked?
so when I have multiple threads, for things like receiving sent udp packets, which do not need nor have a window object, i still can put a cap on them?
--------------------
If you wait for packets it should be networked.....
unless your threads communicate via the loopback interface :-P
-
blocking calls cause the os to stop the thread until a packet is available. this means no CPU cost at all while waiting for the packet. if you use polling with sleeping (as proposed), you'll be checking & rechecking (wasting cpu power) and if you sleep too long, you'll get the packet later than you would have using a blocking call.
excellent! that works great! thanks for the explanation :)
-
Did he say his game is networked?
so when I have multiple threads, for things like receiving sent udp packets, which do not need nor have a window object, i still can put a cap on them?
--------------------
If you wait for packets it should be networked.....
unless your threads communicate via the loopback interface :-P
Ya but you dont need thread in this case :-P