Ramblings++

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.