wraitii

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.

Erh, my patches might improve stuffs a bit the whole concept remains fundamentally flawed in my opinion.

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.

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.

"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.

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.

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.

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.

Can you provide a GitHub repo?

This is an open question for @Itms

Haven't really been able to notice so, which isn't that surprising, moving from 38 to 45. 45 onwards will have spectre mitigations which will slow it down but maybe other gains here and there.

There's also some good looking work with the support of Valve https://vulkan.lunarg.com

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.

Following the upgrade to SM45, I've been looking at profiling Spidermonkey (I've also been considering what we'd need to update to HEAD, i.e. 62, and that sounds somewhat doable) This has been a long-standing issue. We do have ways to do it, Engine.ProfileStart and Engine.ProfileStop, but they: can't use RAII so you need to call the stop before any return, which is troublesome Probably incur high performance penalty, which makes fine grained profiling difficult Can only tell you about what you expect to be slow Spidermonkey has an API to do very precise logging, the Tracelogger. There is an existing tool to analyse this but it's fairly unreadable. However, a script allows outputting things that can be easily converted into a profiler2 parsable JSON file, and then we could use Profiler2.html to read it. The problem here is that the Tracelogger is extremely fine-grained (function level), so it outputs ridiculous amounts of data in even a few seconds. There's internal API support for enabling or disabling that, but we'll have to patch the JS API to do call it ourselves. What I'm envisioning is having an Engine.JSProfileStart / Stop that enables the tracelogger output, call this in fairly high level functions (such as Timer.js::OnUpdate) and then see what this outputs.

The zipped folder worked, couldn't get the pyromod detected either.

Reproduced, can confirm that your mod fixes the issue.

Hi, could you give your us computer specifications and which version of OSX you are using?

Ships require actual pathing, planes have no collision whatsoever. This is a very different situation. Pathing on a curve is quite annoying and slow. Pathing on a realistic ship curve is extremely annoying. Also our maps are ridiculously small and ships are ridiculously big.

This is a discussion we've had many times, and we don't have at the moment a coherent vision on the features we want before we stop calling it an Alpha. The list above fitted the 2010-12 vision rather well, but it requires substantial programming work to complete and may be unfinishable. Advanced Ship Movement is possibly impossible for a 0 A.D.-like game, Charging is technically very difficult, directional attack bonuses also require substantial technical changes to work correctly - unless it's entirely tied with formations, which is then a feature of its own to finish. My personal wishlist, which is mine only, is basically summed up by "Sufficiently efficient pathfinder".

I agree it looks a little too blurry perhaps, but it'd be nice as a setting. It'd be nice to have a settable "low" and "high", to better simulate cloudier weather indeed.

I'm planning to try and review this, in general it's better to have unreviewed patches than no patches at all of course.

I think going far forward we should probably try to find a library abstracting over vulkan, metal, and other low-level stuff, and use that. Apple seems determined to never support OpenGL correctly, sadly.

Some grass and some trees use alpha blending (necessary for making leaves look halfway good). This means we render them twice, and once with transparency enabled. Furthermore, the game has no real instancing (we merely sort stuff in a semi-clever way) so lag is to be expected, we start doing a looooot of draw calls. edit: btw you can disable the alpha blending somewhat easily, and you'll see that our leaves are horrible without it. There might be some trick to that, but I don't know it.

Our current long-range pathfinder cannot handle paths with different walking speeds. It could be adapted, but at a performance cost that's likely to be unacceptable, sadly.

Possible with https://code.wildfiregames.com/D281 iirc. Not possible, nor intended, with the upgrade code.