Frame Delay: does it work with ddraw as well?

[donluca]

Title.

Also, is it necessary to play around with frame delay using d3d9ex?

Most important then both these questions, actually: are any advantages using frame delay with ddraw or d3d9ex?

[intealls]

Frame delay works just fine with ddraw/d3d/d3d9ex. I've noticed that d3d/d3d9ex performs better on my rig, but this can probably vary depending on your hardware configuration.

[donluca]

Frame delay works just fine with ddraw/d3d/d3d9ex. I've noticed that d3d/d3d9ex performs better on my rig, but this can probably vary depending on your hardware configuration.

Thanks for the reply!

Since ddraw already skips the frame queue, does frame delay actually do anything with this render? Like lower input lag or something?
I've made some tests and when using frame delay a lots of games become very slow, unless I enable multithreading and triple buffer.

[Calamity]

Since ddraw already skips the frame queue, does frame delay actually do anything with this render? Like lower input lag or something?
I've made some tests and when using frame delay a lots of games become very slow, unless I enable multithreading and triple buffer.

Frame delay doesn't work with triplebuffer, only with syncrefresh. Frame delay is very cpu expensive, that's why you can't use a general setting for it and you need to apply a custom value per game.

Once you remove the frame queue, you're in the theoretical situation described by the emulation literature where "emulation by definition always has one frame of lag compared to real hardware". The purpose of frame delay is to remove that remaining frame of lag and match the behaviour of actual hardware.

[donluca]

Ahhh that makes it clear.

Let me see if I understood it correctly.

Frame delay is used for:

1 - Remove the frame queue (3 frames of lag) – only applicable to d3d, ddraw doesn't have frame queue.
2 - Remove the remaining frame of lag due to emulation

and it only works with syncrefresh.


Triplebuffer doesn't work with syncrefresh, as such, it doesn't work with frame delay. This means that by using triplebuffer we still have the framequeue with d3d (3 frames of lag) plus the emulation lag (1 frame) and... theoretically more due to buffering?

But triplebuffer is needed in order to let vsync work in a separate thread with the multithread option.


Right?

[Calamity]

Frame delay is used for:

1 - Remove the frame queue (3 frames of lag) – only applicable to d3d, ddraw doesn't have frame queue.
2 - Remove the remaining frame of lag due to emulation

The purpose of frame delay is (2). (1) is a side effect and only applies to d3d.

Triplebuffer and syncrefresh are mutually exclusive. GM always tries to use syncrefresh when possible.

Triplebuffer with d3d must be affected by the frame queue (haven't checked). Triplebuffer with ddraw or d3d9ex must be only one frame of lag more than syncrefresh + frame_delay, in the worst case.

Triplebuffer requires mt in order to actually work. It's purpose is to perform tearing-free asynchronous rendering (an unsupported feature by default at least until DX 10).

[donluca]

Triplebuffer with ddraw or d3d9ex must be only one frame of lag more than syncrefresh + frame_delay, in the worst case.

So it's better to use ddraw (win xp) or d3d9ex (win7) with triplebuffer instead of d3d, lag wise.

When you have some spare time, can you do a test to see if triplebuffer with d3d is affected by frame queue?

Also, I wanted to report that using triplebuffer + multithreading hasn't caused any kind of scrolling stutter so far on lots of games.

[Calamity]

Also, I wanted to report that using triplebuffer + multithreading hasn't caused any kind of scrolling stutter so far on lots of games.

It does cause scrolling stutter, it may be subtle but it does. Only use it when is strictly necessary.