2.7 update and graphics

[swgoddard]

Just a note really.

I have been playing X3 TC for quite a while and have quite a large empire. With some sectors containing alot of ships/stations. This caused alot of graphics stuttering upon entering these sectors. This ruined the game so I needed a fix.
Consequently I had turned down the graphics settings on the initial splash screen to alleviate this problem.
I noticed that patch 2.7 makes better use of memory over 2GB. Well I have 6GB on my PC. So I remembered that I had turned down the graphics settings. If it makes better use of memory lets turn them up again.
So I did this slowly at first right upto max and now I experience
NO PROBLEM!!!
This is fantastic I got the best graphics and brilliant gameplay.
Good Job EGOSOFT!!!

[sparcdr]

Problem is there still is FPS drops to contend with if you're only passing framerate (28-36) with current settings as I am with 1280x720x32@60hz, QCQ, no AA/ASR, medium settings on a 2.66GHz Q8400, 512MB XFX 9800 GT, 8GB DDR2. Just simply order a few of the largest ships and slowly one by one let them deploy, then if you like buy a factory or 5 and place them within 12.5-25k kilometers and your FPS will start bogging down to 16FPS.

When there are so many companies are forcing the gaming and software industry into a gimped state because of 'so-called' consumer fears about 64-bit, general lack of foresight, lack of ability to make it happen, just plain greed and lack of investment, it'd be reasonable to want X3 to have 64-bit support even just experimentally.

Using new registers in low-level assembly calls for crunching math common in 3D rendering engines, having the ability to use the ram that is possible in new boards (8/16/32GB), and then the fact of clock cycle advantages on 64-bit platforms, especially in the area of concurrency.

To thread each subsystem which is common in consoles (Rendering/Logic, Physics, Sound) and then the UI itself (Property and shop list propagation namely) coupled with 64-bit would allow X3 to have more potential, especially in the areas of content development. It'd be unreasonable for someone to argue that a game of this magnitude shouldn't be needing more than 4GB of memory, when it's very possible to break that given the volume of complex scripts, the many points of logic interaction (Path finding, autonomous mineral gathering, anything combat related such as targeting), the high quality of the models, the map sizes and particle effects and so on..

If X3O is a reality behind those closed doors you've already made investments for 64-bit support on the servers because the computation of position information alone requires a massive database to catalog where just stationary units are, let alone plotting where up to 1000+ players are moving toward... to deal with counter-effecting lag by using algorithms to determine logically where it is expected (Plus limitations) units will be to keep then in check, all at the same time presumably on an x86 blade or ten in cluster fashion.

All I'm saying is that even with good coding, the bottleneck is always the number of threads, and x86 vendors never had the edge here, and still don't. Don't be lazy and keep yourself to one platform (Architecture) because it's popular if you pursue an online product.

Back on topic, more updates like this would make the game perfect, which is close as it is, especially if you reflect on the early past versions lay to rest.

Sorry for being so long in the tooth here.

[Baddieus]

2.7 patch is absolutely amazing as far as performance is concerned ... I can run 1600x1200-8AA-16AF without a bit of graphics stuttering.

Considering I've been playing since 1.4, and others even longer, this is by far the best performance enhancement package to date.

[sparcdr]

My issues are a CPU bound logic resource conflict more than the renderer being the cause I'd say. More threading in the areas of AI path-finding and ballistic projectile projections would probably reduce the CPU bottlenecks (Which affect my FPS) since as I reported spawning big ships (Not alone a degrading factor to performance) with lots of equipment in formation causes a fair share of overhead. If you don't have ships moving around but have stations/factories, the performance is a bit better, but obviously you need to have ships going to and fro to make your business happen.

[Killjaeden]

Problem is there still is FPS drops to contend with if you're only passing framerate (28-36) with current settings as I am with 1280x720x32@60hz, QCQ, no AA/ASR, medium settings on a 2.66GHz Q8400, 512MB XFX 9800 GT, 8GB DDR2. Just simply order a few of the largest ships and slowly one by one let them deploy, then if you like buy a factory or 5 and place them within 12.5-25k kilometers and your FPS will start bogging down to 16FPS.

That's because of your CPU. 4 Cores won't help you there. the only thing that really counts are Ghz.

[sparcdr]

Which is obviously a general disappointment with most common game engines still. Egosoft has already stated they are working toward issues surrounding these needs. Back in the MHz days, when SGI and Sun were competing against Intel, it was all about efficiency in clock cycles, and that still is the case but coming through the years of GHz with lackluster developer competence, the more power mantra has came back to bite us when machines have outgrown once again the software behind them.

[festa_freak]

C'mon. Don't derail his thread by talking about threads.

I don't think we will get an entirely updated engine next patch. This fix helped immensely and that is good in my books.

This is a thread praising Egosoft on their commitment to this game and as such, Thanks again Egosoft!

[sparcdr]

It's constructive criticism because the industry hasn't committed enough to it. Egosoft has always been ahead of the game and fully committed to their products, so it'd be nice to see soon, but I do know they will increase the bar again. At the moment the 2.6 and then 2.7 patches have risen my respect for them, and I look forward to more patches.

Again it wasn't meant to be disrespectful by all means it was merely about modern computing on a universe scale necessitating 'experimental' optimizations to satisfy demands and address scalability issues, which they have done by being one of the few small scale houses allowing more than 2GB of ram in their engine.

[Chealec]

...

...which they have done by being one of the few small scale houses allowing more than 2GB of ram in their engine.

Yup - and this is a good thing. We've had 64 bit OSs capable of addressing >2GB RAM for quite a while now (since 2005 apparently - earlier on *nix systems) - it's about time that it was utilised.

Maybe I'll port in a save-game from my old PC and see how the game copes with 120+ super-hubs under 2.7 Then again... it's not really fair to compare my current PC with my old one (since I'm currently overclocked to 4Ghz - with 6GB RAM to play with).

[sparcdr]

I have about 16 factories now with 12 elites as a wing doing patrols in Argon Prime to protect my industry. My 10 mammoths transfer needed goods between my factories and doing ore collection.

No performance issues with that yet, still using only 800mb of ram when everyone is moving around. I guess that's not that excessive given some of the people here build up dozens of sectors with massive trading operations.

I'm curious to know if any players (Non-scripters) can even peg 3gb easily now with 2.7.

[Baddieus]

I'm curious to know if any players (Non-scripters) can even peg 3gb easily now with 2.7.

Oh yea .... it will Peg that 3Gb and bang it's head against the ceiling. It will 'flush' or whatever it is that it does to make it drop 500Mb, then it will Peg back out. The game does stutter slightly for that moment before the flush, but no where near what it used too. There are moments of clarity in the game now that almost make me feel as if I temporarily left my seat.

Windows XP Pro 64-Bit
MSI - K9A2 Platinum
Phenom 9-something Black - (O/C'd & stable at 2.8 Ghz)
4 Gb Ram
ATI - 3870x2
10K RPM Hard Drive

[sparcdr]

Thanks for the confirmation Baddieus, but could you be more specific? How many units of whatever:

(colored) Wings (Units per wing)
Patrols (How many units and how many patrols)
Number of actively seeking traders (The automatic finders not point to point)
Factories (Including in this figure mines)
Average units in your most dense sector at a given time (Including AI obviously)
Average framerates in all sectors
Experienced delay timing (Lagging in seconds or minutes before memory is freed)

This information would help Egosoft even more. (Areas of interest, mainly logic-bound CPU usage: Unit pathfinding, distribution and cataloging (IE: stocks, plot projection)

[dbrowdy]

Not to derail even more, but if you want to complain about the state of the industry, I'd start with the dependence on DirectX instead of OpenGL. It's infuriating that I HAVE to use Windows to game. Steam adding Mac support is a big push in this direction, IMO. I'd never use a Mac to game (moving from an expensive OS to an outrageously expensive OS/Hardware combo? Uh, no), I'm more looking for linux compatibility. Whether or not you like Steam, they're good for the industry in many ways.

Back to topic, The annoying slowdowns that I was getting are gone. I'm gonna have to crank the graphics back up and see how it goes.

[sparcdr]

Not to derail even more, but if you want to complain about the state of the industry, I'd start with the dependence on DirectX instead of OpenGL.

It's more about standardization and losing patent enforcement here which I'm all for. Obviously developers should gear toward OpenGL because DirectX has in fact been used by many large companies and despite that cannot be unencumbered nor derailed, but merely ported at the end.

Necessary evils are one of the last accepted recourse we depend on as a society, namely with technology, such as things as fundamental as as instruction specifications to gridlocked but open in another sense computing languages. (Vendor vs. Vendor adoption and extension of things varying from OpenGL, OpenGL, to (X)HTML(4/5) then literal languages (C/C++ namely) and Java/C# in another class of entanglement to boot)

The obvious problem is the slowness of the standardization process, despite its advantages the hardware vendors demand and can prove reasonable need for having features pushed through, so they are at fault here as well. Even in the areas of performance there are advantages to the vertical API monopoly since Microsoft is more adapted and willing to invest resources to provide needed functionality, even if it is redundant in some opinions.

Keeping on topic: threading, 64-bit support are the future, and a developer needs to experiment publicly with migrating to these new commonplace technologies instead of clinging onto the norm to a T as is expected.

[Hellfire29]

If you were to ask me how to multithread X, then I would say to start with the scripts, rather than the graphics or collision detection. They're already separate sets of code.

[Baddieus]

but could you be more specific?

Fresh Restart with 2.7 (wanna do it all with higher res this time) 10.5 Game Hours currently.
1/3rd of the verse mapped ... about 17 Adv Sats ... the rest is unexplored.
Just started my 1st MK-III Trader ... I only own about 5 ships total at the moment.
No factories yet ... but there will be before the 1st Game Day is clocked.
I don't have FRAPS ... I'd guess fremerates are 60+ 90% of the time.
Lagging before memory freed ... 2-4 seconds ... the "motion dust" goes streaky during that time.
No crashing though ... not even during a full 3 hour session this afternoon.

[sparcdr]

I'd guess fremerates are 60+ 90% of the time.
Lagging before memory freed ... 2-4 seconds ... the "motion dust" goes streaky during that time.
No crashing though ... not even during a full 3 hour session this afternoon.

I'm fine with that as long as the baseline is an expectation range. 60-90FPS I would expect on 3GHz I7, SLI 265 etc. Explored sections won't be the immediate overhead, it's about assigned stock within and your own as well as AI affinity to such stock, and that includes all associated ships as well.

Glad to hear after that many hours no aggravating lag. I finally got my system up to 1.1GB today but it took 24 factories ad 32 ships with various automation routes. So the memory freeing stage has at least half reduced its delay since last time based on your report. The human eye sees up to 28 FPS, and it's increased to 30 FPS just in case of 'lag' so if you are getting double that, it's negligible anyways. More people reporting these kind of circumstances would help compile some relatively useful statistics for this patch which I think Egosoft publicly looks toward seeing.

I'd like to find someone who has too much money and too much screen resolution that can report playable frame-rate with comparable amounts of units here... and that means over-the-top zealousness in peaking memory usage, CPU utilization and general over-extension of reasoning.

FWIW, I did crash the client by spawning in 24 Mammoths, but it's not reproducible as far as I can tell because it depends on you doing it in a really complex sector.

[RicoOcho]

My system is
W7 64 bit
2.5 GHZ Dual Core
6GB Ram
Ati Mobility Radeon HD 4650 (1 gig Dedicated)
HDD 7200 RPM

probably not as power full as many but it does the job...
whatever the issue was in 2.6 its fixed now so no need to complain or go beyond it:)

[swgoddard]

I am so glad that my thread produced such a fertile debate.
I am currently running

W7 64 Bit
6 GB RAM
AMD Phenom X3 720 Black Edition 2.8GHz - not o/c yet.
2 x 1TB Western Digital Caviar Black 7200RPM 32MB cache
ATI Radeon HD4870 512MB

This setup since 2.7 has been brilliant.
Any future improvement for multi core and 64bit systems is to be applauded in my opinion.

[pjknibbs]

Hate to disappoint, but supporting multi-core would pretty much require rewriting the game engine from scratch, which isn't likely to happen in a patch. 64-bit support probably wouldn't need as much work, but would require a metric tonne of testing to make sure nothing got broken, so again isn't that likely to happen.