Off-Topic Discussion > Programming

"Shell Program"



I have a project I'd be interested in starting, and I will explain it here. I'm starting this thread not to tell you what I've done or will do, but instead to ask you how to do it, as it's something I've no idea how to go about doing - at all:

I want to make a "shell program" for an old family of RPGs that I've got - something like a DLL or patch of some form that will let me modify the keyboard input for a specific/specified program ONLY. I realize there are programs that will let you change how the keyboard works globally for the computer, but I most certainly don't want to do that as a solution. I just want to write something that will allow me to combine arrow key inputs so I can move along a diagonal when two keys are depressed at the same time (like left arrow and down arrow - commands like up and down at the same time would not register), perhaps with a user-specified millisecond delay.

Here's some more specific details for what I'm working with: the first generation of isometric games from Spiderweb Software, like Nethergate, Avernum 1-3, and BoA. These games work great if your computer has a number pad (and all good computers should have one!), but for lightweight laptops/netbooks, numpads are probably not an option aside from a USB unit. I happen to have one of those lightweight computers, do not have a USB numpad, and I don't have too much spare change lying around at the moment. But I do have 2008 & 2010 VC++, so I'll work with what I've got...

And, this is what I envision happening if everything can in fact work out properly:

(1.) A DLL/"patch" can be dropped into the folder containing the main .exe for the given game.

(2.) Either the DLL can be edited per program as desired by opening it directly... I'm certain it doesn't work that way... or it will use an .ini file to specify the changes to be made to keyboard inputs when the given program is active. Note that, obviously, it should affect ONLY the program to be modified; e.g., Avernum 1, 2, or 3, etc.

(3.) Desired .ini inputs:

(a.) Basic key directions: -1, 0, or 1. // Essentially, arrow keys work in the old games, but they cannot be combined together to move characters along a desired diagonal. In the oldest games, the arrows would move characters along diagonal spaces rather than adjacent squares... because the arrow keys point to those diagonal spaces, you see. Later, this would be changed to move characters along adjacent squares instead. But, you can't do both at the same time (which I've repeated a lot by now). So, by giving the inputs of -1, 0, or 1 to the program in the .ini, you will adjust the single keypress arrow input by 45 degrees clockwise (-1), 0 degrees (0), or 45 degrees counter-clockwise (1). It's possible someone could make something really wierd for their game if they choose the wrong setting, but I intend to make instructions - if they can't follow those simple instructions, it's not my fault. The idea here is to customize how the game works for the user, whether it's according to the old style or the new one, in any of the older-gen games.

(b.) Delay in milliseconds: [number > 0] // I don't know how the games respond to key inputs for moving. Well, I do, but not in the fine details. Like, I have to hold down a key for a bit before I keep going in a direction with an arrow or the number pad - this keeps you from from making a single keypress and covering more that one square at a time... unless you hold the key down. Thus, the old games have a built-in keypress delay. Instead, the delay proposed here is for when two arrow keys are pressed at once, so both of them can be registered for when you want to move along a 45 degree angle within the limits imposed by the first .ini setting as noted above. Otherwise, the game recognizes the first key to be pressed alone. Unless there's a better way of doing this, I need to find a method of recognizing both arrows at once and making sure that they perform as desired.

...And that should be it. I'll go over a quick algorithm in the next post.

Patch Algorithm:

(1.) The patch recieves data from the .ini file, or however else data is fed into the patch.

(2.) Directional modifications have been discussed in Point 3-a of the last post. Recall that the patch affects the operation of the ARROW KEYS ONLY.

(3.) The input delay, if that is the only or otherwise best solution, is only triggered when an arrow is depressed, and only once per initial keypress. Therefore, if another arrow is pressed within that timeframe, it can be registered to move units along a diagonal.

(4.) Input recognition: only two arrows can be recognized at once for movement; this is kind of like the existing system, where only the first arrow to be pressed is recognized. Therefore, if a third (or more) is pressed, it (or they) is rejected as an input.

(5.) Input conditions: A command like simultaneous left and right arrow is to be rejected. Instead, the first key to register in that condition is accepted as input. If left, down, and right are pressed simultaneously, the following will happen - the first key recognized, along with the second logical command, are accepted as movement inputs; the thrid is rejected. More directly, each first input is linked to a pair of second possible inputs, and any secondary input which is not a possibility for movement along the diagonal is rejected.

In terms of execution, a matrix of four columns and three rows could be used to contain the first input and the logical secondaries. A conditional code then would check the input and relay the appropriate output. I assume the matrix would contain the ASCI or whatever-the-heck the key registers are as values.

...On a conceptual level, that about covers how the program would need to operate. The only question now is, how do I get started?

The E:
I think the first order of business would be to find out how those games receive their input. If they're going through DirectX, it should be possible to create a dll that is loaded in place of the original MS dll which can read the input, alter it, and pass it along.


Should be mentioned somewhere in there..

E: The old Spiderweb games were designed on the Mac first, so they most certainly do not work through DirectX.

jr2: Thank you for the information, that makes starting on research a little easier.

...I'll be certain to drop back in if and when I have more questions.


[0] Message Index

Go to full version