#OPENGL TUTORIAL FOR XCODE HOW TO#
#OPENGL TUTORIAL FOR XCODE DRIVER#
#OPENGL TUTORIAL FOR XCODE CODE#

The “Shaders” tab will actually let you look at the GLSL code of your loaded fragment and vertex shaders. Everything will appear upside down, but that is just how it is loaded in GL. The “Textures” tab in Resources will show you almost all of the currently loaded textures in your application, useful if you’re working with a lot of loaded static images.

Now you can see a huge list of options for the graphics resources that have been loaded for your application. Go back to the “Views” menu at the top and select “Resources” Now you can pry it open and look at what exactly was going on at the moment of pausing. To reverse this, remove the blue dot by clicking, and click “Continue”Īlso, while you’re here…have a look on the right side of the Breakpoints window and select the State tab, and this will let you look at all the currently enabled or disabled GL states like depth testing, GL Point Size, GL Line Width etc etc. My fallback is glClear because the screen usually has to get cleared sometime…įind glClear in the list of glFunctions, and when you’re ready, click in that row next to either “Before” or “After” and a blue dot will appear and your application will pause. Obviously if you’re looking to play with a specific GL call you can find the specific one you’re interested in, but I generally just go for a common call that I know HAS to be running in my app somewhere, even if I didn’t explicitly call it.

In the Profiler Menus at the top, pick “Views” and then “Breakpoints” and you’ll be greeted with a long list of different GL calls. In order to look at the application’s Resources, the application has to be stalled on a breakpoint, so let’s set that up. Let’s take a look at looking at an application’s loaded Resources first. I’m using the openFrameworks “multishaderTextureExample” in this tutorial. Go ahead and select it and hit “Attach” – and now you have several options to explore. Once it is running, it should appear somewhere in the list of currently running apps. Next you should run the application you’re looking to dive into. So once you’ve downloaded the Profiler from Apple’s Developer Connection, open it up and you’ll see this:

#OPENGL TUTORIAL FOR XCODE HOW TO#

I’m not going to go into to much depth about how to use the Profiler to actually debug because there are a lot of options to play with and they get very specific, I’m just going to post a sort of “Getting Started” since the actual helper file can be a bit dense.

You can even run this on an application like VDMX to see all the currently loaded shaders if you want to have a peek at another app. The OpenGL Profiler can be used with any of the creative coding toolsets that use OpenGL, so MaxMSP/Jitter, Quartz Composer, Processing, OpenFrameworks, Cinder, etc etc are all fair game here.

#OPENGL TUTORIAL FOR XCODE DRIVER#

It used to be included with XCode, but now you’ll need to go to the Apple Developer area and download the “XCode Graphics tools” as a separate download, it includes a lot of other useful tools that I hope to cover in some future tutorials (OpenGL Driver Monitor is great for watching VRAM usage to diagnose low frame rates, Quartz Composer is also part of those tools). It’s saved me a few times when I’ve caught my application loading images twice as often as it should, or finding some obscure shader errors when XCode wasn’t being helpful. The OS X OpenGL Profiler is a really useful tool for helping you debug graphics issues with your work. It can help you look deeper into how your application is working on the graphics card level and give you more information about how your application is managing it’s resources.

Opengl tutorial for xcode