Getting different results on different computers
BlitzPlus Forums/BlitzPlus Programming/Getting different results on different computers
| ||
| My game is not exactly the same on both of my computers. I came across this problem trying to solve my network game. I have tanks with AI. They don't do the same thing on both computers, but they do the exact same thing on the same computer every time I run the game, I do use rand , I don't randomize it though for this test The problem doesn't happen right away, All testing is done with no user input at all. Any known problems with floating point on different computers? What about 'random' will always be the same on different computers My computers use AMD 600 and AMD 1200 CPUs(I think) |
| ||
| this is one of the problems with different hardware profiles I guess. |
| ||
| @Dan60 Just for reference, also check out this thread: http://www.blitzbasic.com/Community/posts.php?topic=28810 |
| ||
| Hi! Yo could always generate a big list of random numbers and include this in with your executable, then all instances could look up values in the table, theirfore by-passing the random values are different on different computers problem! Mr Brine. |
| ||
| I'm getting frustrated with this problem. I would like to pin point the the problem so I can find a work around solution. Otherwise I will have to rethink my whole network game. I doubt its going to be the random generator. My map is generated randomly and appears identical on any computer. Unless the the random number changes after a few thousand numbers or something. I do use lots of floating point sins a cos, collision detection and so on. Shouldn't the floating point be the same on all computers? why do tanks take a different path on different computers. The tanks should do as they are told not have a mind of their own. I did discover one interesting thing. *** changing the graphics mode also changes the result. example Graphics 800,600,2 Graphics 800,600,1 wont give the same tank path. |
| ||
| Not sure how to answer this how you want, but... If this is a network game (I'm not sure how network games work yet, so correct me if I'm wrong) then why don't you have one "master" computer, and the values/coordinates/whatever for the AI tanks are all sent from the same "master computer". Therefore, should the AI tanks' values change between computers, they will be corrected and use the values from the "master" computer. I'm not sure how you'd do this or if it's fully possible, but I think that would be a good approach. |
| ||
| I did discover one interesting thing. *** changing the graphics mode also changes the result. example Graphics 800,600,2 Graphics 800,600,1 wont give the same tank path. That could explain the problem if your tank pathfinding/collision detection routines are built around specific colors on a texturemap/image... |
| ||
| Nope, not using colors for pathfinding or collision detection. Using debuglog I've been trying to track when it starts to differ. It seems to be after a imagecollide detection (not the first one though), but hard to be 100% sure. |
| ||
| Nope, not using colors for pathfinding or collision detection. Using debuglog I've been trying to track when it starts to differ. It seems to be after a imagecollide detection (not the first one though), but hard to be 100% sure. Yes, you most certainly are depending on image colors if useing imagescollide() |
| ||
| To MSW: MSW YOU RULE!!! I replaced all ny imagescollide with imageoverlap and problem disappeared! Problem also disappeared when I changed graphics 800,600,16 to Graphics 800,600,32 My network game works now!! I still don't fully understand why that happens. If the two compared pixels aren't black shouldn't that be a collision? What solution to you recommend? a) use graphics 800,600,32 b) don't use imagescollide c) change sprite colors (would that help?) d)other How much do I owe you? I'll post a link to my demo soon. |
| ||
| I would just write my own collision routines, because frankly I don't see any point in haveing pixel perfect collision detection (most professionaly developed 2D games use "hit boxes" or "collision zones" and rarely if ever need to dive into pixel perfect accuricy) But if you must have pixel perfect accuricy then I suggest you do it in your code useing banks or arrays to store single bit depth images that you can use to check with...this is prolly going to seem very complicated, but like the "hit box" methods, it allows you to keep your collision routines seperate from color depth conversion problems... else: What solution to you recommend? a) use graphics 800,600,32 b) don't use imagescollide c) change sprite colors (would that help?) a) yeah, you can do that...but some folks might not be able to run it b) yeah, might be a good idea...but if you must, there are ways to still use it without hitting against the color conversion problems c) might be a good idea...as a 32-bit color like: (red = 8, green = 8, and blue = 8...a very dark grey color) could wind up being converted to red = 0, green = 0, blue = 0 in 16-bit modes... The simplest solution would be to write a little application that loads your graphics in 32-bit mode...then goes through each pixel and if it isn't black (0,0,0) then it changes it to pure white (255,255,255)...the application then saves the resault as something like "<imagename>MASK.BMP" Then in your game you load both the original art and the MASK versions created by the application...then do the imagescollide checks with the MASK versions as the 32-bit to 16-bit color conversion shouldn't effect it that much...but of course this requires that you use approx twice the amount of video memory, twice the number of graphics... |
   |