A Flash Developer Resource Site

1. ## Dynamic Shadowcasting Too Slow - Take a Look

Line Of Sight

Now let me explain the process that I go through every time the player moves. There must be something that I could eliminate, as it seems unnecessarily bulky.

[list=1][*]get direction vectors from player to each corner of one of the blocks[*]dot product every direction vector combination of to find the maximum angle in order to see which corners get their rays extended.[*]extend the rays from the two corners found in last step to well beyond the bounds of the movie[*]calculate intercept between movie bounds and the two rays then change the endpoint of each[*]find what corners of the movie should be filled and add them to the draw list[*]draw and repeat for each obstacle[/list=1]

Now originally I didn't do step 4 or 5, but it started acting weird on me and ran just as slowly. What can I do???

Is the acos function slow? What about sqrt? Could I put some lookup tables in (i don't need perfect accuracy).

And I know about the bugs.

2. ## Re: Dynamic Shadowcasting Too Slow - Take a Look

Originally posted by devnull_2k
[list=1][*]dot product every direction vector combination of to find the maximum angle in order to see which corners get their rays extended.[*]extend the rays from the two corners found in last step to well beyond the bounds of the movie[/list=1]
These seem like the time-consuming steps to me. First, a dot product for every vector combination would be quite a lot of calculations, right? And second, if you're extending the rays a very long way, then flash might simply be taking a long time to render it.

I'm guessing it's #1

3. But its necessary. How else would I find what corners extend the shadows? Its always the two with the largest angle between them. If you have another way, I'd be happy to hear it.

But you gave me an idea. Right now I'm calling sqrt 14 times per obstacle per frame. I can cut it down to 4.

And about extending the rays. They're extended but not drawn. Its just math until the end.

I also noticed that the variables stay set across frames. Should I unset them to free mem?

4. Originally posted by devnull_2k
I also noticed that the variables stay set across frames. Should I unset them to free mem?
unless there are a lot of variables, this probably isn't causing any harm.

if you post the fla I'll take a look at it

5. Maybe in a bit. At the moment my classes and functions are almost entire uncommented and I'm sure a bit confusing (though quite organized).

I was also thinking of something else. I haven't totally worked it out in my head yet, but it would be something like this. On one frame it would check it any of the shadows overlap, then on the next few it would eliminate corner calculations for the covered corners until uncovered. I'm not sure if it would speed it up or not.

6. ...you can see it now. Sorry if its a bit confusing.

Calls to functions are made from the player.

Functions and classes are all on first layer of main movie.

Variable Definitions are on the bottom of first layer's code.

drawLOS(p) is what ties all the functions together.

7. whew!

ok, sorry not to get back for so long, a client of mine suddenly escalated a project and I had to get by head back into work-mode

In the end, I decided that really the cause of your code's slow speed was just all the math. If this was just an in-between stage to a bigger goal and you need the math as it was, hmmm...

But in the meantime, I started over from scratch and worked the same effect using large if statements instead of mucho math (unlike trig functions, flash handles if statements very well). The overall effect is largely the same, although not 100% complete.

On my computer, I'm getting in the mid-40s frames-per-second. Pretty good improvement

The drawbacks are:
[list=1][*]I didn't have time to add methods to calculate shadows when the light-source is inside the outer bounds of the object.[*]I didn't have time to comment the code. So if you have trouble with any of it just ask. Sorry, but just didn't have the time for it.[*]there's a weird bug when the light source is underneath the blue box on the bottom. I have no idea what is causing that. Again, no time to look into it.[/list=1]
But on the up-side, the points are draggable, which was a neat feature that my code allowed me to add very quickly (it literally took me about 90 seconds to go from static to dynamic points!) -- and it shouldn't be too hard to add a flexible number of points also.

8. Actually, turns out that I removed all the trig functions and it ran right at the frame rate.

I'm just doing slope differences now. So no need to calculate sqrts or acoses.

I'll take a look at the FLA though, thanks.

Also, i expect that you can't make the rectangles on an angle in yours without adding a ton of new if conditions... am I right?

9. nope, all you have to do is drag the corners. It uses the same calculations.

the only problem goes back to how I didn't add the code to compute what happens if the lightsource is from within the block -- and with angled blocks there is 'empty space' that is still technically within the outer bounds of the block.

but from a normal position, it works fine.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•

 » Home » Movies » Tutorials » Submissions » Board » Links » Reviews » Feedback » Gallery » Fonts » The Lounge » Sound Loops » Sound FX » About FK » Sitemap