You can (and probably should) store as many tiles as you like in a single texture and render them by index.

If you're using a resource caching strategy then that makes sense, though. Otherwise I usually prefer to load resources encapsulated as objects in the lowest context that they're needed in (which is usually near the top).

[quote name='MarkS' timestamp='1356570181' post='5014560']
I need certain variables across multiple classes.
[/quote]

Why?

[quote name='MarkS' timestamp='1356570181' post='5014560']
Encapsulation prevents this.
[/quote]

Why?

How does encapsulation prevent sharing?

A Bitmap class can be used to encapsulate a bitmap/texture resource and then you just load/create an instance and then hand it to the object that will be doing the rendering. When you're done with it you destroy the object to free the resource.

Also, most real-world codebases are measured using the scientific unit "wtfs-per-minute".

When is it acceptable to use global variables?

every time you can't come up with a better solution. So it is all up to the level of the programmer involved. For experienced and educated programmers, the answer is "never" or "never with some very rare exceptions (ie. logs)".. for programmers with less experience, education and time the answer changes accordingly.

It's perfectly fine to use globals in C++, though instead of accessing them directly you should access them via functions to provide some level of encapsulation. It's just good practice to minimize the number of globals to avoid your code becoming an unmanagable spaghetti mess. For resource management, I personally use globals since passing pointers to resource repositories everywhere where needed would be much worse option.

Cheers, Jarkko

I personally use globals since passing pointers to resource repositories everywhere where needed would be much worse option.

This view seems to be resurging around here at the moment. Some points...

If you are finding you need to pass a resource container around all over the place, there is something wrong with your design at a higher level. Making the container global state just masks this problem, it doesn't solve it. How many places should it be necessary to access a texture? A sound file? A script? What kind of extensible and robust design would require access to such things peppered all over the codebase?

One of the many problems with using global state is it makes it too easy to cut corners. I'm in the depths of my physics code and have an urge to play a sound when objects collide, or update a texture to show a hit mark. Easy to do and forget that I did later. But my physics code is now linked to my audio or rendering code in a way it needn't be. If the resources are not available, it forces me to stop and think of a less intertwined solution.

Nobody is suggesting the alternative to globals is to pass a pointer to some kind of state container into every function. This is a (real-world) anti-pattern that suffers from almost all of the issues that having global state can have in terms of design. The point is it is good to let the compiler and language enfore constraints about what can access what from where.

Robust and extensible code, we have learned over the years, is build from modular, black-boxed components that can be tested in isolation and interconnected in the minimal way required. Any design that moves away from this, whether it be global state, passing pointers around to a global container, singletons, whatever, is probably not going to lead to a maintainable design when projects grow out of triviality.

While I agree with your principle in general, there are practical scenarios where global access to resources is much more pragmatic solution. When you find the need to access a resource in the depths of the code, it can be very cumbersome to change all the interfaces & functions to pass the resource all way through the necessary callstack. You may even have some very generic functions in the callstack where it makes no sense to change the interface to pass specific resources through the interfaces.

If you have need to play sound in the depths of physics code, global access to sound resources doesn't endanger modularity any more than explicitly passing the resources. In both cases you need to #include sound code in your physics code, which should be enough of a red flag.