I have a class called VideoHandler that intializes SDL video and sets up OpenGL (which I could replace with Direct3D or some other system since it's hidden). It keeps a list of Sprites, which are rendered every time an "update" event is handled. Sprites contain Surfaces (which are just texture objects) and Sprites also have a parent and a list of children. For a sprite to be rendered, it must be added to the list of sprites.

Derived from Sprite, there is also AnimatedSprite (which contains an array of rectangles), String (which uses a Font), and TileMap. (Yes, a tilemap is a sprite.)

It works well, but it's still very young.

Quote:Original post by speedie
I'm getting close to finishing my renderer, but I'm curious as to how all of you organized yours.

Currently my core encapsulates DirectX, texture management, Light management, and fonts.

my next goals were to allow loading and displaying of 2D animations, and a Particle engine. For these types of things, do you guys just pile it all into your graphics class, or do you make seperate classes that use the graphics class. What are the pros/cons of both?

There should be a group of classes that interact with each other, not one monolithic class - monolithic classes kind of defeat the purpose of having classes in the first place.

Search for the Renderable() idiom on GameDev - there's been plenty said about it.