This is pretty much a question of software design/engineering - there are a variety of ways you could go about "solving" this.

I'm in the camp that global variables aren't a good idea - for simple/closed systems they're ok, but it's just too easy to go breaking things. Or, more importantly, it's extremely difficult to track down the offending code when everything has access to the thing that breaks [smile]

Your idea of grouping them together as a struct, presumably a global one, is a bit tidier but still presents the same problems...

In my experience I've always wrapped things up as a class - making heavy use of encapsulation to hide the real implementation. However, none of my implementations have been great (hindsight is a wonderful thing).

I don't have any links to hand (maybe someone else will!) but you might benefit from digging up some of the classic software design books or articles.

hth
Jack

Hi,

I do it in the following way:
have a RenderingView which has the device, and all the things that are relevant for a view (eg. the camera position). It has a TextureFactory, ShaderFactory and a FontFactory, which all receive a pointer to the RenderingView in thei constructor, so they can always get a pointer to the device if needed. They can also have a copy of the pointer if it's needed often (and this is more common case). Then, the rendered objects (I call it GeometryElems) are created from the view, they also get a pointer to the view. The parts of the elements that have the same material will be divided into other entities for simplicity, but don't go into deeper details now. So they don't have to be globals at all. Ok, if eg. a GeomElem needs a texture, then it will need two levels of indirection, but if you need it many times, you cal always get the pointer once, and then use that one many times.

I don't say that this is good, I just say that this is how I do it.
Hope you will find some useful ideas.

kp

My engine is structured out in components - for example, the Engine component, Game component, Graphics component, Input component, ect... The Engine components holds all of the other components, and you can access each component through it. For example:

engine->GetGraphics()->GetD3DDevice();

The singleton Engine object is global, so it can be accessed from anywhere. At this point, you can pretty much get into whatever you want - game subsystem, graphics subsystem, whatever. It's very flexible.

For D3D objects that need an IDirect3DDevice9 pointer for any function call other than initialization, I store a pointer to the device in that class. This avoids overhead from calling engine->GetGraphics()->GetD3DDevice() repeatively.