Legacy GM Hue Shader Required - for GMS v1.4.1757

[RyanC]

Anyone got a hue shader script for GMS1.4.1757? as the standard one seems obsolete for this update.

 

[Alvare]

lol. it happens quite a lot with gamemaker's updates. Nothing you can do about it, except if you have knowledge of writing shaders.

 

[RyanC]

Anyone know what's caused the shader to respond differently, or have a recent hue shift shader script?

 

[Aura]

https://marketplace.yoyogames.com/assets/2482/hue-shader

The asset is currently free, so you should give it a try ASAP. But if the documented YoYo's shader doesn't work as expected due to the update, you should perhaps submit a Helpdesk request with a sample project, so that they can look into the issue.

(And you can easily find another hue shift shader by searching on the legacy GMC...)

 

[flyingsaucerinvasion]

Can you give an exact description of the way the shader has changed? Do you have backups of your project from before you updated? Are you sure it isn't something wrong with your project or you haven't made a change to the shader that you've forgotten about?

 

[RyanC]

Can you give an exact description of the way the shader has changed? Do you have backups of your project from before you updated? Are you sure it isn't something wrong with your project or you haven't made a change to the shader that you've forgotten about?

Yes, I saved an executable version before I updated GMS. I'm positive the shader is still the same, I've double checked it with the standard hue shift code too.
This is how the normal correct version looks from GMS 1.4.1398

This is the new update to GMS v1.4.1757
As you can see the levels and leaves that use the shader are different colors completely, it's as if the saturation is way to high as well.

shader code:

// Vertex GLSL ES
// Simple passthrough vertex shader
//
attribute vec3 in_Position; // (x,y,z)
//attribute vec3 in_Normal; // (x,y,z) unused in this shader.
attribute vec4 in_Colour; // (r,g,b,a)
attribute vec2 in_TextureCoord; // (u,v)

varying vec2 v_vTexcoord;
varying vec4 v_vColour;

void main()
{
vec4 object_space_pos = vec4( in_Position.x, in_Position.y, in_Position.z, 1.0);
gl_Position = gm_Matrices[MATRIX_WORLD_VIEW_PROJECTION] * object_space_pos;

v_vColour = in_Colour;
v_vTexcoord = in_TextureCoord;
}

------------------------------------------------------------

// Fragment GLSL ES

varying vec2 v_vTexcoord;
varying vec4 v_vColour;

const mat3 rgb2yiq = mat3(0.299, 0.587, 0.114, 0.595716, -0.274453, -0.321263, 0.211456, -0.522591, 0.311135);
const mat3 yiq2rgb = mat3(1.0, 0.9563, 0.6210, 1.0, -0.2721, -0.6474, 1.0, -1.1070, 1.7046);
uniform float hue;


void main() {

vec3 yColor = rgb2yiq * (texture2D(gm_BaseTexture, v_vTexcoord).rgb*v_vColour.rgb);

float originalHue = atan(yColor.b, yColor.g);
float finalHue = originalHue + hue;

float chroma = sqrt(yColor.b*yColor.b+yColor.g*yColor.g);

vec3 yFinalColor = vec3(yColor.r, chroma * cos(finalHue), chroma * sin(finalHue));
gl_FragColor = vec4(yiq2rgb*yFinalColor, texture2D(gm_BaseTexture,v_vTexcoord).a);

}

 

[flyingsaucerinvasion]

Have you tried going over the change log for the recent verions of game maker to see if anything there looks like it could affect the shader?

Actually, I think I have an idea about this problem. I notice that if you multiply the final color by 0.5, take a screen shot, and then measure the values of each channel in that picture, you will find that some of the colors have channels with a value greater than 128 (more than half the max value), which would imply that the original value before multiplying by 0.5 was more than 1.0. I'm not sure how the shader interprets colors beyond the range of 0.0 to 1.0.

TL-DR: Some of the values in yiq2rgb*yFinalColor will be below zero or above one. How will they be handled by the shader?

 

[RyanC]

Thanks for all your help, really appreciated!
Yes I looked at all the updates and didn't see anything that would effect this.
I'm not too good with shaders, how would I clamp the values, there must be a reason for why this has changed, nearly every hue shader I've seen is exactly the same so I don't understand why there aren't more people wondering what's happened?

 

[flyingsaucerinvasion]

I already tried clamping the values, and it still was producing obviously wrong results. I dunno, maybe they have to be transformed in some other way?

but if you want to try it yourself, just put a clamp function around here:

clamp(yiq2rgb*yFinalColor,0.0,1.0)

 

[RyanC]

Yes your right, it didn't change anything

How can I file this as a bug on mantis? will I get some information on what has changed that could have caused this?

I'm now being forced to render all the different hue types as sprites which is going to seriously increase texture pages!

 

[Mike]

Okay, that was an ancient version you were using - almost 2 years old. Looking back at the release notes, the only thing that appears to have changed in between that time is that matrices got transposed (no idea why, but would have been for some kind of compatibility reason I'd guess). This will probably also include the ones you define in your shader. So the first thing I'd try is to transpose your 3x3 matrices.... see if that fixes it.

Outside of this, shaders haven't changed in....well... years now, so I'm not sure.

 

[RyanC]

I'm not too good with coding shaders, does anyone have the new version?

How are they to be transposed? I've been swapping them around in almost every possible way for weeks now.

Any help greatly appreciated.

 

[flyingsaucerinvasion]

Hi, to transpose a matrix is to switch all its columns with its rows.

so this matrix

0 1 2
3 4 5
6 7 8

becomes

0 3 6
1 4 7
2 5 8

I don't think this will fix your problem, I believe I already tried this. But you should try it yourself just to be sure.

 

[MusNik]

I updated the shader, check it now, please: https://forum.yoyogames.com/index.php?threads/free-hue-shader.5183/

 

[flyingsaucerinvasion]

I just tested that update @MusNik, but it still seems to produce very wrong results on my computer. Try applying the shader to a rainbow and see what I mean.

example:
https://app.box.com/s/8pxetnp8uuxub5zzio2wxx7c16gi24g2

 

[MusNik]

Okay, now I got what's the problem.

Rewrote the shader, now it should works.

 

[flyingsaucerinvasion]

I see you've used a completely different method. Were you able to determine why the other method isn't working?

@MusNik

 

[MusNik]

@flyingsaucerinvasion I have no idea, maybe something with matrices, that's on GameMaker itself.

 

[Wraithious]

Rewrote the shader, now it should works.

Nice work it really works well!

 

[Mike]

So was it just a transpose (flipping row/column order) of the matrices?

 

[RyanC]

Thanks for updating the shader, amazing response and great support, really like your choice of using hsv, as it's much more compatible with GMS

It works very well, however it seems slightly dark and saturated compare to before, any idea where would be the best place in the script to adjust this, I was thinking the vec3.y for saturation but wondering where exactly?

 

[MusNik]

 vec3 shifted_color = vec3 ( hsv.x + Position, hsv.y, hsv.z );

Here.

 

[RyanC]

Thanks mate, really appreciate your help, I've already tried doing that.

It's great the shader is working again, my honest opinion its that the colors no longer seem as vibrant in the new version though.
It's as if there's something not quite right with the red and blue conversion maybe?

Here is a screen shot, left side is the old version.

 

[flyingsaucerinvasion]

I'd still really like to know why the old version stopped working.