function on_input(self, action_id, action)
if action_id == hash("raw") and action.pressed then
label.set_text("/system#key", action.gamepad_buttons)
end
if action_id == hash("connected") then
if action.gamepad_unknown then
print("gamepad_unknown")
label.set_text("/system#gamepad_unknown_label", "gamepad_unknown")
else
print("NOT gamepad_unknown")
label.set_text("/system#gamepad_unknown_label", "NOT gamepad_unknown")
end
end
end
You need to set the input binding for raw gamepad input in your input bindings file:
I know it might seem strange that you need to define the input binding for raw gamepad data, but we also don’t want the engine to flood scripts with raw gamepad data unless the game actually cares about gamespads.
Ah, missed that! Adding a raw binding should be everything you need!
I don’t really know what’s wrong then. We could perhaps add some additional debug logs about gamepads when the engine starts or a gamepad is connected.
I ran the engine on my Anbernic device, and it works well! Plus, it doesn’t require the libdecor workaround, because Rocknix for H700 CPUs uses X11 as a display server.
But, for some reason, Rocknix reports a different name for the gamepad (not “retrogame_joypad”), so add this gamepad description:
The engine prints a warning if the gamepad is not found: WARNING:INPUT: No gamepad map found for gamepad 0 (H700 Gamepad). The raw gamepad map will be used.
Maybe @Red_Wisp built the engine in the release mode, i.e. not --variant debug, so the engine didn’t show anything.
(btw I didn’t test their example)
ark@rgb30:~$ /roms2/ports/test.sh
./test.arm64: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./test.arm64)
./test.arm64: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./test.arm64)
ark@rgb30:~$ ldd --version
ldd (Ubuntu GLIBC 2.30-0ubuntu2.2) 2.30
Even if you build your own Defold binaries on an old Ubuntu, the cloud server (extender) builds binaries that require a newer GLIBC. And without the extender, it’s impossible to develop large games; it’s needed in 99% of cases. So, you also will have to make your own version of the extender.
So, my take is: it’s easier to update ArkOS internals or just not use it. Plus, it doesn’t support X11 or Wayland (right?), so Defold won’t run on it anyway.
stock os port and muos portmaster arent same thing. exporting to portmaster seems easy on godot engine https://www.youtube.com/watch?v=HpedCKGbaY4 but I bought new sd card to install muos.
The sh scripts of the stock OS ports seem interesting. I need a dynamic libretro.so for ARM64 games, or I would have to create a separate libretro.so for each game, which I don’t want to do.
I updated the mapping - Y/X were swapped.
