Sign in to follow this  
Frequist

Oddest error I have ever seen....

Recommended Posts

In my program I have these lines...
intObjectX = (signed short int)(intObjectX/2);
intObjectY = (signed short int)(intObjectY/2);
I've ran a messagebox to determine which value this is returning....
sprintf(chrDebug,"X=%iY=%i",intObjectX,intObjectY);
MessageBox(hwnd,chrDebug,"Ja",0);
The values that get returned are as followings... intObjectX was equal to 351. intObjectY was equal to 161. These values were expected, and should not have crashed my program. I rewrote the code with this...
intObjectX = 351;
intObjectY = 161;
And the program works. Whats the difference; why is it crashing when I use the prevoius code?

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Have you run the program in the debugger to see what's going on?


Debugger? No, I've never used that before.

If you want my opinion, I think its something todo with the way the numbers get stored after being divided by 2.. but I can't make sence of it. [bawling]

Share this post


Link to post
Share on other sites
Perhaps now is a good time to start, then. If you don't know how to use the debugger effectively, you are doomed to waste hours and hours debugging with messageboxes and such.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Perhaps now is a good time to start, then. If you don't know how to use the debugger effectively, you are doomed to waste hours and hours debugging with messageboxes and such.


Yah... gotta love it when you put a MessageBox in a loop. [bawling].

@odiousangel

I would avoid it.. but I have to use signed variables since the map editor is writen in VB, and can't save unsigned integers. [bawling].

Thanks though... btw I'm Visual C++ 6.

Share this post


Link to post
Share on other sites
You're going to have to post alot more code then that if you want to get help from us. We're not mind readers ya know (some of us aren't even code readers ;)). Debuggers are very important tools; you should always know how to use the debugger for you language and/or compiler.
Quote:

I would avoid it.. but I have to use signed variables since the map editor is writen in VB, and can't save unsigned integers.

Integers are assumed to be signed in C++ if not specified.

Share this post


Link to post
Share on other sites
Quote:
Original post by Frequist
If you want my opinion, I think its something todo with the way
the numbers get stored after being divided by 2..


1. Use a debugger.

2. I dont think that the division itself is the reason for your crash. I would guess that you somewhere have some kind of memory problem, probably writing into undecladered memory or out of bound from an array.

Just because your bug does not happen does not mean that its gone. It is a common misconception that a bug only exists when it crashes the program. Your program can compile and run fine and still have bugs inside...

Share this post


Link to post
Share on other sites
bytecoder,

It would be a couple dozen pages of code to show you all the places where it gets read...

btw.. I started working with the VC debugger... (Its easier then I thought). I found the error occured on this region

	if (bytPlayers == 1)
{
/* Get the UpperLeft Tile Coordinates */
intX = (unsigned short int)((intP1CameraX - 160)/16);
intY = (unsigned short int)((intP1CameraY - 160)/16);


bytOffSetX = (intP1CameraX - 160) - (intX * 16);
bytOffSetY = (intP1CameraY - 160) - (intY * 16);

/* BitBlt the Tiles */
for(bytTileX = 0; bytTileX < 21; bytTileX++)
{
for(bytTileY = 0; bytTileY < 14; bytTileY++)
{
/* Generate correct tile coordinates from the map array. */
fltPart1X = (float)arrMap[bytTileX + intX][bytTileY + intY]/13;
intInterY = fltPart1X;
fltPart1X = (float)(fltPart1X - intInterY);
intInterX = fltPart1X * 13 +0.2f;

/* Draw the Map */
BitBlt(hdcGame, (bytTileX * 16) - bytOffSetX, (bytTileY * 16) - bytOffSetY, 16, 16, hdcTiles, (intInterX * 16), (intInterY * 16), SRCCOPY);
RedrawWindow(hwnd, 0, 0, 1);
}
}
}


What the debugger set was...
intP1CameraY is equal to 144 (Not so good.)
intX is equal to 14 (Which is good)
intY is equal to 65535 (Uhm.. HOW?! Its not even UNSIGNED)

(intY - 160) = Negative Value (This shouldn't EVER happen).
There is a problem with my intP1CameraY initiate code it would appear, but why does presetting the devision value fix it.

[Edited by - Frequist on July 7, 2004 4:24:13 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by schue
Quote:
Original post by Frequist
If you want my opinion, I think its something todo with the way
the numbers get stored after being divided by 2..


1. Use a debugger.

2. I dont think that the division itself is the reason for your crash. I would guess that you somewhere have some kind of memory problem, probably writing into undecladered memory or out of bound from an array.

Just because your bug does not happen does not mean that its gone. It is a common misconception that a bug only exists when it crashes the program. Your program can compile and run fine and still have bugs inside...


That fact that precalculating the result of the devision statement made the program work, really convinces me there is a problem with how the result of the division is being stored.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Frequist
intP1CameraY is equal to 144 (Which is good)
intX is equal to 14 (Which is good)
intY is equal to 65535 (Uhm.. HOW?! Its not even UNSIGNED)
Code: intY = (unsigned short int)((intP1CameraY - 160)/16);


Plugging in intP1CameraY=144 into that line:
intX = (unsigned short int)-1
When you typecast to an unsigned short, the value becomes 65535.
But, if intX is a 32-bit integer (maybe you want it to be 16-bit?) then it will simply store that value instead of -1.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by Frequist
intP1CameraY is equal to 144 (Which is good)
intX is equal to 14 (Which is good)
intY is equal to 65535 (Uhm.. HOW?! Its not even UNSIGNED)
Code: intY = (unsigned short int)((intP1CameraY - 160)/16);


Plugging in intP1CameraY=144 into that line:
intX = (unsigned short int)-1
When you typecast to an unsigned short, the value becomes 65535.
But, if intX is a 32-bit integer (maybe you want it to be 16-bit?) then it will simply store that value instead of -1.



EDIT!: I think I understand what you just said... gimme a sec while I test it. :D

<Test Results> After switching the "unsigned" to "signed" the program ran (it didn't crash). However the display still isn't functioning correctly. I shouldn't have needed to switch those words. I'm gonna have a look at my input code, to make sure its interpreting the maps correctly (This'll be my 5268309th time checking it).

Share this post


Link to post
Share on other sites
Quote:
Original post by Frequist
intY = (unsigned short int)((intP1CameraY - 160)/16);

What the debugger set was...
intP1CameraY is equal to 144 (Not so good.)
intY is equal to 65535 (Uhm.. HOW?! Its not even UNSIGNED)


You just said that intP1CameraY is 144...obviously then:

144-160 = -16

-16/16 = -1

convert -1 into a unsigned short int and what do you get?

You guessed it, 65535.

Regards,
Jeff

Share this post


Link to post
Share on other sites
Quote:
Original post by Frequist
That fact that precalculating the result of the devision statement made the program work, really convinces me there is a problem with how the result of the division is being stored.


after 25 years of experience in programming i can only tell you, this is the wrong answer :)

_if_ you can explain why it crashed, than you have found the bug and can fix it. As long as you only change your code until it works, you just worked around the bug with no proof that you actually fixed it.

A bug is not fixed when you avoid it, but when you understand it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Frequist
(intY - 160) = Negative Value (This shouldn't EVER happen).


Sounds like a good candidate for an assert....look into it.

Regards,
Jeff

Share this post


Link to post
Share on other sites
Quote:
Original post by rypyr
Quote:
Original post by schue
A bug is not fixed when you avoid it, but when you understand it.


...and then fix the code! :P


Hehe. [razz]

@schue

Thanks for the info.

Share this post


Link to post
Share on other sites
I feel really stupid right now (and smart at the same time). I fixed the mistake, and I'm kicking myself for wasting your time.

These were my mistakes... (If your interested in hearing them).

Mistake #1:
/* Get the UpperLeft Tile Coordinates */
intX = (unsigned short int)((intP1CameraX - 160)/16);
intY = (unsigned short int)((intP1CameraY - 100)/16);p

bytOffSetX = (intP1CameraX - 160) - (intX * 16);
bytOffSetY = (intP1CameraY - 100) - (intY * 16);


intP1CameraY was getting minus'd by 160, this is wrong because the height is not (320/2) like the width is... its (200/2).

Mistake #2
	/* Determine which type of creature this is and create it. */
if (intObjectType == flag_MapPlayer1)
{
arrCreatures[0].intX = intObjectX;
arrCreatures[0].intY = intObjectY;
arrCreatures[0].bytType = flag_Player1;
else if (intObjectType == flag_MapPlayer2)
{
arrCreatures[1].intX = intObjectX;
arrCreatures[1].intY = intObjectY;
arrCreatures[1].bytType = flag_Player2;
}


The arrCreatures[1] use to be [0], meaning it was loading the second players start off point into the 1st players start off point.

After those two mistakes were fixed, the program ran flawlessly; however I still can't explain why the precalculated division statement worked, while the non-precalculated division statement didn't work. (Not that it matters)

Guess I'll never know. [headshake]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this