real_tabasco_sauce

Ok so the way I do it is this: in phabricator(https://code.wildfiregames.com/D5282), click "Download Raw Diff", this will open a plain text file in your browser. Copy the contents of the file navigate to your SVN directory Paste the contents into a new file with the extension '.diff' type 'svn patch ABC.diff' now at this point, some files should print to console with 'U' for updated. bigger patches might have conflicts, but that shouldn't be the case here. Since this patch modifies the engine, you will need to also build the game: https://trac.wildfiregames.com/wiki/BuildInstructions

ok, well the patch is pretty much done and working: https://code.wildfiregames.com/D5282 if anyone can apply it (and build) to test on their system that would be great!

After a couple of combat demo huges, it seemed a little faster, but that's just anecdotal. Also, i don't know if my build was making use of the builtins, so it may be better or worse than what I experienced for some players. I uploaded the latest version (with the isqrt64() replacement).

ok, I got a 64 big equivalent working, and I tested every isqrt() call against isqrtEst64(), and not once was there a difference. Do you think I should just wing it and replace the old isqrt()?

I achieved this in my non-random buildingAI experiements. Tbh I think a faster fire rate would be fine too as an interim measure. This would be of interest anyway for onagers. I could do a round of updates at some point to address the points made here.

Ok, so I was checking the isqrtEst64 against isqrt(), and they are exactly the same when P = 0. However, because I am using SLD2's "SDL_MostSignificantBitIndex32(n)" to get log2, large integers overflow. u64 sqrt_lo(const u32 n) noexcept { u32 log2floor = SDL_MostSignificantBitIndex32(n); return (n != 0) << (log2floor >> 1); } u32 isqrtEst64(u64 n, u8 P = 0) { u32 est = sqrt_lo((u32)n); u32 b = (u32)n; ... The nice thing is the larger values don't occur in fights, I guess they happen in map generation and pathing, probably a lot of other things. As far as I can tell, the patch is working, but I am sure there are more improvements possible. So @Stan` I would need to come up with a 64 bit equivalent to SDL_MostSignificantBitIndex32(n) in order to see if this sqrt approach could be faster than the current isqrt().

yeah ive done some tests and it works pretty well. I need to set up the precision value in the templates, and then test for OOS. Then there's also the performance side of things.

@chrstgtr 2 developments re sniping: https://code.wildfiregames.com/D5282 https://code.wildfiregames.com/D1971

Wow thats huge. I tried replacing the isqrt64() in FixedVector2D.Length() with my isqrtEst64() with P=1 and got teleporting units and a game crash. In theory, the new sqrt with P=1 should be exactly the same as isqrt(), so maybe Ill need to compare the two to figure out what happened above.

Yeah, i think slightly worse, but its hard to say. It would be great if @wraitii could profile it. I modified EntityDistanceOrdering, which is used by all the different range queries, so its possible this version could be used in less locations. Also, I do whole division after finding the square root: u32 r2 = isqrtEst64(d2,P)/(100000*P); but it might be faster to find the sqrt after whole number division.

Just doing a couple rounds of combat demo huge, I found roughly 13-14 minimum fps go down to 11-12fps. The video was at P=10. I added a pseudorandom tie breaker so the fighting looks like this now (P=3): p3tiebreak.mp4 I think 3 is ideal for archers. I bet 2 would be good for slingers/han crossbows and 1 for skirms, melee units. I suppose the next thing to do would be to figure out how the unit templates can determine P. I guess it involves modifying the UnitAI schema and adding P as an argument to the query setup calls in unitAI. Also, if someone wants to apply the patch and test, that would be awesome.

Ok so it works now, the skiritai are not sorted. Square rooting and dividing by 10^5*P pretty much delivers what I showed in the tables above. The video is with P=10 to exaggerate the effects. I wonder now if a tiebreaker would be necessary for more common cases like P=1,2, or 3. Something like a random shuffle if the low-precision distances are "the same". p10.mp4

The game uses integers for its calculations, because floating point are note reliable on different machines, so we need to have the exact same values on each machines else the game will go out of sync pretty quickly. So I suppose what you are seeing are decimal values represented as int. Ok, I can do it if I can just figure out how the integer representation of float is done. Then I would just need to add the necessary arguments to pass the needed precision value up to the square root. I suppose EntityDistanceOrdering would need to accept P as a parameter, and then queries that don't need so much precision could use the alternative sqrt. if isqrtEst is faster than the current isqrt, i guess it would be fine to just use isqrtEst with a P of 1. With p=1 the result is always floor(sqrt(x)).

Ok so the square root function works, its just the numbers involved are still huge. So that's why there is no obvious impact on the game. I thought meters were the fundamental unit of distance, like for entity_pos_t instances, so how does the square of the x component of a vector get this large? 13035623883809. maps are maybe between 1000 and 10000 meters across, but the square of these numbers doesn't come close to the above number, which was collected from some archer fighting.

Well, the primary goal isn't performance: it is to evaluate closeness with less precision to avoid overkill. However, if it is faster than the current sqrt that would be cool. Ok thanks so much for the help! The function is being called and everything, but either the square root doesn't happen at all, or the fixed datatype is remaining fixed. I suppose it could also have to do with u64 vs u32

@Stan` will all the builds have access to this in SDL2? https://code.wildfiregames.com/source/0ad/browse/ps/trunk/libraries/win32/sdl2/include/SDL/SDL_bits.h#:~:text=SDL_MostSignificantBitIndex32(Uint32,return msbIndex%3B it already does what I need but using u32 instead of u64. my build is working fine, but my changes make absolutely no effect on anything.

this is what I quickly threw together for a scythian 'trade settlement.' The idea is it is like a market you can put in neutral territory like a roman army camp, and train mercenaries from. I thought it could nicely represent some of the sedentary subgroups of scythians.

In this case, stone throwers refers to both catapults and onagers. Although there may be other cases where the terminology could be better.

Thanks @Vantha and @guerringuerrin, the changelog page looks great! version 9 is out right now!

@guerringuerrin I did one more change to increase the temple of Amun capture points for kush. I'll test the the mod put together a decent bit. Lets set the date for this Tuesday, 6/18. When you update the MR, i'll make a testing version and if all is well I'll publish the next version Tuesday.

That looks great! Thank so much @guerringuerrin

ok, I seem to be getting some bad errors when building "release" in VS. Basically, it seems a pyrogenesis process was started but unable to do anything, and when this happens I have to quit using taskmanager since the whole desktop is frozen. this was revision 28109

k, I just did that test and it seems ok. Yeah I can tell that the different balancers are being used on their respective maps. Before I get this next version out, I'll ask someone to do some more extensive tests with me.

Hi @Duileoga, These look really good! @wowgetoffyourcellphone and I are interested in developing these nomad civs for vanilla 0ad. For the xiongnu, I really like 3 of your buildings for the role of "royal yurt". Also, the barracks, stable, and market would do great. I see you have a lot of permanent buildings too. I have tech for the xiongnu called "han diplomacy", and its basically meant to unlock some of the influence from the Han dynasty. So for the dock, it would be really cool to start with a simple yurt-based boat yard (basically what you have here, but with a small boat frame or skeleton on the ground near the yurt), and then upgrade to the dock here with the tech.

@guerringuerrin the merge requests are all in: https://gitlab.com/0ad/0ad-community-mod-a26/-/merge_requests I just need to check the maps compatibility with feldmap. I suppose I could just copy over the resource balancer so they are identical and then in theory, players could apply the mods in either order.