Sign in to follow this  

update() and render()

This topic is 4354 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

I find all game put update in a function ,put render code in another function . why does it be put seperately? popular game do:
update()
{
    update something;
    update other thing;
    update A;
}

render()
{
    render something;
    render other thing;
    render A;
}
I wanna do this:
renderandupdate()
{
    update something;
    render something;

    update other thing;
    render other thing;

    update A;
    render A;
}
edit: minor thing really, but using code tags around small fragments like you've posted make it a bit more readable... [Edited by - jollyjeffers on January 11, 2006 8:33:21 AM]

Share this post


Link to post
Share on other sites
Generally this is just to place some structure within the program and to seperate contents into a logical ordering. This has nothing to do with performance and if you wanted you could probably place everything in one method that keeps getting called.
Another reason for it is that sometimes you wish to only update parts of your engine in a certain time frame, let's take for argument sake... 50miliseconds but you want to render all your objects every frame. By splitting the methods you could accomplish this.

I hope this helps.
Take care.

Share this post


Link to post
Share on other sites
Nothing wrong with putting all your rendering and updating in one function although this doesn't work well in some architectures. But one thing. You should do all your updating before you do your rendering.

Share this post


Link to post
Share on other sites
I think you're effectively seeing the "Model-Viewer" pattern - the two are related, but are seperate processes. Thus splitting them is more logical.

As has been said already, there isn't anything technically wrong with what you're doing - it's just not advised for anything non-trivial.

Think about a complex game that has 10's or 100's of types of objects with complex update rules. Maintainability and so on would start to become an issue. The codebase ends up getting ugly, making changes is time consuming (and error-prone) and reasoning about the system becomes a complete headache.

It's unlikely, but you can get to the point where the compiler starts to generate poor-quality code and performance will suffer. Large functions can generate large blocks of code which doesn't suit the CPU cache very well.

It's all about good code construction at the end of the day.

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by Armadon
This has nothing to do with performance and if you wanted you could probably place everything in one method that keeps getting called.


Well if you are doing 3d rendering, it can affect performance. Updating usually requires CPU processing which can be significant for CPU skinning, AI,etc.. By seperating the 2 and doing rendering before updating, you can get the CPU/GPU to work in parallel and achieve a significant performance boost for CPU limited games(Which is usually the case for most games).

Here is how i do my loops for optimal performance.

Assuming current frame is x.

BeginDrawing(x);// GPU has recieved rendering commands
UpdateAndProcess(x+1);// CPU at work and GPU is busy rendering frame x
EndDrawing();// Swap buffers

This has a few assumptions though, in your rendering code(BeginDrawing), you are not using any commands which will cause a pipeline stall or force the finishing of all buffered commands(Reading back from GPU, glFinish(), etc..). Any decent Renderer would not be using such calls.

Share this post


Link to post
Share on other sites
Quote:
Original post by GamerSg
Quote:
Original post by Armadon
This has nothing to do with performance and if you wanted you could probably place everything in one method that keeps getting called.


Well if you are doing 3d rendering, it can affect performance. Updating usually requires CPU processing which can be significant for CPU skinning, AI,etc.. By seperating the 2 and doing rendering before updating, you can get the CPU/GPU to work in parallel and achieve a significant performance boost for CPU limited games(Which is usually the case for most games).

Here is how i do my loops for optimal performance.

Assuming current frame is x.

BeginDrawing(x);// GPU has recieved rendering commands
UpdateAndProcess(x+1);// CPU at work and GPU is busy rendering frame x
EndDrawing();// Swap buffers

This has a few assumptions though, in your rendering code(BeginDrawing), you are not using any commands which will cause a pipeline stall or force the finishing of all buffered commands(Reading back from GPU, glFinish(), etc..). Any decent Renderer would not be using such calls.




I found a game engine (maybe all game) do all update() and then do render()
so do cpu and gpu work in series other than parallel?
It seem good game engine do not make gpu and cpu work in series.

When draw call issue and then Gpu begin to work, does cpu wait till Gpu finish the frame rendering or cpu do the next frame update()?

Share this post


Link to post
Share on other sites
Quote:
Original post by luasitdown
It seem good game engine do not make gpu and cpu work in series.

Best performance is achieved by making the GPU and CPU work in parallel. It's essentially a form of concurrent programming.

Quote:
Original post by luasitdown
When draw call issue and then Gpu begin to work, does cpu wait till Gpu finish the frame rendering or cpu do the next frame update()?

It's not entirely straight forward - some calls in some situations will "block" the CPU - forcing it to wait until the GPU has finished; but most of the time it will issue the request and move on to the next command.

hth
Jack

Share this post


Link to post
Share on other sites
I have a question regarding the update-then-render vs render-then-update thing:
Why is it important in which order you do that?
After all a game will be doing those things over and over, for simplicity´s sake let´s say in a while-loop:


while(game_running())
{
update();
render();
}

or

while(game_running())
{
render();
update();
}


If I understand that correctly, it would only make a difference in the first and the last frame of the game running? In every frame in between update() would follow right after render() in both cases, so it should just be the same?
At least until the whole thing gets more advanced. But then I would use update() before render(), just because it´s easier to think about it this way, at least for me.
Did I miss something?

Share this post


Link to post
Share on other sites
It'll hide the latency of any expensive code in Update(). Although, in practice whether it makes much difference will probably vary on a case-by-case basis.

If you compute Frame N's Update() before you Render() it, then rendering cannot commence until Update() is finished. However, if frame N is ready-and-waiting then the rendering can despatch the necessary calls to the GPU and return. The CPU can then be busy preparing the next frames data before the GPU is ready to accept it.

Drawing it out as a diagram makes it a bit easier to understand, but I don't have time right now to draw you one [smile]

Jack

Share this post


Link to post
Share on other sites
maybe its off the topic but could someone help me to use render() and update() functions parallel. i mean when the gpu renders the first frame at the same time cpu updates geometry positions, animations, camera posisions,... and on the second and third frame,...
any codes or links of tutorials would be appriciated.
THX

Share this post


Link to post
Share on other sites
Quote:
Original post by ehsan_the_tiamat
maybe its off the topic but could someone help me to use render() and update() functions parallel. i mean when the gpu renders the first frame at the same time cpu updates geometry positions, animations, camera posisions,... and on the second and third frame,...
any codes or links of tutorials would be appriciated.
THX


I need the links or article too.thanks

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
It'll hide the latency of any expensive code in Update(). Although, in practice whether it makes much difference will probably vary on a case-by-case basis.

If you compute Frame N's Update() before you Render() it, then rendering cannot commence until Update() is finished. However, if frame N is ready-and-waiting then the rendering can despatch the necessary calls to the GPU and return. The CPU can then be busy preparing the next frames data before the GPU is ready to accept it.

Drawing it out as a diagram makes it a bit easier to understand, but I don't have time right now to draw you one [smile]

Jack


I don't think it'll actually make any difference. Instead of rendering frame N while updating frame N+1, your updating frame N while rendering frame N-1....

Share this post


Link to post
Share on other sites
Quote:
Original post by joanusdmentia
Quote:
Original post by jollyjeffers
It'll hide the latency of any expensive code in Update(). Although, in practice whether it makes much difference will probably vary on a case-by-case basis.

If you compute Frame N's Update() before you Render() it, then rendering cannot commence until Update() is finished. However, if frame N is ready-and-waiting then the rendering can despatch the necessary calls to the GPU and return. The CPU can then be busy preparing the next frames data before the GPU is ready to accept it.

Drawing it out as a diagram makes it a bit easier to understand, but I don't have time right now to draw you one [smile]

Jack


I don't think it'll actually make any difference. Instead of rendering frame N while updating frame N+1, your updating frame N while rendering frame N-1....

Yeah, good point [smile]

I tend to write these things out as diagrams/timelines on paper to see if they make sense. Serves me right for trying to do it in my head [lol]

Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by matches81
I have a question regarding the update-then-render vs render-then-update thing:
Why is it important in which order you do that?
After all a game will be doing those things over and over, for simplicity´s sake let´s say in a while-loop:

while(game_running())
{
update();
render();
}

or

while(game_running())
{
render();
update();
}


If I understand that correctly, it would only make a difference in the first and the last frame of the game running? In every frame in between update() would follow right after render() in both cases, so it should just be the same?
At least until the whole thing gets more advanced. But then I would use update() before render(), just because it´s easier to think about it this way, at least for me.
Did I miss something?

Yes in your case it wont make any difference until you realise there are 3 main parts in my example vs your 2. The way gfx cards work is that when you swap buffers, the swapBuffer() call will not return until all rendering by the GPU has been done and the frame is ready to be swapped. All this precious waiting time could have been better spent doing other calculations. The crux of it is to do all your CPU work in between your rendering calls and the swapBuffer call. Thats all there is to it, there is no need for any length articles/links to this. Or if you still dont get it, you could google for a table/diagram showing this.

Share this post


Link to post
Share on other sites

This topic is 4354 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this