Amortizing texture rendering

I can''t find any information about OpenGL''s multi-threading capabilities. So, I had another thought. Instead of trying to spread the cost of the texture''s rendering over several frames, maybe I should just distribute all the major tasks over several frames. For example, I might have this code in the main game loop:




This way, on the first and third frame, the AI will be updated, on the second and fourth frame, the physics will be updated, and on the fifth frame, the texture will be updated. So, one would get a loop like this:

updateAI();
updatePhysics();
updateAI();
updatePhysics();
updateTexture();
updateAI();
updatePhysics();
updateAI();
updatePhysics();
updateTexture();
updateAI();
updatePhysics();
updateAI();
updatePhysics();
updateTexture();
updateAI();
updatePhysics();
updateAI();
updatePhysics();
updateTexture();
 

and so on until the end of the game loop.

This will need some tweaking (for example, I could probably get away with updating the AI and physics much more often than the texture) and it will probably be more complicated in practice.

What do you think? Will this work? Is this a good way to distribute the tasks, or is there a better way (or is this even needed at all)? Thanks for your help.

>>My question is how do I distribute the cost of this texture’s rendering over several frames of the in-game scene? I was thinking about multi-threading, but I don’t know if OpenGL is thread safe. Can someone point me in the right direction? Thanks for your help.<<

multithreading wont help.

what exactlly will take so long to construct this texture?
perhaps create a pbuffer.
and each frame render X amount of objects into it, after a second (+ once all objects are done)
copy that to the screen

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

quote:

---

Original post by zedzeek
what exactlly will take so long to construct this texture?

---

It wouldn''t, normally, but it is a particularly complex scene, there could be more than one (up to four, I would imagine), there is the regular scene to render, not to mention all the other stuff that has to be done (like updating the physics, collision detection, etc).

Since the textures don''t change very often, it would be foolish to render them every scene (that kind of defeats the point ). But I can''t just decided to render them every x frames because that would slow everything down:

// in the main game loop
if (timeElapsed == one_second){
   updateTextures();
}
 

Now, the unlucky frame that gets to updateTextures() is going to take much longer than the other frames.

quote:

---

perhaps create a pbuffer.
and each frame render X amount of objects into it, after a second (+ once all objects are done)
copy that to the screen

---

I''ll check this out. Thanks for the suggestion.

Instead of spreading the rendering out, render the entire thing to texture once, then wait a second or so, then repeat. It''s a lot easier, and if your frame rate is high enough you''ll notice no difference because either way you''ll get the same result.

------------
- outRider -

quote:

---

Original post by outRider
Instead of spreading the rendering out, render the entire thing to texture once, then wait a second or so, then repeat. It''s a lot easier, and if your frame rate is high enough you''ll notice no difference because either way you''ll get the same result.

------------
- outRider -

---

That is kind of the track I''m on. The thing I''m worried about is jumpy frame rates. I am under the impression that it is rather desirable to maintain a steady frame rate. But I will try it this way and I''ll let you all know how it turns out. Thank you for your help.