Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Game: keyboard input 1

Status
Not open for further replies.

Oak

Programmer
Aug 6, 2000
77
0
0
CA
I everybody!
I've got a problem about keyboard's INKEY simpling rate.
I'm on old video games projects; Mr.Do and PacMan likes.

My problem stand while I try to make a change in the character direction. Even if I keep a key down(arrow-up for exemple) my character wont turn every time I tell him.

The only way to make him execute command on every time is to interrupt the program execution each time the instruction pointer pass on the INKEY$ statement(slowing the video refreshing rate to a critical point - to not say unacceptable)

I've tried the ON KEY() statement but get a similar interruption rate.

I think that question's a particuliary point of interest for Qbasic game programming which the keyboard's a important input device.

Can you help?
Thanks
Oak
 
Oh come on now. Oak, just read the post I made! It explains it all!
 
logiclrd,
Sorry but I just can't find an answer about ARROWS. They doesn't seem to respond like all other keys. Even in your previous post that contain a program about scan codes, arrows are acting sticky-> when I relaese 'em, the "1" still. I talk about arrows by-themself (not them on the calculator wish respond like all the others).

Oak

 
Have you tried it on any other keyboards? It could be that your keyboard is sending out the "extended" scan code in the opposite order of most keyboards and so the value returned by [tt]INT(&H60)[/tt] is changing twice rapidly -- first to the actual release code, and then to the 'extended key' release code. Other keyboards send it in the other order -- the actual release code after the extended scan -- and so it works smoothly.

If this is the case, then you will need to use an actual interrupt handler to catch the release code. I have written one in assembler callable from QB with extensive functionality, if you are interested.
 
I didn't try it on other keyboard. Ouah! What a mess! My keyboard COULD do tricky things?? It's sound like I went into something bigger then I though!! Few!!

I tried to make a PacMan game for my REAL first try and got cought into... a sticky problem... FEW!!

Well, I guess it will never be easy!

So, I'm interest in your assembly interrupt handler; I got a base on assembly so I gest it couldn't be worst! :)

thanks
Oak
 
I had the same problem with the arrow keys – when I pushed more than one arrow key down at the same time, sometimes one would ‘stick’ and continue telling my program it was pushed down after I lifted the keys up (I'm using logiclrd's code). I discovered that if you set keyDown(i%) to 0 after reading it, the keys no longer stick. However, this prevents the computer from scanning for more than one key at a time. If down and left are pushed, for example, one of the keys is ignored.
An excerpt from the code:

IF keyDown%(i%) THEN
COLOR 15
PRINT "1";
keyDown%(i%) = 0 'I added this line here
ELSE
COLOR 7
PRINT "0";
END IF
 
Another question that I have about this. If I wanted to press and HOLD two keys at once, even if I use this code that reads two imputs at one time, if I hold the keys down, it will then only repeatedly read the last one to be pressed.
How would I make it so that if I press and HOLD more then one key at a time, it continues to read all the keys that are being held?
 
sandmann999, just don't use the '[tt]keyDown%(i%) = 0[/tt]' line that mgh730 proposed. :) Alternately, you can use an assembler module that implements it properly, as an interrupt service routine, but this throws a spanner into debugging your code, since the IDE no longer receives the keyboard events ^_^
 
Oak,

I seem to have forgotten to post the assembler routine :) Good thing this thread got awakened.

I have posted the files, along with an example .BAS file, at the following URL:


The example .BAS shows how to use the routine. It has many features: it automatically calculates demicardinal direction from the arrow keys, it queues keydown/keyup messages into a buffer 128 entries long, and it keeps track of which keys are down (using an INTEGER for each key, so you can just check the array offset). It shows it all there :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top