Direct3D vs. Directdraw Question

[adder]

Hi i was wondering when using groovymame, what are the differences between using direct3d vs. directdraw with regards to the following:
1. overall emulation speed
2. input lag
if there are any other advantages/disadvantages between using direct3d vs. directdraw, i'd be interested to know. many thanks

[machyavel]

Hi, Regarding input lag and according to these measurements made by Calamity: http://forum.arcadecontrols.com/index.php/topic,133194.msg1374879.html#msg1374879,
ddraw is preferable over d3d without frame_delay option. Else (frame_delay on) it's about the same.

[adder]

cool thanks for the response
hmm so are there any other advantages/disadvantages, just wondering if there is no real difference between the two lately (when using groovymame), or if it's still preferable to use directdraw over direct3d (it seems that using directdraw has been a long running preference amongst real arcade monitor/crt users)

[cyb]

I could be wrong here, but the biggest reason to use direct3d is for HLSL effects. I personally use directdraw since I'm running 15khz crt.

[Calamity]

Since the video rewrite in MAME v0.107 ddraw was preferred for 15kHz setups because it was the only way to achieve integer scaling with vanilla MAME (leaving apart SDL). But then Cabmame came out with the -cleastretch patch making d3d just as usable.

D3D performs much better than ddraw when scaling is involved. That's why it's almost a requirement with LCD screens or high resolution CRTs.

Sometimes the video card or Windows decide that certain modes are unsupported by your monitor and these are filtered out. You can still force Windows to list them. But trying to set those with d3d will fail. Only ddraw allows you to use the theoretically unsupported modes.

Then it was discovered that the video drivers (ATI at least) set a frame queue when using d3d that adds 2 frames of lag. This frame queue is bypassed when using ddraw. It can also be bypassed with d3d & frame_delay, *but* this produces static tearing when working with high resolutions. Being d3d the only decent alternative for LCDs, this means there's not a good solution for lagless v-sync on LCD screens.

Then it was discovered that in W7, interlaced modes report a halved refresh rate so you can't v-sync on them. This doesn't happen with ddraw. But ddraw is terribly flawed with W7, its set-display-mode api just can't handle interlaced/progressive mode switching and bilinear filtering is only supported with flipping surfaces. So some dirty workarounds had to be implemented in GM to make ddraw an usable option.

Finally the situation with W8 and current drivers looks like ddraw is a fake/emulated interface and not an option anymore.

[haynor666]

Calamity, I'm using windows xp x64 so what method is preferable? Is it better to use D3D with syncrefresh/throttle or DDraw with tripplebuffering ? Many people reporting that using D3D with vsync is less laggy than ddraw with tripplebuffering.

Note that I'm not using frame_delay generally as this caused some games to work at erratic speed even with various games in the same driver.

[bulbousbeard]

Being d3d the only decent alternative for LCDs, this means there's not a good solution for lagless v-sync on LCD screens.

If you go the LCD route, it's basically G-Sync monitor or don't even get out of bed at this point. It's the only way I'd run an LCD.

[Calamity]

Is it better to use D3D with syncrefresh/throttle or DDraw with tripplebuffering ?

That's a false disjunctive.

If you're talking about GroovyMAME, syncrefresh/throttle should be used always when possible with both D3D & DDraw. When combined with -frame_delay, both methods are equivalent in terms of lag.

Triplebuffering is used when you want asynchronous flipping, either with D3D or DDraw. Multithreading must be enabled for triplebuffering to make sense.

Many people reporting that using D3D with vsync is less laggy than ddraw with tripplebuffering.

Maybe with regular MAME, not with GroovyMAME.

Note that I'm not using frame_delay generally as this caused some games to work at erratic speed even with various games in the same driver.

Don't trust the on screen speed percentage when using frame_delay. Use your eyes to judge if the scroll is smooth. If you notice any hiccup, lower the frame_delay value. This option needs to be adjusted game by game.

[haynor666]

frame_delay in some really produces strange results (Air Attack is good example) and this I've seen just observing game bit majority it didn't causes problems. I've now build new arcade pc based on G3258 clocked to 4,2 GHz on Asus H81M-E so I have more power for games that previosly didn't even enough power to work correctly with frame_delay 1 (like some stv games).

I'm not professional player but I'll try to enable frame_delay 1 just to bypass D3D queue and reduce lag. Probably I won't notice any difference but worth try