Gamma, specifically GDI32/SetDeviceGammaRamp is a display correction function and not something to ABUSE for special effects or change to any value other than what the end user explicitly asks for. I strongly recommend to remove all references to it in the source and never touch it again.
Anyway, I already edited my executable byte code to void the function call. Faster than doing anything with the source myself :p
Until next release.
Trans_*
functions that we already have.
We already have several texture fetches and coordinate transformations in the pixel shader in the lights branch at the moment, and even with my onboard GPU things run mostly smoothly for a scenario such as Crash.ocs. So I'm not worried about one additional matrix multiplication.
The good thing is the the game restores gamma to previous value when it loses focus or exits - A step in the right direction, however small.
The bad thing is it still runs the game with it's own value and no way to change it. As if there's no good reason for a non-standard gamma setting...
Not that editing the bytes in the executable is difficult or anything, just saying. ;)
edit:
Noticed that there's a DisableGamma in the registry now (wonder if it was there all the time :?) . That should be enabled by default, and in game control for it should be added for those who trust games with their gamma settings. I'll find out if it works next version.
Edit: Why SetGamma(r,g,b) with r, g and b being values between 1 and 100? It should be SetGamma(RGB(r,g,b)) with r,g,b being values between 0 and 255 in my opinion because it is more consistent with other functions and allows 16 times more color precision.
Also, what exactly does the gamma shader slice colorize? (hud elements, upper board, text etc as well?)
Did you follow the discussion(s) here and there?
It is unfortunate that you do not have a clonkspot account, the latter forum seems to be invisible. I will cite the second one here:
>Clonkonaut: Und @ck - wie sieht es damit aus, dass die Engine einen veränderlichen Sonnenvektor vorgibt?
>Matthias: Erstmal bin ich dafür! Ich glaube, dass das sehr stark zur Atmosphäre beitragen kann, besonders, wenn man Sonnenrichtung, Lichtfarbe und Intensität irgendwie an die Uhr- und Jahreszeit koppeln könnte. Etwas mehr damit zu experimentieren, um beispielsweise die "Flachheit" des Hochofens auszumerzen, steht dann natürlich noch aus.
>Newton: Das würde dann den SetGamma-Kram im ersetzen. Wenn ich mich nicht irre, ist es (noch) nicht möglich die Lichtfarbe des Umgebungslichtes zu setzen. Das war an der Diskussion erstickt, ob man nicht auch Lichtfarben für Materialien festlegen kann/möchte (Lava: rot), denn die rote Lava soll ja vom Sonnenuntergang nicht auch dunkler werden. Diese beiden Features (globale Umgebungslichtfarbe setzen, zwecks Tag/Nacht/Ambient vs Farben pro glühendes Material) scheinen sich gegenseitig auszuschließen.
>Clonk-Karl: Wie wäre es wenn man die globale Umgebungslichtfarbe einfach als "glühende" Farbe des Sky-Materials betrachtet?
>Newton: Wie ich es verstanden habe, wird zum Start einer Runde für die gesamte Landschaft eine "Ambient Light Map" generiert. Diese wird dann im Spiel nurnoch bei Landschaftsveränderungen punktuell neu berechnet. Zurzeit ist dies ein zweidimensionales 8bit-Array.
>Würde man nun eine SetAmbientLightColor Funktion hinzufügen, so würde diese so funktionieren dass jeder Pixel beim Anwenden der Lightmap im Shader in der angegebenen Farbe eingefärbt wird.
>Möchte man stattdessen verschiedene Farben in der Lightmap, so müsste man diese bei Rundenbeginn als zweidimensionales 32bit-Array erzeugen. Dann funktioniert jedoch nicht mehr die oben erwähnte einfache Lösung für SetAmbientLightColor, da sonst die gesamte Lightmap gleichzeitig eingefärbt werden würde. Stattdessen müsste bei jedem Aufruf von SetAmbientLightColor die Lightmap komplett neu erzeugt werden. Da SetAmbientLightColor beim Zeitobjekt bei Sonnenauf- und Untergang sehr oft, vielleicht sogar jeden Frame, aufgerufen werden würde, halte ich diese Lösung für nicht machbar.
>Matthias: Die komplette Lightmap müsste man nicht erzeugen, man könnte doch eher den Himmel und die Materialien seperat halten.
>Newton: Hm ja stimmt, das würde gehen. Das hätte sogar den Vorteil dass man die Himmel-Lightmap nur updaten müsste wenn jemand Material überschreibt (aus Erde mit Hintergrund Tunnel Erde mit Hintergrund Himmel macht).
Having implement a shader based replacement for SetGamma, what do you think about this plan? Does this play into your current implementation (=is this easy with how you realized SetGamma?)
So in my mind this is a completely different discussion. We will probably want both options - especially because they are both cheap.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill