-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
do not cache lightgun input #1067
Conversation
This has the same touch screen issues we discussed before. In the current implementation, the "X-Y Device" core option determines what's appropriate to poll (mouse, pointer, lightgun, or none). We will need to preserve that feature for touch screens to work properly. |
Tested touchscreen after adding the core option check. Seems to work fine now. Can't test the light gun since I don't own one ha. Btw what gun do you use? |
Could you take a look at this issue to see if it sounds familiar to yours? libretro/RetroArch#12417 One of my headaches is that the RetroArch input code itself is buggy and not many cores are using the new lightgun API yet. Not sure how my code could do this, although of course that's the definition of a bug I guess :) |
I use my laptop trackpoint for quick testing, but to actually play I've been using a wiimote. |
Hmm I'm not sure if the flycast bug is related or not. Hard to tell because it could easily be a port issue or polling issue in that core too. As far as this core, I can only test the actual lightgun code with my touchscreen. I would test a real lightgun in the mame menu to see if we can reproduce the bug I saw. Basically....
Edit: as far as the possible bug, the mouse doesn't have this issue if selected instead. |
Tested this bug with the current build and it doesn't exist. So it's a new big in this PR. |
The MAME menu doesn't map those additional lightgun buttons when I test the PR locally. I wish it would go wrong on my end to make this simpler to investigate |
I just use my smartphone. Mines a motorola Z3. Works very well. Easy to setup and test. |
I have a Google Pixel I could use, but I have never installed any apps other than through the Play Store. Kind of embarrassing. I assume you are downloading and installing RA manually on your phone? |
RA is on the play store too but it's delayed from live updates. This option installs like anything else. There are 2 options to choose from based of your Android version. Personally, I installed the official version from retroarch.com instead - download stable from the home page. You will have to enable 3rd party installs on your phone under settings for your phone to install it though. It's updated live. To install beta builds of mame, download them from the pipeline. Extract the zip it comes in. Then manually install it in the ra menu. |
thanks for pushing me to finally get RA set up in android for the first time. I may not be able to spend much more time right now on this but I'm in a better position for sure. is there any convenient way to read logs in android that you can recommend? |
I typically view it in a text editor app or on a online txt editor. Sometimes you have to rename the file extensions to ".txt" first. |
I think the issue is in this return. Not sure why at the moment. I'm guessing input_cb returns 0 or 1?
|
In the case of the trigger, I trace That in turn leads me to consider https://github.com/libretro/RetroArch/blob/master/input/drivers/android_input.c#L565-L579
|
I have yet to explore how the touch overlay fits into this scheme. |
With our current build the lightgun works with the touch screen as it should. So by moving polling into osd_is_joy_pressed seems to cause this odd issue in this PR. I've tested a bunch of things and I can't see why it starts mapping multiple lightgun triggers. I started organizing the polling into its own function for simplicity. https://github.com/libretro/mame2003-plus-libretro/compare/poll It's come to my attention that poll_cb is called from retro_run and is important to be in sync for each frame. This maybe part of the issue here. |
From the android input code mark posted seems to me the multiple tab menu entry may be each player mouse index is set to zero and the lightgun is mapping to all player triggers to mouse index 0 because of that. https://github.com/libretro/RetroArch/blob/master/input/drivers/android_input.c#L1455 try setting a different index for each player in input port settings for the mouse |
Our current build doesn't have the issue though. It came from this PR. I'm guessing because he's calling input_cb from osd_is_joy_pressed out of frame? I also have my Android set to only 1 player port too. So the others are disabled. I'll test though |
I would really need to look at the code and what been changed. Im trying to stay away from input stuff libretro side of things |
Just to be sure I tested by changing the mouse index as suggested for the other ports and it still maps multiple gun triggers. So I think it's just a frame issue if moving the call to input_cb? |
I don't see how the input callback should ever have junk data no matter when you are checking it. From my understanding, polling data should be from the last time the callback was polled, even if that was many frames ago. |
code here mame2003-plus-libretro/src/mame2003/mame2003.c Lines 2141 to 2153 in 94cfaa8
you should log through mameui or retroarch to see whats triggering the reload . |
I'm making some additions to one of the libretro test cores in order to make it easier to see what input is being polling, without the complication of the MAME code. I just need to work on it a little more 🔢 then I'm hoping it will help narrow this down. |
I could uncomment and modify this line: mame2003-plus-libretro/src/mame2003/mame2003.c Line 2139 in 94cfaa8
|
my thought is if the user doesn't want to use it why poll it? Idk lol. Inptport.c
|
Yeah as long as the core option is needed we might as well use it to
simplify the polling logic. In my ideal world, the user could have digital
controls, analog controls, mice, and light guns connected and mapped in
retroarch all the time.
They can pick up whatever they prefer for the current content, and it will
work without having to change core options.
That's still a while off. I'll take incremental progress ⏩⏩😁
…On Wed, Jun 9, 2021, 11:29 PM mahoneyt944 ***@***.***> wrote:
my thought is if the user doesn't want to use it why poll it? Idk lol.
Inptport.c
/* update mouse/trackball position */
if(options.mouse_device == MOUSE || options.mouse_device == POINTER)
osd_xy_device_read (i, &(mouse_delta_axis[i])[X_AXIS], &(mouse_delta_axis[i])[Y_AXIS]);
/* update lightgun position, if any */
elseif(options.mouse_device == LIGHTGUN)
osd_xy_device_read (i, &(lightgun_delta_axis[i])[X_AXIS], &(lightgun_delta_axis[i])[Y_AXIS]); }
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1067 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVGC5VBSKBUTTSRHI42AALTSAWSZANCNFSM46BNBNYQ>
.
|
I'll put your code back in a commit soon, although not today. Bedtime.
…On Wed, Jun 9, 2021, 11:36 PM Mark W. Kidd ***@***.***> wrote:
Yeah as long as the core option is needed we might as well use it to
simplify the polling logic. In my ideal world, the user could have digital
controls, analog controls, mice, and light guns connected and mapped in
retroarch all the time.
They can pick up whatever they prefer for the current content, and it will
work without having to change core options.
That's still a while off. I'll take incremental progress ⏩⏩😁
On Wed, Jun 9, 2021, 11:29 PM mahoneyt944 ***@***.***>
wrote:
> my thought is if the user doesn't want to use it why poll it? Idk lol.
>
> Inptport.c
>
> /* update mouse/trackball position */
> if(options.mouse_device == MOUSE || options.mouse_device == POINTER)
> osd_xy_device_read (i, &(mouse_delta_axis[i])[X_AXIS], &(mouse_delta_axis[i])[Y_AXIS]);
>
> /* update lightgun position, if any */
> elseif(options.mouse_device == LIGHTGUN)
> osd_xy_device_read (i, &(lightgun_delta_axis[i])[X_AXIS], &(lightgun_delta_axis[i])[Y_AXIS]); }
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1067 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AEVGC5VBSKBUTTSRHI42AALTSAWSZANCNFSM46BNBNYQ>
> .
>
|
@markwkidd I threw some commits at it to lighten the load. Feel free to remove, add, edit, etc anything you wish. Here's where I stopped.
|
@markwkidd I'm not sure why, but when I tried to add the standard retropad in. It was crashing the core so I reverted that one. Otherwise it seems to be working on my Android phone so far. Needs more testing. |
I ran into an issue with retropad polling causing a crash with my previous
attempt to eliminate caching, and I figured out a fix/workaround. I'll see
if that can make a difference in this case. It had to do with making sure
that MAME doesn't poll the retropad in the first frame if I recall.
…On Thu, Jun 10, 2021 at 11:59 AM mahoneyt944 ***@***.***> wrote:
@markwkidd <https://github.com/markwkidd> I'm not sure why, but when I
tried to add the standard retropad in. It was crashing the core so I
reverted that one. Otherwise it seems to be working on my Android phone so
far. Needs more testing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1067 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVGC5VQMC3FG55RTUEAZEDTSDOOXANCNFSM46BNBNYQ>
.
--
Mark W. Kidd (he/him/his)
http://facebook.com/markwkidd
(606)536-0115
|
@markwkidd ok. I used the flag check from retro_run in osd_is_joy_pressed and that clears up the 1st frame crash. It's working now. I'd really like to optimize the heck out of osd_is_joy_pressed though. This seems to be a downside of this new method. I'm wondering how much this even does. The current implementation
This pr
Seems to me we are trading off where the slow down is. While we save time not caching we lose time identifying the return and polling out of sync. The real question is, which is actually faster? We'd have to setup some kind of controlled test between the two and log the delay. |
I have tested this locally and it's working as it should.
I would like to trim away the other input caching eventually, but the lightgun seemed like a good place to start rather than biting off the whole thing at once the way I did with my previous PR #1044