pathfinding

I don''t see why you still can''t use tiles as your A* search blocks, or some copy of the tile array. You make an array that is purely for path finding and in each "tile" you store the direction to the goal point or some blocked value if you can''t travel through this tile. Even if you can have multiple units per tile, I think this would be possible. Simply leave this tile "open" if the tile is not full of units that would block another unit''s passage.

I would be more inclined towards the hard-core pathfinding algorythems that take weeks to write and take a raw map with no pathfinding data and sorts out the path on runtime, but thats just me .

~SPH

P.S. You are so lucky to have friends like that... ("wrote me an engine...")

[edited by - ShmeeBegek on February 20, 2003 1:03:48 AM]

There is no reason that the pathfinding algorithm you use has to use the same size squares as are on the map. You could overlay your map with another set of squares that you then use for pathfinding.

The two maps would be closely related and when obstacles change they would have to inform each other of the changed positions. In my game I have three different arrays storing the information. The first stores the map display info. The second stores the obstacles and the third which resets to the second is for pathfinding.

yes.. but let''s imagine a block structure:

struct block {
int posX;
int posY;
bool fog;
bool visibility;
int resistance;
}
resistance let us calculate the speed variations.

so we have 4*bytes*3+bytes*2 for a block = 14 bytes.
with 16 blocks per tile and a map of 256*256 tiles we have 14mb only for the pathfinding. And with 1024*1024 maps.....
Now we are using flags on one byte for fog, visibility and resistance and that''s much better but not enought yet. So i tought that i can construct my vertex only with this tab and put it in my vertex buffer in my video card. I don''t know if it''s possible so that''s why i''m here

anyway thanks for the answers.