If you're sure you haven't done something wrong (you're not setting the fWidth parameter above 0.5 in an event or something?), maybe we need to check with Clickteam? I can't see why it would work on one computer and not another.
I'm getting nice sharp edges, regardless of the size of the wheel, and with only one parameter to worry about (the thickness of the ring)
The only other thing I'd change (apart from getting the tint to work properly), is that it doesn't take into account the aspect ratio, which would be easy enough to do - just in case anyone ever wanted an oval shaped colour wheel (which I doubt).
I just tested the example that comes with the shaders, so that might have something messing with it, I'll check once I get home
Weirdly, when I tried doing what you say, and it wasn't working - the fWidth refused to stay set, so as soon as I deselected the object, the parameter instantly reset itself to 0.0. It turns out that it's because in the XML file, the "min" property was "0", not "0.0", and so for some reason Fusion was treating it as an integer, and rounding it down to 0. So I guess try that...
I'll upload a fixed version tomorrow (with support for ovals, hopefully), but it's obviously a super-simple fix to make yourself.
Oh great, it works now, thanks for helping with this, I always learn a lot from these situations.
Been fun porting shaders to DX11, I've been doing it for a while, and there's a few original shaders that I plan to release soon
Regarding the TileNormalMap shader could you check this please? The effect is different in dx9 vs dx11. Do you know why?
As far as I know, that's a issue of the parameters that returns the pixel size on DX11, which might act weird when applied to a layer/frame.
There's nothing I can do without adding a parameter where you manually set the resolution...
I also need to report this issue since this isn't the first time I've encountered it.
Do you want me to make a alternative version that works on layers/frame by using resolution parameters?
Oh, sorry, it was a mistake I didn't knew actually, the order of declaration of pixel size does matter, but doesn't eliminate a issue I had with these in the past.
It's fixed now. Oddly enough it was working just fine if applied on objects lol
There's one issue still: The shader is meant to square sprites/tiles/objects. Meaning light gets stretched depending according to the aspect ratio.
So this means you will need a version that specify the resolution if you really want to apply it to the frame or layer.
I see, once again thank you very much!
Yep I realise I'm using the effect in an unintended way here (as you say it's meant for objects with corresponding normalmaps loaded into the tileset) but I've been experementing with a fast easy cheap way of doing lighting in my latest project and found this to give a good result. Maybe I could achieve the same effect using a different method/shader.
I don't mind the stretching actually, but maybe you could answer this regarding performance though.
Since I'm not using the tileset loader at all would there be any performance gain by removing it?
(perhaps having a set variabel value instead, ie in the example above the normal map only uses RGB = 128,141,254)
You currently have the option of doing 3 individual lights. Do the number of lights affect performance much? What about just 1 or if you were to add something extreme, say 100 lights?
The tileset thing doesn't seem too intensive, it just use basic math, 2 lines of code.
I think you would still need to specify the texture size (which is the same as tileset size), so it doesn't make much difference.
About more lights, I'm pretty sure this already have too many equations, at least for DX9 which has a pretty low limit for these.
The amount of lights would certainly affect performance, yeah, I think it would be more efficient with a loop, so would reduce the code and run only the necessary part.
But DX9 sometimes refuse to work when doing something like this...
I may try if you're really interested tho.