Leaderboard

A picture on some changes that have come with the units, which include more accurate armor textures from the 13th century to late 13th century.

Hyrule's Spartans are ready:

Hello! Thank you for the detailed overview! After digging a bit thru the code today, I did notice the hierarchical pathfinder, and wondered a bit about its use; your post clears that up a bit! I haven't looked much at the AI stuff yet ... but since I'm already into the pathing, maybe I'll stick with that for a bit. I did notice some issue where units would continually try to go somewhere when they can't (for example, having a large group of workers go to an area without formation). They'll just continually pace around trying different angles to get there. I have some ideas on how to fix this ... just haven't gotten to it yet, since I've been working on / getting familiar with path-finding in relation to the extended corner idea. With that, I do recognize those concerns there, more vertices would slow it down, but it maybe a case where having those few extras are better - since if a 'successful' path can be found faster, then overall there 'may' be less computation. That bug you mention seems like it's the same thing I noticed (where they can't get somewhere, but keep trying). Maybe I'll give that a shot next. Aside from that, the OpenGL instancing thing mentioned ... is that just with regard to supporting older versions rather than updating?

@Stan` I think some of your info is a bit outdated. This isn't that accurate to be honest (sadly, how good would that world be) At a high level, the renderer is draw--call bound (heavily so) because we aren't using any instancing - because we support OGL that doesn't support it. They "why" on this will lead to a flamewar. The GUI rendering is particularly unoptimised, since we don't even render similar items together. At a high level, the simulation is pathing + JS bound. The AI itself is a slowdown, but it doesn't increase over time that much. I have ideas on how to improve it, but surprisingly perhaps my idea is actually to unthread the AI. The reason for this is that the AI is slow mostly because it needs a copy of the simulation state every turn, which is slow to create, which it wouldn't need if it lived in the same JS container as the simulation itself. The pathfinding is slow. There are 3 pathfinders. The hierarchical one is high level and fairly fast. The long-range pathfinder is JPS and fairly fast on its own, though it searches very large grids and can still take some times if enough calls are made on a given turn. Then there is the vertex pathfinder, which isn't fast. I think it's also kinda broken (see D1908). These 3 pathfinders are used from CCmpUnitMotion.cpp, which I am currently in the process of rewriting. The pathfinding calls should be threaded (D14 - which as far as I know does not leak memory, it might have done in the past but the current revision should work), which will help. We should also implement unit Pushing (D1490) to reduce the usage of the vertex pathfinder. After that, it's just optimising stuff and we'll get into 'difficult' territory. The rest of the simulation isn't extremely fast either. JS code is slow, and from profiling I would say about as slow as the pathing itself. There's just not much that we can do here except move some of the slow stuff to C++ and hope for the best. Spidermonkey, our engine, needs to be upgraded and hopefully things will get a bit better in the future. Finally, our Entity-Component-System is also rather unoptimal, using maps in a lot of places and not really being optimised for cache misses. ---- Your extended corner thing is an interesting idea, though one needs to consider that: - adding more vertices slows the vertex pathfinder further - there is a bug that we always try to go for the nearest point on goal with the vertex pathfinder, even if that is unreachable, which can lead to stuck-ness. Maybe it's better/faster to fix that instead.

Ah, ok cool! I started playing around with VertexPathfinder.cpp ... and came up with this: It's a little modified from the concept above, just extending the corners out, and adding those as extra vertices to be considered in pathfinding. The result, seems to be that units can get to their target a little faster, and actually seem to have access to more sides (that last lady there got a little confused, given she was on the other side of the building to begin with, that's ok I guess... but overall the rest were better I think). I might play around with these changes a little more ... just to see how it affects a long-term game. But from what I can see it looks to be some sort of improvement! What do you guys/gals think? EDIT: I changed how the new points are created, basing it off of the existing buffer based on unit clearance, and a constant. Also created a Diff for it (hopefully it's created decently well) https://code.wildfiregames.com/D1911. Thanks again, Crynux

I used a tool called ApiTrace (https://github.com/apitrace/apitrace). If you're using Linux, your distro might have a package for it. What takes about ~3500 calls is the GUI when the game hasn't started (the lobby, main menu, settings screen, etc), so I misremembered. Acropolis Bay (2) map needs about ~14500 calls (before any user input of any kind, so default camera, units and GUI elements) After selecting a Citizen Soldier (because they have the most complex GUI) calls go up to ~21500 If I disable the GUI, Only about 11500 calls are needed. Frames with a citizen soldier selected in red. Frames with a disabled GUI (Alt + G) in green. The .trace file weights 240MB, I can upload it somewhere if you want to have a look at this specific file. There is also this: https://trac.wildfiregames.com/attachment/ticket/5422/out.svg It is a interactive flamegraph, but trac's preview isn't interactive at all. Click 'Download in other formats: Original Format' and then open the local file with an internet browser. After that is done, click elements to zoom in, hover to obtain aditional info.

Hello! I recently started playing 0AD again, and I must say, it's looking good! One thing I noticed is that during game-play, in the late game, everything slows down (2 humans vs 2ai; 300 pop cap). I haven't looked at any performance metrics yet (I may here in my next game), but I'm interested in looking into and possibly working on some stuff to help speed this up. From what I've gathered, there are 2 issues (please correct me if I'm wrong): 1. The Renderer is somewhat bound by simulation. 2. In late game specifically, the AI is the main slowdown; partly due to pathfinding, and use of a single thread. With that in mind, I've looked thru some of the code, specifically the code here : https://trac.wildfiregames.com/browser/ps/trunk/source/simulation2/components/CCmpAIManager.cpp It looks like it has been partly setup to use threads, but doesn't yet? I've also read that there's some concept of moving some of the AI related JS code to C++. Anyways (I apologize if this seems a little scattered), I was wondering what the current plan is for this. I noticed there are a few performance related tickets open, and some have been worked on. Really, I'm just looking for maybe some clarification of where to go from here (specifically, if there are known problem-areas, I'd like to be aware of them before-hand, knowledge sharing on these things is important). I have some time that I could dedicate to this ... and I'm very interested in performance improvements. On a side note, with conversion of some of the JS ai code to C++, has any design or some other outline of what 'needs' to be in JS vs C++ been outlined? I think it'd be valuable to set some rules or guidelines as to how much should be available in JS. To be honest, I don't have very much experience with AI programming, but at a glance, I believe any of the heavier computations should be strictly implemented in C++. An AI should really only contain decision logic... (I haven't looked thru the Petra code yet so if this is already the case, that's awesome!). I think that's it for now. I really appreciate any pointers on this, or clarification. If anything above is dumb or obvious, please point it out ... I really only started looking into this in the past few hours ... but figured it may be worth-while to make a post, in case there's some info out there that I'm missing. Thanks in advance! Crynux

fair but when I'm not productive I don't get that sweet sweet dopamine

Looks like a very nice tool indeed. Don't hesitate to add it on the wiki! The bottom of the EngineProfiling page is probably the best place for it.

It's a good tool. I'm using it for a while. But it still misses some good features from RenderDoc, which doesn't support our GL unfortunately. We mostly use 1 draw call per each GUI element. It'd be good to refactor it and to use only 1-2 draw call per all GUI.

Awesome ! Very excited to see the buildings !

Sounds like a challenge to come up with a new team of generals every year. But I'm 'confident' they'd find a way to make customers pay...

About a year ago I wanted to change the code so that it uses a seeding animation for building fields just to discover that we don't have such animation xD

Well we could use Godot Make the game a gdnative plugin and rewrite things as we go. Yeah might very likely be. I'm using what I can gather from the wiki and a few recent threads Thanks for clarifying things. a bit.

Berry bushes. https://en.wikipedia.org/wiki/Rubus_glaucus https://en.wikipedia.org/wiki/Rubus_adenotrichos is a highland fruit.

.

I did not know that my ancestors were 2 meter Aryans. Interesting. That explains the envy of Guatemala xD

That would be @wraitii's domain

Hmmm, thanks to everyone for the posts/pointers! I started poking the code, seeing what I can observe that 'may' contribute to slowdown. At first I enabled some code to draw paths - these are commented out by default, so I just commented them and enabled the overlay. From there, I started testing moving units around, and started playing with some 'usual' cases. What I found is that if you have a good few units tasked to an area (say 20 or so workers), and a building is parallel (with respect to it's bounding polygon thing [the blue lines on the overlay]), in some cases you'll get a "unit bounce", where they'll continually bounce around, looking for paths, since there's never a space within the 4 points available (the right two corners of the stone grid polygon, and the left two corners of the storehouse grid polygon). This can be seen here: By contrast if you rotate the building 90 degrees (excuse the rubble, had to try a second time since the first angle wasn't great), the points now being outside of the vertical (relatively) min/max of the right points of the stone, helps the units resolve their paths more quickly, since they can now access the bottom and top sides of the stone. As seen here: This may not cover every case of unit pathing ... but in cases where you get a good few units tasked to an area, and they just happen to line up, I could see how this could cause some slowdown. (sorry if the video too blurry... I made them small clips, and I'm not sure how to make them use their original size on here). With that in mind, I'm thinking a solution to this would be to add some "satellite points" of which the pathfinder could use to resolve the paths more easily around corners; maybe something like this (orange areas are where units would be expected to 'bounce' if no other point of path finding was available): Not sure how 'possible' that would be ... well, I guess anything is possible. But I'm not sure how well that would fit into the existing setup. Just an idea anyways. Thoughts on this? Thanks, Crynux

Ficus : more common species in mayan world http://www.maya-archaeology.org/FLAAR_Reports_on_Mayan_archaeology_Iconography_publications_books_articles/57_Economic-potential-for-Amate-Ficus-trees-in-Guatemala-FLAAR-Reports-Nicholas-Hellmuth.pdf there is a list of speciment of Ficus tree (oaxaca in the map.) and the rrst of Mayan World. ficus goldmanii is in many places of mesoamerica. https://en.wikipedia.org/wiki/Ficus i give the list of mayan Ficus. https://en.wikipedia.org/wiki/Ficus_insipida Ficus Padifolia. https://en.wikipedia.org/wiki/Ficus_pertusa Ficus petiolaris or Amate Amarillo(yellowish). https://es.wikipedia.org/wiki/Ficus_petiolaris Ficus pringlei S. Watson Ficus Naxima mill. this is similar that I found. Ficus Ficus Citrofolia Brosimum Alicastrum (most common in copan ruins) Ficus Segoviae same as insipida. Ficus Ficus Aurea Ficus Castilla Elastica for example from all the species of flora in Copán the top list are the following. you can see some of them inn Jurassic Park movie.

Famous last words.

Looked again: Found the animations' master commit: https://trac.wildfiregames.com/changeset/18970 - all those animations are in there. A month later Enrique commited this: https://trac.wildfiregames.com/changeset/19061 - I believe most of those those animations come from this file: https://trac.wildfiregames.com/browser/art_source/trunk/art/meshes and animations/skeletal/animations_and_meshes_mainfile.blend Animations_and_meshes_mainfile.blend doesn't include LordGood's animations. So, I think people just kinda forgot to actually include them in the game.

@Crynux there is also and if you want more details on what each release was implemented (https://trac.wildfiregames.com/wiki/Changelogs)

drag last column to include players 11 to 21, same formula TP/TM <- 1

Productivity is a concept engraved in our minds by our corporate shills overlords to make us work more for that next quarter earnings report. /s

@wowgetoffyourcellphone What do you think of having the Agrianian peltast become more hellenized as it gets unit promotion? P E L T A S T E S A G R I A N I K O S (Agrianian peltast)

@HMS-Surprise in chart week#5 my killed were 127 not 71

show em magellan

Don't want to throw Larissa in there too? Maybe your list is exhaustive enough. I think the city name aspect of this mod would be great as its own standalone mod. Would probably get a lot of downloads in its own right. @Monder87

oh my god what is that ground texture

It's just like 0AD's development process