Profiling the non-OpenGL parts of my game

Member
Posts: 353
Joined: 2002.04
Post: #1
Hi guys!

It's been a while, I finally decided I need to make a new game more than I need sleep so I've actually made some progress at last. Anyone who follows me on Twitter may have seen the screenshot I posted to Instagram last week, thanks for the kind words from some old iDevGamers! Smile

Anyway, I'm hitting a bit of a snag in that around every 15 frames or so the app appears to "stutter" and the scrolling jumps by a few iterations in one frame. I have my updates and drawing decoupled using code similar to AnotherJake's in this very old thread, and I am using a fixed value to update the scrolling on each update.

I have been trying to figure out where these hiccups come from in the code. I have tried using OpenGL Profiler but it shows the OpenGL calls as only taking up about 12% of the app's time and there doesn't appear to be any spikes.

So my main question is how do I profile the parts of the code that aren't OpenGL calls since that doesn't seem like the cause?

Or any other suggestions would be much appreciated!

Thanks.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #2
(Oct 24, 2012 03:57 PM)monteboyd Wrote:  I have my updates and drawing decoupled using code similar to AnotherJake's in this very old thread, and I am using a fixed value to update the scrolling on each update.

Yikes, it's been a while since that post, and I have since sworn off global variables except in a very few cases.

Anyway, if profiling doesn't help, my guess is that somehow your fixed rate timing algorithm isn't quite right. I seem to recall that what you are describing happened to me in the past too. I really wish I could remember exactly what it was, but I do remember it was a very simple logical math mistake. If this is the first time you've used that little timing routine, definitely double and triple check the logic there. I found it difficult to think through initially but what I posted should be correct, since I've been using it for years now -- unless I made a copy-paste error in that post! Blink
Quote this message in a reply
⌘-R in Chief
Posts: 1,254
Joined: 2002.05
Post: #3
Quote:So my main question is how do I profile the parts of the code that aren't OpenGL calls since that doesn't seem like the cause?

Well, the answer to that is Instruments, but it still may not be easy to track down.
Quote this message in a reply
Member
Posts: 353
Joined: 2002.04
Post: #4
Thanks for the replies guys.

@SethWillits - I did end up trying again with Time Profiler but couldn't really glean any useful info from it. If it was something slowing down the app constantly it would be more straightforward, but since it seems to stutter irregularly it is much harder to diagnose.

@AnotherJake - intriguing that something similar may have happened to you! I too have been using the code for years but since none of my projects have gotten all that far until now I've never delved too deeply back into it. I did just look at another prototype I was working on earlier in the year and, although it is not as noticeable, I think the glitch is in that one too. So yes, it could very well be a logic mistake that has always been there!

I'll go over the logic of the timing again, but if nothing jumps out at me I'm thinking I might rebuild from scratch in ES2 (currently it's still ES1) and initially start out with updating and drawing coupled together.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #5
Off the timing topic, I too am currently in the process of upgrading my codebase to ES2 via GLKit. It's actually pretty easy to get started with on iOS, but Mac examples and documentation are severely lacking, although I managed to get the Mac version working too. It's nice to have basically identical rendering code between iOS and Mac now. Apple did great with GLKit, but I have found that I am now having to change a lot of my geometry submission routines to "batch" everything, which is turning into quite a hassle to rearrange my old 3D code. I miss the old, more immediate GL, but such is progress I suppose.
Quote this message in a reply
Member
Posts: 353
Joined: 2002.04
Post: #6
Quote:I miss the old, more immediate GL

Oh man - you have no idea how much I miss using ES1 when trying to get my head around ES2! I understand the benefits, it just seems like such a hassle to get something simple rendering. But as you say, such is progress.

I was wondering about GLKit and how practical it is for games but decided it was a good place to start to try to get this up and running in ES2 quicker without worrying about so much GL set up. So right now I'm going through this tutorial which seems pretty good for 2D.

I'll worry about 3D later. Blink
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #7
Heh, I started GLKit with a slightly older article from the same guy. I am still heavily into the "confused" stage right now with the updating of my codebase, although things are progressing steadily.

Best of luck with your endeavors!
Quote this message in a reply
Member
Posts: 446
Joined: 2002.09
Post: #8
This might seem like a silly question, but are you drawing any GL_LINES or GL_POINTS? While working on a scrolling game earlier this year I had an intermitted frame hiccup that was driving me nuts - disabling 2 tiny debug boxes drawn with GL_LINES completely fixed it.

Otherwise, yeah, those fixed time-step loops can sometimes be a PITA if your frame interpolation isn't syncing up just right.

P.S. Just checked your twitter stream for that screenshot - really nice! Grin
Quote this message in a reply
Member
Posts: 353
Joined: 2002.04
Post: #9
Hey Frank - thanks for the tip, unfortunately it's all GL_TRIANGLE_STRIPs I'm using.

Now I've recreated almost the entire game using ES2 and GLKit and whaddya know - the hiccup is back! So I suspect it wasn't the timer-update code in the end. I'm basically at a loss again as to what the cause might be. Very frustrating, but thanks for all the help so far. If you have any more ideas I'm all ears!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
If you add the OpenGL frame monitor and the time profiler and/or system trace to instruments, you ought to be able to correlate the long frames with the CPU usage or long blocking that's causing them.

(Time Profiler is for profiling high CPU usage, System Trace is for profiling blocking; either might be the cause of frame rate hitches)
Quote this message in a reply
Member
Posts: 353
Joined: 2002.04
Post: #11
Thanks Keith, I'll give that a try.

Although on further testing I have found the ES2+GLKit version experiences the hiccups a lot less, but they are still there occasionally so I would like to diagnose the problem.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Profiling OpenGL ES App Nick 20 14,931 Jan 19, 2010 08:50 PM
Last Post: Frank C.