|
|
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
10/08/18 10:34 PM
|
|
|
I'm telling you that you're asking for metadata that can't be derived from hardware directly (in a 100% logic based way) and that in most cases it's down entirely to the programming of the game.
It's information that is completely irrelevant to MAME or how MAME works. We emulate things, accurately where possible.
> > You're asking for an arbitrary number that can be measured against any number of
> > things, not something that can simply be derived from hardware specs.
>
> But among all the things that the hardware does internally there's a peak value that
> matters to the player isn't it?
>
> Most times you're playing the action with a layer of sprites, shouldn't that value be
> what counts for peak/total lag of the hardware, assuming it all happens within a
> frame?
>
> If so that's what should be referenced IMHO.
>
> Anyway I think the more info the better, because the more you remove the more
> incorrect things people assume, and we clearly need to understand more, not less.
>
> EDIT: okay maybe you're giving me a developer answer because you don't think like a
> user.
> I'm talking about input lag in MAME, the one we can count in frames, each game
> hardware has a number of those, some react to the next frame, some need 1 more, 2
> more, etc.
> Then on top there's the frames used for syncing to display if we choose waitvsync or
> something.
> That (initial) number of frames is the one I think should show somewhere. (and
> optionally the ones used for sync to display)
>
> EDIT2: or are you telling me that the translation in a number of frames in emulation
> isn't fixed in a set number to a 'cycle' ? if so how come we can always count the
> same number of frames when we try a particular hardware for input lag?
|
|
Index 
Flat 
Re: I may get flamed for this, but this IS the loony bin so... (Retroarch Bounty)
Reply
