Any chance to make SOM friendlier to DirectX9 and beyond?

[Holy_Diver]

Well the weather had knocked out the internet/tv for tonight, and I had a bug to do something in the middle of the night, so I ended up redirecting SOM's WindowProc() procedure. Unless SOM uses some fancy DirectInput crap that bypasses the WindowProc, this is how many messages including keyboard and mouse events are interpreted by a window. So with this technique we should be able to add extra keys to SOM, like for starters I'll probably use up the remaining F (function) keys for stuff, but there is really no limit. We could also draw GDI type stuff on top of SOM and use the mouse as well. Ultimately all of this will be configurable in an ini file with the same name as the proxy dll.

I think I have an idea of how SOM draws it's text to the screen. I think it uses yet another interface after directdraw, and direct3d, actually that last interface is called directx I think... though afaik directx also includes all the prior crap including directinput/sound/play/etc. I have at least one major reason to hook the text drawing routines. It really bothers me that items in your inventory there are only one of say x1 instead of just nothing. I think it's kinda tacky in general, but it seems dumb for unique items and even pseudo (action) items like I like to use to extend the basic command set.

^In general there can be a lot you can change up with the text, considering all printed text tends to include a printf like format string (how I added the percent sign after the HP and MP numbers in my status screen and other things) ...but there are limitations which could be routed around by catching the text as it goes to DX and modifying it on the fly. Still situations where the text is identical but you only want to change one case might be tricky or even impossible.

[Holy_Diver]

I realized sometime today SOM is just using the WinAPI DrawText() routine, which was kinda the only game in town back then other than rolling your own text rasterizer.

That should've been obvious to me given the DrawText import string in the SOM.exe text section. But I wasn't convinced SOM was using GDI over DX. So anyway,

I was pretty stumped on whether it was possible or not to catch SOM's DrawText calls. So the question kinda grabbed hold of me... and after two or three hours I was successful in hooking the DrawText entrypoint thanks to this project (https://easyhook.codeplex.com/)

Don't ask me how their stuff works, but it is very hacker like. I don't think the library uses any approved Microsoft measures, but it works... probably via some back doors MS has left open for itself.


These last three posts are very huge deals... you guys are going to owe me all the possibilities this stuff will open up


PS: This hooking technique can be used for other stuff. I'm not sure what all I could think off. One thing it can do is change text without physically modifying the SOM.exe file. But it can also probably do things like tell SOM to look into different folders for it's files depending on some configuration option. Who knows what all else.

[Holy_Diver]

Offtopic (as usual) but the way the easyhook^ library is working I'm thinking has got to be it is really overwriting the code section of the loaded exe image. So like it actually erases the front end of a routine and replaces it with a reroute to a setup that then jumps the processor to the hook then back. So really this is the same as code injection (injection is actually the language easyhook uses) only it's done over the running exe after it's loaded up. Which to me, I think is safer than having multiple versions of the exe floating around.

There is probably some merit in disassembling SOM. Or really I mean decompiling I think. If we could find for example the entrypoint of a routine that is always/only called when processing each event instruction then I could setup a sort of calculator system, that would let you do complicated math inside an event, by loading two counters for example with different values, then reading from a third product counter which would already have the product of the two operand counters loaded. This way we could do multiplication with three instructions in a row. Where as presently the only way to do multiplication and division is to always use always on events (or multiple adds if one operand is fixed for multiplication)


EDITED: Btw, using this runtime hooking technique might not be compatible with Windows before Win2k, but I'm not positive. Not really a prob I think. If so, it's probably possible to do the same thing via another (probably simpler) means with older versions of Windows, but I'm not positive.

[Holy_Diver]

Hmmm, I tried to run my own project thru this setup instead of my little testing project space. It was really slow, so I go to see if it's accelerated or not (well it looked accelerated) and saw the driver numbers cycling like mad (or whatever it means when SOM throws random numbers up instead of a resolution)

Anyway it seemed like SOM was rebuilding the direct3d device every frame or something. I've come this far, so I'm fairly confident figuring out what is wrong won't be too much more work.

I don't think anyone else is going to be playing with this too soon, but it might be a little longer before I upload anything for you guys to play with.

That said I don't think it's too soon for anyone to start making hacking requests for their projects. We really have a lot of options at this point. Still nothing on the joypad or sound front (that will mean applying the same techniques to dinput/dsound) ...I wonder though if I could fashion a keyboard config setup (you know I think I kind of remember seeing more stuff in the ini files for some Japanese games... it may be the manual has more suggestions than appear in the default ini file)

^I know I can add new keys, just haven't done tests about rewiring built in keys without dinput.

Another wild idea I have, is I wonder if we could attach multiple "surfaces" to SOMs texture surfaces somehow. If we manage this somehow, we really could seriously extend SOM to do basically anything graphically (as in look like a contemporary game) ...I would say there is actually hope for this, now that I understand how DX attaches surfaces to one another (not something OpenGL does) ...if nothing else we could probably just make every texture in your game look like 1 lookup pixel, or spell out a file name it pixels, then we could use that to fetch multiple hires textures for any kind of shader effect your want (for bump mapping etc) ...For the record, you know, I think I could probably make this work if SOM had used OpenGL as well.

I don't know if this would require a rewrite of the DX routines or not. It might be possible to mix DX9/10 code with DX7. I'm pretty sure you can mix lower levels in, so I don't see why not higher levels?? It might take some trickery though... like starting with DX9/10 and requesting low level interfaces on behalf of SOM (if they're still supported)

I think fixing (and or finding ways around) SOMs many bugs would be a worthwhile investment as well. Decompiler might help that.

[Holy_Diver]

Update,

Whatever was causing the crazy device bug seems to have gone away somehow. I think today I might've coded it away when I was just adding some options code here and there and remember seeing a thing or two that didn't seem right.

And anyway, it seems the next thing to tackle will have to be Dinput, because there seems to be no other way of getting interface device input into the working process presumably because dinput overrides everything else??

I hope I can cram everything into one dll for now. If not I'm not sure what to call the fake dinput dll at this point. Anyway... I should probably take a break from this business and get back to more serious work, but it's all a little exciting... so don't be surprised if next I'll be letting you all know about the cool shit we'll be able to do in the dinput dept. Of course the immediate reason I'm doing this is so we can add new keys to SOM for working with all the tools we'll soon have at our disposal... I know you all just can't wait

But seriously... for all of you starting new projects, you really should pay attention to all the crap I'm up to / be thinking about what sort of interesting stuff you'd like to add to your future projects now that things will be much more flexible.

[Holy_Diver]

If anyone wants to look at some of the code I've thrown together so far for SOM, I've uploaded a backup folder at (https://anon.swordofmoonlight.com/holy/SOM_Projects.zip)

This isn't the way I usually work, so it's just sort of haphazard tossed together for the most part. Some of the early DX code I copied from places around the WWW and just haven't gotten around to cleaning up at all. There is that evtcat command line applet in there as well. I really only recommend peeking at this if your into C++ and would just like to get a feel for the scope of what's involved.

If you guys want to use some of this for your projects, just ask and I'll prepare what you need. No need to decipher it all for yourselves. Until I can prepare proper config file(s) that is


PS: I think I will try to setup a system so half of the config file can be downloaded off the internet (if desired) that way it would always be up to date for the players and you could use php to do sophisticated stuff. But I think you'd only want to make changes that would effect the game cosmetically this way. Maybe bug fixes if somehow possible. If I can get that working I might try my hand at downloading resources/patches on the fly as well.

[Holy_Diver]

Tonight I drove myself to the brink of insanity trying to understand why SOM likes to crash when I takeover the DirectInputDevice2 interface. I just can't make heads or tails of it. It seems to want to execute a function off in some memory that does not exist after "acquiring" the joypad. I looked up and down the DI api for any remote reason for this behavior and nothing.

Anyway, SOM doesn't want "2" (DX5) for the keyboard. So the keyboard seems to be working fine. Which is all I had immediate want for anyway. Still I got stuck on the controller interface just for pure curiosity of it. I can only hope after working with the keyboard for a while I might find some insight, but I'm not hopeful.

I even intercepted the OLE com functions for the hell of it, just in case SOM was going behind the back of DI for some reason. I'd guess it uses the raw com interface for the movies. But DX is built on it as well.

I really drove myself sick/tired over this and burned the better part of my night. Lord knows what time it is now