posted 02-15-99 08:03 PM ET
Jeffrey: thanks for the reply. It really is mystifying.To add a few things to what I posted before:
1) the CrystalFusion chip "may" not only be a Dell issue. It's on an OEM Intel motherboard. Now, it might be one made to Dell's specs, or Intel might have sold it to other manufacturers. Even if it's only Dell they've been pushing the on-board sound option as a way to hit price point and save the $100 for a built-in Zip drive instead of a sound card (saves a slot too.) So, it might be bigger than Dell owners, or not, is my point.
2. The in-game music plays fine, and doesn't seem to be affected at all. No popping, no echoes. Only the .wav files (the voice-over files.)
3. I "think" the popping and the echoing are separate issues. Even when I fixed the .ini file to be ds3d=0 and eax=0 I had popping (and echoing.) Previously, with both at "=1", I had no in-game sound or music at all. With the new Dx6.1 and sound drivers I get rid of the popping, but not the echoing.
4. I assume that sound worked for the QA folks (duh), and that many/most of the people running the patch aren't having trouble. But perhaps (I'm no programmer, so bear with me) the problem isn't only a "sound" problem. It might be manifesting through the sound, or the sound hardware/software could be opening up a new, unintended logic route in the patch code (maybe to do with the PBEM or hotseat modules.)
The reason I say this is the echoing sounds like a new base is being "housekeeped" before the last has finished its comments. I assume there's a logic loop that runs through the base list in that phase, calling subroutines to calculate resources, look for drone riots, finished production, etc., and if the code finds that the state is met it jumps to another subroutine to update to the new state, and orders the .wav file played at some point. How it knows to wait for the end of the .wav file before playing the next base's .wavs I don't know, but right now its timing is off, almost like it's allowing a jump to the next base's housekeeping loop out of the middle of the last .wav subroutne call.
Now, if that's true, I have no idea how sound hard/software could cause it. Might be a dumb idea; like I said I'm no programmer. But it's unusual for a patch to break formerly working sound. This case is suspicious because Brian went deeply into the .exe to rework code on the new PBEM, etc. stuff, rather than just fixing unit specs. So, maybe the sound glitch is evidence of something deeper. I can live with the sound (I'll go to unpatched if it drives me crazy) but I'd like to know all the base housekeeping is really being done before it moves to the next in line.
Hey, one more thing. I know you must feel like you're at the end of a big, wide funnel, and the whole world is throwing mud down on you. The game, as shipped, is fantastic, and worth every penny. If you didn't change a thing I'd feel like I got more than my money's worth. Right now I'd guess things there are crazed, but it's a good kind of crazed. We all just want it to be perfect, and it's darn close. So take a deep breath, don't lose perspective, and take 'em one at a time. You guys are doing good work. I'm sure all this will be fixed soon, and like I said, right now it isn't even very broken. Don't let 'em wear you down! <g>
Snoman