Can confirm nightly build of RA D3D11, D3D12 HDR menus as far as box arts go are displaying correctly.
Vulkan still displaying issues. Not pressing, just offering feedback. Thanks for the work on this issue.
Vulkan:
2 Likes
That’s what I thought. On my Android it works exactly as you described, but on Linux almost it, when I enable HDR just in RetroArch I can see the content and load the Sony Megatron shaders in HDR mode, but I notice that the brightness doesn’t increase to its maximum, if it’s at 50%, it will remain at 50% after enabling HDR just in RetroArch. And it does increase if I enable HDR in the system settings, but that will further break the colors and brightness lol
But looking at the HDR-related issues for Gnome and KDE, it’s hard to know if the behavior is a bug, or a feature, or something not yet implemented. Unfortunately, HDR on Linux still seems like a broken mess in most cases.
I’ll stick using Sony Megatron in SDR mode for now to see if things improve with future Gnome and KDE releases.
Thank you very much for your reply and dedication maintaining this!
1 Like
Hmm thats odd - when did the nightly come out? My pull request was only merged this morning (9am UK time). Every driver should be fixed including Vulkan. If Vulkan is broken and the build does include my changes can you tell me what you have set in regards to the HDR menu and what if any shader are you running. Thanks
2 Likes
The release notes about the v2 release states that it only works on nightly builds for now, here: Sony Megatron Colour Video Monitor
This is because this is not only a major rewrite it is also more tied into the RetroArch runtime as it now uses the HDR menu’s settings rather than its own settings. This means it will only work with builds from last night onwards .
So it will only work on the Flatpak build when a new stable version is released there, which will come with the rewrite for the RetroArch HDR system needed for v2 work.
2 Likes
Do we know what time zone 06:28 is from? If its US then it probably has my changes in it, if its GMT or Central European then it probably doesn’t.
1 Like
doesnt say on RA website. I’m Eastern US time zone
1 Like
Just to add that to what @MatheusWillder said is that v1 of the Sony Megatron should still work perfectly fine with on all builds of RetroArch.
3 Likes
Thanks - knew I’d missed something!
1 Like
Oh - think there will be a Reshade port for v2?
Really appreciate a bit of simplification and clarity in the settings by the way. I’ve been using CRT-Yah recently and this partly because the settings are clear and accessible. I love Guests shaders but they’re dense with settings which can feel overwhelming even for technical users.
1 Like
There’s going to be big things for the reshade port hopefully coming later this year so Im afraid you’re going to have to wait but to be honest the major things Ive done here are perf optimisations (that dont really effect Reshade as their typically running on discrete gfx cards) and RetroArch specific issues such as the builtin HDR shader.
4 Likes
Fixed this typo and fixed the presets as well - should all be working now
4 Likes
I have what i presume to be a different nightly build with a retroarch.exe modification date of 2026-01-26 14:13:24.
First, the good:
The HDR aware UI for Vulkan appears to be active in this build.
HDR UI brightness is now tied to the RetroArch HDR menu Luminance settings, and gamut to the Colour Boost setting. So if you are using an HDR aware shader with separate Luminance settings, you can now increase the luminance for the content without changing the UI’s brightness.
I would still encourage the creation of a completely separate setting in RetroArch’s HDR section specifically dedicated to HDR UI Luminance if that is possible, especially if you want to continue having Megatron v2 use RetroArch’s Luminance settings, but even aside from any other fixes in this update, this is already a fantastic QoL update.
Thumbnails for Images and box art now display correctly with HDR enabled, and with all known working HDR aware shaders running. Just like the rest of the UI, their brightness is tied to the RetroArch HDR menu Luminance settings, and their gamut to the Colour Boost setting.
This means that is you have Colour Boost enabled, thumbnails will look oversaturated. If there is a desire to expand the capabilities of RetroArch’s image viewer in the future, making it automatically respect color space metadata, etc, this will probably want to be addressed at the same time, but for now it is working as expected.
Now, the bugs:
Pop-up thumbnail images, such as those seen when taking screenshots, are displayed at a lower brightness than they should be relative to the UI brightness. (This is still a significant improvement over the way things were before tho.)
And relatedly: this did not resolve the “scale_type” tonemapping bug. So when an SDR preset doesn’t include a “scale_type” line ???in the final shader of the chain???, the content is still displayed with broken 10,000nit tonemapping.
Edit: Pop-up thumbnail images are only displayed somewhat correctly (but overly dim) while the menu is open. (Or maybe they only look dim because they are behind the menu, and they are actually correct when the menu is up?)
Pop-ups while the menu isn’t open/during gameplay (such as RetroAchievements pop-ups), the fast forward and pause indicators if you have those enabled, and so on, still have broken tonemapping, and are displayed at 10000 nits.
3 Likes
If you absolutely must have a version of Megatron v2 that works on an older RetroArch build for some specific use case, the AzMods version of Megatron v2 which i altered such that it doesn’t use any of RetroArch’s HDR menu settings does appear to work on older builds, but i did not test this extensively.
Please treat this as unsupported unless you can verifiably reproduce the issue in a newer version with the HDR revamp and fixes.
3 Likes
Confirmed: the versions of crt-sony-megatron-v2-default-config.slangp, hdr-config.slangp, and hdr.slangp included in the most recent slang-shaders commit about 15 minutes ago are all working as expected.
I will definitely have suggestions for some changes to the default settings for hdr-config.slangp and hdr.slangp in particular at some point, but in terms of the broad underlying functionally this appears to do exactly what it needs to. Thank you!
Also worth noting: with the correct settings, appending hdr-config.slangp or hdr.slangp automatically fixes any SDR presets presenting the “scale_type” tonemapping bug without further modifications to the presets.
2 Likes
Yeah I noticed the scale_type bug when I was testing the hdr.slangp. What shader uses that in the last stage again? Ill take a look.
1 Like
It’s the other way around. Stuff that doesn’t have a scale_type in the final stage is effected.
Off the top of my head, one example is bfi-simple.slangp in subframe-bfi.
It’s just
shaders = 1
shader0 = shaders/bfi-simple.slang
2 Likes
Thanks btw I thiink this is a Vulkan only bug: I think d3d12 and d3d11 drivers are fine in this respect.
1 Like
Interesting. On my system it happens on d3d11 and d3d12 as well. Could be a Win10 thing i suppose, or maybe GPU driver.
2 Likes
Hmm no I doubt it maybe its just hdr.slangp that was working. Ok I’ll try that bfi-simple.slang in D3D11 as its the simplest driver we have so makes the whole problem a lot easier.
1 Like