"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.