[SDL] Where SDL goes in your game

[Facundo Dominguez - INCO]

Hi, There:
   This really took my attention. I have some answers but not truths.
   I throw them for the sake of discussion.

> - GameObjects  ( super-class )
 
   I have a similar thing with methods to draw it at some position in the game world, and to update it every few frames. Yes, sometimes I need to downcast a GameObject to a derived class, but the books of C++ I read tells this is quite unavoidable in some circumstances. This is a limitation of C++ type system, I think. And C type system is not better ...

   
> As for efficiency, planning and game design, is it best to:
> 
> A) have a separate class specifically for all the SDL stuff ( surfaces, music, 
> sound effects, etc. etc. )

  Yes! A! A thin layer over the API lets you tweek its semantics to better fit your needs. Then if you whish you can always make the layer functions or methods inlined to remove the call overhead.

> In an SDL program, ( speaking in 2D terms ), you have surfaces. Let's say you 
> have an image you want to place onto the screen. Let's say this is an image of 
> a Ball. Do you:
>
> A) create a separate class to hold all your SDL data and place that surface 
> (SDL_Surface* ball) into that class
> B)
> place the  surface (SDL_Surface* ball) object in the Ball class 
 
¿Are you going to share image data across objects who use the same image? 
¿Who is responsible for freeing the image data?
¿Do you have something like a resource manager to make the housekeeping?
You need for sure some way to link an image to (some of) your game objects, there's
more than one way to do that. I think there's not a one for all solution, since it 
depends a lot on the resource management you are planning.

Regards.