Can you be more specific about what systems you're talking about, what dependencies you have between them, and what pointers you're passing around?

You might be overthinking this. If you have a low level graphics system and higher level systems that depend on that, the easiest thing to do is just have a global graphics object/interface that other systems use. No need to even pass any pointer around because you'd just access the gGraphics (or whatever you call it) object. If you have to pass a pointer around, that should be a pointer to some context data that actually changes from frame to frame, or render pass to render pass, etc.

Start by defining your sub systems. A well defined design would solve almsot all your issues.

Game engines tend to be more component-oriented. Meaning each "sub system" is a reusable and replaceable component. Each component is an abstract idea.

For example, a "console host" is not abstract, it's a concrete type of a gui.

Therefore you want to define an interface like "IDisplayMessages" (Name might not be the best, but suits the idea for now).

A gui for console would imeplement it with cout, but a gui with openGL rendering would use glfw or glut to implement it.

The second thing you want to do is seperating your logic into groups, buisness (Game), graphics (Rendering), input,aduio, database , etc...

A map doesnt need to know how you draw it, it has some system called IDrawingService which does the actual drawing.

*Note:
It may not be the best way to design a real time application, many flaws may arise when trying to speed up the rendering.

So here is what I have I have a class for graphics that creates the DirectX 11 object, and the device context and everything else it needs to get graphics displaying on the screen. This class also contains a Map that contains all textures in the game they are tied to a name in the map. This class also contains certain methods for drawing graphics to the screen I have methods like Draw Object which you can pass in the name of the texture and the position you want it at. I have other methods like that in the class.

The other sub systems I'm referring to are like I have a class for the Console window that handles everything related to displaying a console on the screen and accepting commands.

I have a system that I'm working on that will be a level editor for the game this level editor right now is only going to be used by the internal team for developing the content for the game but that may change when the game gets closer to release. This system will be heavily tied in with the Console class.

Then I have my map and game world classes the game world class contains all the maps for the game I haven't gotten very far with this class yet as I'm working on just getting a single map displaying on the screen and updating properly with animations and when user input is present.

Right now I am passing the graphics pointer from the Game class to Map, and its various classes and what not, and I'm also passing this pointer to the Console and Level Editor classes.

I'm a little embarrassed to say that I didn't think of the idea of using an interface to the Graphics system of my game to be honest I have never implemented one before in a class I guess I will need to go do some research on how to properly do this because I do remember reading about using interfaces in game development just never implemented one myself.

Ok so it sounds like you have a Game class that creates the Graphics object and then passes a pointer to that to anything that needs to render? This is really not needed because you just create your D3D device and that's what gets used all the time. So yeah, you just need a global pointer to your Graphics class which you can instantiate once when your app starts (before anything tries to render or create any graphics resources). If you extern that pointer in your graphics header file then you're set because now anything that includes it can call functions on that class.

As far as that graphics class interface, if you make it generic then you can implement it however you want based on what platform you're supporting. So for now you have just a D3D implementation, but you might want an OpenGL one later. If your interface doesnt rely on any D3D specific concepts or code, then you should be fine.

OK me again ignore my rants and my dumb questions I figure it out I had to move the actual declarations from the game header file to the game cpp file and the error went away and everything works again so this was a simple dumb error on my part. But you live and you learn and I have learned quite a bit today so kudos to everybody that gave me their thoughts on this and thanks to everybody on this website because I have learned so much from these forums and the various articles on here as well.

Sounds like you solved it. One thing I would recommend is to separate things out into logical units as much as possible, and try to keep your dependencies so that lower level systems dont have to depend on higher level ones. So, it sounds to me like you have your graphics code and then your game code, and possibly other code that will need to render stuff. But, that other code should not depend on the game code, because in theory your game code is the highest level. What that means is that your g_graphicSystem variable should be declared in the graphics code so that other systems can use it, but not in the game code.

Now I dont know exactly how your code is structured, but I'll give some examples going along with what I think you're doing:

// lowest level

graphics.h (extern your g_graphicSystem pointer variable here)

graphics.cpp (includes graphics.h, define your g_graphicSystem variable here)

// mid level

console.h (includes graphics.h)

console.cpp (includes console.h, you can now use g_graphicSystem variable here since you included graphics.h through console.h, and dont need to include game.h)

// highest level

game.h (includes console.h)

game.cpp (includes game.h, you can use anything in graphics.h or console.h)

Basically you want each system to know only as much as it needs to. Your g_graphicSystem variable will need to be used in either the graphics, console, or game modules, so you put it at the lowest level... the graphics module. Then you work your way up from there. The game module (in this example) is the highest level and you only want other things at that level to include game.h. So the game module knows about the console module, but the console (or graphics) modules should never need to know about the game module.

I hope that's helpful and that I didnt misunderstand your problem.

Do what WoopsASword suggested. Split your Console classes into two entities: Console itself and ConsolePresentation. Console has a bunch of typical methods and a pointer to ConsolePresentation. ConsolePresentation is an interface responsible for drawing console contents. This way you'll separate console logic from visualization details and the code related to console rendering will be in one place which will make it easier to maintain in case of changes in Graphics subsystem. Plus as WoopsASword said you'll be able to have different console representations (std::cout, UI or using your renderer).