bernyeh

Sorry, looks like I somewhat misunderstood the context of your code snippet, but performance code is somewhat of a hot button for me. I agree that a construct like that can help greatly in performing bounds checking, though I prefer the use of asserts or explicit debug enabled bounds checking code. I don't think that PBEM file concerns had much to do with the selection of using char types for many integer values. After all, all data (regardless of size) is being packed and converted into a seven-bit (with useless eighth bit) ASCII encryption format. BTS may have been concerned about keeping run-time memory footprint as small as possible, in accordance with their desire to keep the game runable on somewhat older systems. I'm just commenting that this will have a (minor) performance impact on current system architectures. I doubt the hit is very large, since I think their use of chars/shorts is probably not too prevalent, and probably not in a critical code path.

<BLOCKQUOTE>quote:</font><HR>On a side note, here's a neat trick: #ifdef DEBUG typedef signed short u8; /* to catch overflow/underflow bugs */ #else typedef unsigned char u8; /* for performance */ #endif <HR></BLOCKQUOTE> Huh? Operating on anything less than 32-bit values is usually a performance hit for most 32-bit CPU architectures. Basically, if the compiler was dumb, the CPU has to do an expensive 32-bit alignment operation before doing any math on it. If the compiler was smart, it would align that char or short size location into a 32-bit location ('wasting' 24 or 16 bits). As for the memory latency cost of using 32-bit values, it rarely is an issue today. Current x86 system architectures bring in 32 bytes at a time from memory into the L2/L1 cache, regardless of how much data you really want. And once in the L1 cache the memory latency cost between a char, short, and long is identical, since the CPU almost always brings in 32-bits at a time from cache. Some older programming books (mainly pre-Pentium circa 80's/early 90s) have suggested using char types to reduce memory latency cost, mainly due to slower memory of the time, and the tiny or non-existant caches in 486 and earlier CPUs, but this is no longer the case for general purpose computer CPUs. Moral: always use long integers for performance. As for signed/unsigned, at least for x86 CPUs, performance-wise, there is no difference between the two in most basic integer arithmetic operations. I don't believe there's a difference in PPC CPUs either. This might have been the case in some early RISC architectures (like early-mid 80's MIPS or SPARC), but not since then. Apologies for the computer architecture digression.

Follow-up: Actually, the reason why I didn't notice before was because it doesn't happen in single player, or 2-player hotseat. It is happening in my PBEM games. After some more checking, It appears it's not consistent, as I can't seem to recreate the reverse audio effect. I noticed the reverse audio effect after processing 5 different PBEM games turns in a row, I noticed the problem in my 6th and 7th PBEM game turn. (these are not 7 turns of one game, these are 1 turn each of 7 different games). After some more testing, I can't recreate it simply by loading each pbem file I did today, and running through each once. My guess is that some combination of escaping from the game, and doing the actions of each turn, somehow reversed the audio. In any case, I think quitting and restarting the game will fix the problem the next time it happens. I am positive, though, that the reverse audio effect happened.

BTS: The CM audio is clearly reversed (sounds on my left perspective from the 3D view are coming out of my right speaker, and vice-versa) on my desktop PC system, with a Diamond Monster Sound MX300 (basically an A3D Vortex 2 sound board). I'm using Aureal reference drivers 4.06.2041.04. I didn't really notice before until I put in the MDMP-1 sound patch... Aureal's test applet tells me that left is left and right is right. This is also the first game that I've had that has this problem. Thief/Thief 2/System Shock 2, games where positional audio clearly matters, was not reversed and I did not need to check the 'reverse audio' option in those games. In any case, in the next patch, could you put in a reverse audio option? There doesn't appear to be any option in the control panel applet to reverse audio. Thanks.

Another generalized plea for help. If anyone out there has Win98 running with dual-monitor support on, are you having trouble running CM? I'm trying to narrow down what the potential problem with the drivers are. Thanks.

Yes, I've tried ATI's site. They don't appear to provide drivers for Rage Mobility chipsets. They point you to the laptop vendors.

Greetings: I'm a long time lurker of this board, and I'm looking for a couple of blind PBEM games, since my copy arrived Friday (pre-ordered early december 1999, if you must know...) I am a PBEM newbie, and I've not played any of the scenarios, except the tutorial and the first operation, and a bunch of random battles. If you're interested, send me an email at: bernyeh@yahoo.com. I'll probably accept the first half-dozen requests (don't have time for more). Also I request that all games use Full Fog-of-war. Thanks.

As a follow up, I tried Soldier of Fortune on this machine, and it appears to work just fine without any special modifications. (running it at 1024x768 with full screen scaling)

I'm having problems with getting CM to run on my Dell Inspiron 5000 laptop with ATI Rage Mobility-P AND Super XGA screen (ie 1400x1050 max resolution) Basically, after the game loads the 3D engine, after some time scrolling through the landscape (usually less than 1 minute), the game hangs, ie can no longer scroll, buttons no longer works, can't exit to windows, can't ctrl-alt-delete, have to power down and power back up. I've tried various resolutions (800x600, 1024x768, 1280x1024) and they all eventually hang. I've tried disabling the full screen scaling for lower resolutions. Windows98 is reporting the presence of 2 monitors, (the other is I think the S-Video out) and I've tried disabling the other monitor in hardware. Combat Mission is also reporting 2 display drivers for each resolution, and I've tried both. I've tried both versions of the drivers available at the Dell site. I've updated directX to 7a, and then reinstalled the video and sound drivers. I've updated my mouse drivers (tried both synaptic touchpad drivers, and logitech mouse drivers w/externally attached mouse). I've tried reducing hardware acceleration 1 notch (2 notches forces software mode). I've tried monitor tricks described previously on this board. None of the above have resolved the problem. Software rendering does work, though, so it appears really to be a problem with the video drivers. Haven't tried any other 3D games on it yet, so I can't tell if it's CM only or something more global. So any other suggestions, or is it wait for new drivers from Dell and see if they work? Thanks.