Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Idling a program  (Read 8506 times)

0 Members and 2 Guests are viewing this topic.

Pwndja

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Idling a program
« 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

  • Full Member
  • ***
  • Posts: 113
    • View Profile
Idling a program
« Reply #1 on: July 21, 2008, 10:19:04 pm »
You might have a look at sf::RenderWindow::SetFramerateLimit().

Pwndja

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Idling a program
« 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

  • Sr. Member
  • ****
  • Posts: 260
    • View Profile
    • http://www.dabostudios.net
Idling a program
« Reply #3 on: July 22, 2008, 12:06:33 am »
I would like to know that as well.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Idling a program
« 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.
Laurent Gomila - SFML developer

Pwndja

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Idling a program
« 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

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Idling a program
« 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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Idling a program
« Reply #7 on: July 22, 2008, 05:52:34 am »
Yep, that's the right solution :)
Laurent Gomila - SFML developer

l0calh05t

  • Full Member
  • ***
  • Posts: 200
    • View Profile
Idling a program
« Reply #8 on: July 22, 2008, 11:14:18 am »
the right solution would be to use blocking calls for receiving network packets...

Pwndja

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Idling a program
« 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

  • Full Member
  • ***
  • Posts: 200
    • View Profile
Idling a program
« 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

  • Full Member
  • ***
  • Posts: 166
    • View Profile
Idling a program
« 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

  • Hero Member
  • *****
  • Posts: 896
    • View Profile
Idling a program
« 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.....
Pensez à mettre le tag [Résolu] une fois la réponse à votre question trouvée.
Remember to add the tag [Solved] when you got an answer to your question.

l0calh05t

  • Full Member
  • ***
  • Posts: 200
    • View Profile
Idling a program
« 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

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Idling a program
« 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 :)

 

anything