BenQ Zowie XL2411 vs RL2455 *vs* Dell U2414H

[RealNC]

This only works on a CRT on analog signals

Not sure that's correct. The vblank works the same over digital (like HDMI) like it does over analog.

[lexlazootin]

Yea, i'm not 100% sure how it works but i know consoles with a analog output also carried a Sync signal which was used to control the V-Sync, I've also heard that the consoles like the NES and the Atrai and such would do all of it's calculations during the VBlank and then spit out a image as it's drawing.

Some games would even change resolutions on the fly like Silent hill 1 when you go into your menu and the same with Chrono Trigger. It's all pretty neat.

I THINK because it has full control over the V-Black and Sync it can work out a way to only render and calculate during that time and in theory have better latency then a LCD. But maybe i just don't understand the tech at all.

[t2k]

The NES can absolutely have much lower input to display lag than 16ms. Thorough explanation - https://wiki.nesdev.com/w/index.php/The_frame_and_NMIs . One takeaway from that is that in practice, most games do have exactly 16ms of latency because the game logic runs outside of vblank, queuing up PPU commands in a buffer, which then get dispatched during the next vblank. However, what I've measured is that some operations (pause screens appearing/disappearing for example) are <= 4ms latency because that processing does happen entirely within vblank.

HDMI and LCD panels do not inherently need to force additional buffering into the image processing path, but in reality most LCD displays do (especially tvs) in order to do more image processing - noise reduction, motion smoothing, rescaling, etc.

I've ordered a U2414 and we'll know for sure by Monday or Tuesday whether it has less lag than the BenQ's.

[Chief Blur Buster]

Have you tried GSYNC or FreeSync? They are lower lag for fixed frame rates than VSYNC ON. They massively reduce emulator lag, sometimes to less than the original machine (in certain cases).

GSYNC and FreeSync use line-buffering instead of full frame buffering, and each refresh cycle is scanned-out at max Hz. So a 240Hz G-SYNC monitor will refresh each "60Hz emulator frame" in 1/240sec onto the panel.

The main catch is your emulator must be outputting in a Direct3D or OpenGL mode. Some emulators such as MAME and certain NES emulators are able to do that.

[RealNC]

Well, this is an FPGA NES implementation, not an emulator, so no VRR. Just plain old 60Hz.

[Chief Blur Buster]

Well, this is an FPGA NES implementation, not an emulator, so no VRR. Just plain old 60Hz.

Oh yes. Good catch.

The only way to get less lag than original arcade machine or NES (and FPGA emulators) is to use a surge-execution tactic + a >144Hz VRR display (you can do non-VRR, but it is much harder to do just-in-time-rendering-before-refresh). Basically, each jiffy's (1/60sec) worth of emulation is executed at full throttle (e.g. 10 times the speed of a real machine) then the framebuffer delivered in a huge hurry in 1/240sec on a 240Hz monitor. Meaning each "60Hz" refresh cycle is delivered in 1/240sec to the monitor, instead of the usual 1/60sec (VRR such as G-SYNC makes this easy to do nowadays). Then the emulator practically idles almost 1/60sec till the next emulation surge. Basically just-in-time surge-emulation+delivery, once every 1/60sec, then idling till next "emulated refresh cycle", rinse and repeat. Rasters/emulated scanouts can still work in a "60Hz-compatible way" (it simply outputs into the scanout-accelerated internal framebuffer in GPU). To the emulator, the emulator feels like it's just running at a constant 60Hz at a constant speed. But to an outsider, the emulator speed is surge-pause-surge-pause-surge-pause. As long as that's perfectly in sync with 60Hz refresh cycles, there's no difference in emulator quality and speed, just miraculously less input lag than the original 60Hz machine. That shortens the time between the input-read and the actual display hitting the human eyes. Not all emulators can do this, but some can be configured to do such. This works best with emulators that buffer their actions in the console (less input lag than the original Nintendo) but may not always reduce input lag for on-the-fly rasters (e.g. Atari 2600 TIA, or Commodore 64 raster interrupts, etc) since there would not be a 1:1 scanout symmetry. But that doesn't matter for framebuffered 8-bit games (e.g. scrolling character modes and bitmapped modes that reads controller input once every 1/60sec during the VBI) -- those games can run with less lag in a PC emulator than the original machine, if using surge-execution-per-jiffy + accelerated-scanout trick. I don't know if any Nintendo emulators support this, but either way -- this emulation rendering pipeline needs to become more popular, and for emulator purists, the delay can be calibrated to allow a PC-based emulation to have the same input lag as the original machine (at least making the assumption that the input reads are read during the VBI of the original 60Hz machine).

Now FPGA-based emulation is the best way to get maximal accuracy in all possible input-read situations; just saying that it's not impossible to have less input lag than the original machine or an FPGA based emulator -- thanks to multiple tricks now availalable that weren't possible back in the 1980s.

____

Back on topic.

You definitely want a realtime-scanout panel (line buffered) rather than a full-frame-buffer lagged LCD.

Try turning off strobing. Strobing adds an average of half a frame lag (full frame lag for top edge, half frame lag for center, and near zero lag for bottom). This is not because of buffering but because the LCD is refreshed in total darkness, top-to-bottom, and then flashed all at once. High speed video at http://www.blurbusters.com/lightboost/video -- will visually helpfully explain why there's more lag during strobing.

That said, many BenQ/Zowie displays are already realtime scanout. The lag you're witnessing, is probably the strobe-backlight mode. Turn that mode off, and the lag probably will disappear -- and your FPGA emulator will have "correct" input lag feel, except for the amount of motion blur.

Blur Busters Tip for Emulator Programmers: Less Lag Than Original Machine!

Programmers of emulators should add a "reduced lag mode" for doing low-lag 60Hz onto ultra-high-Hz VRR displays. The method is as follows:

(0) Get a high-Hz VRR display. Add a Direct3D or OpenGL mode to your emulator (even for 8-bit -- treat your framebuffer as a single texture stretched to full screen -- or piped through a HLSL filter for nostagilia scanlines, etc). Higher Hz VRR the better, even for 60Hz emulation.

(1) Emulate at full throttle (at maximum CPU speed) for 1/60sec into an emulated 60Hz software framebuffer (on GPU). You can keep full raster interrupt compatibility (e.g. sprite multiplication, scroll zones, etc), it's just run at accelerated pace.

(2) Use a 240Hz G-SYNC mode at 60fps. You're delivering the emulated framebuffer (emulated 60Hz refresh cycle) in 1/240sec instead of 1/60sec. Do not use VSYNC ON or VSYNC OFF, use the VRR mode for ultra-accelerated refresh-cycle. VRR is good for "low-lag fixed Hz" too: The monitor patiently waits for you, and instantly immediately begins refreshing at the *instant* of Direct3D Present() or OpenGL glFlush() -- the refresh cycle of a G-SYNC monitor is software-triggered! You're actually software-commanding the *exact* moments of the actual monitor's VBI -- rather than the video chip doing a tick-tock VSYNC at 60Hz.

(3) Idle until the next emulated "60Hz" refresh cycle (this may be a ~12ms busywait if (1) is nearly instantaneous and (2) is only 4ms) before doing rinse-repeat of (1) and (2). Use accurate busywaits (multimedia timers) to get microsecond precision, to emulate a fixed Hz with a variable-refresh-rate display.

(4) Result: Real-time emulator speed (normal 60fps @ 60Hz speed) but with less input lag than the original hardware!

In this situation, you can have up to 12ms less input lag than the original console/arcade machine (And consequently, 12ms less lag than an FPGA emulator! (At least for 8-bit and 16-bit games that does input reads during VBI/VBLANK/VSYNC).

Special note: This is enough to compensate for the input lag of a strobe backlight, so you can use this with the strobing+VRR trick (there is a ULMB+GSYNC hack available on certain GSYNC monitors) to have a blur-reduced mode with roughly the same input lag as the original machine. Normally ULMB does not support 60Hz, but the ULMB+GSYNC hack also successfully strobes at 60Hz as well whenever content is running at 60 framebuffer Present()/glFlushe() per second (aka 60 frames per second) -- the strobe flash is timed right after the software-triggered display scanout (done in dark before the strobe flash).

[t2k]

The Dell U2414H arrived today and I did some tests. The BenQ's are not even close, the U2414H is clearly the winner. It was pretty good right out of the box but after switching it to "Game Mode" it was even better. Filming at 240hz I detect screen updates as low as *4ms* (a single 240hz frame) after the LED on my NES controller lights up. The BenQ's are about 16ms slower. You can see the spreadsheet here: https://docs.google.com/spreadsheets/d/ ... QMLoGjmnB8 (didn't list the XL2411 cause it was essentially the same as the RL2455)

However - The pixel response times on this Dell monitor are not as good as the BenQ's, taking a little longer to get from black to max brightness and vice versa. It's too bad it's an IPS monitor, I assume a TN panel would be on par w/the BenQ's.

Mystery solved, case closed. My bet would be that the BenQ monitors have a single buffered frame internally for image processing, whereas the Dell must buffer much less - perhaps a line or two.

I played several games and as far as perceivable input lag goes, the AVS+U2414H is essentially indistinguishable from a NES+CRT.

[RealNC]

Is the signal 1080p? Or 720p? I suspect the BenQ might have scaling lag. It would be extremely surprising to see the BenQ have a full frame of lag in its native resolution, because that would make every reviewer out there look suspicious (fabricating review data.)

[t2k]

It's 720p - the benq does have a 1:1 mode where it displays the source unscaled in the middle of the screen but that seems to have no impact on lag. I agree, rescaling lag seems like a plausible explanation though. Unfortunately I can't force the NES clone to output 1080p. Either way, the Dell manages to rescale 720p up to the native res of the panel with very low latency so they deserve the trophy.

[lexlazootin]

what... that's a pretty insane amount of difference and i'm not sure how that's possible.

But maybe Benq is really that useless at doing the one thing they advertise they do.