Blur Busters Forums

ophidon wrote: ↑

18 Sep 2020, 13:51

Yes, I am not against the idea at all. I never have an issue with more options existing than I would personally take advantage of. The comma seperated list doesn't exactly match how Retroarch seems to have designed its menu options to be programmed, but you could still easily do a predetermined set of patterns without a major rewrite. It's just I wanted to get this version out first, before considering additions in case life gets too busy soon (which is possible as we have a new puppy arriving soonish, to train).

(A) At first, this could be a configuration-file-only feature initially. Basically of only interest for experimentation. Wouldn't this be a quick change? Doesn't RetroArch support undocumented options? (If I am wrong, then yeah, it would be harder).

(B) Or you can synthetically generate your own comma-separated internally simply by "BFI Full Brightnes Frame Count: Number", "BFI Decay Frame Count: Number" (for frames after last full brightness frame) etc. And automatically calculate. Decay speed should be a geometric formula. And use padding (zeros) and trunctation depending on framerate-vs-refreshrate divisor automatically calculated.

Regardless of whether you do approach (A) or (B) or both, you'd process the string into a float/double array, and cycle on that as your BFI sequence -- item (A) should be easy peasy (in theory) with no UI changes? That way, user experimentation on (A) can be done before doing UI changes to add (B), perhaps selectable profiles of discovered beneficial custom BFI sequences. Both can be done above, with a Custom setting to load the manually-edited text line from the configuration file.

This could be a separate pull request, but I would wait on closing BFIv2 github unless sufficient configurability is added since I consider complete BFI sequence mandatory for a closure of BFIv2 (though future iterative enhancements such as moving BFIv2 into a separate thread will prepare it better for conversion to a BFIv3 algorithm)

I'm open with whatever BFIv2 configurability you come up with -- I'm totally happy with hand-edited configuration file initially for experimentation's sake before any official BFI-sequence UI configurability.

Just an fyi, this first version has been merged upstream into RetroArch proper now.

Chief Blur Buster wrote: ↑

18 Sep 2020, 13:15

But emulator games are low resolutions, like 320x200 rather than 2000 pixels wide, so low MPRT is unimportant in most emulator games. The point is that low MPRT is more important at higher resolutions than at lower resolutions.

Technically arcade games are generally like 384x224 or something like that(later 3D ones were higher resolution) but depending what you do on a modern screen it would be your panel's native res(be it 1080p or 1440p or 4K). Like if you integer scale 240p to 4k it's effectively 4K as far as the Display is concerned.
I don't know exactly how CRT Shaders work but as I understand it they use several pixels to render what would be one individual phosphor on a CRT. If you do a screengrab of an arcade game in MAME at 4k the screengrab itself will be in 4K and the shaders themselves rely on high resolutions(particularly slot mask shaders which need extremely high resolutions like at least 8K to emulate properly)


Now if a display would be low res at 320x240 and that's it then yeah you're right but in the case of emulating games on a high resolution display(whether you're doing simple integer scaling or using CRT shaders) then as I understand it the same principle applies as if you were playing a modern HD game because you still have to scan through millions of pixels. That is unless you're playing the game at 1:1 scale which would result in an extremely tiny picture on a 1080p screen let alone a 4K one.

Of course I could be wrong but I thought that's how it was. At least I'm pretty sure that's how it works for simple integer scaling, I could be wrong about shaders.

I tend to not use the shaders, and just use pure integer scaling myself, so depending on how much they modify things that is a different argument for sure. But by using integer scaling you still have the same low resolution, you've just made the size of the pixels 'effectively' larger.

Instead of one pixel making a transition when there is movement, you have a square of 4 (or 16, etc) doing it. But they're all doing it at precisely the same time (minus a verrrrrrrry minute difference for pixel scanout behavior as you're talking pixels that are literally right next to each other), and with the exact same color transition, so it might as well still be one pixel.

thatoneguy wrote: ↑

20 Sep 2020, 03:44

Technically arcade games are generally like 384x224 or something like that(later 3D ones were higher resolution) but depending what you do on a modern screen it would be your panel's native res(be it 1080p or 1440p or 4K). Like if you integer scale 240p to 4k it's effectively 4K as far as the Display is concerned.

Correct.

However, the majority of human-visible MPRT motion blur would be proportional to original video game graphics resolution. Pac Man doesn't scroll, and its resolution is very low. Other arcade games scrolled, but they didn't scroll at 2000 original-machine pixels per second necessary to really make 1ms-2ms MPRT really blatantly visible.

240 emulator pixels per second (more than half a screenwidth per second on original machines) at 1/240sec MPRT only has 1 emulator pixelwidth blurring, regardless of how many pixels that emulator pixel is rendered as.

That said, stroboscopic scrolling effects of dotmask/grille does require low MPRT to be visible, though this is not generally visible to most people at normal CRT viewing distances, and even when becomes visible, is extremely subtle as you've already noticed.

Low MPRT is much easiser to notice with really sharp high-resolution graphics with HD textures.

This is why we see diminishing returns earlier with old games than with newer games, in terms of motion blur effects.

Also, I think beyond about 180Hz, will require a doubling or tripling of Hz (360Hz or 480Hz), and major increase in lumens, to be a really noticerable improvement over 180 Hz, especially in the territory of being able to more accurately emulate a CRT electron gun.

Chief Blur Buster wrote: ↑

20 Sep 2020, 14:47

However, the majority of human-visible MPRT motion blur would be proportional to original video game graphics resolution.

And that's what I meant by just effectively making the pixels larger with integer scaling.

As they mentioned though, some of the emulation shaders are fairly advanced and creating more real high res data. Is using the tensor cores to do custom forms of DLSS upscaling even possible? I'm not sure how locked down Nvidia has that, but it could be promising for retrogaming if the algorithms are available to be played around with.

ophidon wrote: ↑

20 Sep 2020, 15:22

And that's what I meant by just effectively making the pixels larger with integer scaling.

Personally, I prefer 4K + CRT filters for original faithfulness, some settings can look reasonably good with that, even if not perfect.

One has to define "scaling". Applying forms of CRT filters is a glorified scaling algorithm.

Now, if you are adding extra detail/textures from AI/DLSS-like algorithms, things would likely look different.