Fuerte

I have Diamond MX300 (Vortex 2), the latest drivers, Windows ME and DirectX 8. I tested the stereo with the Control Panel / Aureal Vortex Audio application, and it worked right. Unfortunately I don't have any other game installed at the moment where I could easily check the stereo... except Diablo II perhaps. Are you saying that it works right in your system?

A new version is available ( http://www.sci.fi/~fuerte/pbem.htm ): 1.0.69 (27.11.2000) Fixed: Release 1.0.68 couldn’t send via SMTP, if the From and Sender e-mail addresses were the same. Thanks to Alan Kinner for reporting this! Sorry for the inconvenience… [This message has been edited by Fuerte (edited 11-26-2000).]

Right, but that doesn't help if I use headphones. This is not really a huge problem in this game, but I was just wondering if anyone else has noticed it.

I just noticed that the stereo sound effect is reversed, so the tank hit in the right comes from the left speaker. I have suspected this earlier, but now I'm sure about it. Is this a known bug or is the fault in my system?

My PBEM helper takes care of that "same turn again" problem as well, because it checks the file times before overwriting the actual game files.

I am not aware that overwriting has never corrupted a file. My PBEM helper application supports both MAPI and SMTP. If your e-mail client supports MAPI (MAPI32.DLL), then all your files are saved in the Sent folder, so you have a backup. I personally use SMTP just because I don't want my e-mail program to get filled with old PBEM turns. I have all received turns in a separate e-mail folder (automatic Outlook Express mail rule), and that is enough for me.

Overwriting is correct. My PBEM helper application supports only games where the file name remains the same. Try it. It remembers all e-mail addresses and you can send all e-mails with one mouse click. http://www.sci.fi/~fuerte/pbem.htm

I can confirm, it helped. I see no difference between partial and full fog.

Thanks, have set that, hope it works.

I have ASUS GeForce DDR 32 MB and the latest ASUS 6.32 beta 5 drivers. We are playing a generated PBEM game which has fog. The problem is that if I enable partial or full fog support, then the whole display is gray, I can't see anything. I belive that the resolution is 1024x768, 16-bit color depth. Any ideas? Should I change to 32-bit, and how it is done? I have DirectX 8, no problems with other games.

<BLOCKQUOTE>quote:</font><HR>Originally posted by paullus: I have not yet attempted PBEM (due to my schedule), but am extremely interested in going through with the TCP/IP gaming when it becomes available.<HR></BLOCKQUOTE> This is paradoxal. You don't need a schedule to play PBEM, but you need it to play online.

If somebody is still wondering if you should try this, read the following comments from SPWAW forum: "For those of you that haven't taken a look at this program and you run more than one pbem at a time, do yourself a huge favor. This is one sweet looking program, it's a 5 star folks. Fuerte followed KISS to the letter (Keep It Simple, Stupid) and that is the mark of a good program. I've come close to tearing out my hair in making sure I'm sending the right files many times, I thank you very very much." All the bugs have now been fixed (hopefully), so go and download it. You won't regret.

PBEM 1.0.65 is now available. Release notes: Fixed: The time zone conversion was managed already by Info-Zip routines, so my routines just doubled the time difference. I removed the unnecessary code. Funny that WinZip 8 and PKZip25 don’t understand different time zones.

There is a new version already: 1.0.62. It fixes one nasty zipping problem.

Check it out! It will make your PBEM life a lot easier.

I made a program, which compresses and sends PBEM files automatically, and also decompresses the received files automatically into correct directories. It supports currently two programs: Steel Panthers: World At War Combat Mission: Beyond Overlord Read the documentation and download instructions here: http://www.sci.fi/~fuerte/pbem.htm WARNING: This is the first public release. This program has not been tested thoroughly. Please post all problems and questions into this forum under this topic. Enjoy!

<BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software: If CM used integer instead of floating point, both would be slower. However, my G4 would probably be 3 times as slow as it is right now. That is a nice little argument for using floating point math to me <HR></BLOCKQUOTE> Again a misunderstanding... I meant that you should use double precision floating point instead of single precision. You said previously that you are using "float" in C, not "double". But even that may have been a misunderstanding! But I still think that integer math is (always?) faster or as fast as floating point math on most CPUs. In the current CPUs both are probably executed in single cycle, and in good conditions even many operations in one cycle. But of course there is no sqrt operation on integers built into CPU, so if complex arithmetic is needed, then floating point is faster.

<BLOCKQUOTE>quote:</font><HR>Originally posted by degreesK: With the help of a friend with a Mac I've managed to get the following chaotic function to give the same results on both Mac and PC for doubles. Wasn't able to get the same results when using floats. PC gives the same results on AMD/Intel and Win98/2000. <HR></BLOCKQUOTE> Exactly, I believe that with a good compiler and double precision it could work right away, even without any extra floating point tricks. But BTS have said that they are using float, and a CodeWarrior compiler, which I don't know at all. It might be good but I just don't know it (or anything about Mac development). I have also said previously that the decision to make it more like PBEM is a good one, and I still think that way. But the use of floats must be a mistake, there can't be any speed difference.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software: Funny enough, last week when I forwarded the stuff about the double precision stuff to Charles he said, right away, "yeah, but some functions like square root will screw that up". So me thinks chrisl is correct on this one.<HR></BLOCKQUOTE> Sure chrisl is technically correct, but in practice the double precision floating point would certainly work. Just check for zero (with some epsilon value) before every squre root operation... there can't be so many. "It is preferable to either treat a floating point field as character data that is immune to rounding errors or incorporate a small offset value into comparisons (known as an epsilon value) to allow nearly equal values to be considered sufficiently equal."

<BLOCKQUOTE>quote:</font><HR>Originally posted by chrisl: This won't work-- a simple square root operation can propagate an incorrectly rounded digit near the least-sig-fig of the double back to near the least-sig-fig of the single (but where it won't be rounded away), and then it won't give the same result on different machines. All numbers have to be consistently rounded by every mathematical operation that's done on them, i.e. you have carry extra (guard) bits around and perform a consistent (from machine to machine) rounding operation after each and every mathematical operation. This is described in the Sun document referenced above (scroll down to the stuff about IEEE 754). I'm not at all up to date on how chips or compilers treat this, but it wouldn't be surprising if you had to use software libraries that give you a performance hit if you want to be IEEE compliant.<HR></BLOCKQUOTE> It would work. You can't have so big errors in double precision calculations (15 digit percision) that they would propagate to the seventh digit (where it would be rounded). Or if you insist, then give an example. And good compilers like Microsoft Visual C++ are IEEE 754 compatible (to my knowledge). From MSDN: "/Op (Improve Float Consistency) The Improve Float Consistency (/Op) option improves the consistency of floating-point tests for equality and inequality by disabling optimizations that could change the precision of floating-point calculations. By default, the compiler uses the coprocessor?s 80-bit registers to hold the intermediate results of floating-point calculations. This increases program speed and decreases program size. However, because the calculation involves floating-point data types that are represented in memory by less than 80 bits, carrying the extra bits of precision (80 bits minus the number of bits in a smaller floating-point type) through a lengthy calculation can produce inconsistent results. With /Op, the compiler loads data from memory prior to each floating-point operation and, if assignment occurs, writes the results back to memory upon completion. Loading the data prior to each operation guarantees that the data does not retain any significance greater than the capacity of its type. A program compiled with /Op may be slower and larger than one compiled without /Op. Note The /Op option disables inline generation of floating-point functions. The standard run-time library routines are used instead. For more information, see the /Oi option. If you select the Disable Language Extensions (/Za) option in order to compile for ANSI compatibility, the use of /Op is implied. The use of /Op improves the consistency of floating-point tests for equality and inequality. The nature of the improved consistency provides for strict ANSI conformance and is the only situation under which /Op is selected by default." "/Op Ensures the precision of floating point operations. This is useful when you are concerned about error propagation and intermediate results of floating point operations. The following topics contain information on understanding floating point operations: IEEE Floating-Point Representation and Microsoft Languages and Why Floating Point Numbers May Lose Precision."s "Microsoft Visual C++ is consistent with the IEEE numeric standards. There are three internal varieties of real numbers. Real*4 and real*8 are used in Visual C++. Real*4 is declared using the word float. Real*8 is declared using the word double." "For EPSILON, you may use the constants FLT_EPSILON defined for float as 1.192092896e-07F or DBL_EPSILON defined for double as 2.2204460492503131e-016. You need to include float.h for these constants. These constants are defined as the smallest positive number x, such that x+1.0 is not equal to 1.0. Because this is a very small number it is advisable that you employ user-defined tolerance for calculations involving very large numbers."

<BLOCKQUOTE>quote:</font><HR>Originally posted by chrisl: That's not likely to work either, as the deviations due to machine differences can propagate up if you do multiple calculations with a number.<HR></BLOCKQUOTE> It would work. If all calculations would be done with double precision floating point (precision 15 digits), and all comparisons with single precision (7 digits, rounded correctly), for example, then it would work. This is all theoretical, of course there is no reason to do it this way.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software: So if one machine turns up 1.00001 and the other comes up with 1.00002 there is no way for the first machine to know that it must have 0.00001 added in order to be the same as the other.<HR></BLOCKQUOTE> You didn't quite get what I was meaning, but it really doesn't matter. I'm sure that the new TCP/IP play which resembles the current PBEM play is the correct way of doing it. But if you want to know what I meant: If BOTH computers add 0.00001 to 1.000001 before comparing it to 1.000002, then BOTH computers think that the first number is greater, and we have a penetration (or something) on BOTH machines. After thinking a bit, I think that my logic is flawed. The only way of doing the comparison right is to round all numbers to some precision before the comparison, as someone suggested. [This message has been edited by Fuerte (edited 11-11-2000).]

<BLOCKQUOTE>quote:</font><HR>Originally posted by aka_tom_w: Is there any chance these suggestions could be part of the solution for the simultaneous crunch, on one common complier? Fuerte sounds like he may know about these things.<HR></BLOCKQUOTE> I'm not really an expert, but considering that the Seti@Home client works on several different platforms (even Unix/Linux), it should be possible to use such floating point routines which work exactly the same on all platforms.

From the numbers you gave it seems that you are using single precision (32-bit) floating point numbers. If that is so, then the fix is easy: use double precision (64-bit). If you are using double precision already, then you should just use a C compiler with IEEE 754 support. It is a standard which works the same in all computers. Good compilers can even work around the Pentium FDIV bugs with proper settings. I don't know, perhaps Macintosh doesn't have a proper compiler and that is the problem.

Only on page 39? Wait until I'm boozed next time.