Jump to content
  • Advertisement
Sign in to follow this  
inbgche

Update(), Render() Seperation

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
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)

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 method
float 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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

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!