VReaperV

> > This doesn't require changing the image data itself, right? Just some `shaderStage_t` data? > > Yes. What if you just go through all non-UI shaders after loading a...

So on those screenshots the only thing missing is interpretation of textures/colours in q3map2 as sRGB, right?

We just need to add HDR->LDR tonemapper, since we already have the HDR buffers, but currently we're just clamping the values to [0.0, 1.0]: https://github.com/DaemonEngine/Daemon/blob/9352952a9a04a298c64b7f2360f92e3d5cf3169d/src/engine/renderer/glsl_source/cameraEffects_fp.glsl#L45 Which effectively nullifies this advantage...

> The current advantage of using HDR buffers is to not lose precision when blending multiple stages. > > Using HDR buffers may have other advantages that may be nullified...

There is now an HDR->LDR tonemapper implementation in #1550. It fixes the dynamic lights being clamped as well: `r_overbrightDefaultClamp off`:  `r_overbrightDefaultClamp off; r_tonemap on`:  `r_overbrightDefaultClamp off`:  `r_overbrightDefaultClamp...

Also note that #1425 NUKES the random dynamic light scaling, so any changes made to dynamic lights should take that into account.

Actually, the last 2 screenshots are nearly the same as current with tonemapping: Current:  With the dynamic lighting changes reverted:  However, without tonemapping reverting the changes still makes...

I'm not sure why those random multipliers and additions in shaders were even there in the first place, maybe we should just NUKE those while making sure that dynamic lights...

> surprising cost > Raspebrry Pi 5 (VideoCore 7) Choose one

> I know people having been students _in the recent years_ who had worse hardware as laptop bought brand new by their parents (4GB RAM with 32-bit Windows, RIP 😂️)....