Update(), Render() Seperation

This topic is 4267 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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

Share on other sites
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 :
-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)

Share on other sites
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.

Share on other sites
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]

Share on other sites
Quote:
 Original post by inbgchewhat is MVC? -_-a

Model view controller

Share on other sites
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.

Share on other sites

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~

Share on other sites
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.

Share on other sites
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.

Share on other sites
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.

1. 1
Rutin
32
2. 2
3. 3
4. 4
5. 5

• 11
• 9
• 13
• 92
• 11
• Forum Statistics

• Total Topics
632972
• Total Posts
3009626
• Who's Online (See full list)

There are no registered users currently online

×

Important Information

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!