Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 20 Aug 2012
Offline Last Active Mar 31 2015 03:05 PM

#5200637 Game class holding a pointer to Renderer class

Posted by D.V.D on 29 December 2014 - 02:55 PM

"Same with that. Not everything is a interface. If you inherit the scene, I suppose you pretend to put some logic data inside, but a scene just have drawable actors  (sprites in your case), lights, cameras, etc. Logic is a good canditate to live in the game state or some mechanism out of the scene scope. The scene can have functions like: GetAllObjectsOfType(...), GetAllObjectsInsideSphere(...) (altough this fits better in the physics library).


Soon you'll see that passing the "renderer" pointer around is good for design and tedious for maintenance."


Im very confused about your resoning here. It seems very normal for there to be a scene interface, I could have 2d scenes or 3d scenes and 3d scenes could be octrees for some games, bsp trees for others, or just lists for smaller ones. Ensuring all of them have a render method and implement the scene interface seems like a proper solution.


"The game is an loop that will update N times per frame, where N = FRAME_TIME / FIXED_TIME_STEP.

The low-level libraries belongs to the game engine. "


Then how does the game gain access to them unless I give it pointers to own?


"Your sprite needs to be rendered with an interface not a specialized object – that's why is an interface. I won't give any suggestion here because I don't use SDL, but you're doing it wrong if  you're pretending to have an interface that needs to be static casted in real-time to use the interface; doesn't make sense to be an interface."


Im going to have to disagree here. The Sprite is a implemented renderable for the SDLRenderer and SDLScene. I guess it would make sense to call it SDLSprite or something. It has to have access to stuff from SDLRenderer because it will only be rendererd by SDLRenderer. Its like knowing an OpenGL Renderable won't be rendererd by a DIrectX renderer. However the OpenGL Renderable will need to know some specific functions of a OpenGLRendere to set the proper shaders, uniform variables, etc. Same thing in this case, the SDLSprite needs to know some stuff about the SDLRenderer in order to be able to render itself properly. The problem is more so of should the renderer render the renderable or should the renderable know how to render itself. In this case, it gets pretty messy if the renderable has to render itself but the opposite is true when you start using OpenGL or DIrectX.


"A private destructor? An obligation here? Make them public destructors, propagate on all of them and delete them when the scene is destroyed. You can use shared pointers; search in the forums."


Yeah I could but thats double indirection. In this case its not that important but if I wanted to do an std::vector instead, the difference between a vector of objects vs a vector of pointers to objects is a lot bigger in terms of performance and I want the ability to potentially optimize in the future. BTW, what do you mean by propogating on all of them? The worry is that somewhere outside of the scene code in the game code a destructor will get called when it shouldn't.



"It looks like he is deleting those operators (by making them private), which is a smart thing to do, because otherwise they can be generated by default.


With C++11 this can be done explicitly, by saying:

IRenderer(const IRenderer& other) = delete;

But prior to C++11, the only way you could 'remove' an operator is by making it private, like D.V.D is doing."


Yeah exactly this.


"Yeah I know, but if he'd to do this to every class that should not be copied/instantiated explicitly he'd be writing for a lot of classe for the same reasons. I'm just warning him that such thing is out of scope when trying to solve a problem that's bigger than that.

Intrinsically he could copy the engine, game, etc., when its much more easier to just don't do. What is better than explicitly defining what something can't do is just don't do it when isn't necessary.  If we can't manage how things are working in the engine, we can make any progress further obviously. 
If someone isn't using a C++ 11 compiler (like me) things would get messy by don't knowing what to do (instead of having a global solution that works even old compilers).
Another suspecious spot is that he is creating a private constructor for an interface class, with no members, which in that case can't be instantiated at all.
In his way he is explicity defining that he don't have enough control of the life cycle of the renderer laugh.png (not criticising)."
Im confused, if your not using a C++11 compiler thats how you remove access to copy constructors. This is something lots of people on this site and in the industry talk about (ie Rule of 3, 5). Isn't it always better to explicitly define what a class can or can't do instead of assuming it can't be copied? That assumption could be forgotten over time and cause lots of bugs later if people do start copying. Also, which class is the interface with private constructor? I looked at the code I sent you and only the Sprite class has a private constructor but its not a interface, it implements an interface.