2-3 seconds freezing/stutter

[Prax]

Here are the instructions:

First rename your X3TC.EXE to something like X3TC.BAK

Then download CFF Explorer and do the following:

[ external image ]

[ external image ]

[ external image ]

[Snatcher42]

This will work in Vista 32 with some extra steps:
http://www.jaloonz.com/2008/04/enabling ... games.html
Solved my problems!

[cucher]

Thnks a lot Prax! Sorry for may be stupid questions, but will it work for Vista 64? An where can we find CFF Explorer? I'm not a big OS specialist...

Added later: Downloaded the prog. But have another question: should I change settings for .exe file or for the renamed .bak one? If I do all this stuff with .exe file, then what is the reason of creating .bak file?

Found all answers for all my above questions

Will try to fix game tonight.

[DDM_Reaper20]

btw, XP x32 will never see more than 2gb of ram...

Not quite. XP 32 can easily see 3 gigs and some, but can only assign 2 GiB maximum to any program, which leaves the rest to deal with whatever else is floating around.

[Prax]

sorry I wasn't clear about the BAK, i meant for you to copy it and rename it BAK so that you have a backup.

Glad to hear you figured it out.

[pjknibbs]

Not quite. XP 32 can easily see 3 gigs and some, but can only assign 2 GiB maximum to any program, which leaves the rest to deal with whatever else is floating around.

Again, not entirely accurate. By default, each program running in XP 32-bit gets 4Gb of virtual address space (note: this is regardless of how much physical RAM you actually have installed), of which 2Gb belongs to the program and 2Gb belongs to the OS kernel. If you add the /3GB switch to the entry in BOOT.INI that starts your XP install, and the flag they're talking about in this thread is set, it will rebalance that virtual address space so 3Gb belongs to the application and 1Gb is kernel. This will make a difference if you have enough RAM available.

[VincentTH]

Can someone post a detailed step-by-step procedure for WinXP-32 for us non windoz savy users?

[cucher]

Thanks Prax. Hope it'l help me. The report will be ready on monday.

[Moonrat]

VincentTH...

Being a UNIX cretin (professionally) and knowing next to nowt about Xp I typed the following into Google...

xp boot.ini /3gb

It comes back with loads of useful looking stuff. Have a look.

[ragamer]

Just to focus on the OP problems I suffer it regularly... My machine beats the recommended setup by far and I can tell you I suffer from this stuttering a lot.

And I also isolated the problem... It's on new sound use. The stuttering (and the 100% associated GUI dissapeararance) are always in my case when new sounds are triggered by:

- Explosions.

- New weapons shot nearby.


Seeing how "picky" is X3:TC with the sound subsystems... Well, I would start by looking there... Having to address more than 2GB on a single executable to reduce this effect (specially when you compare with X3:R) is just a dirty solution... I hope Ego fixes whatever is triggering this HUGE cache flushes on new sound execution, because going around hacking executables is not what I call "user friendly".

[VincentTH]

I second that. My game has become unplayable for combat missions, so I only do Build or Delivery missions. I will have to wait till Ego fix the performance problem before I can do FInal Fury. I wish I did that mission when the game was young. Sigh! When I did the Terran plot, it was a slide show in Aldrin, but fortuantely, I did not have to fight that much.

I have applied the patch (/3GB switch and modify X3TC header), and it did help a bit, but overall, the game is very slow. I have all graphics to the lowest settings (Low, no AA) and that seems to help. THe graphics is ugly, however.

[RegisterMe]

In no way is the /3gb switch a "patch".

Anyway, I've suffered from this from release, and whilst I thought it was sound related I'm not so sure any more. I think it is more general than that.

I think it is to do with anything that isn't immediately available in memory. When I say anything I mean model, or sound, or effect. If it isn't in memory it has to go to disk for it, and for whatever reason TC is not good at it (or perhaps TC plus certain combinations of OS and driver).

I noticed it tonight. I was SETAing across The Hole, from the west gate to the North gate. Nothing else was going on (does a TS of mine heading to AM count?). No missions, no combat etc. As I approached the gate things stuttered, I lost the gui, and then a ship popped out of the gate, then the gui came back. This was before I could see the gate itself. There was a minor stutter when the gate itself became visible (hate that word, can never remember how to spell it, is it an i or an a?).

At least with my setup (good machine, Vista 32, dxdiags available in a couple of other threads) the problem appears to be related to the fact that the game wants something that isn't there, and struggles to get it.

My simplistic interpretation at the moment is that it is on the disk but is being choked / throttled / thrashed by something else, possibly including the OS.

As most / some of you know, I'm a fairly avid (some might say rabid) reader of these forums. One consistent theme I've noticed is that you don't get people with 64bit Vista (or XP?) saying that they are having these problems. It's not conclusive (and ignore the /3gb swtich for a second) but my gut feel is that TC doesn't play as nicely with memory as it is meant to. It's greedier, lazier, slower and doesn't use the GPU / memory on the GPU in the way that we would expect.

None of the above is conclusive, and I'm not knocking anybody, least of all Egosoft. What I am going to do is set up some save game situations and some perfmon logs.......

Spoiler

Show

And now I am going to go back to trying to work out wtf to do in the hub .

[bumpinthenight]

Seriously, once you let TC take up more then 2GB of ram its happy again, whether or not it should use that amount is up to debate but that was clearly the situation for myself where the hud would disappear, I hear the disk thrashing around and then re-appear and continue. Sometimes it would do this multiple times and for long stretches, it tended to behave this way more in busier sectors and without-fail when two races' groups got together for a showdown, regardless of it I was facing them or not.

Vista64 /w 4GB of ram, I edited the exe's 2gb limit flag and life is now peachy, haven't had that happen even once since then. The disk-thrashing is pulling the data from game's data folder after flushing the cache to try and fit it all, not swapfile getting eaten. Pre edited exe TC ate 1.4GB, post it'll now eat 2.2GB after a few minutes in a busy sector.

[Prax]

That was exactly my result.

This game doesn't push the graphics cards at all because the poor core that gets burdended with this game is chocking trying to process what seems to me like textures, which should be processed by the graphics cards, which arent being used at all.

I think this is all just a case of an outdated engine being pushed to do more than it is capable of. IMO they should have scrapped X3:TC re-wrote the entire engine, and just released an X4.

[ragamer]

The problem with hacking the executable is mentioned collateraly by a Mod on the linked thread...

...X3 is not been tested in the big memory model.

What I'm afraid of, in particular, is that X3 saves are partial memory dumps so if something goes funky with some memory pointers and that affects a savegame...

...I don't want to discover in 2 or 3 weeks that all my savegames are been corrupted because of been created under a non-tested memory model.


Now that RegisterMe talks about it, the "GUI" dissapearance (and a small sttuteting) happens sometimes also when a new ship enters through a Gate/Jumpdrive... But as I have played all X games I became "immunized" to that effect as it had happened always AFAIK.

Combat are basically events were a lot of ships dissapear (and in the scripted battles appear also as they "jump in") so it's possible that the combination of the sound overload plus the overhead of creating/destroying objects is behaving erratically on X3:TC.

The other possibility, and sadly famous on this series, is an infamous memory leak that makes the memory consumption increase over time... But so far, this time, I do not detect a time dependency as in other cases on past tittles.

I have the feeling that it may be hard to track this bugger... But I hope they catch it, because big battles on this game are very common and it's pitty that most users can't enjoy them as smooth experiences.

BTW, my OS is Vista 64... So I don't think that, this time, OS matters.

[bumpinthenight]

What I'm afraid of, in particular, is that X3 saves are partial memory dumps so if something goes funky with some memory pointers and that affects a savegame...

I can't imagine how that'd happen, as a hobby-programmer myself I just can't imagine a senario where giving something a larger memory pool would hurt it.

Now that RegisterMe talks about it, the "GUI" dissapearance (and a small sttuteting) happens sometimes also when a new ship enters through a Gate/Jumpdrive... But as I have played all X games I became "immunized" to that effect as it had happened always AFAIK.

I was used to this as well, but it'd never been as pronounced nor nearly as often as I'd experienced with an unedited TC session, I remember the first few times seeing the hud disappear and going 'well that's not a good thing'. It reminded me of when windows' explorer crashes and reloads itself, didn't sit well with me at all and not at all the same as the slight stutter-pause of Reunion's loading stuff as it comes into the environment from OOS.

Combat are basically events were a lot of ships dissapear (and in the scripted battles appear also as they "jump in") so it's possible that the combination of the sound overload plus the overhead of creating/destroying objects is behaving erratically on X3:TC.

If there is one thing I can count on with this game is that when it comes to sound it'll just ignore playing sounds when too many are being used, every time a NPC dialog goes mute because some random GUI noise was made confirms this. Nah this ain't a sound thing.

The other possibility, and sadly famous on this series, is an infamous memory leak that makes the memory consumption increase over time... But so far, this time, I do not detect a time dependency as in other cases on past tittles.

I watch mine quickly grow to occupy 2.2ish GB of ram but it doesn't climb above that, even after a few hours of manually roaming around the universe.

[ragamer]

I can't imagine how that'd happen, as a hobby-programmer myself I just can't imagine a senario where giving something a larger memory pool would hurt it.

Oh... it does happen regularly. The problem are the type conversions applied on pointers, dangerous as hell... Combined with the necesity to migrate to bigger data types to adress memory directions above the 2GB barrier. That's why windows executables include this flag... Old code is good to reuse, but sometimes can have disastrous effects if ported without extensive analysis.

The above is one of the typical problems... If we go to more exotic problems like memory adresses encapsulated on structures, or some typical memory offsets operations that can overflow now... Well, I hope you got the picture .

[pjknibbs]

I can't imagine how that'd happen, as a hobby-programmer myself I just can't imagine a senario where giving something a larger memory pool would hurt it.

As ragamer points out, what happens if you're doing pointer arithmetic, storing the result in a signed variable, then doing something with that result? With more than 2Gb of RAM your result could go negative (top bit set is a negative number in a signed variable). Note that I'm not saying X3 does this, because I simply don't know; I proffer it as an example of a scenario where having a larger memory pool COULD hurt an application, though.

[bumpinthenight]

Wouldn't the only danger be if the compiler/language of choice chose to use a signed vs unsigned pointer-tracker-variable/setup (sorry, hobby programmer ) and the rest of the variables wouldn't know the difference between whether they're stored in the first GB or the 3rd of the pool allocated to the program? Overflow is something I became intimately familiar with coding for MUDs in decades past but again wouldn't the only concern be whether or not the ability to reference pointers was 31 vs 32bit sensitive? I can't imagine negative pointers so ideally it'd be inherently a fully unsigned 32bit system.

I'm just under that impression as since the game didn't crash after getting bigger then 2gb on my computer it should be completely safe to continue running it like that.

ED: Sorry, after re-reading and seeing the part about type conversions for pointers I'm getting the picture a bit better now, thank you

[cucher]

Tryed switching to 3Gb with my system. Well, dont think it helped. Some details: then you load thesave, the game runs ok (even with max settings). I was able to complete Station Defence Mission with few M6 without freezes. But entering new sector caused total performance stoppage, i.e. 1 frame per 5-10 seconds. Thus I assume switching to 3 Gb is not a solution. Glad it helped for other players, but not for me.