[Request] Tile normal map DX11

Here
This one wasn't so hard, just time consuming.

Can help upgrade colorpicker package to Dx11, thank you firstPlease login to see this attachment.

That's quite a lot, but sure, I'll do it tomorrow.

;D thank you thank you

wuxuechen here's the thing, after a lot of pain with the ColorWheel, I got it all working.
BUT, ColorWheel simply refused to work correctly on DX11 premultiplied mode, so I had to make a innacurate workaround for giving it the donut shape.
I really hope someone can figure this out cause I've tried a lot of things and alpha won't work because it's outside the 0.0 to 1.0 range.
In general, it's usable, but I wouldn't mess too much with ColorWheel parameters on Premultiplied DX11...

I don't see how the alpha component can be outside the range 0-1. I reckon there's something else going on, but I don't know what... I'll have a look later, but I'm about to go out right now.

A couple of thoughts which probably won't help:

* You define a "Demultiply" function that you don't ever call. Is that just left over from an experiment that didn't work?

* With this particular shader, there's no need to worry about Tint, is there? I can't picture a situation where changing the tint or alpha wouldn't defeat the purpose of a colour wheel.

* I think your version is fine, so it's probably best to change the other versions to match.

* The edge parameter was really just a quick and dirty hack to make it look a bit nicer, and it needed to be changeable depending on he size of the colour wheel. If I were remaking the shader now, I'd probably make use of pixelWidth and pixelHeight to hardcode the edge value.

1- Was a left over, I've tried using it somehow but didn't helped, yeah, in fact, multiplying rgb by alpha seems to fix the alpha but messes up the colors.

2- Just a habit, but doesn't make any difference, I've tested.

3 & 4- Well, if you think so... I could update both to match, seems smoother anyway

But in all cases, I really think there's something off with alpha... I mean, it only breaks once premultiplied is turned on, it shows some remains of alpha but not the same as when you output it as RGB.

Well, I've updated all to match, but I'm not sure if I used fPixelWidth and fPixelHeight correctly here...

Next, I want to use it in my working file, but will an error occur when the modification is unknown? I will check all the next work, thank you!

It should work fine, I just removed the parameters from the ColorWheel cause that wasn't really necessary.

If it doesn't work properly, Dx11 will exit automatically.....

Please login to see this attachment. Dx11 will automatically exit.....

Please login to see this attachment.Please login to see this attachment.
The cause of the error has been found and started normally after deletion, but why? It is still unknown whether there will be errors with other objects, so we can only continue like this......

Please login to see this attachment.
There are still other mistakes. The road is long and the repair is far away

Is this a coincidence? Just let me meet? Or something else?Please login to see this attachment.

I don't think it's crashing because of the shader, it's most likely a font incompatibility, specially on active system box.
About the shader, if you had my previous port, delete ColorWheel.premultiplied.fxc, it might conflict with the new code.

Quote from NaitorStudios

Well, I've updated all to match, but I'm not sure if I used fPixelWidth and fPixelHeight correctly here...

I was thinking something like this:
Please login to see this link.

So you still have control over the width of the wheel, but you don't have to change the edge softness according to the size of the object (it's a fixed 1 pixel transition).
I didn't multiply by In.Tint, because I'm still not sure if / when you're supposed to?!

To be honest, I've never understood the point of pre-multiplied alpha - it's always been a pain to work with, for example when loading .png files etc. Is there any reason Clickteam have added it, or any reason why anyone should use it? I'd just recommend that noone ever uses it.

I like what you did there, but it didn't worked for the middle hole, it's shows just a circle for me...

In.Tint is actually the RGB/Blend Coef data by the looks of it, unfortunately DX9 lacks this...
Anyway, it's not necessary in this case, wouldn't work on DX9 anyway because there's no way to get it.

I think some stuff looks better on pre-multiplied alpha, like text rendering, but idk what else it does...
I wonder if it increases (or decreases) performance...