Jump to content

Sylvain Gadrat

Community Members
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Sylvain Gadrat

  • Rank
    Discens
  1. The current heuristic function already do a pretty descent job by avoiding square root. Optimizing only the heuristic function have it's limits. While it may be possible to improve it a little, dividing by 16 the time consumed by the current pathfinder, and being able to change current tiles to 4x4 little ones, seems unrealistic if we want to only change this function. And beware, sacrifying the heuristic quality for speed can leed to far worst pathes than ignoring terrain cost. Note that it is just for calculating pathes. Camels will still be speeder on sand than on grass. Simply if a camel
  2. Wooh ! Impressive tool ! Great work ! Just as a reminder, please keep the "EngineProfiling" wiki page up to date when integrated. It is an awsome wikipage While talking about optimization, on the first post you talk about optimizing the pathfinder. Do you think your changes will impact the long pathfinder ? I am still musing about implementing hpa* whereas I terribly lack time. Note that it is just a question, not a request, your work is awsome and I lack time
  3. Just throwing an idea : A big clue to know if the path may need to be recomputed is to check if the pathfinder modified it's abstract maps. It can be done by checking if "CCmpPathfinder.m_Grid->m_DirtyID" changed since last time you check it. Note that it is not perfect : - It is not triggered, you need to check periodically - m_DirtyID is updated only if the pathfinder where asked to compute a path, so it can be unchanged while the line is invalid (until something ask for a path) (*) - m_DirtyID can be changed due to a modification on the map not influencing your path (*) Note, there is
  4. That's because all tiles on the border of the area could be good exit point. Considering a unit travaling on sand and grass at same cost, here a picture with two acceptable path (brown : common ; blue : to the last blue dot ; red : to the last red dot) Both path tarvel from the same area to the same one, are going through the same ones, but dont exit but exit the big sand area from different points. Maybe limiting transition between areas to only one point, generating a high level graph and runing some kind of Hierarchical A* could be a good enought approximation.
  5. Thank you for the wiki page Philip, it is exactly information I needed. So, I played a little more with the Area optimization. While I have to continue to tune performances to be sure, I begin to have serious doubts about de viability of the solution. Let me explain why. First, I have to correct the second graph of my first post, the one showing tiles considered by the pathfinder. It presented tiles that could be used by pathfinder but, in the example, only the ones used to compute the brown path impact on performances. Heres the graph with only really used tiles : The first goal of areas was
  6. Successfully built, ran and played at revision r9956 with boost 1.47. Thank you Oops ! Sorry ! Happy to see that you fixed it anyway.
  7. Attached to this post : the big output of "thread apply all bt full" I suppose that the only interesting thread is the main thread (Thread 1) as pyrogenesis get stuck in it. I compiled with "make CONFIG=Debug" but some values still shown as "<optimized out>" And a clue that does not appear in the attached file : * 82 % of time is spend in "CParticleVarUniform::Compute(...)" itself * 15 % of time is spend in "boost::random::mersenne_twister_engine<...>::twist()" called by "Compute()" * 3% in the other componants of my system gdb_output.txt
  8. Hello, Recently upgraded my system from boost 1.46 to boost 1.47. Thank to svn revisions r9905 and r9907 it compile well, but get stuck when starting a game. Downgrading to boost 1.46 fix the problem, the compatibility patches don't hurt anything. I use ArchLinux's packaged boost version. The code seems to stuck in the particles engine. I have no more information for now, but if needed I'll can later reproduce and give logs, exact stuck location, core files,... Note : it is not impossible that the packaged boost is buggy, if so, sorry for the dummy bug report. System : * Archlinux * Nvidia's d
  9. Ok, I succeed to implement a functional version, now I would like to profile it. Here are some questions about profiling. I saw a macro named "PROFILE( xyz )" which seems to be perfect, except that results are not printed. Is there some documentation I missed that indicate how to have such stats printed ? Is there a way to start 0.A.D without rendering ? I suspect it to disturb callgrind and sysprof and I focus on pathfinding, I don't really need rendering. What's are your habits for profiling ? Your favourite tools ?...
  10. Hmm, it can be possible by creating special areas containing a grid where uniform areas are inefficient. It can improve the worst case scenario, but it will be more complex to implement. So lets wait to see if such mix is needed before thinking of implementing it Talking about five tiles per area, I'd think of an average value obtained by : <number of tiles> divided by <number of areas>. Sorry if it was not clear. Rectangles should work very well, thanks to point that. My idea was that an area is useful only if it has a maximum of "inner tiles" (the skipped ones by A*). So, avoid
  11. Hello, I am a programmer and I recently discovered that playing with 0.A.D's pathfinding logic on my spare time is incredibly fun. While experimenting I thought about a way that can sligthly improve the pathfinder cpu usage and memory consumption. So I'll use this topic to outline the idea, feedback about progresses and get some ideas from you. Disclaimer: I am not expert (actually, not experienced at all) regarding 0.A.D's internals, pathfinding theories nor video games programming in general. I do it to play dolls with units on my spare time. I have not a lot of spare time. 0.A.D needs more
  12. Hello, I am a programmer and I spend a little of my spare time to play with 0.A.D's pathfinding logic. I currently work on determining areas of homogeneous terrain tiles to speed up the long pathfinder. Such areas allow to not run A* on each tiles, but just looking at the ones necessary to go from an area to the other. For the moment my code is not mature at all. Understand : hacky, buggy, don't respect coding styles and slow down performances. But if you are interested by such optimization/research, I can easily create a topic to give feedbacks about progresses. If you don't specially care I'
×
×
  • Create New...