[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