A controller thread...

[tperry2x]

A controller sub-thread would be handy.
I'll kick things off by saying I've actually been writing something already, as Richmond has mentioned these Nostromo controllers before.

I'm using the SDL library here (cross platform) - as I mentioned, for it to be of any use (IMO) it has to work on Linux, Windows and MacOS.

Here, I'm using a Saitek P880 (Playstation form-factor) controller and detecting inputs that aren't registered as 'keys' normally.

sdl-lib-cross-platform.png (179.13 KiB) Viewed 3524 times

the-controller.jpg (311.49 KiB) Viewed 3524 times

I'll wrap this into an OXT stack, which calls the C++ binary - that way, it'll just return the inputs which can be picked up in OXT.

Should ultimately make for a nice, compact little library I can add.

small.png (72.06 KiB) Viewed 3516 times

Anyway, I've hijacked your post here - sorry Richmond. I'll move these to a controller topic, although there's probably one already somewhere here.

[overclockedmind]

I know I answered in the Telegram, but a second look at that pic... you're getting AXIS information?!? God, the further you push the stick, the harder it goes. I mean, like I said in Telegram I have NO problem with KB/mouse as an option... I just want the controller option, too.

[OpenXTalkPaul]

A controller sub-thread would be handy.
I'll kick things off by saying I've actually been writing something already, as Richmond has mentioned these Nostromo controllers before.

I'm using the SDL library here (cross platform) - as I mentioned, for it to be of any use (IMO) it has to work on Linux, Windows and MacOS.

Here, I'm using a Saitek P880 (Playstation form-factor) controller and detecting inputs that aren't registered as 'keys' normally.
sdl-lib-cross-platform.png
the-controller.jpg

I'll wrap this into an OXT stack, which calls the C++ binary - that way, it'll just return the inputs which can be picked up in OXT.

Should ultimately make for a nice, compact little library I can add.
small.png

Anyway, I've hijacked your post here - sorry Richmond. I'll move these to a controller topic, although there's probably one already somewhere here.

Have you ever tried my wrapper for HID API?
It's much the same sort of input data you'll get from SDL joystick input command line app thing, but as a wrapped library extension. That is also cross-platform (*there may not be an iOS build of the library but there are Android, Mac, Linux, Windows builds). You won't get the data labeled like that (which probably is relying on a SDL gamepad database) instead you'll get raw unmapped bytes of data, but it should work with ANY HID controller (even things like barcode scanners or braille assistive devices). I set up a little system for mapping controllers, and made mappings for some controllers I happened to have (Nintendo, Playstation, etc.)

Maybe not the most exciting demo video but you can see it in action with a stack UI here: https://www.youtube.com/watch?v=UElNxSq7r9k

[tperry2x]

Have you ever tried my wrapper for HID API?
It's much the same sort of input data you'll get from SDL joystick input command line app thing, but as a wrapped library extension. That is also cross-platform

I hadn't tried it, I didn't know it existed - I must have missed it completely.
What do I download to get started with it?

Maybe not the most exciting demo video but you can see it in action with a stack UI here: https://www.youtube.com/watch?v=UElNxSq7r9k

I'd followed the link on your video description, which pointed me back to 'the other place', and from there I read:

NOTE: I have not tested the Linux version, I've only tested under Windows 10 and macOS 10.14.6, so if anyone want's to test this on Linux and report back, that would be great! And if you can compile or find a binary of the HIDAPI for either mobile platform and send it to me, that would be good too!

So, I'd love to test - and my aim with this thread is to pull it all together with a stack that people can actually run.

(I think that's the barrier: as soon as you essentially have to 'install' a plugin or something, rather than just opening a stack that looks in a /data/ folder relative to where it is, that might be enough to put a lot of people off). I don't know - just my impression. I know you can reference the SDL2 framework from your ~/Library folder on MacOS, but I need to do some more testing - it doesn't work as smoothly on the Mac as it does in Linux... but that could just be down to me

However, if you can provide me a link to get started with - that would be great. Apologies if I missed it already, just can't see the wood for the trees.

Here's the link to my SDL2 one, and I'm sure it can be improved further. I've tried to comment as I went through, but I'm by no means an expert in C++ - probably just know enough to muddle through.

edit: I should mention, in version 2 of my SDL controller test - I added a command line switch (-t) or (/t for windows).
Why? well as default, it'll poll (check) for input through USB of anything controller-related as fast as your computer can go. This obviously pushes the CPU and is probably not needed.
So, by using:

Code: Select all

cd [directory of where the compiled binary is]

to switch into that directory, you can use:

Code: Select all

gamepad -t 20

which will only check for inputs every 20 milliseconds - which is probably more than adequate. You can adjust the polling rate this is sampled at, by simply adjusting that number.

The idea of this will eventually be, in OXT:

Code: Select all

get shell(tBinarypath & "gamepad.bin" & " -t 20")

or even better, to "one day", wrap it in a function in the OXT Lite custom library - something as:

Code: Select all

put SDLinput(20) into tInputPressed -- returns whatever button was pressed "axis 2 moved 50" for example

So then you'd do:

Code: Select all

-- tInputPressed contains "axis 2 moved 50" at this point, as it's read from the gamepad input as above.
put word 2 of tInputPressed into tAxis 
put word 4 of tInputPressed into tAmount 
send tMoveSprite(tSprite, tAxis, tAmount) to this stack in tDelay milliseconds

(for example), which would send your player sprite galloping down the screen in a non-blocking way.

BUT... before I get too carried away with all this, Paul's method may be far better. I'll have to wait and see.

[richmond62]

Well: here's a stupid question:

Here's the link to my SDL2 one

HOW do I integrate that into OXT Lite so it works?

[tperry2x]

HOW do I integrate that into OXT Lite so it works?

Please read the above.
"The idea of this will eventually be"... eventually

This is what I mentioned to Paul, that it needs to be as simple as a stack you run. Nothing that needs installing, compiling, adding as an extension etc. However, doing these things EITHER

require changes to the engine
(not going to happen any time soon on MacOS)

OR

Need to be done via loading a C++ runnable binary
(likely blocked by MacOS at every turn).

OR

Done through Xtalk Builder syntax.
(prohibitively difficult for anyone else to actually use) without digesting and understanding all the xTalk builder widget lessons FIRST.

I'll quote myself here:

BUT... before I get too carried away with all this, Paul's method may be far better. I'll have to wait and see.

[richmond62]

Might one, on MacOS not just crack open the app bundle and paste the code into the relevant folder?

[tperry2x]

Might one, on MacOS not just crack open the app bundle and paste the code into the relevant folder?

Unfortunately not.
If only it were that simple.

I'm making an oxtstack you can run this with, showing you how you'd start and stop checking for gamepad inputs, and returning the keys pressed.

I did test the compiled mac version this morning. It works on MacOS 12 but not on MacOS 10.9. Seems to be that the SDL2 framework isn't compatible with that older MacOS version.

Again, don't expect this tomorrow. Perhaps in a few days.

[OpenXTalkPaul]

HOW do I integrate that into OXT Lite so it works?

Please read the above.
"The idea of this will eventually be"... eventually

This is what I mentioned to Paul, that it needs to be as simple as a stack you run. Nothing that needs installing, compiling, adding as an extension etc.

Impossible, the engine has never had any built-in support for polling USB devices (HIDAPI supports Bluetooth HID too, I've tested this with wireless Playstation 4 controllers). if you're relying on SDL framework that's already external to the engine and something that needs to be installed in order for it to work. SDL framework is not likely to be installed on macOS unless the user already has (indy) games or console emulators that use it (which of course I do).

An Extension module could be embedded into a stack and then loaded or installed into the IDE on pre-openStack. I've demonstrated this technique with other Extension modules. HID API is a fairly small library, and if I recall correctly it has zero dependencies on any other libraries. Still for such a stack to be cross-platform it would need to include a version for each supported platform and CPU architecture, and Linux has TWO versions due to Linux-world having different options available for every level of an OS.

Need to be done via loading a C++ runnable binary
(likely blocked by MacOS at every turn).

HID API is a C++ runnable binary (dynamic library), my HIDAPI OXT extension is just a wrapper-library that binds to it using FFI strings and passes the data along to the engine when a script is asks to poll a device. 'HID API' is the same library that PyGame uses.

I've tested this and it loads fine on macOS Mohave, BigSur, and Sonoma. I updated the mac (64bit) version of the library binary not long ago which the authors seemed to fix a permissions issue on Sonoma (macOS is only getting even more like that with Sequioa). In general, on BSD UNIX (and macOS is sill certified BSD), libraries loaded by an app should have same privileges/permissions that the App that loaded it has, but Apple's code-signing notary stuff that's on top of that does get a bit annoying and it is intentional, meant to turn people away from software that didn't come from the (cr)AppStore.

I'm not saying there will never be any permissions or code signing issues with this extension and new macOS versions, but I have tested this just fine on the macOS versions I mentioned. It also works fine on Windows 10 (that was a struggle to get device info working due to Windows 'wide-strings' variable type).
I did (eventually) test it on Linux (Unbuntu 22.x). There's TWO Linux binaries, which one actually works use depends which Linux distro you're running. You'll have to manually unzip the other one version and rename/replace the unzipped one if that one didn't work for your distro.

The thing that SDLs API has that this wrapper library doesn't is a database of mappings for various common found devices. There's a dat file that's part of SDL framework that contains mappings for many different controllers (I've had to modify this file before for an old obscure controller). But I made a script mapping system for as a proof of concept that works well (see video). As I mentioned in the video I had plans to optimize and simplify that, by integrating the mapping system into the (compiled) Builder module itself, however life gets in the way, and I haven't gotten back to working on it (other than dropping that updated macOS library binary into the appropriate folder).

I would ultimately want to have an script library for HID Devices / Game controllers, which would facilitate abstraction and obfuscation of the implementation and mapping process so that script authors don't have to deal with any of the nitty-gritty Bits, Nybles, Bytes etc. A script would just ask for a list of devices of a certain type (such as GamePad/Joystick) and then pick one to start receiving messages from (messages that might have a handler like 'on DPad pDirection').

[tperry2x]

Well, here it is. Working.
A simple C++ program which the oxtstack gets the input on, while being fully non-blocking.
(video)

screeenshot.png (169.86 KiB) Viewed 3364 times

I only set the -t to 20 milliseconds in the oxtstack, but it's quick enough as I mash buttons and axis in the demo.
I haven't read the above post properly from Paul, so will do that now...

edit: I've read and re-read that. I don't know if the HIDLibrary makes it over complicated. It sounds like it might be.
I've not specified the make/model or anything of the controller in my C++ program. The SDL2 library just finds it.
Yes, you do need the SDL2 library, but that's just a matter of copying a 2MB program into /Library/Frameworks on MacOS.
On Linux, it's easier to do:

Code: Select all

sudo apt-get install libsdl2-dev

Then, you essentially just open this oxtstack in the demo video and it does it's thing.

You can customise how often you want to poll (check for) controller inputs by adjusting the button script:

script.png (32.77 KiB) Viewed 3370 times

I've already compiled a mac version, but just want to test it first. But initial progress seems good?

I'll re-mention, that the mac version may take me a couple more days. Let the OS-battling commence!
Edit: actually, if you'd rather use Paul's method - feel free to do that instead. Whatever works for you.

[OpenXTalkPaul]

Oh yeah here's the repo for that project on GutHub:
https://github.com/PaulMcClernan/OpenXTalk-HIDAPI

In the Linux 64bit folder here:
https://github.com/PaulMcClernan/OpenXT ... 6_64-linux
You can see the TWO linux versions I mentioned. One version uses LIBUSB the other one uses HIDRAW. Which ever one is in that folder and is named 'libhidapi.so' is the version the wrapper will load. The one that's labeled that in the repo worked for me in Ubuntu 22 (IIRC). It would be better to have EITHER versions be loaded based on a check of what's in the current running Linux distro.

The individual library binaries for HID API are only about 20k in size.

Also in case anyone is interested, here's the source repo for the actual HID API library (written in C) that the Extension wrapper binds to:
https://github.com/libusb/hidapi

[OpenXTalkPaul]

Looking at the Builder source again just now. HID API does have both a blocking mode and a non-blocking mode, you might need either depending on what your code is doing. For example if you are mapping buttons to some action you'll probably want that to be blocking mode (but with a time-out timer) until a button or knob or whatever on the device is selected.

[tperry2x]

Well, anyway - here's my effort.
Feel free to use it, or not. Whatever. Hopefully someone finds it handy.
I'll let you continue with the other methods, as you wish.

screenshot.png (16.47 KiB) Viewed 3352 times

[OpenXTalkPaul]

After you install the HID API extension into the IDE, like other extensions, the demo stack (as seen in my video) is in the 'samples' folder https://github.com/PaulMcClernan/OpenXT ... r.livecode

You initialize it which loads the dynamic library, then you can list HID devices and use that information to begin poll one of the devices for input data. It's pretty simple to get polling for the data, but like I said what you get is the RAW bits/nybles/bytes you have to make sense of the incoming data yourself, or see if one of the mappings that I included in the demo stack works with your device (which may be the case with 3rd-party 'knock-off' game controllers).

Tom your work is appreciated too, I will definitely check it out later! The more methods for getting controller input the better I say! In fact at one point I was saying we should wrap ALL of the SDL framework (and anything else that PyGame uses).

HID API won't work on the web (unless someone compiled it with WebASM maybe?), but HTML5 has its own Gamepad API.
Different underlying APIs that are basically do the same sort of things... is why I think there should be obfuscation/abstraction libraries like 'unified gamepad library'. Ideally then the underlying implementations could be swapped out for a different framework, while script authors that built something against that library's syntax wouldn't have to re-write a single line of script (ideally).

[OpenXTalkPaul]

Latest builds of SDL2 are on GitHub here:
https://github.com/libsdl-org/SDL/relea ... ase-2.30.9
On macOS it's a .framework bundle, but It can also be installed via HomeBrew.

[tperry2x]

Yes, I also included those (in the original post above). Perhaps because I'm paranoid about things 'not being available' at any given moment. But essentially I copy everything I can find that's useful.

[OpenXTalkPaul]

Yes, I also included those (in the original post above). Perhaps because I'm paranoid about things 'not being available' at any given moment. But essentially I copy everything I can find that's useful.

Same here, and I've been doing that since the late 1980s! I have ceiling high filing cabinet full of binders of backup disks that started as a floppy disk collection then moved to ZIP & CD-Rs, then to DVD-Rs, now BlueRay BD-Rs! I guess it is a bit like being a 'hoarder' but takes up less physical space than hoarding other things I guess. It's mostly music, gaming, and Mac stuff, but if you're looking of some old software from the early 1990s I might have a back up copy of it. I even have some very old Windows/DOS software because I used to have one of the Mac that came with a 'DOS Compatible' card (a 486DX chipset on a NuBus card).

[tperry2x]

Okay, perhaps I overestimated how long it would take me *please see footnote.
Spent some time on this last night (back problems, so couldn't sleep) and tested today on MacOS 12.

(The link is the same shared folder as before).

Demo video of it working here.

Screenshot at 2024-11-13 21-03-26.png (115.72 KiB) Viewed 3143 times

As mentioned in the stack, please ensure you have the SDL2 library installed.
(direct link here for the SDL2 mac dmg)

* I fully expect that "gamepad-runner.app" and / or the C++ binary to be blocked by MacOS.
You'll need to allow permissions as previously mentioned elsewhere for MacOs, as the OS will try and fight you, I'm sure.

Explanation:
What's the "gamepad-runner.app" do? - like a bridge, it passes focus between OXT and the shell, making it non-blocking. That's the only way I could reliably get MacOS to detach (and yes, I tried all the dev>null and nohup, detach commands).
If it's all in the same folder (no matter where it is), then it should just work. *OS-permissions-granting aside.

[richmond62]

The ONLY snag I can see with this is the requirement for an end-user, who, say, downloads my upcoming "Need for Speed: the Search for Amphetamines." to install the SDK themselves.

Just plugging in a Belkin Nostromo n50 (released in 2001), which does NOT have keyDowns/Ups automatically picked up by LC or OXT . . .

Nor for that matter by MacOS 12, and nor for that matter by MacOS 10.04 PPC unless the Belkin driver is installed.
-

n50.jpg (4.54 KiB) Viewed 3190 times

-
On connecting the n50 to a powered USB hub the lights on the thing flashed.

Right, now let me fool around with your stack.

Which I shall do initially before puzzling over those other 2 files inside the ZIP thing:
-

Screenshot 2024-11-13 at 14.29.49.png (53.58 KiB) Viewed 3185 times

-

Screenshot 2024-11-13 at 14.34.48.png (51.15 KiB) Viewed 3179 times

-
Uh-Huh.

[tperry2x]

Please just open the stack, and we'll see what barriers the OS puts up.