Update(), Render() Seperation

Started by
19 comments, last by Bob Janova 17 years, 2 months ago
In so many practical code, we see the seperation btwn Update and Render(); -Update part : CPU operation -Render part : GPU and Graphic card operation But, is there any reason why many people does not mix these two part. I mean... Traditionally we use this kind of code method,

Object::Update()
{
 ...
 ..
 UpdateObj1();
 UpdateObj2();
 UpdateObj3();
 ...
 }

Object::Render()
{
 ...
 ..
 Render1();
 Render2();
 Render3();
 ..
 ...
}
So there was repeation, CPU operation -> Graphics operation bottleneck -> CPU operation -> Graphics operation bottleneck -> CPU operation -> Graphics operation bottleneck -> ... But, if we mixed those two part, I think we could reduce GPU bottleneck. When CPU operation time, we pre-call Graphics operation to reduce delay. like this code,

Object::Update()
{
 ....
 ..
 UpdateObjectAnimation();
 ...
 renderObj1();
 ...
 ..
 ...
 UpdateObj2();
 RenderObj2();
 ..
 ..

}
Maybe, If I use this kind of coding method, my game's performances will imporve. Is it true? I am not sure.... any comments plz~ -_-a
Advertisement
Your assumption is correct : If you use your methods, it is POSSIBLE that the performance will increase. But it will probably be a very small increase.

On the other hand, having Update and Render in 2 different sections allows :
-Better readability
-MVC compliance
-Easier to interoperate (if you switch from directX to OpenGL, you need only to change the render ... not the update)
-By the time the GPU is done with your last batch, your CPU will be able to do it's Update anyway ... so no time is lost in having both section separate. (The bottleneck you spoke about ... is usualy not a bottleneck at all since everything is batched)
I seperate update/rendering code for modularity. Also, by seperating them, you can change one without effecting the other. ie, keep the updating code, but change the way it is rendered.

I dont think it really matters for performance though.
What is MVC? -_-a
you mean "Multi-Vendor Compliancv"
and
I could not understand fully your forth opinion...
what does it mean?

"-By the time the GPU is done with your last batch, your CPU will be able to do it's Update anyway ... so no time is lost in having both section separate. (The bottleneck you spoke about ... is usualy not a bottleneck at all since everything is batched)"




[Edited by - inbgche on January 30, 2007 1:13:19 AM]
Quote:Original post by inbgche
what is MVC? -_-a


Model view controller
mvc(I guess)
I use a different model than the regular update/render one
// regular:void game(float delta) {  update(delta);  render();}// my methodfloat timeTotal = 0;void game(float delta, float step) {  timeTotal += delta;  while( timeTotal > step) {    tick(step);    timeTotal -= step;  }  renderWithInterpolation(); // interpolation}// where step (in my case) is 40 ms

In this model you can't combine update and render since there is one render per frame, and 0 to many updates. What you can do is to send everything before, and flush&flip later.

sirGustav,
your question is possible without seperatio Redder and Update like this.

Update(){  ..  ....  for(step=0; step<oneFrameTime; step==5)  {     UpdateEngine();  }  RenderEngine();  UpdateOther();  RenderOther();  ..  ....}


so, that's not problem~

inbgche, I don't understand your last reply at all. I think what sirGustav was saying was that to get rid of a graphics bottleneck you can move around your flushing and buffer flipping, or what direct3d calls presenting.

Maybe it would be more clear if we explicitly separate rendering from buffer flipping.

1.update
2.render
3.flipbuffers

could be changed to

1.update
2.flipbuffers
3.render

I think this would allow the hardware accelerated rendering operations to overlap with the game logic updating since the rendering isn't flushed until after the game logic update is complete. If the update and rendering rates are decoupled, just imagine separate conditions guarding the update and the rendering/bufferflipping.

I could be entirely wrong on this; I'm not that familiar with the low level workings of these hardware accelerated graphics interfaces. Are sequential rendering operations buffered or is it possible for a rendering operation to block while a previous operation completes? Or maybe the buffer is of a limited size? I have no idea.
Quote:Original post by Vorpy
Are sequential rendering operations buffered or is it possible for a rendering operation to block while a previous operation completes? Or maybe the buffer is of a limited size? I have no idea.

It depends on the exact operation, but generally most drawing calls are buffered. Readbacks usually cause a stall/wait, and swapBuffers usually waits if you've got vSync on.
When you get into more advanced programming, it becomes possible to separate rendering and gameplay into separate threads. This means that slower frames don't mess with things like physics or other algorithms that might depend on ODEs or time-sensitive elements.

This topic is closed to new replies.

Advertisement