so are there any other options available besides:
1. clearance based
2. enlarging obstacles on the astar map
3. no diagonal movement
how does "clearance based" compare to "larger" obstacles for implementation complexity? as i recall, when considering options, clearance based didn't sound that straight forward. its a two step check, itsn't it? and the assigning of clearance values, can that be easily computed automatically on the fly for on-demand real-time map generation? or is it more suited to hand edited level maps?
i suppose "no diagonal" followed by path smoothing is also an option.
if the size of an astar tile was sufficiently larger than the size of an entity, diagonal movement wouldn't clip corners would it? actually, no. no matter the size of the tiles, moving diagonally from the center of one to the next with a non-zero radius swept area will always intersect the (potentially impassable) tiles to the left and right along the path. the "padding" must be added at a higher resolution - a smaller tile size.
what about a tile size smaller than an entity's diameter? for collision maps, you just check a bbox of tiles the size of the critter, instead of a single tile. i guess you'd do the same for astar maps?
that would let me use just one set of maps at 1 foot per tile for all critters, instead of maps at various critter diameters per tile.
EDIT: i double checked the code. astar is using a map with tile size = entity diameter. and it does do diagonal. and it does not "grow" the obstacles by the radius of the entity. so it looks like clipping corners is the issue.
suggestions?
grow obstacles? clearance based? no diagonal? no diagonal with path smoothing?
took a look at the clearance based article, clearance values and HAA map may not be suitable for real-time on the fly on-demand generation? it looks a bit intense...
tried doubling the scale of the astar map vs the collision map. didn't seem to work. but i probably didn't scale up then back down correctly.
i'm thinking a single astar and collision map with a tile size of 1, and check a bbox rad=criiter rad of tiles around a tile for both astar obstacles and collision checks. this would mean just one map, and would effectively "grow" obstacles for use with diagonal astar movement. so a tile would only be traverse-able in astar if all the tiles in a given bbox rad around it were traverse-able. this would work, wouldn't it? i would think it would be fast enough too.