Sign in to follow this  

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

This topic is 3316 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

This topic is 3316 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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