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.

That being said, in libmame I attempted to hide all of the nuances of the MAME input system behind an API that is fairly sane. Rather than deciding to attempt to redesign the MAME input system, I just defined my own API and put all of the MAME stuff on one side of it, allowing everything on the other side to not care about the implementation details.

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.

I read your other posts about improving the audio and video systems with interest. I hope you can accomplish what you want to in a way that can be incorporated back into MAME. 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.

I think there is nothing wrong with wanting to improve MAME and I support you in your efforts. I also agree with you that the way that MAME is implemented, so much of it is intertwined in suboptimal (from a design and maintenance perspective, not so sure about performance but we'll see) ways and it would be difficult to make significant changes piece by piece. So it's only natural to want to rewrite large parts of it rather than deal with trying to make incremental changes.

For what it's worth, I think that the C++-ification that's been worked on off-and-on by Aaron is not very useful. Maybe it is from a MAME driver writer's perspective but it looks to be very marginal to me, and the use of a terse and self-obfuscating C++ style doesn't help. Like I said, maybe somehow driver writer's jobs are being made easier but looking at how drivers are currently defined, with a bunch of confusing macros that have been repurposed and overloaded in weird ways, not to mention weakly documented, I can't see how things could be worse. But that's just my opinion, and it's not super highly informed (I've never written a MAME driver), and I'm only posting it here because this thread seems to be a place that dissatisfaction with MAME design is a relevant topic.

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. It reminds me of the type of design sensibility that says that 128 bit filesystems might not be sufficient even though you'd need more energy than it would take to boil all of Earth's oceans to populate a 128 bit filesystem.

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.

Edited by Bryan Ischo (05/08/12 06:28 AM)