MAMEWorld Forums - The Loony Bin - Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)

I'm starting to find your posts somewhat abrasive.

Yes, these things can be measured on hardware, but they're entirely to do with how the game is programmed in most cases, nothing to do with the actual hardware.

NeoGeo for example has 'next line' response for most things, including sprites (which is why you can do raster effects on sprites) but plenty of the games have measurable input lag due to how the games are programmed. MAME has no way of knowing that, or communicating that information back to you. Systems like the Genesis are 'next line' too. It's meaningless however, because the games are almost never programmed to take advantage of that, the game code buffers inputs and buffers sprite lists, that is where most of the 'lag' people are measuring 'with hardware' comes from.

In a 'best case' scenario MAME will be 1 frame more laggy than the original games due to having to compose the screen to a buffer for the video card to present. If you start turning on options that specifically add extra buffers then it will be more. If the game code (software) is out of sync with when your PC reads inputs / MAME gets inputs from your device, then there can be another, but again, that comes down to the software programming of the game, something MAME does not know about. PCs and original hardware don't work in the same way.

As I said before, you're asking for something which outside of running the game, and having a specific piece of software running, cannot be summed up in a simple number. This is not something MAME can know.

MAME does not think as a 'player' as it is not a player, it is a piece of software, it is not self-aware.

MAME will not be following projects like RetroArch down the ugly path of databases for per-game hacks of things that are completely irrelevant to emulating a system properly. That is the wrong direction.

Techniques like Beam Racing, which requires a lot more effort to actually do right, can take out the extra frame of lag from the PC side and match how the games would run on hardware (to the nearest line, not pixel, but nobody is measuring response times in pixels right now) Run-ahead is an ugly cheat. Unfortunately as people would rather cheat it seems there is less incentive to do it properly (as doing it properly actually will requiring rewriting every single driver to have 100% proper line rendering and buffering logic emulated at the exact times the hardware does it)

At this point I'm just repeating myself, and will not be responding further.

> How the game play in MAME is what I'm talking about, this is what matters to
> everyone, and why to attend to the matter of lag things like frame_delay and
> run-ahead exist.
> In practice when we play MAME this lag appears to us and we can at the very least
> count it in frames between the time we input (action) to when the reaction is seen on
> screen (reaction)
> Additional frames used to sync to screen notwithstanding, as far as we've seen the
> 'initial' delay consistent, each emulated hadware produces a number of those frames
> from input to reaction.
> And this is the one lenght that we understand corresponds (even if maybe not an
> accurate translation) to what we can have in the emulated game environment, and we
> qualify as the original game hardware's lag.
>
> I think either you don't get where a user-player stands, or you're giving me the
> answer that concerns the developer point of view, which is probably the right one for
> someone who would like to understand all what it's about but is less interested in
> knowing about what it translates to in the real life practice, and yet is verifiable
> when playing games with MAME.
> Maybe as a dev it goes against your way of thinking to speak of it in terms that
> would be relatable to the user/player for the matter that concerns him.
>
> Don't get me wrong I'm not criticizing you there, and I believe I've got a portion of
> what you said, but if you remember my idea was to add some form of information about
> what indeed happens in MAME delay-wise and the user experiences while playing,
> because I think it would prevent a good number of misunderstandings (again at a
> use-player experience level) and therefore limit misuses in practice (driver hacks,
> abuse of lag reduction like run-ahead, stealthy 'cheating')
>
> Now if discussing this from that perspective is something you refuse then nevermind
> what I asked, and please again don't take offense, remember you're not talking to an
> engineer or a developer here, just a user-player who loves MAME.
> What I'm thinking of can probably be done outside of MAME without your involvement
> (even if of course I think it's much, much better when actual MAME devs are involved)
>
>
> EDIT: last attempt from my side; were you actually simply trying to tell me "the lag
> in real life environment (pcb + crt) is not the same thing as the lag in MAME" ?
> If so just try to understand that if you then also say that MAME emulates the
> game-hardware accurately, as users playing we are naturally driven to think that we
> can trust the lag frames we can count in MAME.