Class Member Variable Won't Stay Changed From Its Initialized Value? (C++)

Started by
6 comments, last by MortusMaximus 15 years, 5 months ago
Hello, I recently started working on a simple 2D game and I've run in to a bit of a problem with one of my classes.
class AddSprite
{
private:

	D3DXIMAGE_INFO Size;
	bool drawBrick;
	static RECT Player;
	static RECT Ball;
	RECT Brick;

public:

	enum OBJ_TYPE
	{
		PLAYER,
		BALL,
		BRICK,
		DEFAULT
	};

	AddSprite() { drawBrick = true; }

	void LoadSprite(LPCSTR filename);

	void DrawSprite(int x, int y, int z, int type = DEFAULT);

	void TileSprite(int xStart = 0, int yStart = 0, int xEnd = WIDTH, int yEnd = HEIGHT);
};

/*...*/

void AddSprite::DrawSprite(int x, int y, int z, int type)
{
	/*...*/
	if(type == BRICK)
	{
		SetRect(&Brick, x, y, Brick.left + Size.Width, Brick.top + Size.Height);
		if(Ball.top <= Brick.bottom && Ball.left <= Brick.right && Ball.right >= Brick.left && Ball.bottom >= Brick.top)
		{
			drawBrick = false;
		}
		if(drawBrick == true)
		{
			D3DXVECTOR3 loc(x, y, z);
			d3dspt->Draw(sprite, NULL, NULL, &loc, D3DCOLOR_XRGB(255, 255, 255));
		}
	}
}

/*...*/
The problem is on this if statement:
if(Ball.top <= Brick.bottom && Ball.left <= Brick.right && Ball.right >= Brick.left && Ball.bottom >= Brick.top)
{
	drawBrick = false;
}
I want to change the value of 'drawBrick' from true to false, to stop it from drawing that sprite. However, it only stays false for when the ball sprite is over the brick sprite, then reverts back to it's initial value, true. Should this be happening, or am I doing something wrong? Is there any way I can stop this from happening without making it static? Any help would be greatly appreciated. Thanks.
Advertisement
I hate these problems. It's usually something stupid. I'd look very carefully at every, and I mean every, place where that variable is referenced. In particular, look at places where it is tested, as in drawBrick == true. You never know when you've forgotten to use the equality operator instead of the assignment operator.
Put a breakpoint on the drawBrick = false; line, then when it fires, put a data breakpoint on drawBrick. No need to wonder things the debugger's willing to tell you.

You do know how to use your debugger, right?
It's hard to tell you definitively, since you didn't post all the code, but the only other place it is changed in the code you give here is in the constructor. Is it possible that instead of keeping a single instance of the class, you reinitialize it every time you try to display it? That would definitely cause it to keep resetting it to true, but still setting it to false when it is on the brick.

Put a cout or breakpoint in the constructor to see how many times it is called. If it is called a LOT, then you have the problem. If not, then it is in one of the other functions.
Check out the first gameplay video from my javascript/PHP RTS game
Quote:Original post by MortusMaximus
It's hard to tell you definitively, since you didn't post all the code, but the only other place it is changed in the code you give here is in the constructor. Is it possible that instead of keeping a single instance of the class, you reinitialize it every time you try to display it? That would definitely cause it to keep resetting it to true, but still setting it to false when it is on the brick.

Put a cout or breakpoint in the constructor to see how many times it is called. If it is called a LOT, then you have the problem. If not, then it is in one of the other functions.


It seems that's exactly what I was doing. I (foolishly) reinitialized it every time the current frame was drawn. It works fine now. Thanks.
You shouldn't really change an object's logical state (usually, this means "any data member", but there are exceptions) during the rendering process. Keep in mind that member functions are perfectly capable of having local variables, and in fact you should normally use locals when you can.

It looks like what you're doing is holding a constant set of bricks, and periodically "drawing" them by doing collision detection, disabling the brick upon collision, and rendering it if not disabled. This is bad for a few reasons. First off, the collision detection should go elsewhere; it doesn't have anything to do with drawing. Second, if you destroy a brick, you should actually destroy it, by removing it from the container. There are more implications to a block collision than simply not drawing the sprite, after all. For example, the ball should now be able to pass through that space :) And third, you have the concept of what an object looks like mixed up with the concept of what the object is.

Proper design involves making a sprite class with no "type" or drawing flag, which simply represent an actual sprite (i.e. a rectangular region of a source image), and behaviour classes to represent each type of thing (ball, paddle, brick), which have a Sprite as a data member.

Also, 'AddSprite' makes no sense as a class name. Classes define a data type; they should have noun-like names.
Quote:Original post by Jeff Parry
Quote:Original post by MortusMaximus
It's hard to tell you definitively, since you didn't post all the code

It seems that's exactly what I was doing.

Wow. Where did you buy your crystal ball, Mortus? I want one, too :)
Quote:Original post by DevFred
Quote:Original post by Jeff Parry
Quote:Original post by MortusMaximus
It's hard to tell you definitively, since you didn't post all the code

It seems that's exactly what I was doing.

Wow. Where did you buy your crystal ball, Mortus? I want one, too :)


Hehe I didn't, I was having a *very* similar problem that I fixed mere moments before I saw this post xD
Check out the first gameplay video from my javascript/PHP RTS game

This topic is closed to new replies.

Advertisement