Blur Busters Forums

Seeing that you're taking so much care in dejittering vsync pulse, I'm wondering. How bad is jitter in vsync? In our experience (GM) vsync was way more reliable than cpu timing to base emulation throttling on. E.g., tying sound update to vblank-end lead to very little or none buffer overflows/underf...

twilen wrote:My assumption is that continuous D3DKMTGetScanLine() calls waste bus bandwidth and/or requires some driver locks, stalling other threads.

Yes, whatever the reason behind, that is true. Constant polling in a loop stresses the gpu badly. That's why it'd be great to have an interrupt-like mechanism.

It depends on which os the bigger latency issue - slice size adds latency, as 6 slices is about 33 percent more laggier than 8 slices. So your VSYNC offsets savings have to be big enough to more than compensate for this. Basically the vsync offset savings need to be bigger than the slie thickness d...

(EDIT: I concur -- raster prediction becomes less reliable with longer intervals between tearlines. It might be some form of background processing in the graphics card or something. But perhaps a flush call might solve the problem) Indeed, you were right. I've added a flush before Present(), and no...

I still have one unexplained problem where Present() still shows few lines from previous buffer randomly in top of the screen. D3DKMTGetScanLine() always returns InVerticalBlank set immediately before Present() call. So it looks like something randomly stalls inside Present() for some reason. G-Syn...

Nice, the lag is what I expect: That said, if graphics card performance allows, I'd go 20 slices per refresh cycle (maybe more). That reduces input lag by half and will probably be quite dramatic for high speed video demonstrations. I'll implement the ability to add more slices soon and see what's ...

Lots of bounce on that switch at 1:53. If you're going to work this into an actual game controller I'd suggest using the NC contact of the switch for debouncing. Thanks for the suggestion, you're right. I thought I'd post the uncut video material with all its imperfections. Initially I was planning...

Current frame response is finally possible! https://youtu.be/egIEL7158N4 Demonstration of the experimental "frame slice" feature. Tear free rendering at 500 fps, 728x567i 49.890 Hz. Emulation of each frame is divided in 10 "slices", synchronized with the physical raster. Input data is polled and pr...

Hi Mark, I'm not sure when or how I'm going to release this thing. In a way it's already released: you have the binary and the source. As I've said, it's problematic with many drivers, which is the reason why I refrained from releasing it right away. Then you opened this thread and my pride was stro...

Here are the diffs, that must be applied over MAME 0.195 baseline code, in this order: 0195_groovymame_017g.diff -> d3d9ex.diff -> slice.diff (being slice.diff the file that contains the "frame slice" implementation. Most of the file just removes previous GM features). Now, an important warning: THI...