Global variables constantly stay in memory, hence, why they are global. It's just not efficient. You pass members around through parameters in your methods.

For example:

class Foo
{
void Bar(foobar)
{
//Bar executes with "foobar" being passed to it, thus, making it available to only relevant methods
}
}


Doing things this way makes your app code a bit more efficient, cleaner and more logical.

As I see it

1. init game
2. loop
3. clean up

inside the loop are maybe 10 functions which are called every frame. And inside those functions again are more functions. Seems to me quite cumbersome to pass 40 parameters to the main loop from WinMain, and then continue to pass em down.

There's nothing to say you have to code a certain way. All I stated was fact that global variables aren't memory efficient. That's not to say they can't or shouldn't be used. What makes sense for your app is exactly that. However, I have a hard time understanding why you'd have 40 arguments to one method. Super methods are bad, mmkay. Sounds like you need to refactor your code regardless of the concern about global variables.

Can I create a function which creates them statically and returns the adress upon calls? Or are staic variables just a cover name for global variables?

Yup!

The bad sides of globals isn't really much to do with memory efficiency. It's more of a design issue - a global can be referenced anywhere that can see it so changes tend to propagate horribly around the system and code becomes brittle.

The cache issue is a bit meaningless really since the variables in question are pointers, so whether the pointer itself is on the stack or not, any dereferencing of it will involve going elsewhere in memory anyway.

Tispe - A common approach might be to have related variables held in classes. So your first few might be in a GraphicsDevice class, then you might have a GraphicsResources class that looks after your font, sprite interface etc.

[source lang="c++"]
int WINAPI WinMain(...)
{
// create window etc

GraphicsDevice graphics(hWnd);
GraphicsResources resources(graphics);

Clock clock;

Application app;

while(loop)
{
app.Update(clock);
app.Render(graphics,resources);
}

return 0;
}
[/source]

The nicer parts of this approach are that the logical lifetime of entities matches the lifetime of the variables so you can use constructor and destructor to manage acquisition and release. It also limits the access to a subsystem to only those methods or functions that actually need access, so code is less prone to break when changes happen later.

Insert obligatory arguments about the advantages to concurrency etc here. Can't be bothered.

For avoiding global rendering variables, I create to classes. One named "RenderInterface" and one named "RenderUtility".

RenderInterface does much of the heavy lifting of getting the scene ready, such as Begin,Present, setting blend modes, initialize the graphics api, etc. This does not get passed around and stays in my "Application" class.

RenderUtility will be used as a utility to create things such as vertex buffers, index buffers and render streams, etc. This will get passed around slightly, but is still rarely passed around.

Neither one of these classes are registered as singletons, but in order to build a RenderUtility, it needs to have a valid RenderInterface passed in.

You using interface in this way makes me want to ask the OP a question. Are you talking about interfaces such as the contracts that bind multiple classes to a common set of properties and methods or are you using it arbitrarily to describe a quazi-utility/factory class?