Vista, 800x600, CRT, 120 Hz, gl, Retroarch 1.6.7 changes my fullscreen video mode
Retroarch switches to some 60 Hz junk on startup and I can no longer use black frame insertion (flickery).
Looks like I’m sticking to Retroarch 1.3.4.
I assume you changed the vertical refresh rate to 120hz in retroarch and it still didnt work? It works for me but I have a different setup.
I edited my post; forgot my desktop was actually 800x600. Anyway, even after setting my Retroarch Refresh Rate to 120, the video mode still changes (looks like 640x480, but now it’s at 120 Hz). Why is my video mode changing?
Oh, and there’s an ever-present bug with Black Frame Insertion: If I leave it on (in either Retroarch version) and quit, the next time I start, flickery as eff. I have to turn off Black Frame Insertion, quit, restart, load content, then and only then can I turn Black Frame Insertion on and it works correctly. Again, this is in both Retroarch versions, so I’m guessing that this has never worked? Or Nvidia just sucks, which is highly likely.
Why are you using BFI on a CRT?
120Hz with Black Frame Insertion is working fine for me with this config, with the latest nightly.
https://hastebin.com/raw/mutorulupa
When RA starts with this config, it chooses 3840x240 @ 120Hz for the fullscreen display mode and runs with black frame insertion enabled. As always, this video mode must already exist in Windows as a custom resolution for this to occur, or else it will fail to set the video mode correctly.
video_refresh_rate is set to 60.0 in this case because you are still synchronizing to 60Hz when you insert black frames.
The Windows context driver automatically doubles that value when selecting the fullscreen video mode if video_black_frame_insertion is set to true OR if video_swap_interval is set to 2.
If you’re using a PC CRT, though, you’re better off using 480p @ 60Hz instead and inserting black lines with the interlacing shader, it will have pretty much the same effect as running 240p 120Hz with black frames, but will have less requirements to maintain perfect synchronization, and will also allow you to display games with 480 line interlaced modes correctly.
Why Black Frame Insertion (on any type of display)?
Frames are discrete samples, but real motion is continuous. We’re talking about interpolation in the time domain, not space (x,y). Smooth motion is analogous to anti-aliasing in the space domain.
https://dspguru.com/dsp/faqs/multirate/interpolation/
"3.3.3 Why do interpolation by zero-stuffing? Doesn’t it make more sense to create the additional samples by just copying the original samples?
This idea is appealing because, intuitively, this ‘stairstep’ output seems more similar to the original than the zero-stuffed version. But in this case, intuition leads us down the garden path. This process causes a ‘zero-order hold’ distortion in the original passband, and still creates undesired images (see below).
Although these effects could be un-done by filtering, it turns out that zero-stuffing approach is not only more ‘correct’, it actually reduces the amount of computation required to implement a FIR interpolation filter. Therefore, interpolation is always done via zero-stuffing."
Even though CRT’s aren’t exactly like the zero-order hold behavior of LCDs, in lieu of expensive interpolation filtering, just inserting black frames makes the CRT strobing more instantaneous, so I perceive the motion being smoother (less judder/jerkiness). At the expense of brightness, of course. But not to mention no CRT flicker when using 120 Hz.
Thanks for linking to the documented configuration file. As usual, Retroarch is very user-unfriendly; this information could be included with the menu items, especially the rounding done for the Windows integer tidbit. Very confusing that I can set a floating point value on Windows when the fractional part is rounded away.
I don’t think 480p @ 60 Hz with scanlines is similar to integer scaling at 120 Hz. As I described above, motion is the issue. I don’t care about solving the interlacing problem now (not really viewing that type of content at the moment).
That superwide CRT mode intrigues me, though. Wonder if my hardware can handle it.
http://emulation.gametechwiki.com/index.php/Display_FAQ#240p.2F480i
By the way, the bug I reported still exists somewhere, whether in Retroarch, in Windows, or in Nvidia’s driver. Old Retroarch 1.3.4 left my current video mode alone with the following (default) configuation:
video_fullscreen_x = "0"
video_fullscreen_y = "0"
Retroarch 1.6.7 changes the video mode in spite of the zero values. I had to change them to 800 and 600 to at least make the video mode change back to the same mode as my desktop as Retroarch starts.
CRTs aren’t sample and hold, though. They already have flicker at 60Hz, and running at 120Hz with black frame insertion would result in the same exact amount of flickering as 60Hz , and therefore the same motion quality. I’ve compared both on my own CRT and I can’t notice any difference in motion quality.
Very confusing that I can set a floating point value on Windows when the fractional part is rounded away.
Well, video_refresh_rate is primarily used to configuring dynamic rate control to sync exactly to your display, where fractional refresh rates can apply due to timing variances on the system or display. It just has a secondary use for selecting a video modeline with the correct refresh rate when using exclusive fullscreen. While Windows only supports reporting integer refresh rates, the actual modeline could still have timings that have a fractional vertical refresh. which you would want to reflect in video_refresh_rate.
That’s what I said, and I agree. But CRTs aren’t perfectly instantaneous, either. If CRT 60 Hz is equivalent to CRT 120 Hz by adding black frames, then why does 120 Hz black frame insertion appear about half as bright?
Another interesting read:
How do you run 30 FPS content and insert black frames to get 60 FPS output to the display?
This is valid, because a lot of 3D games run at 30 fps (or less). Plasma 60 Hz TVs with 30 FPS content, for example, suffer from an image doubling/offset effect during motion. So do LCD TVs, but the artifact is smeared over with their inherent (no black frame insertion) blurring.
I’ve tried the following combination of settings:
video_refresh_rate = "30.000000"
video_black_frame_insertion = "true"
Flickery; doesn’t work.
To be clear, I want to play games that render at 30 FPS and thus use frame doubling to output 60 FPS. I should be able to replace each duplicated frame with a black one. Black frame insertion/duplicated frame replacement. How?
I believe what you’re describing isn’t possible because the frame-duping happens internally. That is, despite what fps the game ran at internally, the console still put out 60 fps to the display.
For example, Star Fox on SNES runs at something like 15 fps internally, but the SNES still put out ~60 fps to the display, so it has to dupe those frames internally. You can think of RetroArch as the TV in this case. Even though your game is running at 30 fps or whatever, 60 fps (including dupes) is still getting sent out to the “display”.
Why couldn’t Retroarch throw away every other core-generated frame and instead output black?
Because RetroArch has no way of knowing which frames are internal dupes. The cores don’t communicate that to the frontend in any way. We could use heuristics, like take a hash of each frame and throw away any that haven’t changed, but that would lead to black screens on menus, title screens, etc.
Well yeah, like most Retroarch features, the user has to understand what it is before they turn it on. And they could always turn it off, too. Hotkeys are fun. Which frame to blank, odd or even? Another simple toggle. The power of software… is powerful.
What an emulation enhancement, no? Better motion than the real thing.
I just pushed up a shader to the GLSL repo called “flicker” (there was already a Cg version that does essentially the same thing) that just blacks the screen on every other frame. You can see if that does what you want.
Awesome, thank you for the effort! I’ll take a look.