Koko-aio shader discussions and updates

RetroArch Additions Shaders
#1074

To be honest, since my LCD has already its issues with ghosting, I never considered it, but maybe there is something similar that is actually used by koko-aio gameboy preset.

Check under the dot matrix emulation section, ignore the warning and enable it. In the following image, there are settings made to bypass the grid and the shadow code and just keep the ghosting part. You will have to play with “Refresh-inertia and Inertia-on”; probably for afterglow you want inertia on=2 (means black).

Let me know if it works as expected, I’m totally NOT sure about it :

Screenshot_20231129_153156

#1075

Does that mean that basic is the new algo and extensive is the old one?

#1076

Nope, basic is the old that checks horizontal and vertical, it is enabled by default, while extensive is the one that search oblique, and by default is 0.0.

1 Like
#1077

ok will take a look

K

1 Like
#1078

Thanks for the answer. Yes I have tried this already. Functionally it is what I want, but it does not look very natural. I guess the luminance decay is too linear, where real afterglow is closer to logarithmic.

There is a good explanation of the phenomenon here: Libretro-Retroarch-SLANG/crt-guest-dr-venom2/shaders/guest/README at main · guestrr/Libretro-Retroarch-SLANG · GitHub

An example here: Libretro-Retroarch-SLANG/crt-guest-dr-venom2/shaders/guest/afterglow.slang at main · guestrr/Libretro-Retroarch-SLANG · GitHub

The later shader is pretty simple in itself. I would like to make a trial but I am completely noob at slang shaders. If someone could tell me how to integrate it in a Koko preset that would be incredible!

1 Like
#1079

“peeping” code from other shaders would in turn steal all fun, so I dont feel that comfortable doing that, but thanks for pointing that to me.

Actually the decay is already not linear, because it is something like:
color_next=mix(color_previous, color_now, k), so color_next starts to decay faster, but maybe the eye perceives it as linear.

I’m just playing with my code and maybe something like:

if color_now is less than color_previous then ->color_next=mix(color_previous, color_now, color_now*color_previous)
would work better if we constrain color_now*color_previous to a minimum value that would represent a decay rate.

A video with a very high fps showing the real thing in action would help…

Will keep playing :slight_smile:

#1081

What about this running circle:

Screenshot_20231130_171628
Screenshot_20231130_1716281647×1051 365 KB

There are 2 parameters in a new section just added to dev code:

Screenshot_20231130_170631
Screenshot_20231130_170631731×129 19.6 KB

Early decay is the “fast” decay that happens immediately after the phosphor is less excited; how much the light is cut.
Late persistence modulates how much the phosphor will keep emitting light after the first cut (how much the tail is long, in the screenshot)

Always keep in mind that tracking time is not possible in retroarch shaders; only frame number is given, so if a core outputs at 30fps, the persistence time would be doubled.

If you could take a look and maybe find saner defaults :wink:

#1082

Thanks for the development effort! I gave it a quick try on Donkey Kong and here is what I see.

  1. It looks like the ghost tail is very long even with low values of “Late persistance”. I would expect this parameter helps to control the length of the tail.
  2. I am surprised to see scanlines applied to the tail. It looks like the ghost is present only on even lines, not odd lines (or the opposite). Intuitively I would expect it to be homogeneous.

Hope that helps!

1 Like
#1083

About the first point, I think scanlines gaps, the void space between two excited scanlines/phosphors, have to stay black while scanlines themselves (the excited phosphors) have to fade away “slowly”, so if an object that looks “scanlined” is moving on a black background, i think it is right that its tail will look scanlined too,
or else it would mean that a phosphor grows in height as soon as it is not excited, right?

-edit- I just checked again the low persistence tail, and for me, the tail of this white circle running from left to right correctly shrinks till zero by modifying late persistence:

2.0:

Screenshot_20231130_192840
Screenshot_20231130_1928401637×268 322 KB

1.0:

Screenshot_20231130_192945
Screenshot_20231130_1929451637×268 119 KB

0.4:

Screenshot_20231130_192738
Screenshot_20231130_1927381637×268 266 KB

0.25

Screenshot_20231130_193048
Screenshot_20231130_1930481637×268 256 KB

0.0

Screenshot_20231130_193129
Screenshot_20231130_1931291637×268 207 KB

If you mean the clone you still see on the circle left, then it is the early decay setting, lowering it:

Screenshot_20231130_193219
Screenshot_20231130_1932191637×268 209 KB

Can you point me to how are you testing? (what part of what game and what preset)

Maybe there are unhandled cases.

1 Like
#1084

from memory, a good test would be the Bombs/Rockets in Gradius 3 (snes or arcade), and looking at the pics, I’d guess strength/setting 1 (2nd pic), or 0.4 (3rd pic).

Don’t have time to test myself this evening, but will take a look at the options tomorrow if the code is still in the dev repo.

UPDATE:

had a chance to look/play. Based on the current code, my sweetspot was 90/.45-.50.

The challange here is I guess it comes down to personal preference (as always), and what you are trying to replicate/emulate.

Any higher than .50 creates too much phosphor blur with non-sprite backgrounds (Gauntlet/Ghouls and Ghosts etc),

The 1st article here I found interesting, it goes into some detail on phosphor trails, and how/why we perceive them: https://tinyurl.com/327k2etd

1 Like
#1085

Thanks let it be the default then, this circle crosses the screen in 1.8 secs, looks ok to me:

Screenshot_20231201_125303
Screenshot_20231201_1253031696×248 311 KB

1 Like
#1086

Cytat Thanks! I don’t know, dx10,11 and 12 have lot of problems from my experience. From a quick view, it seems a rounding error, but i do all of my development on Linux, so debugging dx11 is not an easy task for me, Since you can use Vulkan, why don’t you just stick to it or even try GLCore that could be faster on some hardware? Also, we’ve a dedicated thread, can you answer there? Cytat

I use Dx11 on most retroarch cores and have no problems with them. Perhaps it’s the fault of the dx11 driver itself, or problems with retroarch. This is not a big problem because you can use any driver for individual games.

1 Like
#1087

So, you are able to use latest koko-aio with retroarch and dx11 without any modification? Are you sure you updated the shaders? Because i’ve had to made specific workarounds for koko-aio to work with dx11 and those workarounds need to be enabled by editing a text file and in turn they disable some optimizations and features; i did that just for xbox users that have no choice.

Without editing that text file, It does not even start on dx12 and on dx11 there were flickering issues, that’s why i’m asking.

I’m not saying d3d11 has issues, but that retroarch support for glcore and vulkan is in much better shape.

If you update, maybe it is better to backup first :wink:

1 Like
#1088

I’m not sure if this is the latest package, but at retroarch today I updated slang slader from their server. In general, shaders work properly in dx11 mode. The problem only occurs when I try to use the Tate Mode 0 --> 2 shader option. When I place the monitor vertically and play vertical games (1942, Mikkie, etc.) Tate Mode 2 (in my opinion), they are correct compared to the original arcade machines, but also look better. Unfortunately, this particular option does not work correctly in dx11, and when switching the screen orientation in retroarch to 90 deg.

Here is the correct image:

Zrzut ekranu 2023-12-02 200037
Zrzut ekranu 2023-12-02 2000371920×1080 1.43 MB
And here’s the problem after rotating the screen. Strange lines along the screen and diagonally.
Zrzut ekranu 2023-12-02 200604
Zrzut ekranu 2023-12-02 2006041920×1080 1.48 MB

Edit: It works perfectly on the vulkan and gl core drivers.

1 Like
#1090

Gave up with the (soon) deleted previous posted idea since it started to be too much complicated.

The good news are that the dedot code has turned to be simpler and smarter and paired with vertical mask visibility can produce better results.

Dedot and vertical mask visibility allowed range went from 0-1 to 0-2 to survive overmask parameter, and there is a new preset that takes advantage of the new code to produce an almost artifact and (almost) moire free slotmask even with curvature and with a proper phosphor height.

The reference preset is: “Presets-ng/Monitor-Screen_Hmask-Screen_SlotMask_Taller.slangp”, following some examples based on it:

Screenshot_20231206_160512
Screenshot_20231206_1605121920×1080 1.22 MB

Screenshot_20231206_161615
Screenshot_20231206_1616151920×1080 3.64 MB

Screenshot_20231206_151052
Screenshot_20231206_1510521920×1080 3.67 MB

Screenshot_20231206_161009
Screenshot_20231206_1610091920×1080 1.06 MB

4 Likes
#1091

Tweaked last preset to be more colorful (was a bit pale) while preserving mask visibility as much as possible through the use of input signal luminance (+0.20) and output gamma (+0.05), bloom is higher too (bloom power +1.0)

Screenshot_20231207_124349
Screenshot_20231207_1243491920×1080 1.84 MB

Screenshot_20231207_124919
Screenshot_20231207_1249191920×1080 3.61 MB

4 Likes
#1092

There is now a new feature named lcd antighosting that more or less works like the “AMA” function found on some Benq lcd monitors.

Its purpose is to mitigate the low response time of some lcd displays.
The base of the theory is that if an lcd cell has to do a transition from one value to another, it will do it faster if the values differ more.

By leveraging that, this function will force the moving areas to have an higher previous/current state contrast.

In the following image you can see the effect in action; the image is scrolling from right to left, so at the right of the crosswalks you see a darker vertical line.
That way, the lcd cell that should normally switch from white to light gray, will instead be forced to step to a darker gray, but since it is slow, hopefully it will be unable to reach that dark gray, but will reach the lighter gray faster:

image

It works quite well here, but you have to find a value that works good for your particular monitor model.

The feature is static and if you want to test it, you have to edit config/config-static.inc and modify the value on the line:
#define LCD_ANTIGHOSTING 0.0

A value of around 0.2…0.3 works well for my MVA monitor; choosing a value that is too high will produce visible trails, so play it safe.

4 Likes
A shader for the BFI function?
#1093

Hello everybody, I finally released version 0.4 of my Arcade presets based on koko-aio, and it was worth the work. Many thanks as always to @kokoko3k for this incredible achievement!

Highlights:

Enjoy and happy for any feedback.

11 Likes
#1094

Ahem, sorry pal, you released the day i did 2 mistakes, one that broke xbox/d3d workarounds compatibility and the other that turned rf noise static. You are now behind upstream by just those 2 commits that fixed the bugs!

2 Likes
#1095

Many thanks, new v4a uploaded, also one artwork and release notes fixed.

2 Likes