GameKeyboard

CardboardGuru

I'm looking at the possibility of providing keyboard input for Defender, mostly because then it'll be compatible with all the Prop boards and gets round the issue of a shortage of keys on joysticks and gamepads. Baggers has pointed me at comboKeyboard, which is Mike Green's portable update for Parallax's keyboard driver.

The first issue I have is that it needs a cog, and I've already allocated mine. I have:
1 for game logic.
1 TV driver
1 reserved for sound
1 for a statusview renderer
4 for playfield renderers.

So I'm going to have to combine the keyboard driver with one of the other functions. The only one that would possibly have the cog memory available is the TV driver. And during the vsync, there's likely to be a reasonable amount of time available to do something else. Anyone have any idea whether looping through the keyboard driver at 60 Hz would be successful? It seems fast enough to keep up with human fingers at least.

Then I was thinking that a lot of the code in the driver is probably unnecessary for use with games. For games, for the most part you don't really care about ASCII values, capslock state and keyboard repeat etc. You just want raw scancode up and down events, or better still just to query the driver whether a particular key is currently pressed.

I'm thinking that perhaps it'd be a good idea to do a generic GameKeyboard driver that's set up just for the requirements of games, which is stripped to the minimal code. And possibly, since the TV driver is pretty generic for any scanline buffer driven game, a generic game KB/TV driver could be done.

Just thought I'd float the idea for comment from those people who've already had some experience with KB drivers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK

potatohead

60Hz is 17ms or so best human rapid fire is ~60 - 80ms, average 100, lamers > 150

At the 60hz, would it capture more than one key change? If player does, down, reverse, fire, up, fire, fire, like to nail a baiter, all of that could happen in a ~150ms window. Those would come in rapid sequence at the least. (one key press per keyboard scan) IMHO, that seems fast enough as you would get 8 scans for 6 actions, making it tight, but workable even with one key per scan --golden with multiple ones, IMHO.

Edit: Maybe not...

Just thought about those actions. There are two states, down active, down inactive, etc... that's more states than scans. Will need to scan multiple keys per 1/60sec cycle, or player will feel constrained by the input...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Post Edited (potatohead) : 11/17/2007 5:29:11 PM GMT

Spork Frog

The keyboard has its own "stack" built-in, though (at least, that's how I understand it.) I could see holding clock high (to stop the keyboard from talking) during most of the screen, then in Vsync, have it spit out all the pressed keys.

I've read the Hydra book a little, so as far as I understand it, this will work.


Actually wait a second. A person could press and release a key during the video frame, making a lost key most of the time. Maybe that wouldn't work then.

AndreL

That will work fine, more than enough.

andre'

CardboardGuru

Having done a bit of work on this, I suspect it's not going to work. It's complex, because to communicate with the keyboard there is a lot of waiting to be done. But if you wait past the point at which the video registers need feeding, the TV display will break down.

There are some fixed periods to wait, which is difficult, but not impossible by interleaving with waitvids. But then you get to the part of the protocol where you have to wait for the keyboard to set a line low or high. Which is something that I guess you can't rely on.

Perhaps a state machine that never waits indefinitely, but keeps feeding the waitvids and testing the keyboard might work, but it'll mean starting from scratch on the keyboard driver rather than adapting the existing one.

I think perhaps for now, I'll offer the choice of keyboard control or sound, but not both. Then maybe come back to this problem later.

If anyone has any helpful suggestions I'm all ears.

LATER... I guess one alternative would be to driver the keyboard in SPIN from the game logic loop. That also goes round at 60 Hz, but is less time critical than the TV driver.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK

Post Edited (CardboardGuru) : 11/27/2007 2:28:59 PM GMT