you're probably better off with the hitTest() especially if you can limit the number hexes to less than 100 by doing some rough estimates of which hexes are nowhere near the hit area and avoid tests on them.
the main thing that slows flash is having a lot of movieclips/graphics. so anything you can do to remove movieclips that are no longer going to be used is worthwhile. in addition, you should check if enabling the cacheAsBitmap property of your movieclips will enhance performance. for those movieclips that aren't scaled, faded, rotated and don't have timeline animation, this will be a major boost.
Thanks for the reply.
However, I think I just found a snag that is going to preclude hitTest alltogether.
It's rather involved and probably not worth detailing, though. (Unless one finds detailed discussions abut LoS on hex grids unhealthly facinating. Heh.)
The short version:
For game mechanic reasons, the particular sides of a potentialy blocking hex the LoS line passes through are sometimes important. Sometimes, for a particular hex, they will determine which adjacent hex to also look at. (without going into too much detail)
AFAIK, hitTest() will only tell me if a hex is hit, not where it is hit, unless I make every edge of a hex a potential object to hitTest() against. (correct me if I'm wrong). If that's the case, I'm looking at an efficiency comparison of 1 to 1 of hitTest() vs. intersect formula, as opposed to, say, 1 to 3 on average.
1 hitTest vs. 1 intersect formula prolly puts the runtime win on the formula - unless I've been missinformed on the cpu cost of hitTest(), which I admit is certianly possible.
you're correct: hittest can't be used to determine where an object is hit unless each part of the hit object is a movieclip and you loop through those parts using another set of hittests or use some other means to determine where an object is hit.
As a follow-up, I did some caluculations, and on my sample 7x7 hex grid, when computing LoS between 2 hexes, the intercept formula runs about 10-25 times, (depending on terrain) and sometimes 0 times for short ranges.
However, when looking at an 'all inclusive' LoS picture (that's LoS to all other 48 hexes) from a particular hex, the function runs about 300-700 times, and takes about 1/2 second on my old-ish machine. So hitTest() is probably less than ideal in that case anyway.
So, the unit-to-unit LoS calculations should run pretty quick in the background, as they only have to perform a check on the hexes the units happen to be in. Whereas the comprehensive LoS test is nice to have to show the player visibility from a particular spot for planning purposes, and is not intended to run continuously in real-time.
if you want to decrease your calculations you could divide your stage into a rectangular grid. each grid would contain say 4 hexes in their entirety and parts of others.
you could then do a first pass LoS calculation to determine which grids to check and then check the hexes in those grids.
I currently limit the area to check into 4 quadrants. Centered at the LoS origin, the target hex will only fall in one of the four, and that's the one you check.
I wanted to use 6 directions, in 60° cones (works well with the hex sides), but I messed up the code. So, until I need to revisit it, the 4 sections will work for now.
ok. good luck!