None of the editors have ever crashed on me... why do I always miss out on all the fun
Like I explained above I have a "Mock DLL" working already, and will soon have it doing Game Genie (game trainer) type crap, which will be infinitely useful for event programming.
Virtual functions are interfaces... so they are defined internally I suppose, but they're always intended to be called externally... so replicating a virtual function interface is no problem at all with a little documentation (I think I was able to hunt down a DX7 SDK eventually -- not as easy as it sounds, since MS would prefer they be erased from time) ...but it is a mind numbing mostly data entry type task. People have already done it for DX8/9/10... they like to take 3D screenshots of WOW and crap. But no ones done it for DX7, though there is interest and parties have demonstrated a willingness. We would basically just have to wait, or do it ourselves.
Getting data into SoM is a trick, I'm not even too hot at. Basically SoM understands a specific set of fairly esoteric file formats for import, and the import/export tools are very touch and go. Probabably as we continue to unravel SoMs internal formats, I and others will find the time to program more robust means of generating SoM's files from more standard/contemporary specifications.
Making SoM work with "more modern" graphics... well there are a number of ways to go about that. Personally I'd like to see SoM working with more primitive/abstract graphics also... in time, in time
I was up late last night inadvertently taking a stab at this.
Basically I started working from the "game trainer" angle, but soon realized there was no real way (I know of yet) to debug this from a traditional debugger pov. So I thought it might be a good idea to take a detour into ways to integrate graphical debugging tools directly into the SoM runtime's execution (which beats the hell out of debugging via logs anyway) ...So in order to get (intercept) some basic info about the SOM process, I had to replicate the first level of the DX API. I looked into how many functions that would be, then decided I could live with it, and so I did...
The first problem is not even a message box seems to work in fullscreen mode. Having a message box being the child of the SOM process seems to make the screen go black and basically Vista at least completely useless short of taskmanager. I guess this means message boxes and fullscreen mode are a no no.
So anyway, I also felt like trying to get SOM out of fullscreen mode. Doing this wasn't too tough, but for reasons I don't yet know, this forces SOM to go into software "RGB emulation" mode. Furthermore I can't get SOM to play nice with a normal captioned/border window. I think this is because even though in fullscreen mode SOM is requesting the device context for the entire window and not just the client area (the box inside the window where the application goes) ...since SOM's "window" is technically undecorated this seems like overkill, but anyway, this mean SOM draws over the caption/border. There is no way by this technique to change this behavior since it's not part of the DX api. The only possible way might be to proxy the WindowProc, but that might be a little dangerous (if even possible... though if possible, doing so would let us know when SOM calls the DX API within it's control flow)
One way that might be possible, is to try to spawn a window, and then try to make SOM's window its child (go inside the new window) ...however that would still force SOM into software (non-accelerated) mode at present. Still something I will definitely look into at least for debugging purposes.
Interceding in SOM's graphical routines might require further replicating the API. I'm not sure. It might also be safe to just draw shit whenever... I don't know enough about DirectX personally. It's my last graphics API of choice in the whole wide world. I've even learned a lot more than I cared to know about the Windows API fooling around with this stuff.
Anyway, I think I've experimented enough for now (and frankly worn myself out) ...so I will just get back to blindly developing that multi-threaded memory mapper. Or maybe try harder to find a way to properly debug it (probably depending on how things go)
Well the only games in town are really DirectX or OpenGL for what I know. Between the two, OpenGL is an easy side to take. So OpenGL is what I know... methodology wise at least. DX has a ton of problems. So if I'm programming something I want to use DX, I'll seek out a second party API that wraps around DX (and usually can work in OpenGL mode as well)
For a programmer like me, learning/using DX is basically a waste of time. Besides, it changes like every other year, so there is no real reason to learn it in the first place
Anyway, I just finished a round of this business. It turned out, even though I couldn't get SOM to cooperate much in window mode, being in window mode magically fixed all my debugging issues. Now I think I know why one of these DX7 books warned against fullscreen apps being impossible to debug. I don't know if this is a DX7 thing, or if it applies to all fullscreen apps. I find fullscreen apps always run much slower under XP and Vista, so if I want one I just make a window as large as the display mode and strip off all the "chrome". I would never make someone run an app in fullscreen mode anyway, what with the havoc it wreaks with your desktop (and I don't even keep icons visible on mine... but there are the Vista sidebar widgets)
I am making significant progress in just these couple of afternoons. Short of any hurdles out of left field, I think I will have some serious results soon that will really extend the event system just by dropping a dll into your output game folder (or your SOM program folder for developing projects)
After the basic system is in place, all we will need to do is map out the memory space (find out at what addresses different data is stored... not very hard but could use a collective effort) ...I'd rather spend my time programming a fancy configuration system and maybe some graphical tools to help people debug their games and find addresses they can use. The simplest promise I can make is for starters we will have access to any game parameter we want in an event, like what items are equipped, how much exp the player has, what is their bad statuses, and so on... anything really. And probably be able to change (write to) many of these values on the fly.
2009-10-07, 11:11 PM (This post was last modified: 2009-10-07, 11:25 PM by ArbalestX.)
DirectX changes around? Hmm, can't say I'm surprised. I take it the changes are rather so significant that each version is incompatible with the previous one?
It would be interesting to change the API, but that would require decompiling the whole program and redoing alot of the code (which may or may not work).
I really should go over those OpenGL tutorials though, maybe I can be useful somehow.
Well, it is not so unreasonable for DX to change around... if that is you want to work in the video game industry and every product you're involved in developing has like a 1yr life cycle. But it's basically useless for people who approach development from a less disposable pov. Of course this is where all the APIs that keep up to date with DX and don't change come to save the day. But if you're in our situation, dealing with replicating the DX api, you really gotta work directly with the api, no way around it (obviously)
Fortunately in this case, DX7 won't be changing (har har) ...so another weird thing about DX is I'm now learning an API that was obsolete like 10yrs ago and which MS aggressively officially deletes/burns any evidence of the API's existance just for SOM. In other words, people think DX is important, but most likely if you're committed to learning any particular iteration evolution of DX, you're really wasting your time. Unless it's your job to make sure the next DX game your company is developing will be up to date with the latest in DX thinking. Of course it kinda makes sense for MS to eradicate all signs of it's existence when otherwise there'd be so many different kinds of DX incompatible documentation floating around the internet. I bet if you put the DX7 docs up online, MS would threaten to sue you.
Learning OpenGL at this point (though never a bad idea) will not be too useful for SOM. Before we could go about translating SOM to Opengl -- which I'm not sure would be so useful in the first place -- we gotta map out the DX7 API completely... or at least every single call SOM makes, but then you might not be able to know that unless you map it all -- I'm not sure. Anyway, an application can't be using both DX and OpenGL, so you have to make the switch whole hog. At least OpenGL would be more future proof as MS rolls out ever fresher versions of Windows and DX. SOM runs in DX7 "immediate mode", so it's not easy to say that using OpenGL or newer DX drivers directly would raise any ceilings graphically. That said you can do a fair bit with the graphics capabilities SOM already has. It's just a matter of how much effort you want to put into fashioning your game's "assets". You could probably fairly easily toss in some flash effects by doing a graphics interpretation overhaul. But it's too early to say whether you could really change things fundamentally. For me a lot of the charm of SOM is the simple graphics anyway.
Quote:It would be interesting to change the API, but that would require decompiling the whole program and redoing alot of the code (which may or may not work).
Well that really is not necessary at any level. But if you did that it would no longer be SOM.
I'm better off learning OpenGL for the sake of my own then.
I wasn't worried about improving the graphics per-se, rather that using OpenGL would make SOM friendlier to modern hardware, though that's really pushing it.
Hmm... It would be pointless to change the API (more unnecessary work.)
It looks like there is probably hope for an easy windowed mode hack yet...
So it turns out DX (or DX7 at least -- or directdraw7 technically) has two different ways (at least) of swapping it's buffers depending whether you're in fullscreen or window mode that seems to indicate some of the weird behavior I'm seeing. So probably if we catch the "flip" call and convert it into a "blit" we'll be in a better position for window mode.
I'm still not sure how SOM is drawing it's text to the screen, but there is a function for drawing debug text (ID3DXContext::DrawDebugText) buried in the d3dx api which is probably the easiest to get at for throwing up a heads up display of sorts (just before the window blit)
I have no idea how deep I'll have to go to get at that interface, but I won't have to intercept it for any reason... so all I have to do is find/call it. Which is a whole lot less work.
If anyone with a little C++ experience wants to help map out the rest of the DX7 API, I've done like two interfaces, which I can send you the sources for. It's pretty obvious what has to be done. It's just a lot copy/paste/find/replace/remix type work. A secretary could do it with a little training. I've done like 70+ routines... altogether there is no telling how many there are. But it only takes so many seconds each once you get the hang of it.
For one thing, it's not going to be easy. But I really broke my back with this tonight... ie. way more work than I would normally allow myself for this sort of thing.
The basic problem is to have any real opportunities for monkey business in the graphics dept whatsoever, we gotta intercept the Surface interface. The problem then is the Surface interface (for each surface) is passed around throughout probably the entire visual DX api. And the API will freak out if it gets a wrapped API, so you have to make sure it gets the original. I've worked everything out, but minimum it looks like every API call SOM makes that passes or expects a Surface api (object) back will have to be programmed around.
After 3 days of work (including working instead of playing games) I have SOM running in hardware accelerated mode with the following interfaces being intercepted:
Intercepting them is not the hard part... doing it without breaking anything is wherein the trouble lies. In this case my focus was working around the most fundamental DX graphical object IDirectDrawSurface7.? These things are passed around the DX API like crazy. It represents basically like the screen and textures etc. To make things crazier, DX is really a mess to work around. And I was also working with DX really for the first time in my life. As a software engineer I really can't grasp why Microsoft code is so expansive. I think to myself in the real world, maybe things are really so complicated (I'm looking at the COM interface for example) but I have some serious doubts. I mean I build systems which appear to be much more sophisticated than Windows and the amount of knowledge required to work within such systems is just dwarfed by Windows. And I'm just talking about the Win32 APIs... much less whatever the hell happens underneath the hood.
Anyway, I'll attach the logs for the first successful run. Some of the PANIC! lines are possibly cause for alarm (which I will need to look into) but since it's working I don't think the cause for panic is being raised by SOM. Like during the Flip() lines, I can probably easily draw anything over SOM before sending the Flip on to the real DX libraries. Actually Flip() needs to be removed and replaced with different calls if SOM is to run in windowed mode. Drawing stuff to screen is a little complicated by realizing whether SOM is in normal play or in a menu (or the on screen displays for that matter) but throwing up debug info shouldn't present any challenges.
I don't know if I will spend more time experimenting with windowing SOM or try my hand at drawing some info to the screen (like what's in SOM's memory/where) first. But the one thing I know for sure, is I'm glad to be over that mountain / probably I will relax for a while. When an objective presents unexpected challenges I tend to obsess over it until I'm in the clear... then pat myself on the back and try to makeup lost my recreational time
?)
