Jump to content
  • Advertisement
Sign in to follow this  
HopHopTraLaLaGdaltiBshAna

should I render and calculate on the same function

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

This days, I am programming my first 2D engine .

 

Until now I had calculated the next move of my objects in the render function .

but the speed of my objects are the frame rate , so I wanted to ask :

 

if I make antoher function that will calculated the next move of my objects, how should i make it, while loop with some sleep function ?

Share this post


Link to post
Share on other sites
Advertisement
Hi.
I wouldn't combine them in one function, splitting it keeps things clear and managable. Imagine an object nothing being visible on screen, you might want to update it, but not render it. I would prevent using sleep functions, but rather use delta/ frame time or so to manage game speed together with hardware independent game speed.

Share this post


Link to post
Share on other sites

Abstraction on many level is an important part of programming. Keep things separated that do not belong together. One option is to have an update function and a draw function and just call update every time before you call draw inside your game loop.

Share this post


Link to post
Share on other sites

It really cannot be stressed enough just how important keeping these two things are; by not doing so, you'll eventually end up with completely unmanageable code -- striving for a deterministic structure is crucial.

 

I'd suggest using the const keyword (C and C++), or whatever may be equivalent in your language of choice on your draw method and argument (if applicable). This makes it read-only, and helps to ensure that you cannot modify the rendering state. It can be a pain at times during early development of the engine, but is one of the many things that has definitely helped me in the longer run.

 

(I'm not saying you should necessarily use this structure, but showing just as an example...)

// Pure virtual abstract class for any object that can be rendered
class IDrawable
{
  public:
    IDrawable() {}
    virtual ~IDrawable() {}


    // Take care of object's frame logic needs here, i.e.: rendering 
    // coordinates or what not
    virtual void update(float delta) = 0;
    
    // const on the argument 'ctx' prevents me from modifying the global state
    // of the rendering context, and const at the end of the method declaration 
    // prevents me from modifying the object's internal state.
    //
    // No doubt is this annoying at times, but has been great for me in 
    // encouraging careful consideration in how I structure things, ultimately 
    // leading to less bugs.
    virtual void draw(const SDL_Renderer* ctx) const = 0;
};
 

 

Edited by JeffCarp

Share this post


Link to post
Share on other sites

render and update (movement) are typically handled in separate functions:

 

while (!quitgame)

    {

    render_all

    process_input

    update_all

    }

 

render_all:

for each object: object.draw

 

update_all:

for each object: object.update  

 

movement and collision check code goes in (or gets called from) object.update.

 

organizing the code this way should have no real effect on rendering speeds, so the game will still run at more or less the same speeds as before.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!