Games like Karateka (which uses UDK) seem to be able to asynchronously load GL assets as well as display animation.

The splash is incredibly short, then presumably their glView shows up.

I can think of 2 ways to simultaneously load textures, models and assets into OpenGL:

1) Create 2 contexts: the "real" one (which is doing the loading) and a "fake" one (which will be on a separate viewcontroller.. on a separate thread.) I'm not sure if this will work however as I don't know if you can create a 2nd GL context on not the main thread.

2) Cut the load sequence into small, small jobs. Each iteration of your draw loop, load one tiny asset (like a single texture or a single model).
The effect of this is probably a much longer total loading time!

Are either of these 2 right or are they both wrong? Is there another way to do it?

  • 1
    \$\begingroup\$ Where is the question? \$\endgroup\$ Apr 5, 2013 at 21:53
  • \$\begingroup\$ Are either of these 2 right or are they both wrong? I have no idea. \$\endgroup\$
    – bobobobo
    Apr 5, 2013 at 21:53

1 Answer 1


After some searching, I came across the concept of EAGL Sharegroups.

enter image description here

It seems as though iOS designers really thought things through, because EAGLShareGroup is exactly what I need here.

Docs say EAGL Sharegroups are useful "When you want your application to be able to create new OpenGL ES objects on a thread other than the main thread for the renderer. In this case, a second context runs on a separate thread and is devoted to fetching data and creating resources. After the resource is loaded, the first context can bind to the object and use it immediately."

Creating a new context with the same sharegroup is easy:

EAGLContext* secondContext = [[EAGLContext alloc] initWithAPI:[firstContext API]
                               sharegroup: [firstContext sharegroup]];

It's ok to read the same OpenGL object on multiple contexts with the same sharegroup provided the object is not being modified.

While a GL object is being modified, you may not read that object on another context. So you can't try and render the texture you are loading on one context with the other context until you are 100% sure the first context is done loading first.

After an object has been modified, you have to re-bind it on all contexts to see the changes.

So much for cutting my code up into little bits!!


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .