Guest Big Time Software Posted November 6, 2000 Share Posted November 6, 2000 Anybody that read the previous TCP/IP update knows that we have this really ultra slick system that makes turn sending between the two machines almost instant. This was done using sychronized random numbers so that each machine could process the turn independently of the other from the first second of combat, as opposed to the way PBEM works where one processes the whole 60 seconds and then sends it to the other. Initial testing went so well we blabbed about it here. Er... bad idea We encountered a hardware problem that kills this rather cool turn processing method. There is no work around, so we are recoding things so that it works a bit more like PBEM. It will involve less "swapping" of data than PBEM, so it will still be quicker to do a TCP/IP game. However, it won't be as quick as we thought. The problem has to do with different famalies of CPUs, and perhaps even different speed ranges within a family of chips. What happens is each CPU has a slightly different way of rounding floating point numbers. Even if a value is off by 1/1000ths it can cause the game to "diverge" and thus each player will see a different game play out than the other guy. Needless to say that isn't good. Here is an example to show you the problem... Let us say that a Panther needs to rotate its hull in order to defend against an enemy Sherman. The Panther notices the threat at second 34.25 The Sherman fires on second 39.25. This means the Panther has 5 seconds to rotate before the Sherman fires. On one machine it is calculated that the Panther manages to rotate its hull 19.0001 degrees, but due to the rounding problem on the other machine the Panther only rotates 18.9999 degrees. This might not look like a big difference (and it isn't), but believe it or not it could make the difference between the Panther surving the shot or getting knocked out. Obviously if the Panther survives on one machine and dies on the other... the game is totally hosed. Unfortunately, this is not a theoretical problem. It was, in fact, discovered because of a situation very similar to the one described above. And this was after only a day's testing by 3 people. Which means such problems will happen quite frequently, and therefore our current method must be trashed and the safer, but slower, system put in place. This whole deal will cause a minor delay since the recoding effort should not be too bad. The majority of the TCP/IP coding involved getting the machines to talk with each other, deal with lost connections, new interface, etc. We'll give you another update in about a week. I am sure a lot of you will try and suggest ways we can work around this problem. Trust me, we spent all weekend trying to figure a way around this problem. But there is absolutely no way around it, therefore we must toss out the current method in favor of oen that works 100% of the time. Sorry for the bad news. Fortunately, we have had very little bad news to report over the last two years. So think of this as your fill for a while Steve P.S. Charles and I did the first test. Unfortunately, we both have the same CPU so this problem wasn't noticed until we widened the testing group. [This message has been edited by Big Time Software (edited 11-06-2000).] Link to comment Share on other sites More sharing options...
Hiram Sedai Posted November 6, 2000 Share Posted November 6, 2000 Thanks for the update. I have faith that you guys will put out a quality product again. ------------------ Did someone compare this to the Peng thread? I've apologized for less. -Anonymous Link to comment Share on other sites More sharing options...
Jadayne Posted November 6, 2000 Share Posted November 6, 2000 aw, shucks. ------------------ "I'm the Quarterback. I make the plays. You back the plays I make." -Harvey Keitel to his adopted son in the movie "Dusk til Dawn" (about 3 hours before they're both ripped apart and eaten alive by vampires) Link to comment Share on other sites More sharing options...
aka_tom_w Posted November 6, 2000 Share Posted November 6, 2000 ooops! Back to the drawing board, I guess. Thanks for the detailed explantation of the technical nature of the problem, I think this is WAY above and beyond the call of duty, but we all sure do appreciate it. And yes you are likely correct we all now trying to figure out a new solution you have not thought of yet. BUT it does make sense to ONLY crunch once and to crunch the turn on the fastest cpu, so I guess one cpu will host the crunch, I really can see how the floating point math problem woudl kill your first idea and how it really does differ from cpu to cpu would REALLY screw up the simultaneous crunch, it WAS a GREAT idea if you could have really made it work. Sorry to hear about that little set back. Oh well, lets move on! -tom w Link to comment Share on other sites More sharing options...
Croda Posted November 6, 2000 Share Posted November 6, 2000 Have you tried running a re-sync script that attaches the multiplicular Z-tex globulets to the already de-modulated tones? This should allow the stepping to be rounded down .5 megapixels, causing the CPU to round it's floating point decimals by 13/98ths instead of the current configuration. I also think that it will cause the M8 Greyhound to look like Mickey Mouse's dog Pluto...an unwanted, but passable side effect. ------------------ "Nuts!" Link to comment Share on other sites More sharing options...
Juardis Posted November 6, 2000 Share Posted November 6, 2000 <BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software: Anybody that read the previous TCP/IP update knows that we have this really ultra slick system that makes turn sending between the two machines almost instant. This was done using sychronized random numbers so that each machine could process the turn independently of the other from the first second of combat, as opposed to the way PBEM works where one processes the whole 60 seconds and then sends it to the other. <HR></BLOCKQUOTE> Slick and sexy way of doing it. Too bad it didn't work . I was trying to figure out how you were doing this without one machine acting as the master and the other the slave (easy perverts, I'm talking about a game here ) Thanks for keeping us in the loop so to speak. ------------------ Jeff Abbott Link to comment Share on other sites More sharing options...
JeffRaider Posted November 6, 2000 Share Posted November 6, 2000 Sorry, guys. Nice work, anyway. Link to comment Share on other sites More sharing options...
Splinty Posted November 6, 2000 Share Posted November 6, 2000 Thanks for the update BTS,I'm glad you're taking the time to do it right. ------------------ Nicht Schiessen!! Link to comment Share on other sites More sharing options...
David Aitken Posted November 6, 2000 Share Posted November 6, 2000 What was that about a floating Panther? Link to comment Share on other sites More sharing options...
Guest Der Unbekannte Jäger Posted November 6, 2000 Share Posted November 6, 2000 Thanks for the update, even if it isn't the best of news. ------------------ "I may disagree with what you have to say, but I shall defend, to the death, your right to say it." Link to comment Share on other sites More sharing options...
PeterNZer Posted November 6, 2000 Share Posted November 6, 2000 Loops! Slaves! Masters! You're getting me excited man! O well BTS chaps, these things happen. Glad to see and read the detailed update PeterNZ Link to comment Share on other sites More sharing options...
Guest aaronb Posted November 6, 2000 Share Posted November 6, 2000 <BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software: What happens is each CPU has a slightly different way of rounding floating point numbers.[...]I am sure a lot of you will try and suggest ways we can work around this problem. Trust me...<HR></BLOCKQUOTE> We - at least I - trust you, however, consider these two possibilities: - use BCD representation with your own RAN() function. You might have to do this in assembler - I'm not that current on compiler technology or the Intel/68K architectures. - use good old scaled integer representation, again with your own RAN() implementation. This you could do in ordinary C, and you can make it portable by fixing the number of bytes in your INT's. I've done sync'd pseudo-random systems (not for games), and these are the two ways we made it work. Both can be blindingly fast with the right optimizations, especially if you accept one of the fast-but-not-uniform pseudo-random algorithms. Link to comment Share on other sites More sharing options...
Guest SS Peiper Posted November 6, 2000 Share Posted November 6, 2000 Thanks for the update BTS SS Peiper Link to comment Share on other sites More sharing options...
mensch Posted November 6, 2000 Share Posted November 6, 2000 I guess a update computer from you guys are out of the question? hmm what did you use G4's? if so Put me on the mailing list for the Upgrade G4 (500 Mhz would be nice).. boy its so nice of you guys to do this.. I mean what service! or the cube. ya the cube would be great! ---------- Der Kessel Home of „Die Sturmgruppe“; Scenario Design Group for Combat Mission. [This message has been edited by mensch (edited 11-06-2000).] Link to comment Share on other sites More sharing options...
Priest Posted November 6, 2000 Share Posted November 6, 2000 No probs here. Everyone tends to forget that when listing the great things about the game we forget to mention BTS as a whole. Not only do we get lots of patches and access to the designers of the game. But most importantly we got no BS reports from them which is rare these days in the PC game biz. Thanks BTS ------------------ Sir are you sure you want to go to red alert...it would mean changing the bulb -Priest Link to comment Share on other sites More sharing options...
Four Stringer Posted November 6, 2000 Share Posted November 6, 2000 D'OH!! ------------------ Homer: [gulps] I suppose you want to probe me. Well, might as well get it over with. [unzips his pants] Kang: [disgusted] Stop! We have reached the limits of what rectal probing can teach us. Link to comment Share on other sites More sharing options...
Spook Posted November 6, 2000 Share Posted November 6, 2000 Regardless, BTS, it was a sterling effort on your part for your first TCP/IP effort, and demonstrates the stake you have with your customer base. A larger PC game company would likely have said instead: "Floating point error? So what? Ship out the TCP/IP patch out now to give the lemmings what they want, stop using up so much time on something that isn't generating new revenue NOW, and get working on the next title. We MIGHT re-patch this 'floating point' IF the lemmings have enough attention span to still be playing this specific game a couple months from now." "Errr.....scratch that last thought. Let's attach a floating-point fix later with a 'CM Elite expansion pack' where anyone wanting this thing fixed right away has to buy the add-on pack. Then a couple of months later, we MIGHT provide a downloadable fix." If you followed the conduct of certain gaming companies very closely last year, then you'd see that what I've described isn't too far-fetched. Link to comment Share on other sites More sharing options...
Maximus Posted November 6, 2000 Share Posted November 6, 2000 Hey guys, **** happens and when it does, you just gotta sit back, drink a brewsky, and rethink things. But hey, you guys haven't let us down yet. Just wished there was a way to tweak the Operational AI to allow the computer to fight a more aggressive attack. As far as this floating point error thing, I'm glad you guys found it, so I wouldn't have to explain to my slow friend why his Panther ran off the bridge on his machine and not mine. P.S. If you ship a free Hamster or Gerbil with the current method, we might take it "as is". LOL! [This message has been edited by Maximus (edited 11-06-2000).] Link to comment Share on other sites More sharing options...
Fuerte Posted November 6, 2000 Share Posted November 6, 2000 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. Link to comment Share on other sites More sharing options...
mensch Posted November 6, 2000 Share Posted November 6, 2000 <BLOCKQUOTE>quote:</font><HR>Originally posted by Spook: you'd see that what I've described isn't too far-fetched.<HR></BLOCKQUOTE> quite right Spook... if it were say a company like.. (won't mention names) it would be like "ok, we were a crossplatformed game, but we need this patch to make more cash and pull in mindless users, so lets put out the PC patch first" "but sir its not working 100%!!" "shut up you welp my Whindoos was 30% funtional when I brought it out to the market and they were on it like flies to moms baked shortbreads, anyhow we can get G section to work on a service pack, but make god damn sure when they do the users have to upgrade thier Lan system I got 50% shares in all major companies so I want more cash!!!" *drool* "hes drooling again." "what what did you say your kreetin! and when we have enough time make a patch for those.. M a c users.. make sure the connection between Mac and PC sux, that way they'll get frustrated and buy a pc and then they will have to have my OS on it! muahahaha" "but sir they are a loyal bunch and..." "hush minion! just cuz that damn Goverment forced me to give Steevie a check does not mean I can shaft him other ways!" "you know I think hes gone off the deepend this time poor users..." "you! you there what did you say...pooor users..lookie what the Goverment is doing to me and you saaaay poor users! I need to by Australia when I retire! hush or be thrown to my wife!" "damn I hate when he pulls his wife in to his fights" ----------- Der Kessel Home of „Die Sturmgruppe“; Scenario Design Group for Combat Mission. [This message has been edited by mensch (edited 11-06-2000).] Link to comment Share on other sites More sharing options...
deanco Posted November 6, 2000 Share Posted November 6, 2000 <BLOCKQUOTE>quote:</font><HR>Originally posted by Spook: A larger PC game company would likely have said instead: "Floating point error? So what? Ship out the TCP/IP patch out now to give the lemmings what they want, stop using up so much time on something that isn't generating new revenue NOW, and get working on the next title. We MIGHT re-patch this 'floating point' IF the lemmings have enough attention span to still be playing this specific game a couple months from now." "Errr.....scratch that last thought. Let's attach a floating-point fix later with a 'CM Elite expansion pack' where anyone wanting this thing fixed right away has to buy the add-on pack. Then a couple of months later, we MIGHT provide a downloadable fix." If you followed the conduct of certain gaming companies very closely last year, then you'd see that what I've described isn't too far-fetched.<HR></BLOCKQUOTE> Boy oh boy is that true. As I was reading that I had a list of games and game publishers going through my head. A great post, right on the button. Just another reason you guys are the greatest. And thanks for keeping us posted like that, I appreciate the detailed explanation a lot. DeanCo-- Link to comment Share on other sites More sharing options...
CrapGame Posted November 6, 2000 Share Posted November 6, 2000 BTS, thanks for the update. It's too bad that the news is not what we wanted to hear, but I am glad you are willing to delay things until they are done right. In this era of vaporware and patches being released before a program hits the shelves, I must say that I have grown to appreciate that a great deal. Thanks again. ------------------ CrapGame Buying CM for yourself is like giving lingerie to your significant other. It's the gift that keeps on giving back! Link to comment Share on other sites More sharing options...
Dittohead Posted November 6, 2000 Share Posted November 6, 2000 Use a slide rule dammit. They ain't never wrong. Link to comment Share on other sites More sharing options...
aka_tom_w Posted November 6, 2000 Share Posted November 6, 2000 <BLOCKQUOTE>quote:</font><HR>Originally posted by Fuerte: 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.<HR></BLOCKQUOTE> 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. I'm a Mac tech geek but ?I have NO idea about a common compiler? IF the math problem is right down in the CPU then maybe the common to all platform compiler would not do the tirck any way? In the simultaneous crunch proposal the rate detemineing step would be the slow speed of the crunch on the slowest cpu, so the other one would be waiting or have to slow down to accomondate it. Sounds like a VERY difficult problem. I guess we are back to master and slave cpu's for hosting the turn crunch? -tom w Link to comment Share on other sites More sharing options...
Herr Oberst Posted November 6, 2000 Share Posted November 6, 2000 <BLOCKQUOTE>quote:</font><HR>Originally posted by Juardis: ... I was trying to figure out how you were doing this without one machine acting as the master and the other the slave... <HR></BLOCKQUOTE> SIT DOWN BAUHAUS!!! oops, sorry, wrong thread... ------------------ To the last I grapple with thee; from hell's heart I stab at thee; for hate's sake I spit my last breath at thee... Link to comment Share on other sites More sharing options...
Recommended Posts