A couple more bugs

[Guest Imperator]

In an operation where I had Escort Squads, I split one in the first battle and left it split. During the setup phase of the second battle, I noticed that both of the split parts of the squad now had 7 members, as if they were full squads, though otherwise they were still tracked properly. However, when I recombined them, the active/casualty display went crazy. I had -23 active out of 32. The breakdown of weapons in the info box was correct, however.

Ammo seems to wrap around when multiple units are expended at once. For example, my Pillbox MGs, which seem to be expending 3 ammo units at once (presumably because all 3 guns are firing at once for some reason), often wrap to 254 or 255.

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

[This message has been edited by Imperator (edited 06-27-2000).]

[krm]

???

------------------

I'm always in the ****, it's only the depth that varies.

[Guest Big Time Software]

Bugs fixed!

Charles

[bernyeh]

<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.

[Guest Imperator]

My guess is that they're using chars to save space in the saved games; when you're sending a file by mail, every byte counts. (Actually, it doesn't, and the PBEM files could be much larger without a serious problem.)

I wasn't suggesting using signed or unsigned for performance reasons; rather, it's to catch overflow/underflow bugs. (Careful coding and assert()s help too.) But let's say they had used a signed short instead of an unsigned char during development. Then they'd have noticed pillbox ammo being negative, through a crash, failed assertion, or tester that spots a negative ammo count. That's what I was suggesting, not that they'd get any noticeable performance gain from using a char.

[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.