in glsl? I've read that you need to divide it by the viewport's dimensions, which is what I did, but the whole quad still renders yellow, which means both X and Y are > 1...I have no clue... Intresting is, that if I only output the

gl_FragCoord.xy

without dividing it by

uResloution

, which is a vec2(800, 600) here, then it renders completely yellow too... Is this related to the deprecation of gl_FragCoord? (Other apps work... for example davedes' 2D Illumination demo)

I'm totally confused... probably it's due to the time being close to midnight here :X

Try hardwiring uResolution and see if it works. If it does, then the uResolution uniform isn't set to what you think it is. Also make sure glColor is some color other than yellow, otherwise your shader could just be failing outright and you'd be seeing fixed function output.

Try hardwiring uResolution and see if it works. If it does, then uResolution isn't set to what you think it is. Also make sure glColor is some color other than yellow, otherwise your shader could just be failing outright and you'd be seeing fixed function output.

Ugh!... Right... uResolutions wasn't set to what I wanted it to be set to. I used glUniform2i instead of glUniform2f Anyways... A previous problem is back. I want to recreate davedes' 2D illumination stuff with my engine...

Also note the differences between your brick normals and mine. The green on yours (Y axis) appears below each brick. Unless you invert the green channel, the normal lighting will look flipped. You should pre-process your normals, or account for the different normals in your shader.

Further, what are you using for lightPos.z? Try various values between 0.0 and 10.0.

Is lightPos in screen space or did you divide it by resolution?Further, what are you using for lightPos.z? Try various values between 0.0 and 10.0.

Both answers are in the comments

1

// This is set to vec4(mousex, mousey, 5, 1);

But yeah, dividing lightPos by the resolution and setting uLightPos.z to 0.5f did the trick!

<offtopic>And I'm not sure if the normal map will give me the inverted y channel problems you had... In the screenshot all shader-drawn stuff was flipped and the shader-origin is in the bottom left corner of the window, instead of the top left, due to wrong setup of the projection matrix. Now this is fixed, the shader-drawn stuff is flipped and everything looks okey.</offtopic>

<offtopic>And I'm not sure if the normal map will give me the inverted y channel problems you had... In the screenshot all shader-drawn stuff was flipped and the shader-origin is in the bottom left corner of the window, instead of the top left, due to wrong setup of the projection matrix. Now this is fixed, the shader-drawn stuff is flipped and everything looks okey.</offtopic>

Yup, it ultimately has to do with left-handed vs. right-handed coordinate system, so maybe it won't be a problem for your engine.

The difference is subtle, so double check to make sure it's correct.

Correct: (light at bottom right corner)

Incorrect: (again, light at bottom right)

Quote from: pitbuller

Just add new varying vec2 and use that. Lot simpler and tt should be faster also.

Huh, that's nice...the textures do seem to "stretch" to the light though...

It's supposed to look like that. If you look at the brick wall you'll see that the seams seem to move away from the light. That's because that part of the seams are facing the light, so it's illuminated. It's 100% natural when you think about it.

Notice how the top edge of the bricks is brighter.

EDIT: Disregard that, it's definitely the same problem. The y-coordinate needs to be flipped.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org