Jump to content


WFG Programming Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


wraitii last won the day on October 29 2017

wraitii had the most liked content!

Community Reputation

1,005 Excellent


About wraitii

  • Rank
    Space Poodle

Profile Information

  • Gender

Recent Profile Visitors

2,105 profile views
  1. It would make the code much easier to understand though :p
  2. Hey, What you've noticed is accurate, and somewhat known (mostly by me I guess): The rendering is draw-call bound and slow, the pathfinder can be slow, and the Javascript main loop is very slow (we use it for most gameplay stuff, which is why it's slow). Unfortunately, profiling spider monkey accurately is very difficult. There are few tools, and almost none that can be integrated with an existing profiler. What you'd see in OSX's instruments and I assume VTune are memory addresses, which are actually JIT-ed code and/or spider monkey code (mostly the former). With a lot of hard work, using JIT debug output and the trace logger, one might create debug symbol-like structures to document these, but it seems not super useful. What we did in the past (and probably will in the future) for profiling JS was using our internal profiling, which does have an overhead but can give you an idea of what's going on. _Overall_, though, we've already optimised most obvious bottlenecks. The remaining bottlenecks are not trivial to fix, and JS is somewhat of a lost cause.
  3. What you're seeing there is just the polygons used for rendering. However we do have a "terrain tile" system, which are the same size as every ground-rectangle you see above. Pathfinding takes places on a 4x more precise "pathfinding grid", which has 16 squares per terrain tile.
  4. Erh, my patches might improve stuffs a bit the whole concept remains fundamentally flawed in my opinion.
  5. I think implementing a Vulcan backend is a good idea, and it could support windows, linux and OSX (through MoltenVK). I'm not extremely up to date on the details of the renderer, but in principle we will need to keep an OGL renderer too so that older hardware is supported. My main question is if there are libraries that could allow us to implement a single low-ish level renderer and that takes care of switching to OGL, Vulkan, Metal or DX.
  6. The pathfinder threading is safe because computing paths is a pure operation (by design) and all paths are computed in between turns in both the threaded and the non-threaded version of the game. If you compute paths in the background while also running other Simulation operations, then things might get weird. The problem is that the Pathfinder Grid isn't actually copied to make it 100%, structurally thread-safe. IMO that's not a huge issue but we need to be careful.
  7. "Ridiculously complex" is a bit of an overstatement. None of the code is super easy but there's nothing too unexpected - except for unitMotion maybe. The pathfinder is actually 5 components: The obstruction manager handles collisions (for unitMotion - not the pathfinder proper) and rasterising static obstacles (like buildings and terrain) and keeping track of units. UnitMotion handles the actual movement logic. It's terribly written at the moment (buggy, unclear and inefficient at actually moving sanely…) and I have a patch (I think it's D13) fixing it. On top of that, we need to change the architecture to a Data-oriented design - I may or may not have a patch for this, can't recall, but I've definitely done it somewhere. The hierarchical pathfinder handles accessibility (and could be used to handle high-level pathfinding, but it's not really much faster). It creates big "regions" and connects them. That's where flood-fill comes in. I have a patch (D53 I think) that improves its performance. The "long-range pathfinder", AKA the A* JPS pathfinder, is pretty well optimised (aka making it much faster would take too much work). It can create a path from navcell A to navcell B using the rasterised map of the obstruction manager - so no unit avoidance here. The "short-range pathfinder", aka the vertex pathfinder, aka a graph pathfinder, is used to walk around units. It's triggered by unitMotion when getting stuck in some special circumstances. It creates on-demand an exact map of all units and A* on that. Nothing is threaded right now but two things are 'easily' threaded: the long and short paths computations. These are currently done between turns, and could be parallelised. Doing it _super_ safely would mean rewriting some stuff, doing it kinda dangerously is very easy and I have a patch for it on Phabricator somewhere. I also have (this one indeed very WIP) patch for unit-pushing, which removes most of the need for the short-range pathfinder (it's still useful to keep around for stuff such as finding your way around a resource). The short-range pathfinder might be optimised for the common-is case of several units close together since we could reuse the graphs across computations if those are in the same region - but it's not trivial to do correctly. The other patches are pretty much finished and ready to merge, they just need some review and some more testing.
  8. It's not all it takes I also need to get my 0 A.D. groove on and I haven't got it back yet :/ . Anyways I think I have a 200$ amazon gift card lying around somewhere so don't worry.
  9. Well technically it's because I'm using a custom setup so I can't bundle the game - why am I using a custom setup? Because my SSD is too small.
  10. I do have a custom setup using brew for most libraries, but I still use the script for some because it doesn't work otherwise. It's also a super-hack and brew is very much not nice if you're aiming at using the same versions across multiple computers as it's not always possible to access a specific version.
  11. There's also some good looking work with the support of Valve https://vulkan.lunarg.com
  12. Such as https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative, which does have an active GitHub : https://github.com/gfx-rs/portability, though obviously it's not finished. Haven't dug much beyond that.
  13. The zipped folder worked, couldn't get the pyromod detected either.
  14. Reproduced, can confirm that your mod fixes the issue.
  • Create New...