Re-Release A27 or RC builds?

[Stan`]

3 minutes ago, Seleucids said:

Since you mentioned selection, there is something strange I noticed: if I draw the selection area from top left to bottom right, the selection works as usual. However, if I move my cursor from bottom right to top left, I cannot select anything. Not sure if this is related

That sounds like the selection bug of Arch based linux using SDL3 through a compat layer (which is not supported by the game yet)

 

4 minutes ago, Seleucids said:

Although it's to be tested when the area we are drawing over contains many allied and enemy units which will not be added to our controllable selection but nevertheless be considered by the engine.

Do you have evidence for this?

https://code.wildfiregames.com/D1618

 

[Seleucids]

 source/simulation2/helpers/selection.cpp:

	for (CSimulation2::InterfaceListUnordered::const_iterator it = ents.begin(); it != ents.end(); ++it)
	{
 		entity_id_t ent = it->first;
		CEntityHandle handle = it->second->GetEntityHandle();

		// Check if this entity is only selectable in Atlas
		if (static_cast<ICmpSelectable*>(it->second)->IsEditorOnly() && !allowEditorSelectables)
			continue;

		if (matchRank)
		{
			// Exact template name matching, optionally also allowing foundations
			const std::string curTemplateName = cmpTemplateManager->GetCurrentTemplateName(ent);
			bool matches = (curTemplateName == templateName ||
				(allowFoundations &&
				std::string_view{curTemplateName}.substr(0, 11) == "foundation|" &&
				std::string_view{curTemplateName}.substr(11) == templateName));
			if (!matches)
				continue;
		}

		// Ignore entities hidden by LOS (or otherwise hidden, e.g. when not IsInWorld)
		// In this case, the checking is done to avoid selecting garrisoned units
		if (cmpRangeManager->GetLosVisibility(handle, owner) == LosVisibility::HIDDEN)
			continue;

		// Ignore entities not owned by 'owner'
		CmpPtr<ICmpOwnership> cmpOwnership(simulation.GetSimContext(), ent);
		if (owner != INVALID_PLAYER && (!cmpOwnership || cmpOwnership->GetOwner() != owner))
			continue;

		// Ignore off screen entities
		if (!includeOffScreen)
		{
 			// Find the current interpolated model position.
			CmpPtr<ICmpVisual> cmpVisual(simulation.GetSimContext(), ent);
			if (!cmpVisual)
				continue;
			CVector3D position = cmpVisual->GetPosition();

			// Reject if it's not on-screen (e.g. it's behind the camera)
			if (!camera.GetFrustum().IsPointVisible(position))
				continue;

If I interpreted this piece of code correctly, it iterates through all entities in the selection zone, then discards entities which are not valid for selection. I think this decision process will take time, even for non-selectable items. 

I stand corrected on this as I don't fully understand how LoS and Cmp work. 

[real_tabasco_sauce]

1 hour ago, Seleucids said:

profiler2.html 4.02 kB · 2 downloads   

These large regular spikes are interesting. I don't have them even in large games, which you can see in my earlier comments. I would look more closely but I can't open the jsonp. This is without AI right? Could you zoom in on some of the more regular spikes, including the surrounding ~30 turns?

The full hash checks are not logged so they should show up as gaps, not spikes right?

[real_tabasco_sauce]

17 minutes ago, real_tabasco_sauce said:

These large regular spikes are interesting. I don't have them even in large games, which you can see in my earlier comments. I would look more closely but I can't open the jsonp. This is without AI right? Could you zoom in on some of the more regular spikes, including the surrounding ~30 turns?

The full hash checks are not logged so they should show up as gaps, not spikes right?

nvm, thats a graphical profile right? so then those are just the hash checks

[Seleucids]

1 hour ago, real_tabasco_sauce said:

nvm, thats a graphical profile right? so then those are just the hash checks

Yes. I did a bit more of these experiments:

• Singleplayer is generally very monotone with a single frequency. If there is too much to render then the rendering time for each frame is equally long until units die out. 
• Even with LAN game, there exists hashes which come in at random intervals and last for quite long compared to render. 
• Singleplayer experience has almost no stuttering.
• LAN stutters with large quantities or units or high number of commands issued. The same does not apply for singleplayer, where the fps strongly depends on the number of units and their animation, only. 

[real_tabasco_sauce]

All the linux users here have described really low FPS in addition to the stutters. I just have the stutters, with good fps between them. With the stutter fix, do you still get unusually low FPS once you reach p3 like u said earlier?

[real_tabasco_sauce]

1 hour ago, Seleucids said:

Even with LAN game, there exists hashes which come in at random intervals and last for quite long compared to render.

Not the usual 20 turns?

[Seleucids]

8 hours ago, real_tabasco_sauce said:

With the stutter fix, do you still get unusually low FPS once you reach p3 like u said earlier?

With the stutter "fix", in P3 there is visible delay (between input and GUI response) as soon as the phase 3 tech finishes researching. It's almost magic. 

Frame rate wise, the counter drops from 120fps in P2 to 50-60fps. However, in reality (at least from user perspective), it is nowhere near the 50 fps claimed by the counter. Occasionally the frame rate counter does shop dips to as low as 8fps while building barracks in P3. 

Weird thing is, if I push with large army in P2, the stutter is significantly less and frame rate is high. P3 seems to be the culprit.  

These graphs illustrate my frame rate experience:

Multiplayer:

[Seleucids]

8 hours ago, real_tabasco_sauce said:

linux users

Is there something special about the Linux kernel that you have noticed, or is it just a coincidence that most people replying to this thread are Linux users?

I have tried to play A26 on Windows 11, with Atlas playbook. The frame rate on Windows was on average 70% of my Linux values but generally more stable. The CachyOS kernel always pushes for the highest frame rate possible so the fps is somewhat uneven.

Vulkan only deteriorates performance compared to ARB, in my laptop's case. But on a stronger computer, Vulkan performs a bit better. 

[wraitii]

19 minutes ago, Seleucids said:

With the stutter "fix", in P3 there is visible delay (between input and GUI response) as soon as the phase 3 tech finishes researching. It's almost magic. 

Frame rate wise, the counter drops from 120fps in P2 to 50-60fps. However, in reality (at least from user perspective), it is nowhere near the 50 fps claimed by the counter. Occasionally the frame rate counter does shop dips to as low as 8fps while building barracks in P3. 

Weird thing is, if I push with large army in P2, the stutter is significantly less and frame rate is high. P3 seems to be the culprit.  

Could you upload a commands.txt of a game which shows this behaviour? It's possible that there's some tech thing that leads to issues.

[Dunedan]

22 minutes ago, Seleucids said:

Is there something special about the Linux kernel that you have noticed, or is it just a coincidence that most people replying to this thread are Linux users?

If you release cross-platform software the vast majority of feedback will come from Linux users, even if they're the minority of users. That's because Linux users are on average more tech savy and are used to debugging and opening bug reports. So that alone isn't necessarily an indicator for a Linux specific problem.

[Seleucids]

18 minutes ago, wraitii said:

Could you upload a commands.txt of a game which shows this behaviour? It's possible that there's some tech thing that leads to issues.

commands.txt

This is a 4v4 where I suicided due to lag. Hakuna was pinging me to retreat but I couldn't, because the GUI was almost frozen. The counter claimed 8 fps but it was more like 0.8 fps. Within 1 frame update, my pop dropped from 200 to 173. The next frame I saw I was at 130. All I did was order a retreat. 

 

This one is me attempting a 1v7 challenge against AIs:

commands.txt

Edited yesterday at 11:07 by Seleucids

[wraitii]

2 hours ago, Seleucids said:

commands.txt 1.48 MB · 1 download

This is a 4v4 where I suicided due to lag. Hakuna was pinging me to retreat but I couldn't, because the GUI was almost frozen. The counter claimed 8 fps but it was more like 0.8 fps. Within 1 frame update, my pop dropped from 200 to 173. The next frame I saw I was at 130. All I did was order a retreat. 

Replaying this - I don't see an obvious point where lag shows up, it's just slowly slower over time.

There are big lag-spikes from the full hashes - they take about 150ms on my machine and I have a very powerful computer. The biggest lag spikes are GC slices, which take around 350ms on my machine.

Regular sim turns take about 30ms, so on slower computers that's a lot of lag.

---

I suspect the phase 3 lag might actually be from the GUI update, which I won't see by just replaying.

[real_tabasco_sauce]

4 hours ago, Seleucids said:

Is there something special about the Linux kernel that you have noticed, or is it just a coincidence that most people replying to this thread are Linux users?

No, its just an observation I made that the 4 linux players also report worse performance in addition to the stutter. I think there needs to be an a26-a27 profile comparison to put this suspicion to rest.

[Seleucids]

2 hours ago, wraitii said:

The biggest lag spikes are GC slices

What is this and could we mitigate it?

 

16 minutes ago, real_tabasco_sauce said:

a26-a27 profile comparison to put this suspicion to rest.

Question: how can i compile A26 on Linux? There are many errors

[real_tabasco_sauce]

6 minutes ago, Seleucids said:

22 minutes ago, real_tabasco_sauce said:

a26-a27 profile comparison to put this suspicion to rest.

Question: how can i compile A26 on Linux? There are many errors

Well I am linux naive, so I can't help much. But downloads are here https://releases.wildfiregames.com/. Maybe you could try  @andy5995's appimage? https://github.com/0ad-matters/0ad-appimage/releases

its on that page if you scroll.

[wraitii]

1 hour ago, Seleucids said:

What is this and could we mitigate it?

https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

It's linked to our usage of javascript.

As it happens, I also have a diff for this problem: https://gitea.wildfiregames.com/0ad/0ad/pulls/7239

[real_tabasco_sauce]

@guerringuerrin and I tested that a few days ago and it’s an improvement but not nearly as noticeable as quick hash only.

[Seleucids]

Another observation: some civs lag and stutter more than others in P3 and when fighting. 

• Unplayable stutter: Athenians, Romans
• Very Lag: Spartan, Seleucid, Carthaginians, Macedonians
• OK: Gaul, Britons, Persians
• Least lag: Ptolemies, Mauryas, Kushites, Han

Unit type also matters: in general, skirmishers lag much more than slingers and archers. Pikes lag less than spears or swords. Cavalry units also follow the same pattern, but will stutter completely if you try to retreat them.