Could someone please convert TileNormalMap shader to DX11 ?
Thanks!
Printable View
Could someone please convert TileNormalMap shader to DX11 ?
Thanks!
Here ;)
This one wasn't so hard, just time consuming.
Still you managed to do it in record time! :D Thanks a lot!
Can help upgrade colorpicker package to Dx11, thank you firstAttachment 31108
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.....
Attachment 31114 Dx11 will automatically exit.....
Attachment 31116Attachment 31117
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......
Attachment 31118
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?Attachment 31120
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.
I was thinking something like this:Quote:
Originally Posted by NaitorStudios
https://1drv.ms/u/s!Atq7cUIJ7uextCG3...4ImmA?e=mYrpGE
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...
Now that is strange. Works fine for me on both DX9 and DX11, both with pre-multiplied alpha enabled and disabled.Quote:
Originally Posted by NaitorStudios
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)
https://i.imgur.com/51ljXwa.png
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
I think I found the problem.Quote:
Originally Posted by NaitorStudios
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 :D
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.
Thanks it's fine for now I still have more testing to do before I know what I really want but I might have the need for a custom shader in the future.