Ramblings++

Hades now has extension loading support! The API is still in the process of being exposed to the extension interface, but that should only take another 15 minutes or so to smooth out.

This is a great step forward because it means extensions can be loaded and unloaded on the fly without having to restart the process (as was the case when it was compiled as a static lib). Furthermore, it means that the modules are independent from changes to the Hades DLL and as long as no breaking interface changes are made should work with updated DLLs without the need for a recompile (as opposed to a static lib where a recompile is obviously necessary, or rather, a relink).

Naturally, both x86 and x64 are tested and working.

One issue I had with this was with the exposure of the interface. It seem that I can’t do what D3D does and do a C-style interface exposure because my interface is just too C++ heavy for me to be able to convert it to work that way. Not that it matters though, all the information exposed via exports is already available in the SDK.

Update (29/06/09):

Scratch that issue, got it working through some minor modifications and the magic of virtual functions! (Okay not magic, but it’s still a nice workaround.)

Yes I know I said I’d be looking at the new mimic build and I still will, but recently I’ve just been busy with more interesting stuff.

I added base .NET support to Hades (thanks Grey and Kynox for the help) . I improved the LUA support. I began adding event subscription support to LUA, I began adding event subscription and callback support to .NET, I continued the implementation of some D3D helper libs I was writing, and lastly, I began working on some random WoW stuff in order to test all the aforementioned things.

It’s just a ‘PVP mode’ ESP hack designed to make PvP just that little bit more unfair. (Thanks to Kynox for the camera/w2s stuff!)

Green is low risk (friendly), yellow is medium risk (hostile but not an immediate thread), red is high risk (hostile and an immediate threat).

Just finished adding the very first revision of LUA support to Hades. Currently it’s just a proof of concept, as all it does is load a LUA script which calls a custom function I’ve registered to print the arguments passed to the function to the console. Getting that first bit done and working though is the biggest hurdle, so with that finished I can now move on to writing proper code for it and exposing my whole API.

Both x86 (WoW) and x64 (HL2) builds are tested and working.

Recently I’ve been doing a lot of bug fixes for Hades in order to increase compatiability with a number of Valve’s games. During this time I came across a bug that fixed a LOT of issues I was having. Currently Hades hooks SetWindowLong and SetWindowLongPtr in order to prevent the game subclassing the window and inserting a custom window procedure above the one owned by Hades. The reason this needs to be done is so that I can ensure Hades always gets ‘first dibs’ on input into the game.

I noticed though that this was causing problems with a number of Valve’s games. After reading over my code for a bit I came across the bug which was obvious in hindsight yet seemed innocent enough at the time. When implementing the hook I got a little lazy, and rather than subclassing only the window handles passed in by the D3D layer, I was just hooking ALL windows that were being passed into the API. Needless to say this is NOT a good idea and can cause great instability.

Low and behold as soon as I filtered it just to rendering windows the issues went away and a handful of games ‘magically’ started working properly.

Whilst I’m much too lazy to actually debug it to the point where I can work out which window was causing issues and why, it suffices to say that it’s probably a bad idea to hook any more windows than you actually need.

Screenshots of the newly supported games:

I just managed to get Hades working in native x64 mode, which is a huge step forward. Not even InnerSpace can do that at the moment. Currently I only have one game to test it on because I can’t find half my fucking game discs >.<. I’ll be getting my hands on some more x64 games soon though, so that should be good.

The game I currenly have and am testing is Half-Life 2. Below is a screenshot of the first working build. Please disregard the profanity, Kynox was trying to troll me on IRC about not being able to get it working, and pretty much just as he said that I did infact get it working .

I had some very minor issues porting the code over, but luckily (and surprisingly) I didn’t fuck up much at all so it nearly worked “out of the box”. Only took about 30 minutes to track down and fix the issues I was having.

Pretty much the only one that was an actual issue and not just caused by a typo, wrong datatype, etc was with hooking the window subclassing APIs. Don’t forget that SetWindowLongPtrA/W resolves to SetWindowLongA/W via a #define under x86, yet is an actual API of that name under x64. If you don’t explicitly handle that then you’ll be hooking the wrong API and you won’t be able to get subclass detection and rehooking working correctly (if at all).

Honestly I’m amazed at how easy it was to get working. Makes me wonder why the rest of the tools out there are lagging so far behind.

Anyway, I guess I’ll test this for a bit longer, fix any bugs I find, then move on to getting D3D10 working and stable.