To answer the original question: if something genuinely is needed all over the place then a global is fair enough – or, this being C#, a public static member of something. I prefer a Globals class as opposed to making singletons; as someone said above, you never know when you need two or more things, and it can be hard to re-engineer a class that only expects one instance of itself.
For a game, I'd tend to put 'global' things in the Engine class: one instance of the game engine requires one renderer, one sound manager etc. So they're not really global; if you had two game engines running at once you might well need more than one of each. But they
are public and therefore visible all over the game.
But, and to reinforce what other people have said,
generally globals are indicative of bad design – even 'pseudo-globals' like this. I would limit globally available things to the top level components at most, and perhaps even those shouldn't interact with each other but should have everything choreographed by the Engine class. But there are of course no hard and fast rules in design issues.
To just go through the things you mentioned:
Quote:Things like the directx device, camera, player actor reference, camera location, frustum, resource manager etc will be used all over the project.
The DirectX device handle should be visible only to the renderer, so it should be a private field of it, not a global.
The camera location is a part of the camera object! The frustrum should as well, unless I misunderstand what you meant there (what the camera can see is a property of the camera).
The camera object is probably fair game for 'pseudo-global' nature, as the renderer needs to know about it (obviously), and it may be influenced by in-game events.
The 'player actor reference' should be visible to the input system, so it knows which entity to control, and to the HUD. These systems can just be given a reference to the right entity on level startup though.
The resource manager depends on your architecture, but it's likely that this should be a 'pseudo-global' (public within the engine) as various subsystems may want to use it.