Legacy GM Lighting (dynamic shadows)

[CoderJoe]

Hey there. I have been working on a lighting engine for my game. I've tried multiple iterations of it but the basic idea is this: I want only shadows to be draw instead of light.
The levels of my game are divided up into sections. The player object moves and there are some lights in each section. To keep things quick, I am baking the shadow of the static objects on the start of the room. However my main problem is that I can't figure out how far to draw the shadow. It's a little hard to explain so here is a picture:the left is what I want to happen but the right is what currently happens. I thought if I had an invisible object that covers the section, I could calculate the intersection to stop the shadow from drawing so far but I haven't figured that out yet. Any suggestions or equations for finding an intersection of a line with the edges of a rectangle?

 

[anomalous]

There may be faster/more elegant ways, but you can calculate the line segment intersect using this:
http://www.gmlscripts.com/script/lines_intersect

From what I recall it was fast.
Read the comment, once you get a collision, you can then use the return value to plug into the parametric line equation to get the x and y coordinate of the intersection.

You could iterate collision until it hits that point, but I recall that being slow. There is a collision_line_first at the same site that does that too, if interested.

 

[Carbiner]

This bit of code would force your shadow to stop after a certain amount of distance, regardless of its angle. This code is also really useful for bullets that need to come out of the tips of guns.

c_y = 0; // Pretty much stays 0. Its the up and down from your center
c_x = 50; // How far out you want your shadow to go
rot = random(360); // Your code to figure the angle from your light to your walls
/* YOUR SHADOW CODE HERE
draw_line(x, y, x + lengthdir_x(c_x,rot) - lengthdir_y(c_y,rot) , y + lengthdir_y(c_x,rot) + lengthdir_x(c_y,rot));
x and y would be replaced with your obstructing object's x/y corners or bits
*/

Without looking at your shadow code, I can't say for certain that this will work. I'm not sure how you would do your in-between bits, unless your just drawing as many lines as it takes.

 

[CoderJoe]

Cool, thanks for the help! I'll look into these things for sure.

You could iterate collision until it hits that point, but I recall that being slow

yeah that was I problem I had originally and was why I was looking for other problems. Thanks for the link though, I might be able to make the code more efficient.

 

[CoderJoe]

Oh, also the way my shadow code works is that each shadow casting object has a list of points (usually corners) to create a sort of mesh. I then draw a primitive using a triangle list by going from a point on the caster to a farther point along a straight line (from the light to that point) to the next point on the caster. This is repeated for each point creating a solid polygon shape for the shadow.

 

[Juju]

Render the shadows to a surface the size of the region, then draw the surface. Alternatively, use a clipping algorithm (fortunately with rectangular spaces, this is reasonably simple).

 

[CoderJoe]

use a clipping algorithm

Do you have any algorithms or have a link to one?
Interesting idea of drawing the shadow to the surface of the same size of the region, but won't this require using multiple surfaces? Is that okay? I'm trying to develop for a mobile platform so I want things to be efficient as possible.

 

[Insanebrio]

I think you can use surfaces on mobile only if you make a pixelart with small resolution, but not on Hd games or above. If you check the rayman mobile games they have no lighting for that reason. Also shadowcasting collision detection is quite heavy, but with low res it should be fine (check stealth bastard, made with game maker)

 

[anomalous]

Cool, thanks for the help! I'll look into these things for sure.
yeah that was I problem I had originally and was why I was looking for other problems. Thanks for the link though, I might be able to make the code more efficient.

No, I meant that to specifically solve your question. Checking segment intersection is very fast.

a point on the caster to a farther point along a straight line (from the light to that point) to the next point on the caster.

Yes, how are you figuring this further point from the quote? The length of this straight line above(to the further point) can be determined by using the segment intersect code I provided, segment 1 being the line you drew above, segment two, a loop for each of the 4 line segments making up the rectangle you want to stop at. You may be able to intelligently select the correct segment to check before checking all 4, but with only 4, and I think its a fast check, and you only calculate the x/y after you find an intersection, it may not be worth the extra time.

 

[CoderJoe]

No, I meant that to specifically solve your question. Checking segment intersection is very fast.



Yes, how are you figuring this further point from the quote? The length of this straight line above(to the further point) can be determined by using the segment intersect code I provided, segment 1 being the line you drew above, segment two, a loop for each of the 4 line segments making up the rectangle you want to stop at. You may be able to intelligently select the correct segment to check before checking all 4, but with only 4, and I think its a fast check, and you only calculate the x/y after you find an intersection, it may not be worth the extra time.

Yeah that is basically what I was trying to do. I'm gonna go through my code and check it all to make sure I do the math right. It's quite a process as first I have to create 4 equations for each segment of the rectangle, then loop through all the shadow casting objects and create their shadows by looping through all the points on each caster and checking where it intersects with the rectangle. Luckily the code only runs once to bake the shadows and then updates only with the player.