It's alive! Oquonie uxn running on my Linux handheld. Controls are twitchy and might need some help, but it's looking good otherwise. #uxn #hundredrabbits #theLudarium
@neauoire Sure, let me try to describe the behavior.
Right now, the left joystick moves the character as expected, but I think it's sending frequent direction inputs because it's hard to "push once" to interact with the environment, i.e. the popup dialogs almost always close instantly.
The right joystick only moves one direction (can't remember which), and the d-pad doesn't seem to do anything.
Getting the dpad working instead of the joystick would be a great start...
@neauoire Good question. I'll take a look later. By the way this is just a fairly stock debug build of https://git.sr.ht/~rabbits/uxn running on the framebuffer of the device.
I'm not yet familiar just how the gaming controls of the device are presented/enumerated. I know they already have a "shim" to map gamepad controls to keyboard, which would probably be the fastest way to get the dpad sending useable inputs, but it would be nice to use dpad with sdl natively if possible.
@neauoire I stared at that part of the page for a good 15 minutes last night trying to figure out what a vector was, I just found it at the top of a page.
Conceptually similar to a callback, right? So the rom sets the callback address for the device and then the emulator calls in to that address with uxn_eval()?
@neauoire I think that confirms my hypothesis... The emulator is calling the controller vector every time the analog stick is measurably moved at all, when it should only call the vector when the conceptual state of the inputs changes, i.e. when the extrapolated dpad input changes state.
so right now it fires way too often right? This is really hard to test with a keyboard, would you like to take a stab at this? Are you familiar with C? If not I can give a hand.
@neauoire Yeah, exactly. I'm familiar enough with C to figure this out so far hah, so I can take a look.
I'm thinking the "cleanest" way to add this is in controller.c, simply checking if d[2] has changed before calling uxn_eval(), thoughts?
Also, I compiled and ran the controller demo, and it looks like the physical dpad maps to a, b, start, select - I haven't looked closer at this, I'm guessing the emu is evaluating them "round robin" by SDL input ID. I may take a look at that too.
@neauoire I made this change, and it fixed *movement*, but not interaction. i.e. the character only moves one square with each push of the stick, but interactions still happen multiple times.
What other input does Oquonie listen to for interaction? Will boot it up on pc again and see if I can find it without seeing the source...
@neauoire actually, I'm wondering if it might be diagonals causing the issue now per your initial question, that's also hard to test on keyboard, key repeat is keeping me from seeing what just holding a diagonal does.
Devine Lu Linvega
in reply to vapid consumer • • •vapid consumer
in reply to Devine Lu Linvega • • •@neauoire Sure, let me try to describe the behavior.
Right now, the left joystick moves the character as expected, but I think it's sending frequent direction inputs because it's hard to "push once" to interact with the environment, i.e. the popup dialogs almost always close instantly.
The right joystick only moves one direction (can't remember which), and the d-pad doesn't seem to do anything.
Getting the dpad working instead of the joystick would be a great start...
Devine Lu Linvega
in reply to vapid consumer • • •vapid consumer
in reply to Devine Lu Linvega • • •@neauoire Good question. I'll take a look later. By the way this is just a fairly stock debug build of https://git.sr.ht/~rabbits/uxn running on the framebuffer of the device.
I'm not yet familiar just how the gaming controls of the device are presented/enumerated. I know they already have a "shim" to map gamepad controls to keyboard, which would probably be the fastest way to get the dpad sending useable inputs, but it would be nice to use dpad with sdl natively if possible.
~rabbits/uxn - Stack Ordinator, written in ANSI C(SDL2) - sourcehut git
git.sr.htDevine Lu Linvega
in reply to vapid consumer • • •vapid consumer
in reply to Devine Lu Linvega • • •@neauoire Does uxn generate some sort of event/interrupt on every `uxn_eval`? If that's the case, SDL reports an event on every movement of the joystick, and uxnemu processes every movement with controller_down() here:
https://git.sr.ht/~rabbits/uxn/tree/main/item/src/uxnemu.c#L398
It also seems like any joystick motion within the deadzone will "zero" the bits for direction buttons, might be why my dpad doesn't work.
Glad to take this to a different medium as well, mastodon is obviously not perfect for this kind of collaboration.
~rabbits/uxn: src/uxnemu.c - sourcehut git
git.sr.htDevine Lu Linvega
in reply to vapid consumer • • •https://wiki.xxiivv.com/site/varvara.html#controller
XXIIVV — varvara
wiki.xxiivv.comvapid consumer
in reply to Devine Lu Linvega • • •@neauoire I stared at that part of the page for a good 15 minutes last night trying to figure out what a vector was, I just found it at the top of a page.
Conceptually similar to a callback, right? So the rom sets the callback address for the device and then the emulator calls in to that address with uxn_eval()?
Devine Lu Linvega
in reply to vapid consumer • • •https://wiki.xxiivv.com/site/uxntal_devices.html
XXIIVV — uxntal devices
wiki.xxiivv.comvapid consumer
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to vapid consumer • • •vapid consumer
in reply to Devine Lu Linvega • • •@neauoire Yeah, exactly. I'm familiar enough with C to figure this out so far hah, so I can take a look.
I'm thinking the "cleanest" way to add this is in controller.c, simply checking if d[2] has changed before calling uxn_eval(), thoughts?
Also, I compiled and ran the controller demo, and it looks like the physical dpad maps to a, b, start, select - I haven't looked closer at this, I'm guessing the emu is evaluating them "round robin" by SDL input ID. I may take a look at that too.
Devine Lu Linvega
in reply to vapid consumer • • •vapid consumer
in reply to Devine Lu Linvega • • •@neauoire I made this change, and it fixed *movement*, but not interaction. i.e. the character only moves one square with each push of the stick, but interactions still happen multiple times.
What other input does Oquonie listen to for interaction? Will boot it up on pc again and see if I can find it without seeing the source...
vapid consumer
in reply to vapid consumer • • •Devine Lu Linvega
in reply to vapid consumer • • •https://git.sr.ht/~rabbits/oquonie/tree/main/item/src/oquonie.tal#L149
~rabbits/oquonie: src/oquonie.tal - sourcehut git
git.sr.ht