Sorry your browser is not supported!

Attached is code to enable you to setup keypress monitors. It allows you to add keys that toggle on and off, and also keys that can only fire a pre-determined intervals.

You must include the ScanCodes.dba file with your project.

To Initialise the system call InitScanCodes



To add a key to be monitored Call the AddKey function



To check the keys,call KeyPress routine



To check if a key has been pressed do the following



Attached test project is commented and should make more sense.

Here is a slightly updated version, the sample program is a little better.

This is the best example I've seen so far. I wish I saw it before I recorded all the scancodes myself - however I MAY have a few more than you - but I didn't get those high (around 200 range) ones. I guess those are on a specific keyboard possibly. I didn't test for the "extra keys" because I figured the OS or key vendor would have them hooked for their purposes. Which brings to mind a neat way to add "developer" cheat codes to a game - Back Door - On YOUR personal keyboard press "Browser" "Volume button" and etc. I digress.

Anyways, I'm working on a complete user input "lib" "plug" set of routines etc. whatever.. User Input system - that covers Mouse, Joystick, Control device (Joystick 2 I guess... where are the fire buttons?), and of course the keyboard.

I haven't touched DBPRO in years so seeing UDT, and the #constant keyword (not in DB Classic) is a god send - thanks for the code sample.

I think I'm going to implement your method of using dynamic array for the "active key" list because scanning all keypresses is SLOW and A$=Inkey$() doesn't allow certain multi-key combinations.

The main difference will be the other devices used and not using the enabled and timer stuff. I figure that same functionality could be made separately in a different context: ACTIONS

Forexample - instead of KEY ACTIVE or NOT or DELAY - HAVE ACTION Active or Delayed - then the whole main idea I'm determined to carry out will work correctly: User Interface Action Mapping system!

In short - you could map user interface (joy, mouse, keys etc) to actions in your game, then separately you manage ACTIONS like you have spelled out for keys.

well I'm working on this right now, so back to it for me, and if you want to see the code - let me know on here - I'll have the email thingy on.

Good Job.

Great Job I wish I saw it before I entered all the ScanCodes personally!

I am just getting back into Dark Basic after a few years away and it was nice to see some commands I didn't know could be used: User Defined Types, Dynamic Arrays, and equally important: #Constants!

I wanted to comment on your dynamic array implementation. This is a good design because polling all the keys or polling a full array is to time consuming for a main game play loop.

I'm going to borrow the technique and apply it to the user interface functions I'm putting together.

I was searching the forum to see how others were grabbing scancodes etc. because its a fact they are smoother for game play then A$=inkey$() and I figured I definately can't be the first doing this.

The TGC developers knew keystate/scancode polling is smoothest when they added little functions like UPKEY(). These allow multi-key input easily - for the predefined ones they made functions for anyways.

The main difference with how mine is put together is the same principle for snagging "user defined" keys is used to snag user defined ANYTHING, such as the joystick, mouse or the extra "CONTROL DEVICE".

The idea is to map user input to ACTIONS. Then programs will ask the UI what "ACTIONS" have been requested ratheer than what key or whatever. I should hopefulyl be able to implement one of those routines when I'm through where the USER picks what control(s) do what action.

As for your "Key Delay" Enabled, not enabled etc. I plan to implement that sort of thing (Your code is a good tested base) for the ACTIONS versus the keys. So On one hand I'll be collecting What the user did and translating that to an action - then the game logic will translate the action into whatever action is/does etc.

Good Post and code snippet!

Sorry for redundant post. I didn't know it posted the first one - because when I right clicked the "Mailback is enabled: [Click Here to Disable it] - It changed the window - I didn't think it was submitted and thought my message lost.

Note to Moderator. Can you please delete THIS message and the one directly above this one PLEASE?

Sorry for the Trouble.

Cheers,

I was beginning to wonder if I was the only person who saw the use for this. I'll look out for your code when it's finished.

Cloggy

Summary: I might not have any code because I'm switching to DarkGDK
C++ version - but I'm going to try to use FreeePascal with it instead of C++. I have a huge code lib for it that should be helpful. Just need to translate the C++ headers to a "pascal unit". (Could be a big deal - dunno)

Cloggy - I managed to get the Keyboard, Joystick, Mouse all working on a variant of your keystate monitor - but unrelated DBPro language semantics had me a bit unsatisified with other aspects of code I wrote. Namely how I ended up with a codebase that ran according to how fast the computer was. Additionally, games I think really SCREAM out OBJECt ORIENTED - for example - in a game like packman - each "Ghost" should simply be an instance of a ghost class. Array's just don't cut it when you start getting fancy.

Making a good timing (timer() based) solution - so that game speed was constant regardless of CPU speed etc - lead me through an agonizing epiphany of how I was "emulating" object oriented programming in DBPro. I think this gets quite dirty when you try!

I tried making a event driven system - similiar to Windows(32bit anyways) Message Loop... That got dicey and unmanageable quickly THOUGH the way I made Messages would have made for a FAST (though LONG) binary tree of select statements allowing fairly quick processing of messages. You could drill down pretty quickly because of howmany levels I made it so rather than deciding if a message was 1 of 200 kinds of message - it was more of a 1-10 check due to how the select statements were nested.

Anyway - unless I get desparate waiing for my DarkGDK (Mail order because Visa wouldn't allow me to buy directly - I tried), I will probably stick to GFX modeling and stuff until it arrives by mail!

I really need to code in something more Object Oriented. My games get prett complex quickly - which is fine - if I can make a very organized code base. Otherwise - Forget it.

Good Day ..
Jason