OptimusShepard

To clarify, and to have a more detailed description and summary (maybe this could be interesting for Matt from AMD support). I have not tabbed out of the game. As, I said the slowdown occurs completely randomly. Sometimes you can play 1-2 matches without a problem, then in another match it occurs after one hour playing, yesterday on Linux it occurs directly after loading the map. So, I can't find a pattern here. When the slowdown occurs the fps display is frozen, that means it displays the last fps. As @Mr.lie said the fps could be very high, or even low, depending on the last situation. Defining slowdown, I would subjective (as I have no working fps display) say, there is no big fps drop. It's more like changing the game-speed (like the option in replays) from 1-times to 0.1-times speed. In difference to changing the game-speed in options, also the mouse-speed and the speed of moving the camera is dropping in the same way. As the slowdown occurs directly after loading the map, and it was my first match this day, overheating (throttling) could be definitive rejected as a possible reason. I' m using an 3700X in combination with an Alpenfoehn Brocken 3. From what we can say the problem is based to the Zen 2 CPUs, we also know the problem doesn't depend on the OS. A little workaround, which is only working rarely, is to pause and continue the game. But even it is working again, the slowdown will occur a few minutes later again.

I had the same problem now on Linux I also noticed, that when the slowdown occurs, the fps display is frozen.

Should be the same problem. I think the only workaround is to decrease the shadow quality. https://trac.wildfiregames.com/ticket/4883

Thank you for this interesting information’s. I think this thread could be closed now.

Nice feature So you planend more than one, but smaller shadow boxes to have only shadows on the rendered area?

So, I tested, as @vladislavbelov said, with the developer panel. As @Angen mentioned, the draw calls I had seen were used for shadow rendering. When the models are inside this render area, they are rendered to be displayed. Also, any model that is inside the red/blue box is rendered for shadows and reflections. Depending on the orientation of the camera/render area, the shadow/reflection boxes (red/blue) may fit less or better into this area. The first image shows a relatively good fit of this area with the boxes. So almost every shadow that is rendered could be seen by the player. The second and third images show the worst case. Here, the fit between the render area and the shadow render box has a bad adjustment. This means that many shadows are rendered that the player can't see, so it's a waste. Optimizing the shadow renderer therefore means to achieve the best case of matching the boxes to the render area. I don't know if there are plans or if this has already been abandoned, but my thought is, is it possible to rotate the red box along the longitudinal axis? Since the longitudinal axis does not change its direction/orientation, the direction of the shadows will not change. So, the direction of the rotation around the longitudinal axis should depend on the orientation of the camera. (Please ask/comment if I have not explained something clearly or misunderstood something.)

So its easy to fix?

Both

@asterix I think you misunderstood my intention As it seems to me that there is a greater area outside the render area where models get rendered, my question is, if this is necessary, or a misbehaviour/bug, which could be solved to increase the game performance.

Does the sound uses draw calls and model tris? I've found the hotkey F11 to show the draw calls. What I see, is looking really strange to me. If the units were in the render area I got ~14.000 draw calls and ~4,4 million model tris. If the units were "near" to the render area, as in the shown screenshots above, I got ~6-8.000 draw calls and ~2,1 million tris. If I left this area I got ~470 draw calls and ~84.000 model tris. So it seems to me that there is a area around the render area where a greater part of the unit models gets rendered anyway. My chosen settings were Anatolian plateau, one player, normal size, 500 units. Can someone confirm this?

Did you meant this Engine.GameView_SetLockCullcameraEnabled(true)? I've tested it with this command again, but as you can see in the following screenshot, the units (I have them tabbed to show them) are not in the shown render area. I had nearly 30 FPS. If I pushed the field of view a little bit more to the bottom I got 60 FPS. So what is going on there?

@vladislavbelov, @Angen As I'm not the pro in graphics programming I want to share my, I think, interesting observations with you.Normally only the objects the user could see should be rendered. So nearly only the field of view should be interesting (with some exceptions because of shadows, reflections etc).As I recognized that some big battles, which aren't in this field of view (only near to it), have a big impact to the performance, I decided to make some tests.In the following pictures you can see, that the area of performance impact (I would guess the area of the renderer) is minimum doubled to the field of view. I guess minimizing this area could have a big performance increase to the game.In the following pictures you can see (on the mini map) a big blue dot, that's the 500 test units. You can also see the field of view in different orientations to this dot. The map size is chosen normal. As you can see on the FPS display in the right upper corner, I made this screenshots at the borders to this (renderer?) area. Especially in the front of the field of view there is a huge offset to the are of performance impact.

No. Currently it seems to be a only Windows related problem. But I will go on testing on Linux.

I have played some test games on Manjaro Linux. I hadn't noticed any problem until now.

You could test the newest patch, to verify, that FXAA still works on those maps. This patch should fix the plattform problems with Linux. The bug, that it works only on some maps, will be propably later addressed. https://code.wildfiregames.com/D2699

Yes, the "G" CPUs of the 3000er series, e.g. 3400G and 3200G are based on the older architecture of the other 2000er CPUs. Thx. The default one is not the best, but as @Dakara has a big cooling system, I think the temperature is not the problem. Lets see if it's only a windows problem.

If you really want to buy a new CPU, you could use a Ryzen 1000er or 2000er series. It should normally work with your system. Merci, should be enough.

Thanks. The Manjaro version is already patched. I will have a look to find some tool to log the hotspot temperature. The normal displayed temperature is always ok. Maybe @Imarok could give you the address or his contact. He contacted them for the first Ryzen patch. Or he could contact them self. But I think an official request from Wildfire would be more effective. Especially because you don't have an own CPU.

As I have a dual boot system now, I will do some tests on Linux in the next week, so that we know if the bug is only windows related. Are there also some other tools that I can use to generate some reports for you? Two thoughts. Maybe Wildfire Games could send an official request to AMDs support? Second thought, maybe this "bug" is related to the new measured hotspot temperature? The thin structures of the new 7nm process increases the temperature on a few spots on the chip, called hotspots. As 0 A.D. uses nearly only one core, the load and so the power consumption is not distributed over the whole chip. So maybe one of these measured hotspots throttles the CPU? But normally the CPU is changing the used core often to provide those hotspots from overheating. On the one side I'm using a really oversized big cooler, on the other side it is running in a slow silent mode. So maybe it would be interesting witch cooler @Dakara and @matricea are using?

The problem is allready known. FXAA and CAS currently doesn't work on all maps. There is also an bug with AMD GPUs on Linux. I didn't find a solution. Hopefully @vladislavbelov come back soon. https://code.wildfiregames.com/rP23484

I've logged two multiplayer parties. In the second one the slow-down appeared. I had HPET in Windows disabled. Multiplayer.LOG

I will test it in my next multiplayer match.

This Problem exists also in the multiplayer. I don't have speed-ups, but random massive slow-downs.

You have to edit the map which you like to play. On a first look, it seems to be very easy. Should be enough to deleting only the part were the animals were created. You find the maps here "AppData\Local\0 A.D. alpha\binaries\data\mods\public\public.zip\maps\random". To editing the map, you have to move it outside the zip. The .js file is what you need. If you need more info’s about map scripting @elexis is the expert. If you want to have the map as a mod, @nani could tell you more.

If you choose "unassigned" you could still attack the other player. I think better would be to take both players into the same team, and to select fixed teams. You will win instantly, but you will be able to go on playing.