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

New releases and general discussions.

Post » Thu Mar 26, 2009 6:15 pm

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 :idea: , like the one that works with shadow maps, or maybe the same light object :idea: 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
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Thu Mar 26, 2009 7:31 pm

I dont really understand what you mean but Im using Bumpmapping in my newest game though only for ground texture^^
B
11
S
3
G
4
Posts: 622
Reputation: 3,186

Post » Thu Mar 26, 2009 8:10 pm

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
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Fri Mar 27, 2009 5:04 pm

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
B
4
S
2
G
5
Posts: 641
Reputation: 3,011

Post » Fri Mar 27, 2009 5:11 pm

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)
B
4
S
2
G
5
Posts: 641
Reputation: 3,011

Post » Fri Mar 27, 2009 7:19 pm

Ah now I understand... Didn't even know you have to do it like that Oo
B
11
S
3
G
4
Posts: 622
Reputation: 3,186

Post » Fri Mar 27, 2009 8:11 pm

hmmmm. there'd be no way to add atoggle for the new way so it wouldnt affect old caps?
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Mar 28, 2009 2:11 am

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.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665


Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 3 guests