Author Topic: "Shell Program"  (Read 754 times)

0 Members and 1 Guest are viewing this topic.

Offline Thaeris

  • Can take his lumps
  • 211
  • Away in Limbo
Bretheren/Sistas/Chaps/Peeps,

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.
"trolls are clearly social rejects and therefore should be isolated from society, or perhaps impaled."

-Nuke


"The Windows Operating System: It can only get worse from here!"

-Me



"Look on the bright side, how many release dates have been given for Doomsday, and it still isn't out yet.

It's the Duke Nukem Forever of prophecies..."


"Jesus saves.

Everyone else takes normal damage.
"

-Flipside

"pirating software is a lesser evil than stealing but its still evil. but since i pride myself for being evil, almost anything is fair game."


"i never understood why women get the creeps so ****ing easily. i mean most serial killers act perfectly normal, until they kill you."


-Nuke

 

Offline Thaeris

  • Can take his lumps
  • 211
  • Away in Limbo
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?
« Last Edit: January 24, 2015, 11:14:01 pm by Thaeris »
"trolls are clearly social rejects and therefore should be isolated from society, or perhaps impaled."

-Nuke


"The Windows Operating System: It can only get worse from here!"

-Me



"Look on the bright side, how many release dates have been given for Doomsday, and it still isn't out yet.

It's the Duke Nukem Forever of prophecies..."


"Jesus saves.

Everyone else takes normal damage.
"

-Flipside

"pirating software is a lesser evil than stealing but its still evil. but since i pride myself for being evil, almost anything is fair game."


"i never understood why women get the creeps so ****ing easily. i mean most serial killers act perfectly normal, until they kill you."


-Nuke

 

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Skype
    • Steam
    • Twitter
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.
**** every cause that ends in murder and children crying. ― Iain Banks
Join the fun at the HLP IRC channel. Get the latest spam and gossip as long as it's fresh!

 

Offline jr2

  • The Mail Man
  • 212
  • It's prounounced jayartoo 0x6A7232
    • Steam
http://en.wikipedia.org/wiki/Windows_API

Should be mentioned somewhere in there..

 

Offline Thaeris

  • Can take his lumps
  • 211
  • Away in Limbo
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.
"trolls are clearly social rejects and therefore should be isolated from society, or perhaps impaled."

-Nuke


"The Windows Operating System: It can only get worse from here!"

-Me



"Look on the bright side, how many release dates have been given for Doomsday, and it still isn't out yet.

It's the Duke Nukem Forever of prophecies..."


"Jesus saves.

Everyone else takes normal damage.
"

-Flipside

"pirating software is a lesser evil than stealing but its still evil. but since i pride myself for being evil, almost anything is fair game."


"i never understood why women get the creeps so ****ing easily. i mean most serial killers act perfectly normal, until they kill you."


-Nuke