Can I pay for a FPS DLC?

[HammerHead91]

The fastest cpu in the consumer world with a 3060 shows being cpu bottlenecked in the following video.

I'm having a degree of amused irony, here. Twenty-six minutes of video time to demonstate a framerate you don't like?

I've got two words for you: (1) Edit Stuff, and (2) A word that doesn't exist in English or (possibly) German but would broadly mean "To Waste My Time Wasting Your Time".

I hope a German speaker will provide the appropriate vocabulary. Surely it must exist by now.

[Imperial Good]

The fastest cpu in the consumer world

5800X3D is only the fastest for some applications like X4 (possibly some situations only). Multi core performance wise it is much slower than the 5900X and 5950X. It also loses out massively in non-cache constrained single thread performance to most of the Intel 12th gen series i5 and above with the higher end models even beating it multi thread performance wise.

These benchmarks. They weren't even in combat, just flying around some static meshes that don't move.

The meshes all have collision. 3D collision is quite complicated. Each station module has dozens of collision surfaces to match up with their geometry. Repeat this for hundreds of modules and performance can quickly tank. Even optimising the collision testing to cull all inappropriate meshes becomes resource intensive when having to deal with thousands of such meshes nearby.

[CBJ]

Didn't devs already confirm, that adv. sats don't affect performance? Whether you see them or not, the rest of the universe still gets calculated. Turning them on should only affect gpu performance.

The existence of the satellites has minimal impact on performance. However, when you open the map to an area covered by those satellites, they cause more stuff to fall into the category of "things the player can see", which means the level of simulation that they receive increases in order for what you see to be reasonably accurate. In addition to that, drawing something doesn't just cost GPU time; there is CPU time involved in extracting and preparing the data needed to pass to the GPU. Some parts of that process can be threaded, others cannot.

[Caedes91]

Didn't devs already confirm, that adv. sats don't affect performance? Whether you see them or not, the rest of the universe still gets calculated. Turning them on should only affect gpu performance.

The existence of the satellites has minimal impact on performance. However, when you open the map to an area covered by those satellites, they cause more stuff to fall into the category of "things the player can see", which means the level of simulation that they receive increases in order for what you see to be reasonably accurate. In addition to that, drawing something doesn't just cost GPU time; there is CPU time involved in extracting and preparing the data needed to pass to the GPU. Some parts of that process can be threaded, others cannot.

Ahh, okay...Thx for clarification. I thought, sattelites were like flipping a switch only to make something visible, that is already there. But that it then falls into the category "player can see, therrefore increasing sim level", I did not know.

On another note: Is it possible to make ships in internal storage of a station not consume computing power? I have a bigger number of ships (100 s and about 30 m ships) stored inside my HQ, and it defintely makes it very laggy when player is present. Like shoving them into OOS computing territory?

For example In sector you can look into eack ship's cockpit and see an NPC pilot with F2 or F3, meaning they do get rendered. Make the models less detailed when not piloted by player or inside of them and mask this fact with an "opaque" cockpit glass (not see through).

Your "proof" is fundamentally flawed. Those NPC pilots are only rendered because you are looking into the cockpit; if you were further away, they wouldn't be rendered at all. We do all kinds of culling, including frustum culling, LOD management, and all the other basic graphics optimisation techniques that you've mentioned, along with a whole lot more that you've probably not even thought of. Those optimisations help with the render performance, but that's not normally the limiting factor in a game like this.

Sorry for not being clear. I meant performance in the direct vicinity of the player themselves. I already know and trust, that you are using all kinds of techniques to make the game run better. What I meant, was not for OOS or after a certain distance, but in sector, when you are in fact, directly looking at more ships other than your own.
For example I'm on a raptor, next to many fully detailed fighters. There is a notable performance difference, compared to when the carrier is empty. And certainly not only for me but others as well. So I was hoping, that it was possible to reduce model detail for situations like that. Even if you are directly near them, as long you don't pilot them or aboard as passenger. May help nothing or only little, but I think that at this point, even a little better than nothing.

[linolafett]

For example I'm on a raptor, next to many fully detailed fighters. There is a notable performance difference, compared to when the carrier is empty. And certainly not only for me but others as well. So I was hoping, that it was possible to reduce model detail for situations like that.

The LOD slider can be used for that.
Lower its value to decrease visual fidelity (render less objects at the same time on screen).

[CBJ]

On another note: Is it possible to make ships in internal storage of a station not consume computing power? I have a bigger number of ships (100 s and about 30 m ships) stored inside my HQ, and it defintely makes it very laggy when player is present. Like shoving them into OOS computing territory?

Ships in internal storage shouldn't be consuming anything much. Their scripts should be idle, there won't be any significant "high attention" processing, and they certainly won't be being rendered. If you're absolutely sure that this is what's making a difference in your case, i.e. if you can show that sending those ships elsewhere gives significantly better performance with all else in your game being the same, then that would be very odd and interesting for us to investigate.

[HammerHead91]

The fastest cpu in the consumer world

5800X3D is only the fastest for some applications like X4 (possibly some situations only).

Ah, well. I might have made an unwise purchase.

[Imperial Good]

Ah, well. I might have made an unwise purchase.

The 5800X3D is still a very fast CPU and currently the best available for some tasks (games like Factorio, a lot of situations in X4, e.t.c). I was more dissecting the "fastest cpu in the consumer world" part to temper expectations as there are also many situations where it is not the fastest (multi core drag racing, single core drag racing, games that performance is not cache limited, tasks that are memory bandwidth limited, e.t.c.).

At the end I do not think it reasonable to expect 60 FPS all the time when playing X4. Situations such as early game, light combat, exploring, e.t.c. should be able to retain greater than 60 FPS as good as all the time on decent hardware. On the other hand extreme station builds or if your economy contains thousands of busy traders and miners it is reasonable to expect some performance hitching.

There are also times where performance just does not make sense, such as flying a destroyer or battleship into a station module that is under construction but not yet being constructed. This still seems to tank performance down to <<20 FPS without anything visually happening. I reported this long ago and although I did not test that exact case recently, I did encounter the same behaviour when I accidently flew my Erlking into a similar Xenon administration module that had yet to begin construction. Not not seem to affect station modules that have begun or finished construction.

[TwoThe]

The main problem is that the devs obviously are not using multithreading in the universe simulation. So literally everything runs in the rendering thread, which kills FPS drastically if the game has to simulate the universe. This is an algorithmic problem that cannot be solved with CPU power.

[Lord Dakier]

The main problem is that the devs obviously have never heard anything of multithreading. So literally everything runs in the rendering thread, which kills FPS drastically if the game has to simulate the universe. This is a poorly implemented algorithm that cannot be solved with CPU power.

Just delete your post, you're embarrassing yourself with a lack of knowledge.

[TwoThe]

Just delete your post, you're embarrassing yourself with a lack of knowledge.

Care to enlighten me so I can delete myself afterwards with it?

[Lord Dakier]

Just delete your post, you're embarrassing yourself with a lack of knowledge.

Care to enlighten me so I can delete myself afterwards with it?

Just read the thread properly. In a fully and truly simulated universe you multithreading requires one core to catch up with another core. This isn't an issue in most games because things don't happen simultaneously on a micro level, but with X4 that's not the case. A single-core running at 12ghz would perform far, far better than a quad-core each running at 3ghz even if the game was multithreaded in its current design as much as possible.

[TwoThe]

A single-core running at 12ghz would perform far, far better than a quad-core each running at 3ghz even if the game was multithreaded in its current design as much as possible.

You might want to look in how particle simulation on GPU works with modern graphic engines. It comes very close to simulating thousands of small ships in a universe.
Also the concept of one core waiting on another is exactly what you would want to avoid when implementing a proper algorithm.

So my point stands: the algorithm they are using is simply bad.

[taztaz502]

Works pretty well for me with my trusty 1080ti and like 2nd or 3rd generation i7.

Infact i tend to play other games whilst running/playing X4.

[CBJ]

There is no need for people to starting flinging insults, either towards the developers or at one another. The forum rules are quite clear about this.

This is the most relevant post in this particular thread on the subject of threading.

As has been explained on many occasions, the core simulation uses a single thread, largely because the very high level of interaction between the objects in the game universe makes it extremely difficult to do efficiently any other way. The engine as a whole, however, uses more threads, with things like rendering, physics, pathing calculations, file access, and so on all using other cores to some degree or another.

[Lord Dakier]

A single-core running at 12ghz would perform far, far better than a quad-core each running at 3ghz even if the game was multithreaded in its current design as much as possible.

You might want to look in how particle simulation on GPU works with modern graphic engines. It comes very close to simulating thousands of small ships in a universe.
Also the concept of one core waiting on another is exactly what you would want to avoid when implementing a proper algorithm.

So my point stands: the algorithm they are using is simply bad.

Well I'm sure Egosoft will be snapping you up to work in their office then. You clearly know more than they do.

[TwoThe]

There is no need for people to starting flinging insults, either towards the developers or at one another.

Sorry for that, I edited my post.

makes it extremely difficult to do efficiently any other way

Difficult maybe, but certainly not impossible. A step based approach with task queues should do the trick rather efficiently with modern CompareAndSwap.

[CBJ]

You might want to look in how particle simulation on GPU works with modern graphic engines. It comes very close to simulating thousands of small ships in a universe.

No, it really isn't. Particles just move according to a simple formula. They don't have orders, interactions with other objects, interactions with the player, or any of dozens of other features that ships need to have. The closest thing to what you describe there is the game's "mass traffic" system, which does indeed work a bit like a particle system, at least until you get close enough to be able to interact with the individual ships in the traffic.

Also the concept of one core waiting on another is exactly what you would want to avoid when implementing a proper algorithm.

I don't know what point you are trying to make here. Cores occasionally do have to wait for one another; this is known as a sync point, and happens, for example, when you need to ensure that everything is in a consistent state at the start of rendering a frame. Other than that, what makes you think that threads are waiting for one another? They're not.

[TwoThe]

Particles just move according to a simple formula.

Which is what ships do most of the time: they move. If you have a ship in combat with a 1s time to fire, that means that 59 Frames the ship is moving according to a particle-like formula, and 1 frame of actual interaction. Most ships however are not in combat, they simply move around in formation doing 99.9% particle stuff.

I don't know what point you are trying to make here. Cores occasionally do have to wait for one another; this is known as a sync point, and happens, for example, when you need to ensure that everything is in a consistent state at the start of rendering a frame. Other than that, what makes you think that threads are waiting for one another? They're not.

That is the old thread based approach to multithreading, while the modern way would be a task-/queue-based approach.

To illustrate that with an example: let's say two ships want to trade.
Now as I said above all the movement can be handled by a particle-like system, so in full parallel. What's left is the actual trading:
1) Ships A injects a trade request into Ship B's task queue.
2) Ship B injects a "trade accepted" return into A's task queue (or otherwise "trade refused"), containing a rendezvous point, which is an arbitrary object handling the actual trade interaction.
3) Ship A and B do "particle stuff" till they are in place, once they arrive they send an "In position" note to the arbitrary trade handler.
4) Once both ships have sent that they are in place, the trade handler queues a "wait" task into them - which will simply make them wait until further notice - and also takes the cargo to trade for either transfer or dump.
5) Once a specific time has passed the trade handler sends the cargo to the receiving ship's queue and released them from their waiting.

Now the rendering only needs to know the position and heading of the ship, which is - thanks to the particle system - always known. The actual trade interaction requires no rendering and can therefore be done off the rendering thread. If the player is looking the trade handler could also have some fake "cargo drones" fly back and forth, which actually do nothing but look good and drop a random part of the cargo in transfer when destroyed.

This form of task/queue based interaction is used in all modern logistic systems around the world, which is by nature "multi-threaded," and has proven to be very reliably and fail-safe.

[CBJ]

Which is what ships do most of the time: they move. If you have a ship in combat with a 1s time to fire, that means that 59 Frames the ship is moving according to a particle-like formula, and 1 frame of actual interaction. Most ships however are not in combat, they simply move around in formation doing 99.9% particle stuff.

No, they don't.

That is the old thread based approach to multithreading, while the modern way would be a task-/queue-based approach.

The part of the game that I described in the text you quoted is not something that can be farmed out to a task-based approach. Sync points are still needed between, for example, the render thread and the simulation thread, which is the scenario I was talking about. What you describe in your example on the other hand could indeed be done with a task-based system in theory, but is also exactly what I was referring to when I talked about it being extremely difficult in a game with so many interactions. The overhead of a task-based system in a game like this, for the particular areas we are talking about, can actually end up exceeding the benefits.

Perhaps if you didn't enter into this thread assuming that the developers were idiots, that you knew more than they did about the systems that they have been working with for many years, and that they hadn't even considered fairly standard programming techniques, you would find people more receptive to discussing things with you. As it is, I'm not going to spend any more time on this.