I have a clean, artifact-less sprite with a pure red color. Shifting hue with the HLS shader shows a clean, usable result in the editor:
But terrible artifacts at runtime:
Attach a Capx
Description of Capx
Uses the HLS shader to shift HUE of a red sprite by 75% or more.
Steps to Reproduce Bug
Just run the capx. From what I hear other users get that as well.
At runtime terrible artifacts appear.
Clean, usable result, just like the editor.
Operating System and Service Pack
Windows 7, 64 bit - SP1
NVIDIA GeForce GT 640/PCIe/SSE2 (Shader language 4.50 NVIDIA)
Latest driver - 347.09
Construct 2 Version ID
I can now add to this that strangely it adds artifacts on positive adjustments and doesn't on negative adjustments - i.e. if we add 75% to a red sprite it goes ugly as sin, but -25% looks clean and proper.
I don't know what we can do about this - as far as I can tell we use the standard math for HSL adjustments, and this looks like some kind of floating point rounding errors are happening on the GPU. I tried improving the float precision but it didn't have any effect. So I'm afraid this is has to be closed as it's just an artefact of the GPU processing.
Well, why doesn't it happen in the editor then? And why it doesn't happen when subtracting? There has to be a way to make it behave properly at runtime, surely. Or, perhaps, introduce a more resource intensive non-rounded version that's actually accurate? In my case it could take half a second for what it's worth, as long as the result is accurate.
Develop games in your browser. Powerful, performant & highly capable.
Do you have an intel processor? If so, you could try switching to the iGPU, and see if the artifacts resolve. Did you try node-webkit? Might be worth a shot.
Maybe if you forced the software rendered mode of webgl, the effect would work correctly. I think you could do that in node-webkit by passing it the right startup argument (don't know it off the top of my head).
Of course, that can be quite slow on anything but a beast of a computer, but you might get a more accurate result. Would be worth it for StuffGen.
Found a workaround for this - just add -100 to any hue setting, so the cycle goes backwards and everything is perfect. I'd still say this isn't normal behaviour and there's an error in there, somewhere, but at least the pinks and purples act normal.
Beautiful! That's going to make a big difference. Brilliant workaround.