Emulation vs Framemeister a few questions

[Fudoh]

in your MAME config, set mame.exe to use G-Sync

are there any user reports yet on this ? Does it work flawlessly with anything from 53 to 61Hz ? Didn't I recently read that G-Sync requires a certain D3D load on the graphics card to stay activated ?

[Ed Oscuro]

Didn't I recently read that G-Sync requires a certain D3D load on the graphics card to stay activated ?

Yes, I had stated that the driver has to switch into 3D mode, but somebody said that this is a bit of a misnomer and that it's not the 3D but the load on the GPU that does it. There are many threads around the Internet about forcing the drivers to use the settings for that 3D mode (i.e. this potential fix), which should pull along G-SYNC activation as well. I think that eventually they should go ahead and make G-SYNC work in all driver usage profiles, or at least give an option for that. There may be something that breaks in Windows if you have an option which basically enables V-SYNC (via G-SYNC) but I will have to ask about that.

re: The PC graphics thing, obviously the screenshots shown are of a console game, nothing to be seen in the PC DOS-derived screen modes like 13H or Mode X. In terms of what is closest to classic PC screens, that look is it. It's obviously different though, and for 2D PC games I would prefer the PC VGA CRT look. But for something like Duke Nukem 3D or Shadow Warrior, I think that the LCD monitor look is just fine (if you can eliminate motion blur, that is, and have good color reproduction / viewing angles). Still not exactly the same and something of the classic experience is lost, agreed, but one thing I don't miss is the flickering present at even relatively high refresh rates.

[Thomago]

but one thing I don't miss is the flickering present at even relatively high refresh rates.

Because of that flicker shit I'd never ever go back to a CRT monitor.

[BuckoA51]

If there's no input lag in Mame what was shmupmame for, was it just a placebo?

[Ed Oscuro]

MAME attempts to faithfully emulate the amount of time it takes for the actual arcade game to process an input and provide output - in some well-regarded arcade games there's already a couple frames of latency between the moment an input travels through the JAMMA connector, and the moment the RGB signals are sent back out across that connector. As far as I know, it's the MAME vision that this timing be represented reasonably accurately (whatever that means). However, MAME as a program runs in non-realtime OSes like Windows and (most variants of) Linux. There are all sorts of tricks one can try to reduce the time inputs and outputs spend within the operating system, but this will never get to an "instantaneous" level. In fact it's been quite a challenge for many users to get it to the sub-frame level (which would be "more than good enough" for many users) in many cases, especially when the monitor is concerned.

Long story short - ShmupMAME tried to eliminate some actually original sources of lag as a way of finding some "free" performance in games, to counteract the lag from the program within the OS. As it turns out, a number of arcade games cannot simply be hacked like this while remaining faithful to the originals. I know that visuals were affected in some cases.

There are a number of things that are possible or should shortly become possible to help fight these new sources of latency, without compromising MAME's ability to present the games accurately.

[BuckoA51]

Makes sense, also as you rightly point out due to the underlying OS I can't see really how Mame could ever be completely lag free (compared to the real thing running on a jamma cab with a CRT I mean).

[bulbousbeard]

MAME can be lagless--you just can't enable v-sync.

V-sync is the only thing that really introduces lag with MAME. Like I said before, if you run fast enough, the extra frames compensate for any lag introduced by the OS or the emulation itself.

ShmupMAME hacked MAME to shit in an attempt to reduce input lag and still enable v-sync.

[trap15]

MAME cannot be lagless. The architecture forces at least 1 full frame of display output delay.

[bulbousbeard]

MAME cannot be lagless. The architecture forces at least 1 full frame of display output delay.

Yes, it can, for the reasons I've already stated. It's been tested with high framerate cameras. It only has 1 frame of lag with v-sync on.

[trap15]

No, you're not understanding. It has to wait a whole frame to be able to then render to a framebuffer, which has to then be displayed. It cannot render while the normal game would render without serious work. It must always have 1 frame.

[bulbousbeard]

No, you're misunderstanding.

It's been recorded with high speed cameras with v-sync off compared to the same game on a real PCB with no additional lag.

[trap15]

Using the same inputs? I'd like to know more about these comparisons: how were they set up, where are the comparison videos, etc.

Because I have serious doubts, considering MAME developers themselves have continuously told me what I said, and I've confirmed it through my various times wading through the code.

[bulbousbeard]

MAMEdev has always been talking in the context of v-sync on (because it's assumed that nobody with taste could stand to look at tearing while playing a game seriously).

http://forum.arcadecontrols.com/index.p ... c=133194.0

Look at Calamity's test results:
d3d_novsync: 9, 6, 9, 7, 8 -> 7.8 -> 3.9 + 1(led-lag) = 4.9 ≈ 5 (no lag)
d3d_vsync: 16, 16, 15, 17, 17 -> 16.2 -> 8.1 + 1(led-lag) = 9.1 ≈ 9 (4 frames of lag)
d3d_framedelay: 10, 11, 10, 9, 10 -> 10 -> 5.0 + 1(led-lag) = 6.0 ≈ 6 (1 frame of lag)

ddraw_novsync: 8, 9, 9, 5, 8 -> 7.8 -> 3.9 + 1(led-lag) = 4.9 ≈ 5 (no lag)
ddraw_vsync: 11, 10, 12, 9, 8 -> 10 -> 5.0 + 1(led-lag) = 6.0 ≈ 6 (1 frame of lag)
ddraw_framedelay: 11, 9, 9, 10, 10 -> 4.9 + 1(led-lag) = 5.9 ≈ 6 (1 frame of lag)

Calamity knows what he's doing. It just wasn't of much interest to him because he only cares about synced video.

[trap15]

Seems pretty imprecise, if you ask me. I'd trust my knowledge of the code far higher than his self-admittedly flawed measurements. And you yourself are even saying he didn't put much effort into investigating no-vsync, so I doubt he's actually verified it too hard.

[bulbousbeard]

Well, he did add extra frames in his calculations to compensate.

Regardless, even if you accept that you'll always have 1 frame of lag (which I don't), 1 frame doesn't always mean the same amount of time.

If you have a 144hz monitor, 1 frame of lag is significantly less than it is at 60hz.

I agree, though, that it would be nice to see G-Sync monitor specific testing so we can be absolutely sure of how good it can be without v-sync and doubling refresh rates.

[Xyga]

MAME cannot be lagless. The architecture forces at least 1 full frame of display output delay.

I've read about that many times as well, didn't get everything but iirc the core is made of several layers working together (like driver, video, sound, inputs etc) and the process always requires about one frame. Is that it ?

It's funny because I've read a similar 'Mame can be lagless' statement much recently on the french forum, and I've asked the guy the same question about Mame's core emulation that's supposed to require at least one frame no matter what, and he didn't have a clue.
Someone must be spreading the 'mame no lag' stuff all over the forums at the moment, the guy I mentioned has been on the Retroarch hype for a while.

@bulbousbeard: High speed camera + timer testing is full of traps so I'd be careful with the figures. Websites like tftcentral, prad.de etc gave up on that method a while ago because they realized it can be very misleading.

[bulbousbeard]

I haven't seen ANY tests besides Calamity's that actually used MAME without v-sync. I see no evidence anywhere that MAME with vsync off has any extra latency.

The whole concept of "1 frame of lag" is the actual trap. 1 frame of lag at 60hz synced might be 16ms of latency, but it's completely ignoring what happens when you run at 120hz or--even better--disable v-sync and are spitting out frames as fast as they'll come in.

MAME without v-sync doesn't have any additional lag. The perceived lag that people run into is coming from their shitty USB joysticks, LCD monitors, etc.

If you plug MAME into a CRT and disable v-sync or use a G-Sync monitor, there is no additional lag besides what a fucked up MAME driver would introduce (on top of the core program). Yes, there are specific MAME drivers that have more latency than others because they're trucked.

[Ed Oscuro]

Right, I forgot about the framebuffer. One of the basic problems is trying to smash up completely different display technologies - ultimately the only way out I see is something like hyper-pulldown (like on the order of 240:1; thankfully G-SYNC offers the possibility of allowing the panel to match the desired ratio exactly and easily).

The worst-case scenario is that the top row of pixels in a frame has to wait until the bottom row of pixels is ready for transfer / display - so the relative delay for the bottom of the frame is much less than that of the top. The bottom pixels might display with a sub-frame delay but the top pixels cannot, as they were waiting for the whole buffer to be drawn before they could even start to be transferred - while on much original hardware they could have been drawn as soon as available (depending on how the video hardware of the original system works - if it races the beam or if it buffers, and how it buffers).

If there was a variant of MAME with a per-scanline output option (this probably forces us to say bye bye to HLSL or any other kind of postprocess effect whatsoever - even nearest neighbor might not work in this case) which could grab individual lines of resolution and send them out across the display connection (external graphics subsystem processing included) then perhaps this source of lag could be eliminated. However, it should be remembered that G-SYNC is explicitly moving away from this direction. G-SYNC does not allow grabbing arbitrary scanlines, but explicitly arranges to send out an entire frame and only an entire frame. We still will have to deal with the top-to-bottom drawing direction because drawing pixels onscreen will still be delayed until all the pixels are available. If we can grab images from an emulated full-frame buffer, then there's still a problem (although maybe a much less important one) because the original hardware had to draw scanlines from that buffer - we might improve the lag characteristics beyond what the original program could provide.

You could "fix" this by having G-SYNC and the monitor draw all the pixels in a frame in the time it takes the original game to draw one scanline, and then continuously update the frame with new scanlines, keeping all the old lines of resolution that haven't been updated (or maybe fading some out to emulate CRT flicker), as each new scanline is drawn. Monitors will have to be able to refresh around 240 times faster than they do now to achieve this for a basic 240p game.

You could try to fix this by having G-SYNC grab a full frame out of an emulated buffer provided by MAME and then very quickly draw the whole frame before the next scanline update, but now you've created a new problem where the bottom scanlines are drawn nearly a full frame faster than they would be on CRT monitors updated per-scanline - and of course this would only work if the game in MAME has some kind of full-frame buffer.

PC games are a different case because that buffer is assumed to be there all the time and additionally not necessarily synchronized. An uncapped framerate and fast enough monitor / connection allows the monitor to grab segments of new frames continuously (drawing those which fall along that part of the monitor that is currently being updated). Game state updates within the program are reflected in close to real time in the slices of screen updates displayed on the monitor - as tearing, which is almost never acceptable behavior. Naturally, I think we all understand that the arcade games normally run at fixed framerates, so it's meaningless to talk about such tactics (and they will give obviously incorrect behavior anyway).

And all this is just a guess and simplification - there may be things going on in games or MAME that I haven't even guessed.

[BuckoA51]

there may be things going on in games or MAME that I haven't even guessed.

Indeed, there are so many other factors that can effect performance too and so much misinformation. At one time I recall there were some folks saying you should run windowed and not fullscreen for instance, which has to be nonsense as then you have to deal with the Desktop compositing.

It seems a bit of a stretch to think an emulated game running on top of an OS like Windows, Linux etc could be as responsive as running it on the original hardware, though it's nice to know that the lag in Mame isn't as great as many folks make out (I hear the old 2 to 3 frame figure for all emulators kicked around a lot from some quarters).

[Ed Oscuro]

Theoretically, a minimal installation of a modern OS polling input devices and sending output quickly should be very close to lagless at many points - but there are many areas where driver support and design will probably torpedo this. Audio drivers might (probably do) have a buffer of some miliseconds, the graphics driver might not have good optimizations for situations where it is under low load, and so on.

One area where the non-realtime aspect of modern OSes appears with a vengeance is in the implementation of hardware timers. Generally, Windows detects the platform timers available and makes use of them. However, using some timers and disabling others can provide better latency issues - emphasis on "can." For daily usage and even gaming it seems that changing the timers used in order to minimize latency actually hurts performance. In Windows alone there are surely too many hidden services and settings - and assumptions in programming - towards a multitasking, high-bandwidth environment, at the cost of hurting its realtime responsiveness. I think things are getting better on the hardware front but it is a slow process.

[Artemio]

There is another factor as well. Rendering extra frames is being regarded as a solution without consequence. In reality the game runs through a cycle.

- Calculate internal state from last input and previous state.
- Wait for v sync
- Read input

Of course that is not necessarily the order, but that doesn't affect the current issue. Every time a frame is drawn, input can be - and is usually - checked.

If you generate more frames from within the game engine you gain nothing.

In the other scenario, where you are just pushing the last frame you have -while emulating the next frame - you still have the frame buffer issue that Trap mentioned. It is very real and you can check the code yourself.

Aside of that, M.A.M.E. works emulating video in a high level. When you check the code, and are in need of information to repair the video section of a game, you have only the information needed for high level checks. Mame doesn't care about how it works in detail, as it is needed when emulating a CPU. In video, it cares about the results.

Older games, for example, generate the video signal from pointers to the sprites in VRAM to the ROM. And the Video logic, usually TTL or a custom chip, gives the current pixel to send in a linear video level signal for the current position.

[Ed Oscuro]

So it sounds as if the issue is not really related to the buffer per se. I may have made a mistake in forgetting that the simulated program state within MAME is not totally disconnected from outside references - it still processes inputs coming from real-time (hopefully...) during its whole frame cycle, and apparently this has priority over screen writes. That just limits you to a frame-length delay for the top of the image - but the bottom of the image can be written as soon as that simulation cycle is over (and the graphics / display hardware have done their work). Hard to say without having seen a description of MAME's input lag source.

A single-buffered image just needs to avoid a race between the buffer being written and read. On chaotic PC systems this is hard to arrange perfectly, but having relatively low processing demands on the input of a frame from MAME makes this easier, and also being able to make use of the vertical blanking interval counts as "free" time for compositing should help this problem.

Multiple buffers can help eliminate this problem, though it goes without saying that the simulation state needs to be locked down before it can be written. But I think modern graphics hardware is fast enough to get this to a sub-frame delay for part of the frame.

It does come to mind that perhaps you could process and buffer conditional output frames, selecting the ones that will obtain once inputs are written. I am not sure that current graphics hardware or drivers would allow this, though, since you would need an insane number of frame buffers once the number of user choices that affect a single frame go up. Writing to the different buffers simultaneously would be problematic as well...probably it is a matter of bandwidth and cheap PC hardware design that restricts this from being reality any time soon (and of course people buy more hardware to process more effects and resolution, not to create totally throwaway frames). However, I wouldn't be surprised if this eventually happens. We have speculative execution already on CPUs but that only impacts small areas of memory, not potentially multi-megabyte buffers being written on another device...but again, I think we run into the problem of a whole-frame readout vs. a scanline-based readout.

I still feel that the "pulldown" style method would be successful, because it allows that worst-case delay to be eliminated by updating the screen in scanline-sized increments.

[fandangos]

Last thing: those shitty shots of emulators do not represent what a well-configured MAME setup looks like at all. You pretty much have to use HLSL at this point if you want a nice image. Here's an example of MAME running on a 2560x1440 LCD with artwork for a widescreen bezel and HLSL.

http://i.imgur.com/oEn1g2d.jpg

This is better than a Framemeister is ever going to be

Hey, do you mind posting your HLSL preset here? So I can test it out?