@Verrazanoit likes to render shadows on top of things it shouldn't
At the moment, there are only 2 settings for how the shadows are drawn over the hulls. One with hull self-shadowing and one without. There is not yet a setting to leave hulls completely unaffected by shadows. I am working on a more generalized OpenGL 2D lighting system, I'll include this feature in there
![Wink ;)](https://www.sfml-dev.org/forums/Smileys/default/wink.gif)
.
Second how would I turn down the intensity of the shadow I noticed in your gore factor game that the shadows were very soft and not quite as hard as the ones in 1.5.1 how would I replicate that
The intensity of the shadow cannot be adjusted at the moment. That would require hull transparency, but that isn't really the effect you want in your case anyways. Actually, hull transparency is available in the library, but it doesn't quite work with the soft portion of the shadows yet.
In Gore Factor, I just raised the ambient light level.
what's the easiest way to optimize ltbl with box2d so that when you render the shadow it actually keeps up with the physics shape
The easiest way to make LTBL work with Box2D is to construct a hull from the transformed points of a b2PolygonShape, and update this hull whenever the shape's body is active. The problem you are having with the shadow being a frame behind is caused by rendering the lights before the physics are performed in a frame.
@posvaBut I still don't know if an auto_ptr is enough for you or not
You can use auto_ptr instead of unique_ptr. I didn't put any unique_ptrs into STL containers, so it doesn't matter (auto_ptr cannot be copied).
I also noticed some errors at compilation like determining a class a friend of himself
I google'd this, it only seems to happen with gcc. But, it seems like you can just leave it out with gcc, since the class is implicitly a friend of itself.
I found this portion of code weird
The color thing is indeed a mistake, thanks for finding this! I didn't notice it, since the color values end up being clamped to a [0, 1] range anyways when rendering. So, you can just remove everything up until the glBegin statement, it doesn't do anything.
There are a lot of warning I'm trying to correct, also not used variables like m_render in convexhull and not initialized variables on constructors. Not initialized variables may give unexpected behaviours
m_render is indeed not used, thanks for finding this. However, you don't need to initialize variables in a constructor if that constructor value is never used for anything. They are set later on, so there shouldn't be any unexpected behavior.