Direct 3D Imports

[MarkR]

I'm thinking to use CEGUI in some kind of DirectX Overlay software, which would mean to inject the CEGUI DLLs into an already running program.
This means, that I don't know what RendererModule to use when the DLL is injected.
To make things easier, I wanted to include all available RendererModules (at least D3D9-11 and OpenGL for now) into one single DLL, statically linking the CEGUI.
To avoid the problem with the D3DX9-11 modules, that functions with similar names but different declarations are needed, I made a class "Direct3D{9,10,11}Imports", which loads the DLLs manually (try to find a matching DLL using "GetModuleHandle", if nothing is found, load one with "LoadLibrary") and imports the functions by GetProcAddress.
Would those changes make sense to you for the "original" CEGUI version?

[Jamarr]

I am not that familiar with hooking into applications, but your overall approach sounds reasonable to me. However, I do not understand why you would need to compile all of the rendermodules into a single dll, nor statically-link anything with cegui to achieve this.

[MarkR]

To hook an application, you need a DLL which exports the hooking function(s). You don't know what processes are injected, because they may be started afterwards. You'll know what rendering system is used as soon as your hooking-DLL is loaded. You _could_ then load the CEGUI-DLLs on demand, depending on the rendering system found, but, well, why? I personally like the idea of having a standalone executable (which it isn't as it loads the DirectX DLLs, but noone cares about _that_)

Another problem I could imagine is the D3DX stuff.
A D3DX DLL could already be loaded by the game, however you'll never know which. There are 20 different d3dx9.dll files right now on my system (d3dx9_24 up to d3dx9_43). Using the GetModuleHandle approach, I'd probe all known D3DX DLLs and avoid loading of a rival d3dx9.dll. Btw, the same thing could occur if you'd use precompiled CEGUI DLLs / libs.

I can't tell if having two different d3dx9.dlls loaded at at time would necessarily lead to a problem, but you never know.

[Jamarr]

You _could_ then load the CEGUI-DLLs on demand, depending on the rendering system found, but, well, why?

That is pretty much what I was getting at. Putting all the RenderModules into a single-dll just seems like extra work for no gain?

Using the GetModuleHandle approach, I'd probe all known D3DX DLLs and avoid loading of a rival d3dx9.dll.

That sounds reasonable to me.

Also, I am just being curious here, but are you making a generic framework to hook into any game, or is this for a particular game? And what is the reasoning for doing so? And are you also re-writing/extending parts of the game (via assembly?) or forging packets to a server perhaps?

[MarkR]

Yes, this should be a generic GUI framework for any game...
I intend to use the GUI in my TS3 Overlay plugin (http://ts3overlay.r-dev.de). I don't want to rewrite / extend parts of the game, the only "real" assembly magic that is used is the code to intercept the D3D / OpenGL-Calls.

[Jamarr]

Ah. I used the original TS overlay a long time ago. It is a really useful application. I assume there are a few different projects working on TS/Vent overlays now? It certainly would give you an edge to have an extensive/customizable GUI. Good luck with your project