keyDown, keyUp, headBang

[richmond62]

As I stated in another posting, I am the owner of quite a few left-hand game pads that I use to reduce tendo-vaginitis and other jolly repetitive stress injuries from faffing around with computers.

This goes back to when I acquired a pair of Belkin pads:
-

BN52.jpg (7.16 KiB) Viewed 349 times

BN30.jpg (5.64 KiB) Viewed 349 times

-
through a number of devices to a genesis Thor 100:
-

GT100.jpg (5.22 KiB) Viewed 349 times

-
Unfortunately the Belkin Nostromo n30 ONLY works with its driver installed (Max system MacOS 10.6).

The others (Belkin n52 thru Genesis) all deliver keyUp, keyDown, rawKeyUp, and rawKeyDown to the OXT IDE.

The 'problem' is that that is all they do, and there appears no way, inwith the IDE to tell if I have hit the 'a' key on a gamepad, or the 'a' key on my keyboard: so macros would seem to be out.

[richmond62]

So . . . there does seem to be a fairly large elephant in the room (no, not that one, nor me for the same reason):

Is there some sort of way we can leverage OXT so that it will pick up key signals from gamepads, joysticks, and what not whenever a standalone is installed on some end-user's machine: and then, map them appropriately?

From a purely selfish point of view I would like to be able OXT to detect when I hit the 'a' on my keyboard, the 'a' on the keyboardy bit of my Genesis device, and the 'a' power button labelled 'G1', and differentiate between them . . .

They ALL appear to send the same rawKey signal to the IDE, and an 'a' at keyDown.

https://youtu.be/qNJQGSnDFOs

[richmond62]

To make things even more warped, the Genesis Thor 100 rgb has 4 'power buttons' down its left-hand side that only deliver the same signals as the 'a', 'b', 'c' and 'd' keys on the Genesis semi-keyboard:
-

stupido.png (52.03 KiB) Viewed 330 times

stupido.png (52.03 KiB) Viewed 10 times
-
I don't even want to get into the aeroplane-style joystick I have mouldering in a cupboard at my school . . .

Now, to games made (potentially) with OXT . . .

I have the dubious privilege of teaching quite a few children between 7 and 17 who are the proud owners of all sorts of expensive peripherals connected up to their computers (mainly running MacOS or Windows 8/10/11), who spend far too much time playing computer games:
-

games.jpg (85.67 KiB) Viewed 330 times

games.jpg (85.67 KiB) Viewed 6 times
-
Personally I think I might go for 'Lost the Plot'.

So, in a daft moment I conducted a quick-n-dirty survey of what Ivan, Ivan, Ivanka, and Ivan have connected up to their machines, and ended up with a list of about 40+ devices, most of which, predictably, I had never heard. -- No dangling prepositions for me, mate.

Now, some of these sprogs are interested in attending my LC/OXT progging sessions in June/July, and the thing that motivates them more than anything else is the idea of making some vaguely credible game that they can manipulate with whatever they have got connected to their machine at home.
-

computer-joystick.jpg (33.79 KiB) Viewed 330 times

-
Random peripherals CANNOT be foreseen by programmers, so were it possible to build detection routines into OXT stacks that could detect, say, that Chummy' has a Super Vroom Joystick connected to his/her machine that can deliver a,b,c,d,e,1,2,3,4,5 keyDowns, it might be possible to build macros that might handle peripheral input signals differently to standard keyboard signals.

[richmond62]

I am not entirely sure who has been given editorial rights on these forums, and who feels they have the right to delete a whole posting because, presumably, they took umbrage to one image: especially without contacting the author.

[tperry2x]

I deleted my post, going on about my gamepad idea, as it wasn't relevant to OXT progress.

I also moved this topic to 'off topic', because that's the best section for it.

I also deleted my post where I replied about your light/dark appearance problem on your Mac, as again it's not oxt related.

That's all.

Getting back to trying to help, there used to be something called 'gamepad companion'. Was that ever updated for the current version of MacOS you are using now?

[richmond62]

Isn't gamepad detection relevant to OXT development?

As at least one of the uses OXT can be put to is to develop games I would have thought it was relevant.

Certainly when the children who I have spoken too seem to spend a fair amount of their time using joysticks or gamepads to control the games they play, it does seem a good idea that, when one develops a game using OXT one should have some sort of idea about what type of peripherals end-users are likely to have.

Gamepad companion, and all the other apps, whether for Linux, Mac, or Windows are all very fine: but I have a feeling it is "bad form" to require end-users to install extra software before they can play with your game. These apps, also, are going to be configured by end-users who may have no idea about the specific requirements in your game.

[tperry2x]

I would assume that most gamepads either do one of two things for input. They behave a little like a keyboard, with conventional key presses (so easy to map into a game).

Alternatively they usually use the HIDinput mechanism on most OS's, a slightly less laggy input method.

However, Logitech - and there was another.... (Come on brain...) - oh yeah, MadKatz - they both used completely 3rd-party closed-source proprietary drivers, and didn't update the drivers as the OS's progressed.

Gamepad companion was a kind of universal gamepad driver, and I had luck in the past detecting gamepads and peripherals that were unsupported officially.

But, while OXT / LCC has a human-readable language, it of course has limits. These are being pushed beyond what I thought was possible all the time, but I wouldn't say that making something that's 'good' is at all easy. It's hard enough in a proper game engine after all.

Gamepad companion used to be developed by a company called CarvWare. Their site seems to be gone now. The versions I have are old. I'm sure they won't work on modern macs now.

Seems like 3.3.1 was the last version, back in 2014.
So probably MacOS 10.7 to 10.8 presumably?

[richmond62]

Some gamepads and joysticks do as you say; send key commands.

Some require drivers and have software where end-users can muck around with settings, which can get in the way of any key commands we might like to leverage.

Some are a law unto themselves.

From my point of view it would be useful if one could differentiate a key signal sent from a peripheral device and a similar key signal sent from a keyboard: but that is probably asking too much.

[tperry2x]

You could go 'full diy' if you have access to a 3D printer, an old keyboard, momentary switches from eBay, and plenty of time and patience.

I'll link my post back here (I couldn't move it individually as the site wouldn't let me).

[richmond62]

I read your impressive DIY thing on your website.

HOWEVER: this is missing the point completely (I am doing just fine re OXT and my gamepads): my point it to do with delivering OXT-generated games to end-users and allowing those games to leverage whatever peripherals those end-users have connected to their machines.

[tperry2x]

What I'm saying is that you might have missed my point. I'll elaborate.
You aren't going to get OXT to see it if the system can't see it either.

Most users who have older tech are going to be in the same position too, unless alternatively they can write a driver in c++ or something from the ground up.
Or, stay on old versions of MacOs of course - which will then mean you are on a really old version of Livecode too which will run on PowerPC (or 32-bit intel macs at best).

Most users will probably just decide to find alternative supported gaming peripherals.

If that's not an option then this isn't about making OXT support it: it goes deeper than that, to the OS-level.
If the system can't see it, then it'll need drivers of some sort. If those haven't been updated for a while, then you might have to create something that looks the same, feels the same, but it would be a totally hand-made one-off.

When you get to that point, you could then think about making OXT games to use it with.

You'll gain all support for all buttons as normal key presses when you make it yourself. Especially if you make it out of underlying hardware that's ultimately supported and as generic as a usb keyboard. That sort of driver support isn't going away any time soon.

Unfortunately you aren't going to write a usb driver in OXT as it's a higher-level language. You'll need a lower-level language, like c++, assembly or pascal. You'd have to essentially write a gamepad-companion-style binary which could be started with the shell command in OXT transparently, to then be able to capture inputs of (all? / any?) gamepads, but even then that's a huge task trying to support them all; then needing to build in support that someone suddenly requests, for a make / model that you've never even heard of, and can't get a physical copy of. At that point, with gamepads of every ilk overflowing off shelves and boxes, you could logically ask yourself - if this is to be a free offering, with no financial reward, then are you prepared for this driver to be your life's work just because you enjoy trying to support legacy gamepads? Otherwise it might be a bit of an unobtainable goal. Then are you writing the universal driver for Windows users and Linux users too, as well as MacOS users with the arm transition being something else you'd support? Modern macs don't even have conventional USB, so do you try and support the use of this through USB-C adapters too?

I wonder if that's why CarvWare and gamepad companion seemingly don't exist anymore. Perhaps it proved impossible in practice to support every gamepad, for hardware the developers just couldn't get hold of (and the companies that created them perhaps not even existing anymore).

How far do you go with supporting 'any' gamepad they might plug in? What about if someone has a legacy PS2, COM port, or parallel connector - are you going to support those too? - at what point do you stop trying to support everything and just list a small subset of controllers that are compatible out of the box.

Much easier for your students just to plug in a supported gamepad from the get-go. They can then process inputs in OXT as normal with whatever they are making.

[OpenXTalkPaul]

Isn't gamepad detection relevant to OXT development?

Yes, in my opinion absolutely it is!
I think a better category for this thread would be 'workshop' or maybe 'discussion'.

In fact there is a way to get signals from separate keyboard and multiple mouse/trackball devices as long as they are industry standard HID compliant, you can use the OpenXTalk-HIDAPI Extension, IT DOES POLLING OF RAW SIGNALS, much like Gamepad Companion or USB Overdrive, no official device driver is needed: https://github.com/PaulMcClernan/OpenXTalk-HIDAPI

This is wrapper extension I wrote a few years back, but it is not as xTalk-scripter friendly as it could be made to be, and it hasn't been optimized for speed as I had planned to do. Currently there are only a few mappings for various common Game Controllers that had accumulated in my household over the years (Playstation4. PS3, PS2 Adapers, Nintendo Wii, old Gravis Pad etc.)

There are a very wide variety of USB and Bluetooth devices that have been released over the last 25 years or so, that are HID Compliant. Not just typical input devices like keyboards, mice, gamepads, but also assistive devices, braille readers, also barcode scanners, and arcade and vending equipment.

HIDAPI is the same library that is used by PyGame. It's a pretty small but very useful library and it is cross platform.
https://github.com/libusb/hidapi

[OpenXTalkPaul]

If it's not USB or Bluetooth then it's not likely to be an HID class-compliant device. Class-compliant means it can use the System's generic drivers.

I recall we went through this before (over there).
Genesis Thor 100 thing appears to be rather old (this review I found mentions playing StarCraft ) so it's probably not an HID device, you would need a proprietary driver for it.
https://xsreviews.co.uk/reviews/genesis ... ad-review/
According to Belkin's site: "the n52 will function right out of the box as a Human Interface Device (HID) keyboard with a mouse scroll wheel, for advanced programmability and functionality, we highly recommended that you install the n52 driver." So that means it sends HID signals, and you should be able capture those signals with that OXT-HID-API Extension posted above.

Again, keep in mind your scripts will be polling RAW DATA from the device(s) and you will need to figure out what Bytes, Nybles, or Bits each button sends, what the byte range any analog sticks send, what the (typically 4-bit) Nybles are for any directional pads, or what bytes/bits any other special keys may send. I have a basic 'key' binding system set up in the demo stack that allows you to map devices signals to something more meaningful than Hex or Binary data. But once you have that mapping you're golden. It was pretty easy to map a Playstation 4 controller, which not only has a bunch of buttons, and special keys (the 'PS' Home Key), but also Analog sticks, two 'expression pedal' like triggers, level/motion sensors, and a laptop style trackpad built in! It works well over USB wired or Bluetooth.

Skip to about 13:30 to see it animate a Graphic 'knob' driven by a Playstation analog stick input:
https://www.youtube.com/watch?v=UElNxSq7r9k

HIDAPI can capture (multiple) Keyboard or Mouse too signals too, in which case it overrides the Engine and blocks keyDown/rawKeyDown from receiving the signals, so be careful, you might have to force quit if you don't give yourself some other way to exit the polling loop.

One problem is that I can only test this with devices that I own (or my three sons own), so that limits the amount of controller/device mappings that I can make for it.

Here is the link for the OXT HIDAPI Extension one more time:
https://github.com/PaulMcClernan/OpenXTalk-HIDAPI
There are copies of the library it wraps inside the 'Code' folder for Mac/Windows and Linux (which has two different versions, one is zipped, libHID or HIDRAW, which one you need to use depends on what library your Linux distro uses).

I would have done more work on making it more scripting friendly and faster, but there did not seem to be much interest in this from 'the community' over there, which I found strange since having Game Controllers input has become pretty much standard for making games. Most web browsers, Web/HTML5 engines now come with WebHID API and/or Gampad API.

[OpenXTalkPaul]

Much easier for your students just to plug in a supported gamepad from the get-go. They can then process inputs in OXT as normal with whatever they are making.

I'm not sure what people mean by supported gamepad?
LC has never had built in support for USB/Bluethooth Gamepad input (with the sole possible exception of one of Monte's 'merg' commercial edition externals but that's only for iOS).

Probably not many modern Game Controllers sends keyboard signals at all, most of them are HID, sending bytes or bits, and a few are proprietary and so absolutely do need a driver.
On macOS "supported game controller" now days means it's been approved by Apple (and there aren't that many) after the manufacturer probably paid them a lot for that 'special' privilege, but that does NOT mean a device won't still work with OS's generic HID driver.

[tperry2x]

Richmond mentioned the ability to support whatever peripherals are plugged in, not just the belkin one:

... to leverage whatever peripherals those end-users have connected to their machines....

By supported peripherals, or supported gamepads: I mean one that works without you having to compile drivers, or the end user also having to install multiple system plugins for it to function.

Thirdly, this topic can go wherever you want of course. Why do we now have two of the same thing?

[OpenXTalkPaul]

Richmond mentioned the ability to support whatever peripherals are plugged in, not just the belkin one:

... to leverage whatever peripherals those end-users have connected to their machines....

By supported peripherals, or supported gamepads: I mean one that works without you having to compile drivers, or the end user also having to install multiple system plugins for it to function.

Thirdly, this topic can go wherever you want of course. Why do we now have two of the same thing?

I know what Richmond meant and that HIDAPI wrapper library does exactly that in an xTalk scriptable way, in much the same way as PyGame uses it, and I imagine memory resident control panels like GamePad Companion and USB Overdrive achieved their controller mapping abilities.
This library basically sort of acts like a generic driver shell, and you have to figure out the data of an unknown device yourself, usually by pressing buttons, moving knobs, pedals, rotary controls, and/or sticks, on the thing while it polls the data and then deciphering the bytes/bits of data that the unknown controller emits. I created a mapping system and some example mappings for the demo stack, using a 3 button mouse with scroll wheel, and a Playstation 3, Playstation 4, 'GreenAsia' Playstation 1/2 to HID USB adapter, a Nintendo Wii+nunchuck, and a couple of others. Additionally it works with a cheap generic Arcade controls to USB HID board I got on eBay for my 'M.E.M.' Arcade Cab project (which now uses Batocera Linux as OS which is why I abandoned my xTalk based Arcade UI efforts).

Of course It doesn't support, at this point rather ancient PC-PS2, Com, Serial port things, but you might be able to buy some sort of adapter to convert a device to USB or Bluetooth HID, often a cheap way to still use ancient controllers like Playstation 1 & 2 for example or a perhaps an old Trackball since those things tend to be on the expensive side.

I don't know why there's duplicate? I thought I moved the topic without leaving a shadow copy in the forum it was previously located in. I'll have to check it.

[tperry2x]

I think the duplicate has gone, not sure what that was all about.

All I was getting at, is it's going to be additional work to support various other controllers, not just a plug-n-play situation.

[richmond62]

Most things involve additional work.

Just spent 6 hours with my wife in the garden: removed a 20 foot, 4 foot high, stones and cement wall: separated the decent stones out, chipped off any adhering concrete, hit my hand 3 times.

Levelled soil, set up strings, boards, and so on.

Positioned first 2 new bits of wall.

About 25% finished: only took us 3 times longer than our estimate.

I rest my case.

[richmond62]

You will NEVER support ALL game controllers, and I would say stick with USB ones.

[OpenXTalkPaul]

I think the duplicate has gone, not sure what that was all about.

All I was getting at, is it's going to be additional work to support various other controllers, not just a plug-n-play situation.

OK, no worries.
And yeah... No we can't support ANY device that's connected automatically, I don't know of anything that can do that. The point I want to get across here is that WE CAN build a database of commonly available devices (like popular game console controllers) and have it auto-load mappings for those that it does recognize, and if any one wants to contribute a mapping for their obscure controller or generic adapter so that we can add it to such a database, that would be great too. And we can have a few generic mappings too, like 'Three Button Mouse' or "Dual Analog Stick Game Controller" acting as templates, which can then be copied and tweaked into a new, more device specific mapping, and save it or added to our controller database.