eliminate the need for (blank - sprite.x)/sprite.width

I'm not sure if I'm the only one who uses bumpmapping as much as I do, but it'd be cool if you didn't have to translate the screen coordinates every time for bumpmaps and heightmaps.

it's not that hard to type every time, but I can't think of too many occasions when you'd want to think in the raw form anyway. I suppose all the scenarios needed to work it out correctly can't be built into the fx file, so maybe another light object with a toggle for bumpmaps, and you just move that around. one or two bumpmaps might not seem like a big deal, but if you want the entire game to be bumpmapped, and multiple colored lightsources and stuff, it's starts to get tedious to copy/paste that or retype it every time

I dont really understand what you mean but Im using Bumpmapping in my newest game though only for ground texture^^

if you want to move the light source around to where your mouse is on the screen for instance

when you do set light x and set light y in bumpmapping

you can't :

set light x to mousex and

set light y to mousey

you have to:

set light x to (mousex-sprite.x)/sprite.width

and

set light y to (mousey-sprite.y)/sprite.height

or your lightsource will be in a totally different part of the world

I'm saying it'd be nice to just be able to put mousex and mousey and be done with it

OR, just be able to use the light object to automatically control the light source for bumpmaps

Originally the 0.5 meant you want the light source in the middle. We can easily change the shader to use real co-ordinates (or at least pixels, so you dont have to divide by width) but what i'm not certain about is if adding the maths into the shader code will have an impact on performance, or if the shader compiler is smart enough to think 'well that parameter doesn't change during the procedure, so i can simply this by performing the maths before looping all the pixels.

I'll test now brb

Just tested it, make no difference...looks like the shader compiler is very intelligent!

However, the problem is changing this will cause existing caps that use the effect to not look right (people would have to modify their events and effect parameters)

Ah now I understand... Didn't even know you have to do it like that Oo

hmmmm. there'd be no way to add atoggle for the new way so it wouldnt affect old caps?

well Construct is not 1.0 yet soo....

plus, arrays recently changed from 0-based to 1-based, I say if it's better just go for it.