Half- Life 2 Stutter Solved

As a followup to the story on Saturday about the HL2 stutter bug, Voodoo Extreme has news that a patch is on the way, with an ETA of tomorrow. "A patch will be coming for this issue that will load all of the required textures into video memory on level load, rather than doing it during game play."

Comments

hmm?

[Sv-Manowar]

"A patch will be coming for this issue that will load all of the required textures into video memory on level load, rather than doing it during game play."

Surely this would have been noted during Beta testing, unless they were testing on all high end machines ?

Re:hmm?

[jpmoney]

I'm not sure what these "high end" machines were. I have the problem (intermittantly and only for a few seconds, but it does happen) on my Athlon 64 3200+, 1G PC3200, Nvidia 6800, etc. I know its not the "latest" with PCI express, etc out, but I'd still call it "high end".

I guess if I had a 4.0ghz overclocked, watercooled system with a 512 meg 6800 Ultra PCI express (do they even exist yet?) I'd be smooth, but for now I'm mostly smooth.

You think it'll work? It'll take a miracle (or longer load-times upfront).

That is the root question though - how did this bug get through QA? Its fairly annoying and beyond that takes away from the "immersion" you have during gameplay.

Hmmm....

[comwiz56]

I wonder what else this patch will include. Maybe some anti-piracy stuff. Valve has to working on cracking down on that more. Anything else that needs patching?

Optimization gone awry?

[seanellis]

Rules of Optimization:

• Rule 1: Don't do it.
• Rule 2 (for experts only): Don't do it yet.
• - M.A. Jackson

Aggressive memory management of textures is an optimisation. If you don't absolutely need to do it, you shouldn't do it. And it seems from the nature of the patch that you don't absolutely need to do it.

Obviously, I'm not being 100% fair - perhaps it needed to be done and then the texture load went down because the assets were redesigned.

Re:Great (sarcasm)

[ZosX]

Going from stage 1 to stage 2 takes some CPU power as well as disk access. Going from 2 to 3 is probably a lot easier on the system, even if the system memory has been paged out (just page back in, no significant CPU cycles used, just a bit of latency).

By hitting the pagefile, the resulting memory space is swapped. It would take it a very long time for it to be passed from the hard drive back into RAM. Probably it would occur somewhere around 33-66 MB/sec. Compared to the hundreds of megabytes per second that DDR memory can pump out. A hard drive is a whole lot slower than just having that data cached in RAM. The last thing you would want to do is swap it out, and it would be more likely that the operating system's components would be swapped out before an actively running task's would. Ever let windows sit idle when running apps that eat up most of your physical ram? When you close that application and let the system swap back in, it can take a few good minutes for the system to be responsive again. While the preemptive tasking in Windows leaves a lot to be desired for (IMHO), it still tries to balance I/O with user interactivity, however I have seen W2K choke with just a 10% cpu kernel load, while heavy paging is happening. If you are pulling information off of the drive (happens a whole lot in 3D games), you would certainly not want the drive to accessing paged memory at the same time. Sound starts stuttering because it is not being cached fast enough, etc.

Sorry just a ramble. Swapping is and likely will always be a very large performance hit.

Revolutionary Slow Motion Feature

[vhold]

This will really date me, but on the box for Conan for the Commodore 64, it advertised:

"Revolutionary Slow Motion Feature when the action gets really intense."

It was basically the same flickering slow motion many c64 games got when the hardware wasn't up to the task.