taking more cpu time

Member
Posts: 194
Joined: 2009.02
Post: #1
I recall years ago when programming ppcs and 68ks (as well as with carbon)that you could pretty much take control of the machine, checking the mouse, keyboard, and(or) system events however often you pleased.

So my question is whether this is still possible with cocoa?
Quote this message in a reply
Member
Posts: 116
Joined: 2002.04
Post: #2
Well, if you're the only process, you're going to get most of the time. Otherwise, the scheduler will make sure other apps get time.

Why is it important to you?
Quote this message in a reply
Member
Posts: 194
Joined: 2009.02
Post: #3
I'm just finishing up implementing dynamic lighting into my 2d opengl based game and It's slowed everything down a tremendous amount(and I'm running a 2.3ghz core duo with a radeonx1600). At times with 3 or more lights it can drop to below 60 fps on my machine, without lighting I get around 250 fps.

Also I run my main event loop from a nstimer. When I want to check the maximum fps, i set the timer interval to something like 1.0/300, I'm not sure but is the fact that I'm using a timer in any way slowing me down at all?
Quote this message in a reply
Member
Posts: 227
Joined: 2008.08
Post: #4
Don't use NSTimer as it will slow down your app in and of itself.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #5
Oddity007 Wrote:Don't use NSTimer as it will slow down your app in and of itself.

Profile with Shark to verify that NSTimer is a hotspot before making assumptions like this.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #6
NelsonMandella Wrote:I'm just finishing up implementing dynamic lighting into my 2d opengl based game and It's slowed everything down a tremendous amount(and I'm running a 2.3ghz core duo with a radeonx1600). At times with 3 or more lights it can drop to below 60 fps on my machine, without lighting I get around 250 fps.

Also I run my main event loop from a nstimer. When I want to check the maximum fps, i set the timer interval to something like 1.0/300, I'm not sure but is the fact that I'm using a timer in any way slowing me down at all?

If the problem is that you are doing lighting, is it because you are overloading the GPU using too much fill rate or passing too many vertexes? As others have said, you need to profile first. By taking full control of the CPU you wouldn't get that much of a speedup anyway. Certainly not double.

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: 3,579
Joined: 2003.06
Post: #7
Oddity007 Wrote:Don't use NSTimer as it will slow down your app in and of itself.

I've heard this a few times since a flood of programmers showed up to program on iPhone. I can see the argument perhaps maybe affecting people on iPhone if they don't understand how to work with timing correctly, but on Mac, NSTimer will not slow your app down in any measurable sense.

NelsonMandell Wrote:I'm just finishing up implementing dynamic lighting into my 2d opengl based game and It's slowed everything down a tremendous amount(and I'm running a 2.3ghz core duo with a radeonx1600). At times with 3 or more lights it can drop to below 60 fps on my machine, without lighting I get around 250 fps.

Also I run my main event loop from a nstimer. When I want to check the maximum fps, i set the timer interval to something like 1.0/300, I'm not sure but is the fact that I'm using a timer in any way slowing me down at all?

On the Mac, I've found that it's best to set your timer to always be 0.001 so that it's "over-revved", to give you maximum opportunity to draw. For checking FPS performance, leave VBL synch off to get a better idea of how many frames you're getting. Otherwise, always turn on VBL synch to match to the display refresh. The only time it would be acceptable to run without VBL synch, other than measuring performance, would be if the app is running at excessively low frame rate, such as less than 15 or 20 FPS, so you can get maximum frames to screen at the expense of tearing. With VBL synch turned on and the timer set to 1kHz (0.001 sec on the timer) visual performance is about as smooth as you can reasonably expect to get. If the timer is set any lower, you'll see more stuttering because of a sort of beat frequency effect between the timer and the display refresh.

Note that for iPhone, the 1k timer trick doesn't work.

As far as actual performance loss from lighting, yeah, as others have said, profiling is best.
Quote this message in a reply
Member
Posts: 194
Joined: 2009.02
Post: #8
Thanks a lot for all of the helpful advice. I found shark to be extremely helpful in pinpointing the weak spots in my code. Now after a few days of profiling and optimizing I went from around 40-60 fps to 250-450 fps with three moving lights.
Quote this message in a reply
Post Reply