Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to know what is the norm of loading rendering code.

Take a button. When the application is loaded, a texture is loaded which has the image of the button on it. When the button is tapped, it then adds a loader into a queue, which is loaded on render thread. It then loads up an array buffer with vertexes and tex coords when render is called. It then adds to a render tree. Then it renders.

the render function looks like this

void render()

update() is when the queue is checked to see if anything needs loading. mBaseRenderer->render() is the render tree.

What I am asking then is, should I even have the update() there at all and instead have everything preloaded before it renders? If I can have it loaded when need, for instance when there is tap, then how can it be done (My current code causes an dequeueing buffer error (Unknown error: -75) which I assume is to do with OpenGL ES and the context)?

share|improve this question
up vote 4 down vote accepted

In general I think you should pre-load all the assets you are going to need immediate access to -- UI-related assets, especially -- otherwise your application may feel unresponsive and laggy as the user has to wait for load requests to queue up and complete the first time they click on any bit of UI.

You can subdivide your assets into two classes: important ones that must be loaded as soon as possible, and less-important ones that can be delay loaded. The critical assets should be loaded immediately (if you have enough of them that it introduces a delay in your application start up, place this loading behind a loading screen of some sort perhaps). The rest of them can be loaded lazily on a background thread.

This latter class of delay-loadable assets typically corresponds to in-game or other gameplay-related stuff, so if the background load queue isn't finished by the time the game starts, you can put up another load screen if you need to in order to get everything in-memory and prepared so that when actually rendering you don't have to worry about it.

Admittedly, however, loading screens are kind of lame. If you really want to avoid them, you can implement a streaming asset system. In order to do that you'll need a fair bit more information about what assets you're going to need before you need them, so you'll still need to know which assets are high-priority UI-related files. Even in a streaming system you want to get the assets you need loaded as early as possible and not wait until they have to be loaded on-demand, unless such on-demand loading is fast enough for your platform.

An old, but relatively classic, paper on streaming systems can be found here, discussing the streaming world implementation used in Dungeon Siege.

In your specific case it sounds like you have a very unusual process. From the description in your question it sounds like the geometry and texture coordinates (et cetera) are not loaded for the button until the user taps on it. But if that is the case, how did the button appear at all for the user to tap on? You must have had some geometry and texture coordinates loaded already, so it doesn't seem like you'd need to load anything else. The vertex data should be the same for both the unpressed and pressed button states -- the only thing different should be the image.

You can use sprite sheets to pack multiple images into one texture and thus avoid having to manage the load of multiple texture assets per button. This will also mean that you only need to adjust the texture coordinates in the existing vertex buffer data for the button, or, if you're using ES 2.0 and have access to shaders, just offset the texture coordinates in the shader code as needed to access a different "frame" in the sprite sheet texture.

Essentially, it does not sound like your update method is necessary and in fact sounds to me like you're over-complicating your code by having it, so I would remove it in favor of pre-loaded assets and a simpler UI codepath that does not create new geometry for every button state. You might also see if loading the assets you need on-demand is fast enough do simply do exactly when you need it (it might be, although I wouldn't really recommend such an approach since it may not scale well).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.