[fpc-pascal]The inexplicable overflow.

ddt at headrush.co.za ddt at headrush.co.za
Wed Sep 25 14:51:18 CEST 2002


Hi, 
The game I am working on is actually nearing completion. 
My enemy ruleset is virtually complete and they can always  
find the player, though not quite by the shortest path 
yet, the version now uses a very simple AI. I check wether 
the enemy is above or below the player, then work out the 
enemy's true line of site and try to head for the closest 
route up or down (as the case may be) within that. 
 
However one enormous bug keeps foiling me. This affects 
only the player (which is wierd since the program doesn't 
actually know the difference between the player and the 
enemies, they are just different instantiantiouns of the 
same object - the only difference is that player status is 
set by asynchronous keyboard commands, and the enemies are 
controlled by a simple AI procedure).  
The program makes use of two sets of coordinates for each 
character, including the player. X and Y stores the 
character's virtual location on the map, where is an 
SDL_Rect which stores it's actual screen location, X and Y 
is easy to work out as I know the borders of each tile and 
can change them whenever a character passes a border( e.g. 
if where.X = 62 then X := 1). 
 
However mysteriously the where.Y value is throwing getting 
a very strange overflow. This is completely unrelated to 
any keyboard input (since not hitting any keys still 
causes it to happen). The overflow happens 
instantaneously, and since Where.Y is an unsigned integer  
(SDL) it becomes ZERO dumping the player in the top line 
of the screen, mysteriously the program keeps running, but 
X and Y do not change (as can be veryfied by the fact that 
although stuck on the top line, you are still bound by the 
physics of the line you were on when it happened.) This 
can only be since 0 is not a tile border and therefore the 
setXY procedure ignores it.  
 
I have added a whatch on where.y which was only usefull in 
that it confirmed my suspiciouns -there is indeed an 
overflow happening. Furthermore this often happens while 
the player is standing still or
 the where.Y value should not 
even be changing at all.  
 
On a hunch I added a temporary variable - increased on 
each alteration of the gameloop, and thus was able to 
determine the only common factor between occurences of the 
error - it always happens after the gameloop has run 1900 
times and before it gets to 2100. I cannot determine the 
exact point (asuming that there is one) because the loop 
is too fast. However I have yet to get it happening before 
1900 or after 2100. 
 
Any idea what could cause this. 
 
I have spent the last three days trying to find it. It is 
easy to fix a bug if you can figure out what causes it, 
but I cannot even come up with a theory this time (which 
is very infuriating) I have checked and rechecked every 
line of code that looks at or alters the value of where.Y 
and I cannot find anything like this. 
 
If anybody would like to look at the source, as usual, I 
am working open-source and will share on request until 
release time - and all helpers will be credited. 
 
 
PS. Thanks a bundle for the tips on the last run, my 
program now runs exponentially faster and never crashes 
anymore at least. 

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .






More information about the fpc-pascal mailing list