Author Topic: Idling a program (Read 9791 times)

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.

Avency · « **Reply #1 on:** July 21, 2008, 10:19:04 pm »

You might have a look at sf::RenderWindow::SetFramerateLimit().

Pwndja · « **Reply #2 on:** July 21, 2008, 10:56:45 pm »

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?

dabo · « **Reply #3 on:** July 22, 2008, 12:06:33 am »

I would like to know that as well.

Laurent · « **Reply #4 on:** July 22, 2008, 02:49:54 am »

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.

Pwndja · « **Reply #5 on:** July 22, 2008, 03:03:57 am »

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
}
}

Pwndja · « **Reply #6 on:** July 22, 2008, 03:27:57 am »

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.

Laurent · « **Reply #7 on:** July 22, 2008, 05:52:34 am »

Yep, that's the right solution

l0calh05t · « **Reply #8 on:** July 22, 2008, 11:14:18 am »

the right solution would be to use blocking calls for receiving network packets...

Pwndja · « **Reply #9 on:** July 22, 2008, 11:05:16 pm »

Quote from: "l0calh05t"

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?

Quote from: "Pwndja"

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?

l0calh05t · « **Reply #10 on:** July 23, 2008, 08:27:48 am »

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.

quasius · « **Reply #11 on:** July 23, 2008, 05:36:50 pm »

Quote from: "l0calh05t"

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?

Daazku · « **Reply #12 on:** July 23, 2008, 06:51:46 pm »

Did he say his game isn't networked?

If you wait for packets it should be networked.....

l0calh05t · « **Reply #13 on:** July 23, 2008, 08:15:01 pm »

Quote from: "quasius"

Did he say his game is networked?

Quote from: "Pwndja"

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?

--------------------

Quote from: "Daazku"

If you wait for packets it should be networked.....

unless your threads communicate via the loopback interface :-P

Pwndja · « **Reply #14 on:** July 23, 2008, 11:59:05 pm »

Quote from: "l0calh05t"

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