2009-10-08, 12:52 AM
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.
Well that really is not necessary at any level. But if you did that it would no longer be SOM.
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.