Shifting hue with the HLS shader produces terrible artifacts

Problem Description

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:

[attachment=1:1zf42kax][/attachment:1zf42kax]

But terrible artifacts at runtime:

[attachment=0:1zf42kax][/attachment:1zf42kax]

Attach a Capx

[attachment=2:1zf42kax][/attachment:1zf42kax]

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.

Observed Result

At runtime terrible artifacts appear.

Expected Result

Clean, usable result, just like the editor.

Affected Browsers

• Chrome: (YES)
• Internet Explorer: (YES)

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

r193

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.

Somebody

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.