Koko-aio shader discussions and updates

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

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

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:

And here’s the problem after rotating the screen. Strange lines along the screen and diagonally.

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

1 Like

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:

4 Likes

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)

4 Likes

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

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

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

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

2 Likes

I am really enjoying your shader presets. Forgive me if it is mentioned somewhere but I noticed that you have three preset categories which is 4.1, NG and handhelds. Handhelds are self explanatory but what is the main difference between 4.1 and NG and what does ng stand for?

1 Like

You’re welcome, it is a recurring question, maybe I should explain it somewhere in the docs :slight_smile:

3 Likes

Greetings @kokoko3k - I’m simply writing to thank you for your tireless work and for sharing all of this with us. Your presets “Monitor_FXAA”, “Monitor_Hmask_Overmasked” and "“TV_NTSC” with their variants are pure gold. Fantastic work. And the performance is always incredible, since you added dedithering it was just the icing on the cake. Thank you very much .

7 Likes

The monitor balanced preset in the ng preset pack is probably my favorite one. It has the look I am going for and looks like my crt I remember growing up and looks beautiful on my 4k oled.

1 Like

Missing feature I always forgot to add (and nobody asked!), but maybe one wants to sacrifice a bit of content screen in the name of integer scaling:

A parameter of 1.03 means you can bare 3% (sum of both sides) off-screen.

3 Likes

I’m sorry if this has been replied before, but I’ve read all thread and I couldn’t find it: Besides ambilight and CRT shaders setting, what’s the difference with HSM MegaBezel? To put it simple, if Koko-aio is able to run in 1080p with reflections, ambilight and CRT shaders, using less powered PCs than HSM MegaBezel, a simple YES would be a perfect answer to my question. Just to clarify: “less powered” means an integrated GPU of 4th Intel generation or newer, or maybe some AMD APU like A8 or A10. Ryzen 3/5 APUs is another league entirely…

I’m not sure what is the question to answer “YES” or “NO” to is.

MegaBezel and koko-aio use a totally different code-base and I measured performances on the machine where develop koko-aio, an Intel® Core™ i5-4590 CPU @ 3.30GHz; on that hardware, presets reach about 90…100fps when running lowres content on a 1080p screen; this with GLCore, Vulkan on that machine is a bit less performant.

Thanks @kokoko3k, I just wanted not to bore you with a long reply. Anyway, it seems a big YES to me then! So, for a similar look in terms of bezel reflection, and CRT shaders (not ambilight), we can say koko-aio is “better” than HSM, or at least faster? BTW, looking at your name: ¿hablas español?

NOPE, test it/them and choose what is better for you!

BTW, I’m from italy, I honestly ignore what kokoko would mean in español :laughing:

Your are a humble person!!! :grin:

Koko sounds like “coco”, means coconut, at least in spanish.

I always think of CoCo from Foster’s Home for Imaginary Friends

1 Like