[Mark]

The pic shows the lights shining properly in Mapster but not in Eduke. I know in this particular case I might be able to make that wall a texture instead of the sprite placed there, but in many other places that is not an option.

I think I saw a passing mention of this before and the person never got a response. Sorry I can't nail it down to which version this started with. I did not have it with version 1640 but I did notice it in the last couple of versions I have used. I'm at 1705 right now. It happens with floor and wall aligned sprites. It makes no difference if they are directly on the wall or spaced 1 unit away from the wall ( which I do out of habit to minimize flickering)

I also made a small test map to verify it wasn't just something with my current map.

Anyone else noticing this?

[Mark]

So is it:

A---- I am the only one with this problem

or

B ---- No one is answering because I'm doing something so stupidly wrong that I deserve a "facepalm"

[Micky C]

I've encountered this problem and apparently it's hard to fix iirc, which is probably why no one wants anything to do with it

There are two things that could help:
1) if you want the player to see the sprite more, just give it a negative shade.
2) if you want the light to have more of an effect, which is what you're after, if you're using custom art, which you are, you can define a specular map fir the texture. Spec maps control the shininess of the texture and I'm guessing that if you make your texture really shiny it will get more light on it. I don't know much about them though, except for that either making it dark increases shininess, or the other way around. I guess you could try an all white spec map and an all black spec map, but someone else should be able to give you more help with that. You can also check the hrp DEFs and files for examples.

Nice pic btw

[Plagman]

What really puzzles me is the fact that it's different in Mapster and the game; it should be the same exact same code running. Can you make sure your configuration is the same across both, and more specifically r_pr_maxlightpasses? It's possible this sprite is already being affected by too many lights because you set a lower value in EDuke32. If not, can you attach the testcase you mentioned earlier?

[Micky C]

If it helps, it seems that for me when a sprite isn't receiving light in 3D mode, if I move it say up or down, it suddenly is. But when I go into 2D mode and back, it isn't anymore

[Mark]

r_pr_maxlightpasses is set to 6 right now. I was messing with that value a few weeks ago trying to tweak some more FPS in my map. Mapster was in windowed mode and the game was in a higher res and fullscreen wide mode. I set it back to match Mapster.

It is happening randomly. Some sprites are always reflecting lights. Some reflect only sometimes. A couple, not at all. I can't figure a pattern yet as to why some work and others don't. I tried pasting them directly on the wall or 1 unit away. Tried a number of different shade values, turned blocking on and off, set one sided on and off. Sprites used were with and without spec and diffuse maps ( or whatever they are called ). Some are located inside and others are outside.

I also removed any other lights that were in the vicinity and still no proper results in the game. Also no difference between SE49 or 50 as the light source.

I'm going to re-install a few previous versions of Eduke to see if I can narrow down when it started happening.

EDIT: So far its working fine for me in 1654 but not in 1690. I'll narrow it down further tomorrow.
EDIT AGAIN: My problem starts with version 1676. The version that started the Polymer frame rate increase.

[Diaz]

Let me rescue this thread, as I'm having the same problem. Lights are working correctly in Mapster but not ingame.

It looks like changing any console variables related to dynamic lights (r_pr_maxlightpasses for example) fixes it on the fly, but only for sprites that are directly on the players view, and if I do a restartvid, sprites are wrongly lit again.

Strange, huh? A problem with loading of dynamic lights?

EDIT: This happens on my work computer too. So it's happening on both an ATI 5850 and a GeForce 310.

Right (after changing any light-related console variables):


Wrong:

[Danukem]

Hey, I just noticed this thread for the first time (shame on me).

Before making assumptions about Polymer, I would start with the most obvious. As everyone who has mapped for Duke 3D knows, sprites are hardcoded to change their shade in-game to be equal to the floorshade of their sector (or the ceilingshade, if the ceiling is parallaxed). In Marked's screenshot, it looks like that might be all that is going on here. And it would explain why there is a difference between mapster and in-game even though the renderer is the same.

Try adding 2048 to the cstat of the sprites and see if that helps.

[Plagman]

I think I said that in another thread (the guy that was shooting rockets from next to the neon sign in E1L1, I think), but I know what the problem is; it's definitely Polymer-related. At some point in the past TerminX tried to make sprite planes cached like all other planes, but only tied the invalidation logic with the sprite structure members. I've already fixed a number of bugs introduced by that change, and this is an obvious culprit.

[Diaz]

Yes, it's absolutely renderer-related. Changing cstat, sector shade, etc. doesn't help at all. I've managed to find a workaround as lame as binding this to the movement keys:

bind "Up" "gamefunc_Move_Forward; r_pr_maxlightpasses 16; r_pr_maxlightpasses 17"
bind "Left" "gamefunc_Strafe_Left; r_pr_maxlightpasses 16; r_pr_maxlightpasses 17"
bind "Right" "gamefunc_Strafe_Right; r_pr_maxlightpasses 16; r_pr_maxlightpasses 17"
bind "Down" "gamefunc_Move_Backward; r_pr_maxlightpasses 16; r_pr_maxlightpasses 17"

so r_pr_maxlightpasses is constantly changing and sprites render correctly...

This has a drawback. It will only update sprites when the player is moving, so for example if I'm opening a door leading to a new area while I don't move, sprites in that new area will render with no Polymer lights, until I move.

I've noticed this happens in Mapster as well while using the UnrealEd style 3D movement. Move into a new area while the mouse button is held, and sprites won't update until the mouse button is released.