OptimusShepard

That solves it. Thank you. Seems to Vulkan is a bit faster than OpenGL for me. Sahyadri Vulkan 20fps vs OpenGL 18fps (reproducible.

Texture or shader quality doesn't change anything. My GPU memory usage is at 2GB when it crashes. My graphic card has 12GB VRAM. My last tests produced some new crashes/ error messages. I hope its my build, not your code that fails here. logs.zip

Hi @vladislavbelov thank you for your greate work. I did some quick test with every graphic backend in Sahyadri, complete map visible. The game crashes reproducible when too many units were produced (I used "gift from the gods", it crashes around 400 units). It crashed with all backends. logs_vk.ziplogs_ogl.ziplogs_arb.zip I can't reproduce the crash with the release candidate A26.

I totally agree with you. Having the menu not in the center is very uncomfortable when using a widescreen.

It works, thank you.

The original works, yes. But maybe it's cutted in the top and the bottom.

@maroder nice work, thank you. I tested it with my 32:9, seems like the backround is a bit broken.

Additional if you use scaling in windows, you should chose 0A.D. properties -> compatibility-> high DPI settings -> activate override DPI scaling. And than use maybe a bigger "gui.scale" value.

What do you mean when you are talking about RPGs? Are you talking about mechanics like in the Spellforce games? Maybe this will be doable as @wraitii committed D11.

You're right, sorry. I guess if my current Ryzen has problems to run the game without lags, most computers wont it too. The drop down menu was only a suggestion as a compromise between numbers and the on/off switch. Currently I use,like @hyperion suggested, a modification of the sinking time. I could agree on this solution too.

I think you didn't get my point. I suggested a limit of 100 units. As the corpse gets stacked on the battleground, you wont notice the popping. I can provide a video with such a limit this weekend. I don't get why you are against this feature? If you don't like it, don't use it. But only on/off is useless. Nearly nobody will chose "off". The feauture has a so high potential.

Than tell me, what's the intention? How do you understand on/off? As I understand it means corpses as it actually is, or no corpses. The first option hast a big performance impact on battle (also on high end PCs), the other is fast but ugly. So my question is why not a third option in between?

If I look to the survey, I think we need a compromise. People like @nani, me and some others see the greate chance to improve the performance by a not realy noticeable visual impact. Be able to chose a number means the complete choise for everyone. But I totaly understand the other faction who say that they only want to have a on/off switch because of complexity. There are people who have difficulties chosing the right options. So I want to suggest a drop down menu. Three options. One for corpses off, called "performance optimised". One for corpses on, called "quality optimised", and one option with a corpse limit of 100 called "balanced".

Hm, nearly a half of the players seems to prefer on/off. But what is meant here? Does "Off" mean zero corpses, or does "Off" mean a fixed limit of corpses, e.g. 100?

Thanks for your hard work. Take the time you need

You wont notice it, if you chose a limit higher than 100 corpses. If you don't overdo, you will notice a performance improvement anyway

The profiling starts (buffering data) always when the map starts loading. To be able to use/interact with this data, you need to start the profil-server. This is done by pressing ctrl+F11. Another thing you need is the html gui. You find this gui at source->tools->profiler2->profiler2.html. When pressing the button "Save live report to file", the buffered data are saved to the file profile2.jsonp. You find the file in the log folder of 0 A.D. You can also analyze the saved data with this gui. You need to profile the data one time with, and one time without patch to compare the both results. Four things to remember. The map loading effects your profile data. Second, the manual pressing of the button saves the buffered data, there is no possibility to "start" the profiling. Third, don't move your camera while you are profiling, or do it in a reproducible way (e.g. following a player in the replay). Four, use a replay for reproduce.

Yeah I'm currently working on benchmark maps and the possibility to start, save and end the game automatically by triggers. I have currently two benchmark maps. One for heavy graphics load, and one for a big battle scenario. For both maps I created a cinematic flight, so the user is not be able to move the camera. A replay wont be necessary as no AI is used. At the end the tester (you) should only start the benchmark map, and let it run until the cinematic flight has ended. Than you only need to apply and compile the new patch and run the map again. That's it. https://code.wildfiregames.com/D3554

In the picture you can see the renderer performance profiling for this feature. The graphs are showing the frametime. Lower frametime means higher fps. Btw. sorry for the offset on the x-axis. The red graph representatives the current vanilla version. The green shows the limitation to max 100 corpes, while the blue is showing the limitation to 50 corpses. As you see the start doesn't differ that much. At this time nearly 500 units starts fighting. In the following more and more units die and corpses are generated. As you see, the blue and green graphs are falling, because the amount of corpses are bigger now than 50/100, so they get removed. In parallel the amount of fighting units decreases, which leads to a lower workload. In the red graph, no corpse is removed, the workload doesn't decrease. For my personal experience I can tell, that a limitation of 100 is a good compromise, as you wont notice the removal of the corpses that much.

Wont completely agree with that. The pathfinder can have a big performance impact to the game, but the renderer is bigger. Late game often lags because people were spamming units (which leads to a growing of corpses). Also especially the AI is building that many houses which has also a huge impact to the renderer. Another problem is, that a big area outside the field of view is rendered. Many of the corpses are inside this area.

Maybe some more explanation. The framerate effects both, GPU and CPU. Every frame which is calculated by the GPU is "prepared" by the CPU. I you have no framerate limiter, you get as much as possible frames as your CPU and you GPU can provide. One of them will limit your framerate. No framerate limit (in 0 A.D.) means you set the framerate limiter to maximum. If you lower this limit, your framerate will be limit to the chosen framerate. If your hardware is limiting the framerate before reaching the set framerate limit, you wont get the set framerate. If you choose graphic effects, you will generate additional workloads for your GPU and CPU, so your framerate decreases. Some of the effects will have a greater impact to the GPU, some more to the CPU. Depends on the effect, but mostly the bigger effect is on the GPU. Current PCs are mostly CPU limited in 0 A.D., because the game is not multi threaded yet. That means they mostly only use 1-2 cores. As graphic effects mostly effects the GPU, you can chose the higher graphic effects without a lose of performance (on newer PCs). In addition to what I said about heating of the hardware (see second post of this thread), there is more to say about it. Heating of hardware leads to thermal throttling of the hardware. This effect is mostly known on mobile PCs. If the hardware gets to hot, the hardware limits it's performance until the hardware is cooled down. So a limited but constant framerate is mostly favored than a framerate which is oscillating because of thermal throttling. At last, VSync will limit your framerate to the framerate of your monitor (I guess 60 frames/herz) too. German translation: Vielleicht mal eine ausführlichere Erklärung. Die Framerate wird durch die GPU (Grafikkarte) und die CPU (Prozessor) beeinflusst. Die CPU "bereitet" die Bilder vor, welche von der GPU berechnet werden sollen. Ohne Frame Limiter werden so viele Bilder (Frames) wie möglich berechnet. Dann wird entweder deine CPU, oder deine GPU die Framerate begrenzen. Um den Framerate Limiter in 0 A.D. auszuschalten muss du den Regler in den Einstellungen auf Maximum setzen. Wenn du ein Limit setzt wird die Framerate auf dieses Limit begrenzt, das schont deine Hardware. Dieser Framerate Limiter garantiert dir aber nicht die gewünschte Framerate. Das heißt wenn du den Limiter zu hoch einstellst, dann wird eben deine Hardware, und nicht der Limiter deine Framerate limitieren. Die einzelnen Grafikeffekte die du auswählen kannst erzeugen eine zusätzliche Last für die GPU und CPU. Manche der Effekte haben dabei einen größeren Einfluss auf die CPU, manche einen größeren Einfluss auf die GPU. Das kommt auf den jeweiligen Effekt an, wobei die meiste Last schon auf die GPU geht. Aktuelle PCs werden in 0 A.D. normalerweise durch die CPU limitiert. Das liegt daran das 0 A.D. nicht so gut mit Multicore CPUs umgehen kann. Da die Grafikeffekte meistens zu Lasten der GPU gehen kannst die Grafikeffekte in 0 A.D. bei einem aktuellen PC meist recht hoch drehen ohne das es einen großen Einfluss auf die Performance hat. Zusätzlich zudem was ich schon im zweiten Post zum Thema Abwärme gesagt habe, möchte ich noch was ergänzen. Wenn die Hardware zu warm wird, dann führt das zum "Thermal Throttling". Das heißt deine Hardware limitiert ihre Leistung damit die Hardware abkühlen kann. Das kennt man vor allem im Bereich der Notebooks und anderer mobiler PCs. Das Thermal Throttling führt dann dazu das die Framerate stark fluktuiert. Meistens wird deshalb eine niedrigere, dafür konstante Framerate bevorzugt. Hierfür kann man dann eben ein Framerate Limit in 0 A.D. einstellen. Btw. VSync ist auch eine Art Limiter. VSync begrenzt die Framerate auf die Bildwiederholungsrate deines Monitors (also meistens 60 fps/Hz).

You can also install it side by side to Windows, so you have a dual boot system. Btw the biggest boost is the used compiler. The Linux GCC creates a much better code than Micrsofts MSVC. On heavy graphics load I get fps increasements compared to Windows up to 30-50%.

I've tried it but didn't get it to work. I will wait for your next phabricator patch :) I worked on Vector3D (https://code.wildfiregames.com/D2789) sometimes ago. The idea was to replace X, Y, Z by one __m128 SSE type and using SSE in the vector functions. Therefore @Imarok helped me replacing all direct accesses on the attributes by getters. At the end we gave up, because as you see, it breaks to many things. @Imarok can tell you more about it.

Too many users would not be able to play the game anymore... I guess, you would be surprised, if you look, how many old hardware is supported. Especial on Linux. But yeah, this would have to be integrated side by side to the OpenGL implementation. But there is currently not enough manpower to do this. Maybe it's easier, to thread the renderer? And sharpening ;)

It's not only a visual thing. In my last game I get annoyed by following behavior. Some of my units were already fighting against the enemy units. Then I selected all my units by double click (left mouse) and send them to attack the enemies. The idea was that the non fighting units help my fighting units to strike back the attack. Instead of that the units who were already in fighting leaved the battle to regroup. Following that the archers of the enemy were killing my regrouping units.