From: John E. <ja...@zh...> - 2002-02-21 09:48:37
|
Jan Ekholm wrote: > Nice. :) I think there are a few similar mistakes in my code too that > cause unnecessary slowdown. Especielly when drawing the map I think there > are a lot that could be improved using some magical Python functions. Nice thing about A* is that its a well understood algorithm. Makes it much easier to notice problems. > Btw. how do I compile the .c file? I haven't used distutils for anything > own (never done a C extension)? Copy your python's Makefile.pre.in into the dc_module directory. It can be found (on debian) at: /usr/lib/python2.1/config/Makefile.pre.in Run the command: make -f Makefile.pre.in boot Then run: make Copy the dcmodule.so file into the ai directory. Not pretty. But that's why the python versions of the algorithms are there. :) > >You want to use it??? Ok then, it needs a bit more re-structuring before > >it will be useful. The quicky class wrapper I gave it has a big flaw... > >The static terrain cost map is generated for each path in the way I had > >envisioned using it. > > Sure, why not let the player use the pathfinder is he/she wants? Simpler > than clicking out a lot of waypoints. I agree completely. > >The way I was thinking it could be used was to create a path object for > >each path, and to delete it when done. I've gotten in the habit of > >making disposable objects while using Zope, and it seemed appropriate. > > Or a list of path objects to describe a full path? One object contains a > destination, nor much else. A list of these describe how to get to an > ultimate destination through a series of intermediate destinations. > Something like that is what I'd like to use. I could then create a new > type of plan that has such a path instead of a single destination. At the moment, you create the path object and run the calculate method. It returns the list of points (x,y coords) of the path. > >I've done several test with this and don't seem to get any speed boost. > >I think any speed gained was lost in the overhead of the additional code > >needed for the map version. I had added a line like this: > > > >distance_cost_l = map(distance_cost,new_points,[p1 for p in new_points]) > > Hmm, you just get another for-loop for feeding the points to map(). I > can't really think functionally, so I have no idea as to what it actually > does... I think I could re-structure the code to take better advantage of map(). But I'm thinking enough is enough for now... it seems fast enough. In python, map() can be faster as it works sort of like an inlined loop. It only requires locating the C function once and inlines all calls to it. It can really help in some situations. > Ok. Currently I think it's no problem if the pathfinding takes some time, > as long as it stays under 1s or similar. Otherwise the UI starts to feel > sluggish for players that use the pathfinder for moving units. There are many other optimizations that can be done, just not in a general manner. We can easily make A* many times faster. No worries. > Ok. I need to dig into the code a little bit and find out what the terrain > map actually does. :) You mean my terrain cost map or the one in civil. Mine is a simple list of lists (x,y) storing terrain costs. I average in all the triangles into one number. > If you need some data in, say, the Unit or Map classes just add it. It's > no problem. That's what they are there for. Hmm.... I might add the terrain costs map to the Map class. Could even make it a lazy cache that way. -- John Eikenberry [ja...@zh... - http://zhar.net] ______________________________________________________________ "They who can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --B. Franklin |