MAMEWorld Forums - Programming - Re: Why are MAME INPUT_ABSOLUTE

R. Belmont,

Except C/C+, what else is there to know? Surely you must have opinion on the subject regardless of whether or not you are aware of the current implementation, eh?

As much as I gather you are one of the last "MAME devs" around, so if you don't know, and the other guy left, does that mean the project is in need of someone who would look at it, or is everyone happy (don't care) to leave it as it is?

On the side note, I find it interesting with all the re-writes MAME went through, that input and frame stepping (animation) algorithms stayed almost completely unchanged from the DOS days. Can you comment on that?

By the way, I am making my own MAME re-write, just finished with frame-stepping algorithm, accompanied with numerous changes to how timing and general frame and audio syncing is handled there. Those changes fixed all the visual glitches and audio hiccups and crackling MAME is cursed with, as you know, or do you not?

Auto frame skipping algorithm is wrong. Some kind of attempt at telecine on the fly, but that doesn't work, it can not work. It's like dividing 5 by 3 and expecting to get a whole number as the result. There are only two properly working frameskip values in MAME: 6 and 9, (from 60fps -> 30fps, 15fps), but even using those would still leave you with audio syncing issues. You know what I'm talking about? Let me know if you wanna hear more.

Anyway, the input handling is next for me to re-write, which brings me here, and that part is tough one since it's everywhere, interwoven in user interface and worst of all it may impacts all the game drivers, possibly requiring individual changes to every one of them.

My re-writes are drastic, you probably will not like it. I throw away anything not absolutely necessary, which turned out to be around 80% of the code so far, but even if you don't think my re-writes are suitable we can still talk about it and hopefully there is something for both of us to learn by it.

Oh, by the way, I was also exploring the possibility to do "interlaced rendering" so every other frame have odd lines and the next one even lines of the frame. I can of course do it with post processing and it looks cool, similar to scan-lines effect, but what I really want to do is to use it as optimization trick, so to skip processing half of each frame and therefore hopefully gain some speed up while getting a cool visual effect in the same time, and I was hoping I could do it from "drawgfx.cpp", but it seems this must be done with each game driver individually, each one possibly requiring unique modifications. Can you tell me anything more about it, do you know how was interlaced rendering handled in DOS builds that supposedly could do it with arcade monitors?