Best approach to a class that handles graphics

Question

When I'm programming any kind of application with opengl, direct3d, sdl or any graphics api (games, in general) I have the habit of creating a class named Graphics that have everything needed to draw, load images, initialize window, etc. inside of it. There is an instance of this class inside another class, that is the main class of the program, or game, or anything that is going to use it.

As the years passed, I tried a lot of different approaches to using this, and I would like to know if you guys think some of these are good, or if everything is just useless crap and I should do it another way.

1 - Having an instance of Graphics inside the program class and having a function in the programs class that iterates the objects (game objects, like the player, for example) and call the Graphics methods to draw everything accordingly.

2 - Go passing pointer to Graphics to every single object so each one can have a Draw function and call the appropriate Graphics functions themselves by means of this pointer.

3 - Have everything inside Graphics to be static and eliminate the need of creating an instance of graphics. Then you can call every graphic functions from anywhere.(You would just have a Draw function to each object, just like topic 2)

Thank you.

Edit: And what if I make something similar to what iostream does with cout, like, just make a header with 'extern Graphics x;', declare x in a cpp file and, then, call everything from this x. Is this too bad? And if it is, why?

Answer 1

Well, I think that a "graphics" class can very well have a state, like, for example, a canvas it is drawing on. Therefore, making it a class is good; by creating a class you can make the same set of functions applicable to different types of "canvases" (opengl, directx, sdl, etc.)

Among your options, I think that option 1 would be the best, but option 2 would be the easiest (and option 3 is horrible, because it makes code dependent on global variables, eliminating reusability of your code - it is the hacker approach :D).

Option 1 is great, because you could write a graphics engine that does intelligent stuff with the things it draws: Assume that you have two objects that share the same textures, but use a different mesh. If programmed appropriately, the graphics engine can call the "draw mesh" functions of both objects with the same render settings, in this case the same texture, which speeds speeding up rendering. This is not possible with option 2, which usually groups draw functions for single object together, leading to more changes to the render settings.

Option 2, however, is easier to implement. If you do not need a lot of render speed, I would go for this one, as it is much less work, and leads to a more logical program structure. To realize option 1, like I explained, an object needs to have "render properties" or such, that need to be matched by the render engine, and different draw routines for different draw settings... very complicated in comparison to an object-draw function that just uses a central set of drawing functions like a Graphics class.

So if you opt for a "large project", choose option 1. For fast results, and if you do not need to draw a lot of things, option 2 is probably better. Usability for options 1 and 2 is similar.

PS: Sorry for the late edit, but my grammar was horrible in the previous version

Answer 2

I have trouble figuring out what a "Graphics" object is. An object in software is analogous to an object in real life, so what would a Graphics object represent?

The way I usually do it is not very different from a standard UI application: I have a Window class that can be instantiated multiple times and a MainWindow class that inherits from Window and is only instantiated once. In that MainWindow class I have all the graphics resources that will be used throughout execution (e.g. the Direct3D device object).

Answer 3

I would opt for a fourth option, make Graphics a namespace, not a class.

It doesn't sound like a Graphics is a data type, just a collection of functions. That's exactly what namespaces are for.