Koko-aio shader discussions and updates

[estefan3112]

Hello @kokoko3k, I’ve been updating koko-aio since a longer time to latest github and experience a strange flicker at the start of a game:

https://www.youtube.com/watch?v=IaoIDetxbSI

I don’t assume that this is a new feature, right? It seems to occur on both vertical and horizontal games. The effect does not occur if I reset the game. I cross-checked with crt-geom-deluxe, where the effect does not occur.

MacOS, RetroArch rather recent nightly build, of course Vulkan, HDR enabled, latest koko-aio from Github.

Cheers!

[kokoko3k]

Hey there, yes it is intended to emulate the crt that syncs to the vertical frequency.

explicitely shake the screen at startup

It can happen at the very start of the game or when the game itself changes the timings while it is running (arcades don’t do that, but consoles or home computers do)

Lot of games takes a while to display something, while others like 1942 outputs the first image right from the beginning, so the effect is visible.

“Resync speed when core resolution changes”, set it to 1.0 to disable it (1 is infinite speed).

There is also a new “breath in” effect at the start, which emulates the tube warming, so the image starts zoomed out a bit.

Emulate CRT startup tube warming when using breathing feature

The latter is modulated by: “★ Breathing (Luma tied zoom, ignored if integer scaling)”

[Boz1978]

Does Koko have a crop/overcrop feature for games like Wonderboy where there are black bars on the left and right while playing? Thanks

[sollrakc]

Hey @kokoko3k ! I’m having a weird specific issue and I was wondering if you could help me. I need to “decouple” scanline number from the core’s vertical resolution in some way. This is because I’m trying to emulate the 200-line video mode behavior from the PC-8801 and PC-9801 japanese computers.

Basically, the problem is that the emulators for those systems (like the QUASI88 core) render the 200 line mode in 400 vertical pixels instead of the more accurate 200 pixel, resulting in an image that behaves similar to VGA doublescan. In other words, twice the amount of scan lines than what was generated on real hardware:

I figured I could just cut in half the scale_y from the final pass, so I edited my preset to

scale_type_x16 = "viewport"
scale_x16 = "1.000000"
scale_type_y16 = "viewport"
scale_y16 = "0.500000"

This did in fact reduce the scanlines to 200 but it unfortunately caused scaling issues:

I imagine this is happening because the rescaler is also working with half the resolution, but I’m might be wrong. So is there a way to circumvent this? Any help is appreciated, Thanks!

[kokoko3k]

Quick answer: achievable.

I don’t know which system you are referring to, but eg: Mastersystem through Genesis Plus GX core has an option just for that.

Generally speaking, cutting just side black bars alters the game aspect ratio, so crop -> changed aspect.

In koko-aio the workflow is instead change aspect -> crop.

What you want is to operate in the “override content geometry” section; there you first change the content zoom so that side black bars go off screen.

Since the zoom preserves original aspect, part of the game content on the other dimention will go offscreen too.

To make it visible again, you will change the picture aspect (still in the override content geometry section).

[kokoko3k]

Uhm, tricky, since koko-aio queries the core resolution, so no workaround crosses my mind atm, but I will keep thinking.

Why cores do that anyway? Any reason they doublescan 200p? If none, a bug report in the core issue page should be filed instead, that would be the proper way to fix the issue.

…and yes, halving viewport resolution breaks the shader in multiple ways I cannot even think about, lol.

[kokoko3k]

Maybe there’s a way, not same quality as real scanlines tho:

Tradeoffs:

• No slot mask possible.
• "scanlines like " height will not depend on underlying color(well, high warpedglow Y values can somehow increase scanline height, try that).

Disable interlace detection, just in case:

Since we’re (ab)using vertical cell mask options to emulate scanlines, disable scanlines:

And configure Vertical cell mask to act more or less like scanlines:

Setting Resolution to CORE means that the vertical mask size will be relative to the core resolution, not viewport one.

Height divider set to -2 will halve the mask period, which is what you want to emulate an “halved-scan”

Even/odd offset has to be disabled, it is for slotmasks, and unfortunately this “exploit” only allows aperturegrille setups.

Rest of parameters are up to your specific taste.

I miss a PCENGINE game with the issue you described, so here is TOKI, at 120p (kinda, since in this example a “scanline” hosts multiple core lines, so I suspect/think your 200 to 400p back to 200p image will look a bit better):

I "could ® " make an option to just halve scanlines, but workarounding cores bugs is something I’d like to avoid, so if the proposed solution is not enough, plz file a bug report to the Pcengine core and see what they answer, then maybe we can rethink about implementing or not workarounds by the shader.

[Boz1978]

This worked perfectly thanks

[sollrakc]

Thanks for the thorough response, @kokoko3k !

So, the systems are actually the NEC PC-88 and NEC PC-98, which were japanese home computers that came before the PC-Engine/Turbografx console, same company though. The emulators for these systems (QUASI-88 and Neko Project II Kai respectively) are not really at the same level as more mainstream console emulation. I did raise the issue in QUASI-88 libretro core’s github but I got no response and it doesn’t appear to be in active development.

I believe the reason they do this vertical resolution upscaling is to keep the system’s original aspect ratio. The 200-line video mode had a native resolution of 640x200 but was displayed in a 16:10 aspect ratio, producing taller than wide pixels and letterboxing on a CRT. By doubling the vertical res to 400 pixels, these emulators produce the correct aspect ratio automatically (PAR 1:1). That’s my take. Even more confusing, those systems had a 400-line mode (640x400) but that was used mostly for displaying OS text, and early games rarely used it.

I had also discovered the “hack” with vertical mask parameters you described! But I wasn’t really happy with the result.

@kokoko3k

I "could ® " make an option to just halve scanlines

My post took a while to get approved here for some reason, so I decided to looka at your original code yesterday and I was able to do exactly that. I just added a new parameter SCANLINE_OVERRIDE in config.inc and config.globals.inc and changed this block on final_pass.slang from this:

    vec2 freq_base_core = in_coords * vPG_OriginalSize_tated_mul_pi;

    float decon_y_strength = DO_SHIFT_RGB * NEW_SCALEMOD_Y;
    if (vFake_scanline_period > 0.0) {
        freq_base_core.y = vFake_scanline_period;
        decon_y_strength = 0.0;

to this:

    vec2 freq_base_core = in_coords * vPG_OriginalSize_tated_mul_pi;
    freq_base_core.y *= SCANLINE_OVERRIDE;

    float decon_y_strength = DO_SHIFT_RGB * NEW_SCALEMOD_Y;
    if (vFake_scanline_period > 0.0) {
        freq_base_core.y = vFake_scanline_period * SCANLINE_OVERRIDE;
        decon_y_strength = 0.0;

I put the parameter in the scanlines section and included some adjustability (1.0 0.25 2.0 0.125). 1 is default, putting it to 0.5 halves the lines.

It works with fake integer as well, albeit with a bit more artifacts. Here are some pictures of Ys I, running on QUASI88 at 640x400 with your shaders at half scanlines (0.5) in both aperture and slotmask:

I would love if you included these changes to your next releases so I wouldn’t need to re-edit the files myself every time you update them but I can totally understand if you don’t want to.

[kokoko3k]

Good work

Unfortunately this is a very specific issue, no other use cases apart from workarounding an upstream bug, so I’d like to avoid modifying the shader just for that, let alone adding another option to the already long list.

But I can implement it as a static option to be configured in config-user-optional.txt file so that you can keep updating the shader (that file won’t be overwritten, see docs) and performance won’t be affected too much.

In that case you’ll have to clone the shader and use that shader just for those games.

[Starman99x]

The previous bug seems to be taking new forms, I’m getting a colorization glitch even with scenes that are mildly dim:

Bright = Normal:

Mildly dim = Glitched colors:

That’s the same overlay btw. Here’s the latest pack version for testing.

[kokoko3k]

Still exclusively tied to the the same triggers? Read: pause and frame advance via k key?

[estefan3112]

Oh that’s great, I like both effects very much, just wanted to be sure that this is correct behavior. Will not change anything. Many thanks.

[Starman99x]

Try Arcade D2 tilt ambilight with the game “1943”. Glcore driver.

In bright scenes (like with the clouds) everything is fine. But after playing for a few seconds; dim to mildly dim scenes cause glitched out colors. Unless I turn off the ambilight. Sometimes using fast forward can trigger the bug.

Also the frame advance thing was not a trigger it was to demonstrate that the textures were going on & off (in totally dim scenes).

I will help with all I can to dig this bug out. Maybe I can bisect with the current fix applied to all previous commits in a separate debug fork (if that’s even possible)?

Because it seems we have two overlapping bugs here, one being already fixed.

[estefan3112]

@kokoko3k: I just encountered a very strange issue - Latest koko-aio Github:

Load the ng preset Vector_std_4_mame2003plus_defaults.slangp with tgunner or mrhavoc Activate a background picture and set it to forefront

In MAME2003, the background image turns black (screenshot) In MAMEcurrent, the background image turns red (screenshot)

Also very strange behavior of background pic in mrhavoc. However, asteroids work without any problem, and I simply don’t know why. If I use my asteroids presets with tailg, same problems.

Do you see this as well? Cheers!

[kokoko3k]

@Starman99x

Sometimes using fast forward can trigger the bug.

I don’t get the meaning of this.

Does it mean that the bug is visible only when using FF?

[kokoko3k]

That could have the same root as the bug described by @Starman99x (?)

Honestly hoping this is the case and that I would be able to reproduce on my side.

OSX and metal?

Does it occur when just when you enable the bg picture after the shader has been loaded or even when the preset is already configured that way right from the start?

[Starman99x]

No. But it can help trigger it faster sometimes.

[estefan3112]

Further testing:

• Just to be clear: I see this behavior only with the vector presets, not with other presets.
• The described behavior with the newest shader version occurs in both RetroArch latest stable and nightly of yesterday.
• The described behavior does not occur in koko-aio version 0.7, which I kept as a backup.
• There is a setting called “Use Metal Argument Buffers (restart required)”, which is of no relevance for this behavior, it’s both in ON and OFF. This is RetroArch MacOS 26 Tahoe with Vulkan via MoltenVK.

EDIT: The behavior also does not occur in NG-1.9.75. Testing further…

OK, it occurs for me in NG-1.9.85 (release code from your Github)

[kokoko3k]

Thanks,

what about this:

@kokoko3k

Does it occur when just when you enable the bg picture after the shader has been loaded or even when the preset is already configured that way right from the start?