I got this working a while ago but have only just recently got round to cleaning* up the code to release it. (* code still isn't really that clean)
I've written a proof-of-concept library (which you can get over at github: https://github.com/adaephon/InjectedXna/) that allows you to use XNA to draw inside WoW. It's a fairly hackish solution, but it works (relatively well at this stage, hasn't been thoroughly tested).
The basic premise is as follows:
- Start process suspended
- Inject .NET Bootstrapper / .NET DLL
- Hook Direct3D Device creation
- Intercept device creation, and create XNA GraphicsDevice
- Intercept XNA device creation, do some magic with the presentation paremeters
- Extract native pointer from XNA GraphicsDevice, detour EndScene (etc)
- Resume process, start XNA 'InjectedGame' which uses the GraphicsDevice created on startup
The GraphicsDevice creation looks like this:
Code:
private static uint IDirect3D9CreateDeviceHandler(IntPtr thisPtr, uint adapter, uint deviceType, IntPtr hFocusWindow, uint behaviorFlags, IntPtr pPresentationParameters, [Out] IntPtr ppReturnedDeviceInterface)
{
uint ret;
if (!_isXnaCreateDeviceCall)
{
try
{
var nativePresentationParameters =
(NativePresentationParameters)Marshal.PtrToStructure(pPresentationParameters, typeof(NativePresentationParameters));
var presentationParameters = nativePresentationParameters.ToXnaPresentationParameters(hFocusWindow);
_preservedBehaviorFlags = behaviorFlags;
_isXnaCreateDeviceCall = true;
_xnaGraphicsDevice = new GraphicsDevice(GraphicsAdapter.DefaultAdapter, GraphicsProfile.Reach,
presentationParameters);
var pComPtrField = _xnaGraphicsDevice.GetType().GetField("pComPtr", BindingFlags.NonPublic | BindingFlags.Instance);
if (pComPtrField == null)
throw new Exception("Unable to get pComPtr field from XNA Graphics Device");
unsafe
{
var pComPtr = new IntPtr(Pointer.Unbox(pComPtrField.GetValue(_xnaGraphicsDevice)));
Marshal.WriteIntPtr(ppReturnedDeviceInterface, pComPtr);
_endSceneDetour = pComPtr.VTable(IDirect3DDevice9VTable.EndScene)
.DetourWith(EndSceneFunc);
_resetDetour = pComPtr.VTable(IDirect3DDevice9VTable.Reset)
.DetourWith(ResetFunc);
}
// TODO
OnCreateDevice();
ret = 0;
}
catch (Exception)
{
// If we get an exception trying to create the XNA device, just call the original method and pass out the return
ret = (uint)_createDeviceDetour.CallOriginal(
thisPtr, adapter, deviceType, hFocusWindow,
behaviorFlags, pPresentationParameters, ppReturnedDeviceInterface);
}
}
else
{
// Now we're inside the XNA Device's call to CreateDevice - get our cached presentation parameters and add a required flag
// TODO: check this process / flag
var pp = (NativePresentationParameters)Marshal.PtrToStructure(pPresentationParameters, typeof(NativePresentationParameters));
pp.Flags |= 0x1;
Marshal.StructureToPtr(pp, pPresentationParameters, true);
ret = (uint) _createDeviceDetour.CallOriginal(
thisPtr, adapter, deviceType, hFocusWindow,
_preservedBehaviorFlags, pPresentationParameters, ppReturnedDeviceInterface);
}
return ret;
}
The example uses Extemory (https://github.com/jeffora/extemory) for DLL injection, memory editing, detouring etc, but there's no reason it couldn't be implemented using your injector of choice / mem editing library of choice. As part of the POC, I've modified one of the basic Microsoft samples (Primitives3D) to work using InjectedXna. As you can see from the code, I didn't have to modify much, and using conditional compilation you can still run it as a standalone XNA game. Interestingly, the HandleInput routine worked without needing to be touched, meaning you can click on the screen and change the shape / colour / turn wireframe on or off, as per the standard sample.
There are still a few bugs, and the code is far from perfect. For instance, after exiting WoW, the process doesn't close properly (you have to End Process from task manager). I think this is a problem with my bootstrapper / injector (Extemory). It also has one C++/CLI class to expose the IDirect3D9StateBlock which is a bit of a pain. There are alternatives to do it all in .NET (like SharpDx), but by the time you pull something like that in, you have to wonder why you're still using XNA. The XNA GameTime class also has internal setters, so at the moment I'm setting the time values by reflection, which is obviously a lot slower than native property setting, but at this stage doesn't seem to be an issue.
As I said, it's mainly a buggy POC, but interested to hear any thoughts / feedback.