26 minutes ago, matt77hias said:

member methods

ResourceManager::CreateWhiteTexture(ID3D11Device *, GUID, string)

This is obviously wrong since objects should only have a bare minimum interface. (cfr. Non-Member Functions Improve Encapsulation

ResourceManager::ResourceManager(ID3D11Device *)
ResourceManager::CreateWhiteTexture(GUID, string)

Problem solved...

59 minutes ago, matt77hias said:

CreateWhiteTexture(ResourceManager *, ID3D11Device *, GUID, string)

This makes everything extremely transparent, but it results in lots of boiler plate. If I would have a method GetResourceManager() and GetID3D11Device(), I could have skipped the first two arguments for a start. And multi-threading will still work since I guarantee that both ResourceManager and ID3D11Device can be used by multiple threads at the same time?

Actually the question here is why are you not using the service locator you mention in the OP?  I.e. you should rewrite that function as:

CreateWhiteTexture(ServiceLocator*, GUID, string);

There are quite a few benefits to this approach.  Primary among the benefits is that you can change everything about how to create a texture, update this function to match and not have to touch any of the uses of the function afterwards.  This is the pattern I tend to use all the way from the main function on up.  If you centralize everything around a combined Factory/Locator abstraction there is a little bit of extra setup boilerplate 'within' wrapper functions such as CreateWhiteTexture but very little when using the function.  I.e. in my codebase it would be something like the following:

TextureBase* CreateWhiteTexture(ServiceLocator* locator, GUID guid, string name)
{
  auto driver = locator->Get<RenderDriver>();
  auto resMan = locator->Get<ResourceManager>();
  ... make a texture etc ...
}

That's not *too* much boilerplate to deal with once in a while when writing these helpers is it?  I admit, I tend to take this to a bit of an extreme level given the choice simply because I've been bitten by singletons so many times over the years that I never want to see such things in the future if I can help it.  Going back to hodg's reply, I don't even believe in singletons for executable resources for the most part.  For instance, the command line passed into main, my "Application::Main" never see's that, it can get the 'environment' object from the locator passed to it after the per platform main/WinMain/DllMain/whatever has setup the process.  It's a bit extreme but can be really useful for instance if you ever worked on an MMO and needed to startup 100 headless clients to stress test servers.  Starting 100 processes is typically bad, but if you have abstracted away the entire environment from main on up, you can just call "Application::Main" 100 times even passing in custom command lines, different cin/cout abstractions (i.e. feed to logging instead of console) etc etc.

10 minutes ago, matt77hias said:

Engine (which is the service locator itself)

Ah, you are breaking SRP at multiple levels then.  But, even without that, the suggested referential chain is another case of writing a helper function rather than typing that over and over.  So, you could rewrite that chain as:

BindPointSampler<PipelinePS>* GetBindPointSampler(engine, slot) { return ... chain of references ... ; }

This goes back to the cohesion problem.  By writing the chain of dereferences you are exposing the ownership into your code.  If you encapsulate the chain of dereferences as above, if and when you decide to change the referential chain you don't have to go hunt down every use case, just change this helper function.  Additionally, you can write a couple variations such that if you already have the state manager, it will automatically start at that point rather than going all the way up to engine.

Obviously though you should be keeping your reference chains as short as possible.  Anytime I see a reference chain longer than two hops, I tend to think there is something wrong.  GetSwapChain(engine) is probably a bad chain, GetSwapChain(window) or GetSwapChain(renderer) are both shorter and imply more context around what you are doing and as such, have less of a cohesion problem exposed.  Or, even better, hide the swap chain completely and only have GetCurrentImageView(renderer).  Utilizing helpers in this way means you don't expose the ownership outwards from the things that actually need to know such things.  When done well your high level code is extremely simple and linear and independent of how you might want to restructure things later.

2 hours ago, matt77hias said:

This makes everything extremely transparent, but it results in lots of boiler plate. If I would have a method GetResourceManager() and GetID3D11Device(), I could have skipped the first two arguments for a start.

As Kylotan suggests, this indicates that maybe a resource manager that tracks the device will be more useful than one that doesn't. You don't need to have a CreateWhiteTexture on the resource manager itself - you can write a CreatureWhiteTexture function that just takes a resource manager and creation data, and then have the resource manager use its internal D3D device to create the texture.

Or, you could put stuff needed for texture creation into a texture factory (which would track the device), and put the texture creation method on that, then pass the created texture to the resource manager when it has already been created. For example, something like:

resourceManager.RegisterTexture(CreateWhiteTexture(textureFactory), guid, name);

44 minutes ago, All8Up said:

Actually the question here is why are you not using the service locator you mention in the OP?

I can think of one reason, which OP doesn't cite - the service locator pattern is just a "better" way to have singletons. Being able to switch out objects from the service locator at runtime is nifty, but it still has the problem that globals and singletons have where it hides dependencies within the methods that use it, rather than making them explicit,. The service locator still looks like global state to client code and most implementations of it still only allow one of each type of object to be located from it - both of which are problems. I see it as a crutch for dealing with globals-heavy legacy code; in new code, it'd call it an anti-pattern.

1 minute ago, Oberon_Command said:

57 minutes ago, All8Up said:

Actually the question here is why are you not using the service locator you mention in the OP?

I can think of one reason, which OP doesn't cite - the service locator pattern is just a "better" way to have singletons. Being able to switch out objects from the service locator at runtime is nifty, but it still has the problem that globals and singletons have where it hides dependencies within the methods that use it, rather than making them explicit,. The service locator still looks like global state to client code and most implementations of it still only allow one of each type of object to be located from it - both of which are problems. I see it as a crutch for dealing with globals-heavy legacy code; in new code, it'd call it an anti-pattern.

Well...  I don't promote the idea of using the locator to hide such details, I only mention it as "you could" do so, not should.  And I agree that such things should be avoided as a better practice.  I tend to get into that a bit more when I mention minimizing the referential chains, those are just evil.  I'm unsure of the OP's desires though, so when you have a hammer, everything looks like a nail kinda applies.