le2: inputs sent in wrong order? #1592
Comments
|
If I'm understanding what you're saying, the cursor is drawn in the new location but the shot is a frame behind at the old location? |
|
I captured a pic of this by holding the dpad and firing then pausing mid movement. I can't see why this happens, but the shot seems to lag behind the crosshairs. |
|
Thanks for the screen shot. Yes, to the naked eye, it does appear that the shot location lags behind the crosshair's location. However, I think in terms of what the emulator sees, it's the other way around: the trigger input is activated too early. The crosshair moved with the same amount of input lag for me in all three of the games I mentioned. If I'm looking at it right, there's 1 frame of input lag for the cursor for me in all three games. Only in |
|
The way our crosshairs work in this core, we draw the game screen then draw the crosshair on top of it each frame. I think what's happening is the games "bullet splatter" animation is taking longer to draw than how fast we draw the crosshairs. Mind you natively the game doesn't draw crosshairs, so you probably wouldn't notice on a real machine. I'm curious to see if the shot actually lands at the splatter point or where are crosshairs are. |
|
If you use the service buttons to enter the gun check service menu, it seems like this is the case as my crosshair passes a grid line, the bullet point is dead on, but the flash or splatter lags the shot. Also our inputs are polled by the emulated machine so timing between games can vary, which isn't a bug just how responsive those machines are. |
|
Oh wow interesting. I hadn't thought of that. I will take a look at the service menu later today with my setup and see if the frame-by-frame test produces a different result from what I got in game. |
thats not quite true the crosshair drawn in an if condition in the video update code instead of unconditionally in this case. |
Yes but the if condition is always true for le2. |
|
Perhaps it some backport missing some code seems an odd variable name just to enable a lightgun crosshair as it has no other function. |
|
Yeah definitely odd naming, not sure why it's that way. Probably should update it to something more simple but it's functional non the less. Btw not sure if you've been looking at #1587, but maybe you'd be willing to look into why radr starts up to a network check screen? It requires you to hit a service button to skip it to actually get to the game. Likely a dip switch, or read/write handler but haven't found it. |
|
havent looked at radr at all but what i will say is the code here. mame2003-plus-libretro/src/drivers/konamigx.c Lines 908 to 930 in c2053dd use these variables for the crosshair draw instead of reading the port directly it could have moved since the last read compared to render time that way youll be in sync with what the game is looking at. |
|
I noticed they are slightly different from the reads to the crosshair draw, I think there's some minor scaling going on when we draw the crosshairs to make it where the game thinks it is. It's really accurate in the test menu, always within a pixel. |
|
you can add another variable just needs to read at the same time so they are in sync for game and drawing cross hairs. Your basically drawing at the cross hair coords at rendered time rather than when the game last read the poll. |
|
Can they actually be different? These are read once a frame and we only poll inputs once a frame. So I'd assume they would be the same inside the same frame? |
|
yeap mame goes through a loop you shouldnt be manually polling something in a different pace than the mame main loop does. |
|
Isn't video update apart of the mame loop? What you're saying doesn't make sense to me, if we are in a certain frame, the game should readinputport, and then video update will readinputport later in the same frame. Mame_frame has to finish before the next loop occurs where the inputs are polled again and the process repeats again and again. What I think you are saying is readinputport can return different values within the same frame, which I don't believe it can? Though I've never specifically tested such things, so I could be wrong. |
|
For reference: we poll then run mame_frame last. So I can't see how readinputport could return differently in the same frame. mame2003-plus-libretro/src/mame2003/mame2003.c Lines 367 to 391 in c2053dd |
|
ok this is my last post on this every post with ends up in you disagreeing do you it all the time.
If you move the mouse fast you probably get bigger jumps with a lightgun. I manage to get 5 difference without really trying. I think your ignoring completely what mame actually does during a loop and a game could skip a read during the frame but manually poling wont account for that. The frame could be dropped you need to see what mame processed not your last libretro manual poll. |
|
I'm not arguing with you I stated I could be wrong, just a discussion. I happen to run my own test and agree with your notion. If you want PR a change I'll push it later. Headed out right now. |
|
Had a second to make a branch for this , https://github.com/libretro/mame2003-plus-libretro/compare/Le2 On a quick test the game doesn't read the input during startup so it's locked out for a little. The input doesn't feel any different to me. I'll wait to see how @StormedBubbles tests go in the service menu before pushing anything. |
|
Sorry for the delay, and thank you both for looking into this. My experience in the service menu is exactly the same as in game when I do the procedure I mentioned earlier. The shot lags behind where the cursor location is by an amount that appears to be the same as during normal gameplay (so the splat effect appears to be where the shot actually lands). |
|
I dont see anything in that branch linked did your get time to test that? |
|
Sorry I may have misunderstood the request. I tested the main branch of lr-mame2003plus. Would you like me to take a look at that le2 branch and test? And I'm also not seeing differences with that branch |
|
I think the branch may have been accidentally deleted. |
|
@StormedBubbles try this. It works fine on a wii mote how aligned it is is another story but you can dial it in with your gun. Just offset the crosshair draws. Youll need to goto the right screen to reload leaving that out out the testing for now. |
|
Yeah I must have deleted it I can write it back up if need be, when I tested the crosshairs (input read) is locked out while the game boots up. And it felt the same to me in the menu and in game. Many drivers read the port directly in draw_crosshair, so its a common practice here for what it's worth. I think this is just how the game feels. Seems like the gun is very accurate to me, not sure what your experience is misty with tests you've done |
|
I guess it depends how good your gun is. I mean a wiimote more like a shotgun haha. The reload check isint needed for lightun not sure about the other modes though. For a wii-mote or andriod screen I guess its like using a shotgun for aiming anyway. A sniper gunner like @StormedBubbles would only be more able to to make a preference. As for the difference when wagging the wiimote around. p1h:246 mamereadh:254 p1v:245 mamereadv:253 is the difference plus the processing to be added thats just a plain port read. |
|
The code changes posted above appear to rescale/shift the position of the emulator's cursor if I'm reading that right. I should have mentioned that I actually play with the cursor off and was just using the cursor as a means of explaining the issue I experienced. I tried said code changes with
Initial shot to show expected alignment Cursor left alone after that shot Move cursor with trackball, take hand off trackball, fire shot, advance 1 frame Advance 1 frame. Cursor has moved, but shot has not yet appeared Advance 1 frame. Shot appears in correct spot with correct alignment Now for Initial shot to show expected alignment Cursor left alone after that shot Move cursor with trackball, take hand off trackball, fire shot, advance 1 frame Advance 1 frame. Cursor has moved, but shot has not yet appeared Advance 1 frame. Cursor moves again, and shot appears at previous location Advance 1 frame to show completion of shot and misalignment I ran the same test with Area 51 and Crypt Killer in this emulator as well as a few other games in other emulators, and they all behave like |
|
Im not sure how accurate the pause method is. But the game will place the shot and allow you to move cursor after shot you wouldnt be able to move this fast without pause. If you move the mouse right across the screen it will be the other side depends how long you travel where the new target appears during the pause. The shots always on the right target thoughbut its does end up in the same place. There is lag its could be the way the game is or the code needs tweaked how are you finding fbneo and mame with this? I struggle to even notice 1 or two frames cause its takes me more than 3 frames to aim and shoot and wouldnt notice this without a frameskip. Its does seem better on mame current on although it running really slow on on a i5 in RA. Neither plus or mame current le2 work on fbneo dont know if it supports this game. I think the video code might be an issue on this one something is cause a delay that mame doesnt seem to have with the pause method used. |
|
@StormedBubbles did a bit of testing on this core and mame its game mechanics its not a misaligned shot. Mame is a frame ahead compared to our core. The game needs 8 or 9 frames with the trigger not pressed after a shot during gameplay to take another shot. This doesnt happen in gun testing mode in the service menu. So around a 160ms between shots for the revolver anyway dont know about the other weapons. |
|
@MistyDreams sounds like this is just how it is for this game here. |
|
Thats the danger of frame advance and runahead some mechanics shouldn't react instantly. Its still interesting with the draw cross hairs everything else goes through the game mechanics loop. Its like drawing a jump animation in the video code instead of using the mechanics not too fussed about when its read but worth keeping in mind for people with decent guns. |
|
The best comparison I found was lr-mame2010. |
|
Try it with the crosshair off if its hitting where it should its the draw cross hair that needs adjusting to match the green dots. |
|
Yeah I patched the colors up for le2 awhile ago in this core, otherwise it would probably have more issues here too. |
|
My previous comment minus the sentence with the "C" word is my experience with line of sight. The shots lag behind my sight in this core by maybe half of a service-menu square more than in 2010 when moving. It actually looks like what I show in my screen shots above. @mahoneyt944 are you referring to the color hack from November of 2021? That was originally implemented in a MAME version predating 2010's and is already in that libretro core. Also, what were the changes that you originally proposed before? I can take a look at those too. After looking at that, I can just close the issue if no one else seems to be having a similar experience. |
|
The change I made here was a color palette shift, can't recall the mame version it was from. The change I had in my branch was basically the same as what misty had, I just kept the scaling the same. But it you saw no difference with his, it won't be better with what I had |
|
Checked the code the scaling should be good. have no idea why this is happening to you and the other games are fine. this code is identical on all mame versions so it must be good. mame2003-plus-libretro/src/drivers/konamigx.c Lines 908 to 930 in a2f76b2 mame2003-plus-libretro/src/drivers/konamigx.c Lines 1487 to 1488 in a2f76b2 screen is 512 x 256 scales here appropriately. mame2003-plus-libretro/src/vidhrdw/konamigx_vidhrdw.c Lines 491 to 492 in a2f76b2 The only thing I can think of is check any frameskip options. One more thing to note the draw_cross hair is drawing from the current input and its ahead of the mames internal gun read you can see it play catch up sometimes. I only read the x axis bit it will print directly below your normal crosshair to see if it differs much for you. Test it in the calibration screen as the game mechanics throw things off. If you get a chance can you test on a pc. Its probably best to leave the issue open is a strange one. this will render mame internal read value and mames last data received. If they both are offset wrong the problem must be somewhere else. I out of ideas might be easier to put an issue in 2010 for someone fix the driver. |
|
Does the game require so many frames of the trigger to register? |
|
no it requires the frames after youshoot with the trigger released to shoot again ingame . Its a revolver probably to make it more authentic. If you see no flash the shot wasnt ready an its still the last shot your seeing. mame current requires the gap as well bewteen shots.I cant reproduce the target being off though. All test are fine in the test menu for me. Zero lag is a meme older hardware had it. |
|
Seemed fine by my tests, but I don't use an actual lightgun. Idk probably nothing we can do here. |
Anecdotally, something seemed a touch off with Lethal Enforcers II (
le2) to me when using a lightgun-like device (Sinden Lightgun, in my case). Using the RetroArch pause feature finally allowed me to see what the issue was. I used a trackball to test this to ensure I wasn't accidentally moving the gun crosshairs.By enabling the crosshairs, pausing the emulation with hotkey+P, moving the trackball a bit, letting go of the trackball, and then holding the trigger button and advancing the emulation frame by frame using hotkey+K, I found that the white flash occurs before the cursor moves. This results in the shot not being aligned with the cursor position even though the cursor was moved first. The shots normally line up exactly with the center of the cursor (i.e., when the cursor is stationary).
In contrast, I tested Area 51 and Crypt Killer and found that the cursor moves before the flash occurs, and the resulting shot lines up correctly.
I hope I have articulated this well enough. I can provide more information if need be. The anecdotal experience was difficulty hitting targets on opposite sides of the screen in rapid succession. The second shot always seemed closer to the center of the screen than it should have been.
The text was updated successfully, but these errors were encountered: