Isometric Path finding in VB Plz
Hi,
I am developing a IsoWorld Editor in VB, DX 8 (or 7?). It supports 3 layers, smooth scrolling, Auto Fringe Placement, etc.
I want to develop a "Jagged Allaince 2" type game. My Fav.
Currently i m looking for a simple Pathfinding Code. Can anybody help me with this. I wanna Isometric path finding code (if possible in VB). That will probably complete my Iso Engine.
SamRock
sammy
SamRock
Which version of VB?
I would suggect A*, google it and you will find a few hits.
Nice coder
I would suggect A*, google it and you will find a few hits.
Nice coder
Click here to patch the mozilla IDN exploit, or click Here then type in Network.enableidn and set its value to false. Restart the browser for the patches to work.
It''s not going to matter that your game is isometric because an isometric tile map is exactly the same as a top-down view tilemap (just a grid) except it is rendered differently.
-----------Autumn Fog - A 2D Action Wargame
I made a horribly slow A* pathfinding routine in VB three years ago. If you decide to implement your own routine, make sure you keep track of how you create new and delete nodes of the search graph. It can easily eat up CPU time if not managed efficiently (like mine). I''ll describe below how to implement a guaranteed inefficient pathfinder .
I had less experience back then so I made each node a class (if I knew better I''d made it a type since there were no member functions anyway). This meant that I for each new node had to make a set statement with the new keyword. Ughh. The open and close lists I saved as huge dynamic arrays, and for each reallocation I used the preserve keyword (!!!). For the test map I simply just a monochrome bitmap with black as totally impassable and white as totally passable. (Yes, it defeats the purpose of A* but I could have done a map with different costs should I have wanted to).
When I finally got it to work the actual graph-building process took ~6 seconds. I actually even added a redrawing function to fill the pixels (tiles of "map"), that had been mapped. It was a nice fill function . Then when I was to trace the goal back to the start as the path I had implemented a very inefficent system: My nodes did not remember their parents. It meant I had to search the entire closed list each to find the parents of each node and to compare their costs. Needless to say that process took ~90 seconds...
Now you know how NOT to do it.
I had less experience back then so I made each node a class (if I knew better I''d made it a type since there were no member functions anyway). This meant that I for each new node had to make a set statement with the new keyword. Ughh. The open and close lists I saved as huge dynamic arrays, and for each reallocation I used the preserve keyword (!!!). For the test map I simply just a monochrome bitmap with black as totally impassable and white as totally passable. (Yes, it defeats the purpose of A* but I could have done a map with different costs should I have wanted to).
When I finally got it to work the actual graph-building process took ~6 seconds. I actually even added a redrawing function to fill the pixels (tiles of "map"), that had been mapped. It was a nice fill function . Then when I was to trace the goal back to the start as the path I had implemented a very inefficent system: My nodes did not remember their parents. It meant I had to search the entire closed list each to find the parents of each node and to compare their costs. Needless to say that process took ~90 seconds...
Now you know how NOT to do it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement