Yuku free message boards

Tassen wrote:

---

Try to unpack just the first pack file, demo1.pack, and see if there's a difference. For me, it was like night and day!

Unpacking will make an impact for everyone but this specific issue for certain people will still remain. People can test if they want.
Although it does somewhat confuse the scenario because there are several loading problems, some people have several, some one, some none.
I actually want to focus one one issue in this topic specifically, other wise we will have too much confusion and clarity will be muddied.
People can try unpacking. Unpacking demo1 did absolutely nothing for me (I unpacked it twice on 2 fresh installs to be sure), but then again I was not having any IO issue either.

A normal load time with the demo should be about 1 minute with recommended specs, faster machine even less 40 sec. But we don't get that.

ShellShockEZB wrote:

---

I suggest it may be helpful to use the Windows perfmon tool to capture detailed performance counters. Run perfmon from Start, Run. In Vista there is a pre-defined Data Collector Set for System Performance, which has many very useful counters. I won't have time to do this myself until Sunday, so here is the brief idea of how this works.

You need a clock/watch that is independent to your PC clock.
Synchronise your watch time with your PC clock time, to the second.
Start the Data Collector Set for System Performance (or define your own with the same counters).
Make a note of the watch time (hours, minutes, seconds) and start Empire at the same time.
When the Sega splash screen appears, note the watch time again, at that time.
Make a note of the watch time (hours, minutes, seconds) and start the land battle at the same time.
When the battle is displayed, note the watch time again, at that time.
Exit Empire.
Stop the Data Collector Set.
In Performance Monitor, click Ctrl+L to load the log file you have just captured (the properties for the Data Collector Set has the location of the log file).
Go into the Properties (Ctrl+Q). On the Source tab, set the time range to the watch times you recorded above, either for the Empire load or the battle load. This narrows the data set to when the problem actually occurred.
Now add counters of interest (Ctrl+I). For example, for the Process object, you should see an Empire instance. This will have lots of counters for Empire, e.g., processer, memory, I/O.

This performance information is captured to a single binary blg file. It would be great if this info could be of use to CA; I'm sure people here would be willing to submit it to them.

Yeah good stuff, I've been using ProcMon. It's pretty useful to show you point by point what is going on. I can see it's not an IO issue, something happening in a thread for long periods of time without any IO.

I only just realized in the last half hour this entire issue which seems to show up on certain machines seems to come from another issue, it infact triggers this issue we are dealing with, and it happens real early at startup.
If the first issue is circumvented then this one doesn't appear.
My guess, without going into to much detail, is it is a real early bug in code initialization that if something that doesn't happen the way it should then this whole load time goes crazy, but the latter issue still seems to favor certain configurations.
So it may have to do with some real early render initialization logic, or even before in querying device caps or something.
I''ve actually been getting up to menu in 7 seconds lately and that is right after it took 53 seconds on the previous starts with commensurate level loading time, only because I stumbled on what appears to be a trigger.

While I think it's imprortant to report this stuff now so CA can see it (anybody looking ?) and get us our patch out on March 4th to rectify it, there's only so much deep troubleshooting I'm willing to do at this stage.
i already probably spent too much time not knowing the state of the final code or without any input. My thought is just to provide some quantifiable evidence that unique issues exist that are not part of one big lump called "slow load times".
If CA wants us to provide them logs they should probably tell us.
Hey but feel free, more the merrier. ;)

Ightenhill wrote:

---

Though why I can do it in seconds and under a minute whilst others take way longer is still odd

Yes the executable looks for files that aren't there whether packed or unpacked, but it is irrelevant because the amount of seconds this takes I took into account day one, I counted how long that IO took and it wasn't excessive.
And that is the crux of the issue at hand, why certain people have certain load times and others do not on hardware that should only show a few seconds difference at most. This is why I am not really interested in speeding load times by unpacking, it ruins the experiment.
I'm trying to take an empirical approach to find out why some people load in under 1 minute into a land battle and others 2:30 +- (1:30 without AA). Additionally, it seems related that AA takes 50 seconds +- to load for them (not positive it is directly related but it appears that way).

If I genuinely was focused on just getting fastest load times I'd try loading it all to my ramdrive, put the files there, and blow everyone's load times out of the water. But that doesn't help identify any patterns or causes for anyone.

That's why I said unpacking confuses things. When you have an experiment, you have a"control", Group A who load without any excessive strange issue, then you have Group B those who have a strange issue (without a placebo effect, it's quantifiable).
Then you look for patterns and differences. Sprinkling "unpacking" into test tubes randomly doesn't exactly help get to the root cause, it muddies the experiment data.
I think I have found out why unpacking helps some while to others it seems to have little effect, but that too is outside of this topic.

The cause of this issue, if rectified directly or indirectly, will actually result in helping load times for people. I know it's what people want, I'm looking for a cause though. The loading times for Group B is an 'effect' of a deeper 'cause'. Fix the cause and the effect is removed.

CA will likely come up with general improvements to load times, but that doesn't mean they will fix this specific issue.
Even if load times drop 15 seconds for everyone, if they don't fix this particular issue, Group B may still have longer load times by about 30+- seconds.

In the end, if this specific issue doesn't have any other deleterious effect for Group B (strange AA load, strange rendering bugs, any other bugs) then I guess I am ok if it takes me 30 seconds longer, I can live with that if that is all.
I'm just not entirely convinced nothing else is affected at this stage. AA adding 40-50 seconds to load gives me pause on the rendering pipeline, although I'm not absolutely sure yet it's directly related to this issue.
There are actually some specific game play bugs that should be higher priority IMO.

Since CA is absolutely silent on any of the specific bugs they are addressing, we will have to just wait and see what the retail build, along with the zero day patch, really brings. My goal was to make the issue known and have evidence it exists, that's all I can do.
I only hope they are a developer that makes patch logs available to the public.

Ightenhill wrote:

---

are we still thinking it only affects the 8 series or have you moved away from that.. (As I now have not got an 8 series in the room to test with anymore)

As far as I am concerned, I'll follow it wherever it leads. I haven't tallied things in the last day or so bit it does look like some 4800 users may be experiencing it too.
From the surface it looks that way, although is it possible some of those users have longer load times due to something else, I don't know.
So I don't know if it's necessarily based on GPU's at all, seems to point around that.

But as I recently mentioned there seems to be a deeper cause that actually triggers all of this for a certain group, that some 'may be' getting around by default, so that adds a layer I didn't really want to see.
It's a trigger that "seems" linked to performance, if a certain thing takes too long (milliseconds) in initialization then stuff hits the fan, which adds a difficult variable. For the most part, everyone is hitting the trigger though and it's effecting a certain group more than others, it's likely a specific configuration. A person in Group A who was supposed to send me some testing info fell sick in the hospital, he has other things to do, so that's where we are.
It would be foolish for me to waste my valuable time digging into this any deeper at this time. I guess we'll see if I carry the flag forward after retail, I just want to play the game like everyone else.
If it was a showstopper bug, then I'd be more motivated as I've been in fixing other games, but it's hard to say how motivated I'll be after release.