Now getting >90 FPS at 1080p - info on issue affecting high-end rigs [spoilers]

[Brachra]

All of this above ^

But my point still stands

You cant have People with 4-6year old videocards(1gb Vram), and 4GB sysram, playing on Dual-core and Older quad-core Processors who run the game Perfectly fine, seamlessly at 40+fps.

and then tell us that "we cant expect framerates like other games, because its not like a shooter etc..etc.., and that its unbalanced this and that.."
It just doesnt make sense

If Old card + Less ram can play it?
there is no way in hell Better card + More ram is "unbalanced". I seriously just dont think he was reading what he was typing.

[lithast]

So I ran the proefiles past a workmate with 15 years experience in game programming and he was just as confused as I was.

The only thing he could come up with was that they were using something like COLLADA to store their game assets in and were loading them back at runtime. Normally you would parse them into a binary file in the format the GPU expects and dump it onto disk on first run. He couldn't think of anything else that would make sense with that much XML work.

The other thing is that he picked up straight away that it had not been optimized yet, things like the DebugSetLevel to the D3D9 runtime being at the top of the list and such, why set it all the time?

[cerberus448]

Anybody seeing a large fps drop after the new nvidia drivers from november 19th? I just installed them and my fps has taken a pretty big hit in rebirth.

[Brachra]

Anybody seeing a large fps drop after the new nvidia drivers from november 19th? I just installed them and my fps has taken a pretty big hit in rebirth.

I received about a 40% DECREASE in Fps with the newest drivers

[Scoob]

Weird, I thought it was about the same with the newer drivers, if anything a tiny bit better.

Scoob.

[Astyrrean]

Weird, I thought it was about the same with the newer drivers, if anything a tiny bit better.

Scoob.

Me too. No change.

[lithast]

Saw something on the general forum that made sense:
http://forum.egosoft.com/viewtopic.php? ... sc&start=0

We're still to see how good this new engine really is.

Cause it looks like pretty large chunks of game code are written in Lua and some fancy XML-based scripting language, which does not even seem to be compiled at all, hence the overhead must be -huge- I imagine, with all the useless XML parsing happening all the time in background.

Lua is a very simple programming language, but it is still the fastest of all dynamic languages out there with LuaJIT. However, performance-wise it should still be quite slower than standard compiled code.

So if overhead of Lua and that XML-based monster is high, no wonder performance is, was and probably will be their main concern. If so, X Rebirth is not made for 'the computers of the future', but rather it depends on them to be playable.

BUT, if it all ends up being fine, the game may as well be extremely modding-friendly and live a long and happy life.

That might explain the XML...

[SpareRib]

So i'm not sure if its the same issue for all the issues here, but I found from another thread on the forums (sorry I can't find the link now) a reference to the higher-end graphics cards downclocking during gameplay.

after a quick search on how to stop this for my 660Ti, my performance issues disappeared.

I found the following instructions. instead of following them exactly (which makes the setting global, ie always on), I made a new profile for x-rebirth by selecting the x-rebirth.exe so it's only effective in x-rebirth.
https://forums.geforce.com/default/topi ... s-desktop/

I don't have experience with Radeon cards, but the reference at the time was to a program called RadeonPro (no idea if the Catalyst control centre has the same feature)


edit - found the other forum post about RadeonPro and Radeon cards - http://forum.egosoft.com/viewtopic.php? ... =radeonpro

[curt428]

Thanks for the tip, but unfortunately it did nothing for me.


On top of terrible frame rates, is anyone else noticing their CPU spike after newest patch (1.15)??

I have a Phenom II X4 BE 3.6GHz and all 4 cores are up in the 70-90% range after starting a new free mode game... I had to quit the game out of fear.

Anyone?

Here's hoping they can start fixing up that code soon.

Keep up the great research everyone!

[omfgjohnnyisback]

So I ran the proefiles past a workmate with 15 years experience in game programming and he was just as confused as I was.

The only thing he could come up with was that they were using something like COLLADA to store their game assets in and were loading them back at runtime. Normally you would parse them into a binary file in the format the GPU expects and dump it onto disk on first run. He couldn't think of anything else that would make sense with that much XML work.

Anark Studio & FCOLLADA is exactly what they seem to be using indeed as middleware.

[omfgjohnnyisback]

I'm half temped to dump its address space and have a poke around, but I'm not sure if I'm really that motivated.

Anyway this info might be nothing or it might be something, hope it is of use to somebody.

I cba myself. But in case you ever do, check out the following functions. I ran a quick xperf profile with stackwalk on a freshly started free play game and did a count of how many times each thread was seen in some function. I limited the data set to ~25 seconds when thread load seemed more or less stable.

Format is: function, number of times a thread was detected spending CPU time there, thread ids. Offsets are for the originally released game exe (no patches).

Code: Select all

sub_8A71C0	1575  3896	4092					
sub_52F830	986	3324	3848	3896	4088	4092		
sub_42C4E0	913	4092						
sub_42C960	886	4092						
sub_430420	711	3324	3848	3896	4088	4092		
sub_6125A0	698	3324	3848	4092				
sub_BD72C0	604	4088	4092					
sub_9D8080	591	1512	2064	2456	2960	3548	3912	4092
sub_997AA0	566	4092						
sub_55A260	561	4088	4092					
sub_A3C270	450	4092						
sub_BD7070	404	4088	4092					
sub_BC6CE0	395	4092						
sub_42FE00	392	3324	3848	3896	4088	4092		

4092 was utilizing the most CPU time, so it may have been running the main loop. No idea why another thread was going for the same hottest function at all.

sub_52F830 - string-related function with 176 xrefs, may be Lua related
sub_430420 - may be "GetDistanceTo" and related to AI script execution probably
sub_9D8080 - asset management, the famous "async loading" I guess, no idea why 4092 even goes there

Many of these functions exhibit some form of thread contention be it mutexes or lock cmpxchg themselves, or in a calling function.

The most bizarre thing I've seen is Lua code calls being intermixed with XML script calls and heavy FPU code in one function.

Have fun!

[lithast]

I guess this is one problem that they face..

The intersection between the groups "Sandbox space sim fans" and "Programmers" seems to be quite high.

Lots of people to poke holes in their code

[omfgjohnnyisback]

Indeed you just can't throw s**t at people who love complexity and can read your code.

[pirke123]

My experience in software development (projects of +10 milion lines of code) has learned me:

Building up a DOM XML model is very expensive. Only do it once at startup. Even better: don't do it. Parse the XML into your own binary format (classes and/or structs). Manipulate those at runtime.

Multithreading is good (it's actually my expertise), but locking kills your performance. Write your code in such a way that you don't need locks and still can guarantee correct behaviour. No global shared state is a start. However I must smash everybodies hopes in: you have to design your program around it. This is the basic foundation of your design. You can't patch it in afterwards.

I wrote a simple demo in Unity to show that even a fully overloaded CPU is no reason to get a bad framerate if properly designed: http://www.stinkyrhino.com/unity/multi_threading_demo/ it also shows the cost of repetitive use of an extremely fast (50ns) lock.

[curt428]

However I must smash everybodies hopes in: you have to design your program around it. This is the basic foundation of your design. You can't patch it in afterwards.

Is that it then? Is there no hope? Will Egosoft be forced to find some other way to reduce this effect, or is that even possible?

[pirke123]

However I must smash everybodies hopes in: you have to design your program around it. This is the basic foundation of your design. You can't patch it in afterwards.

Is that it then? Is there no hope? Will Egosoft be forced to find some other way to reduce this effect, or is that even possible?

If you're patient then they can continue to work on it, bit by bit. Stop using XML in memory but a proper data format. Big change: several months of work probably. Stop using shared state between threads. Bigger change. I don't even dare to guess as it completely depends on how they set things up. I suspect they have higher priorities at the moment (fixing bugs), and perhaps there are a few quick wins, but a structural solution will take a lot of time.

[windscar232]

With the latest patch for Nvidia cards, it seems to help my non-Nvidia system run better. Instead of getting a low frame rate right when I go into cloudy Albion zones, I can actually play in those sectors for a while before I become affected with my AMD. Then the amount of crashes I had today was a lot less. I think I only actually crashed once in my free play game I started the other day.

I think it was a good quick fix, for me. Then I don't agree that it has to do with the areas being more crowded. I don't experience these problems in Albion sectors that are crowded but do not have cloud effects.

I think I heard about them having problems with the dash lines and was going to take them out of the game, but then I see those in my game. I think it may really have to do with the programming of the cloud effects themselves (dust). That is the one variable that is always present during my performance problems.

[mattek1979]

Is that it then? Is there no hope? Will Egosoft be forced to find some other way to reduce this effect, or is that even possible?

No it is not, my gut feeling is that there's probably a great deal of optimization left to do

[SimB]

So - nobody is working on this anymore?

[Spikeles]

So, my summary from what I've gathered from various topics and my own research so far.

The game seems to be hampered by its unoptimized code and possibly uncompiled scripting code, while the logic and render threads are experiencing synchronization and lock issues ( see comment by egosoft employee linolafett on reddit ). Also, apart from frustum culling, it also doesn't seem to use any kind of occlusion culling (except for the sun and other lights funnily enough).

Being multi-threaded issues, its entirely possible that the faster your CPU is, it's more likely to hit these synch/lock issues.

It's also 32bit with LAA which gives the game 4GB of address space to play with (not an issue in itself, plenty of games work in 32 bit and 4GB of memory). However when running on rigs with large amounts of video memory and due the fact it uses D3D9 and it's majority of video resources are in the D3D MANAGED pool(meaning the app itself is responsible for keeping a copy), this can cause it's virtual address space to be exhausted by shadowed (and lockable) video resources that the Windows Display Manager helpfully duplicated into it's address space (Its a Vista and above thing when using D3D9: see Microsoft KB940105). The memory space exhaustion is usually represented by missing objects, flashing objects, and other fun rendering artifacts, all things I've personally witnessed when it's neared it's limit.

There also seems to be some kind of memory leak(possibly related to the above mentioned behavior of the Windows Display Manager) as although its allocated memory heaps don't actually take up that much memory (They seem to use Elephant memory manager and you can see how much they used by using DebugView when Rebirth starts and exits), its virtual address space still ends up being sucked up by "something" .
[ external image ]

There isn't much any player can do. Tweaking your CPU, graphics, motherboard settings probably won't help unless there was already some underlying setting like cpu parking, using the wrong video card, down-clocking etc.

It's fundamental programming issues that Egosoft need to fix themselves but once fixed, everyone should see the improvements.