MAMEWorld Forums - Programming - Re: Why are MAME INPUT_ABSOLUTE

>> I think that the input system of MAME as implemented could definitely use a re-design, and if you can accomplish that and improve the design and implementation, I say do it, definitely.
<<

It's only that my build is based on 0.37, I will try it there first.

>> I don't personally believe that input latency can meaningfully be improved, and I don't think you'll accomplish significantly better input latency with any rework you do. However, making the code more readable and more maintainable would be welcome.
<<

Has anyone ever even attempted to measure input latency in MAME?

I've seen some funny comments in older MAME builds that seem to suggest input is actually delayed on purpose. Not sure what was the reason, think it's about catching multiple simultaneous inputs (keystrokes?). Possibly has to do with the speed of serial transfer via USB or PS/2. I will start my investigation from there.

Anyway, just like in animation handling routine there are dozen of function calls before the value gets where it needs to go: A calling B, B calling C, C calling D, D calling E, where the call could have been made from A to E directly. When re-writing video I wasn't even really looking in those intermediate functions, since I was gonna re-write it all anyway, I just made sure the value in question got prepared and converted to expected format and then deleted everything else. Just doing that fixed most of the problems, so I'm optimistic to see improvements in input handling code too once I start deleting it.

>> I am not aware of the specifics of the issues you are dealing with - I didn't realize that MAME had flaws in its audio or video handling that would cause video frame rate jittering or audio buffer underruns (cracking, etc), but if it does and you can fix them, that would be awesome.
<<

1.) Issues related to AUTO frame-skip and hardware too weak to run the game at full speed.
- solution: different frame-skipping and video syncing algorithm

2.) Issues related to impossibility of syncing non 60.00 Hz games with fixed 60fps displays such as LCDs.
-solution: speed up or slow down each game if necessary to fit available display refresh-rate.

Audio issues in both cases are just byproduct, it's because the time from one frame to another gets to vary wildly, too much for audio-stream to catch up, re-sample, re-sync or whatever it is doing. Have no idea how audio in MAME works, fixing video glitches fixed audio hiccups and crackling automatically. In any case it's about "temporal uniformity", you wanna even out turn-around trip time from one frame to another, doesn't really matter if you can push just 30 frames per second, or even 15 only, if it is uniformly distributed in time and synced with the display's refresh rhythm it will sound and appear smooth, smoother in many cases than if frame-rate varied from 50-60fps.

These are not very obvious issues in most cases and with most games, but depending on your hardware configuration and MAME settings some games, particularly scrolling ones, will manifest video imperfections. Audio problems then usually come when you try to smooth the video as neither video syncing nor auto-frame skipping works properly. And sometimes it simply can not work, you can not divide 60 with 57 and get a whole number, so it's simply not possible to run Moon Patrol (57Hz) smoothly at its authentic speed on a fixed 60fps LCD display.

>> More on topic, I agree with everything you wrote about the 34 bits analog input ranges. It's nonsensical. 32 bits would already be overkill - is there any input device for which input ranges of -32678 to +32767 is not sufficient? I would say absolutely not.
<<

Yeah, not a big deal really, just sort of thing that makes you think what else has been wasted and what makes you wanna do the re-write, but the reason in its essence, for me, is really more about aesthetics and principles than it is practical.

>> In libmame I recently collapsed the range down to 16 bits in either direction and scale the results to 17 bits before passing them to MAME. The one part out of 32000 difference in accuracy will never, ever be detectable.
<<

I guess, if it is scaled at the right place, otherwise I'm guessing there is a possibility you could have a problem with centering and dead zone with analog sticks. I'd test it out on Star Wars and maybe also Missile Command & Road Runner. Also spinners that have to return the pointer to exact same position every 360 degrees, you might now have a gap there.