LÖVE

Hi,

i thought i would relax during holidays but it is so much fun programming with Löve so i did another program

This time it is a little demo of a lighting simulation with shadowing. You can dynamically insantiate lightsources also you also could insert over a thousand light sources (well fps would be very low than but in fact you could do that).

There are also some optimizations like every light source is only drawn when it is on screen or only the part of the image is will be redrawn where the light source actually is. I could add another optimization that only the polygons are checked that are on screen but thats future work.

Until now the shadowing only works with convex polygons. I will see if i will fix it in future.

Has anyone an idea why the lighted areas aren't smooth? Solution of this problem must be somewhere in the shader but i cant find it :/

You have no antialias enabled, so naturally you get stairways when drawing geometry. If you mean the light circle being stepped, it's about color jittering.

I once did about the same thing in GameMaker, and I even went great depths optimizing it, but ultimately it was running like bollocks because of GML's outstanding performance. Mostly it was clipping rendering that doesn't contribute to the picture, but I also did big job with minimizing calculations. My shadows weren't covering the object they were shadowing, although they would cast shadow onto other objects, and thus concave objects would cast shadows onto themselves which doesn't look so good. With GM I couldn't think of way of just clipping sprite area out of shadow rendering, but with LÖVE you could simply use stencil. I attahed the sources in GML, shouldn't be a problem to port to love.

EDIT: forgot to include invoking script (that performs clipping), re-uploaded the file.

EDIT2: light sector -1 was reserved for directional light (like sunlight). 0 reserved for 360° point light, >0 is for point lights with narrow sector i.e. flashlights, where the angle is half the sector witdh in degrees; specifying >135 (>270° sector) has no meaning, since it would yield exactly the same picture as 360° light, but will cost more time to check clipping.
point_direction would estimate direction in degrees between x1, y1, x2, y2, kinda like math.atan2 ( y2 - y1, x2 - x1 )
point_distance is math.sqrt ( ( x2 - x1 ) ^ 2 + ( y2 - y1 ) ^ 2 )
lengthrid_* is essentially len * math.sin/cos ( dir )
Other specific functions are for dealing with GM's data structures (more C-like distinct versions of Lua's tables that perform very specific data handling).
Oh and vx/vy are cam position.