search

nesbox / TIC-80

TIC-80 is a fantasy computer for making, playing and sharing tiny games.
https://tic80.com
MIT License
5.06k stars 492 forks source link

Keyboard input method #156

Closed ajc2 closed 7 years ago

ajc2 commented 7 years ago

Letting the user use the keyboard as an input method for carts would be pretty nice. You have to use the keyboard to work the command line... so you can't really claim the device doesn't have a keyboard attached. I think it would open up a lot of possibilities for games and other software.

Maybe instead of specifying it on the --input: line, it could always be available in the API (I always took the input methods to be "peripherals" you attach to the computer, and a microcomputer of this sort often had a keyboard built in.)

darkhog commented 7 years ago

Agree 100%. I've actually mentioned it on the itchio forums and the response I got from nesbox was "I'm thinking how to do it better". I think your idea of keyboard being permanently attached is better, although there are still some kinks to work out: How gamepad input (which is mapped to arrows/zx) would work then?

nesbox commented 7 years ago

I just want to cover all types of the devices to run games made with TIC. You can play on keyboard/gamepad/virtual touch gamepad or mouse/touch screen with the current realization and I can't imagine how to use a keyboard to play games on mobile, that's a problem...

darkhog commented 7 years ago

Just display a virtual keyboard. This is how C64 emulators on Android are doing it, for example Frodo 64.

hseiken commented 7 years ago

Android has quite a few virtual keyboards to choose from already, how would re-inventing this wheel be beneficial to the project?

darkhog commented 7 years ago

Did I say "make your own"? Because last time I've checked, it said "Just display a virtual keyboard." Display. Whether he makes a custom one or just call system keyboard is of no consequence.

Though most keyboards (Swiftkey excluded) tend to omit arrow keys which i imagine would be pretty important part of playing games that use keyboard input and even on Swiftkey, the layout of the arrows is less than ideal (fine for typing, not fine for controlling a character) so displaying a custom keyboard would be best.

hseiken commented 7 years ago

It does do this already, so i'm struggling I guess to understand what you mean. Hacker keys is what I use and it's got FKeys and arrow keys and they work just fine. So far, the only hangup is the tracker, which doesn't seem to respond to any android kb input, which is not the same issue.

Either you're not being clear, I don't understand, or the request doesn't make sense at all.

ajc2 commented 7 years ago

The request was to allow checking keyboard input while a program is running, the fact that the keyboard already shows up in the editor is a bit irrelevant. But yeah it is a concern that most Android system keyboards don't have specific keys. Keys being mapped to keyboard and gamepad is only a concern for programs that would check both simultaneously, but it's still a concern.

Gamepad and keyboard input would obviously use separate API functions, of course.

hseiken commented 7 years ago

I see. Hmmm...I've got no opinion on it either way. If it does make it in, i think extending the codes in BTN would be fine, treat them as scancodes or registers being triggered in memory or something, starting after the buttons already used in that function. I know under the hood it's more complicated than that, but from the end user perspective, it seems fairly clean. I'm usually against adding more 'do-fers' in a language, so if it can be consolidated instead of checking both with different functions that essentially do the same thing (check if there's any response from the human), then they should be using the same function() to find out what the user did and the programmer can decide how to file it in their own program; separately as KBINPUT() and JOYINPUT() input routines or as one long ALLBUTTONS() type handler with a long list of BTN() checks in line how they want. From there, you could easily write a routine to check the BTN() value and assign it an alphabet table lookup to get the right character for any kind of handling after that involving alphanumerical messaging to the program from the user.

I think what makes LUA powerful is it's very open ended meta-ness and rearrangement of innards and code handling, so I say the less specialized extra stuff the better, it keeps everything simpler and more flexible in the process, imo.

Also sorry for the misunderstanding, I seriously was trying to figure out what the meaning was.

nesbox commented 7 years ago

only gamepad or mouse input...