# Why are my two classes sharing variables? C++

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

## Recommended Posts

Okay I have two classes:

SWORDBEAM: This one basically handles the projectiles that come out of the player, its pretty simple:

class SWORDBEAM
{
public:

int x, y;
int alive;
int dir;
int xspeed, yspeed;

//COnstructor
SWORDBEAM()
{
x = 0;
y = 0;
alive = 0;
dir = 0;
xspeed = 0;
yspeed = 0;
}

//Core Functions
void drawbeam()
{
int n;
int px, py;

px = x;
py = y;

//Is the beam active
if(!alive)
return;

//Draw sword beam sprite
if(dir == UP)
al_draw_bitmap(swordbeamUp, px - mapxoff, py - mapyoff, NULL);
if(dir == DOWN)
al_draw_bitmap(swordbeamDown, px - mapxoff, py - mapyoff, NULL);
if(dir == LEFT)
al_draw_bitmap(swordbeamLeft, px - mapxoff, py - mapyoff, NULL);
if(dir == RIGHT)
al_draw_bitmap(swordbeamRight, px - mapxoff, py - mapyoff, NULL);
}

void movebeam()
{
int px, py;

px = x;
py = y;

//Is the beam active?
if(!alive)
return;

//Move the beam
x += xspeed;
y += yspeed;
px = x;
py = y;

//Stay within the screen
if(px < link->x - (gameBufferWidth/3) || px > link->x + (gameBufferWidth/3) ||
{
//If it goes off screen, than kill it
explosionSprite->alive = 1;
alive = 0;
return;
}
}

void fireweapon()
{
if(!alive)
{
alive = 1;
al_play_sample_instance(swordcomboInstance);

//Fire the beam in the direction that link is facing
{
//Up
case 0:
xspeed = 0;
yspeed = -swordspeed;
dir = 0;
break;

//Down
case 1:
xspeed = 0;
yspeed = swordspeed;
dir = 1;
break;

//Left
case 2:
xspeed = -swordspeed;
yspeed = 0;
dir = 2;
break;

//Right
case 3:
xspeed = swordspeed;
yspeed = 0;
dir = 3;
break;
}
}
}
};

//Declare a swordbeam
SWORDBEAM swordbeam;


My other class is the enemy, It basically moves in a path I set for it:

class OCTOROCK
{
private:

int x, y;
int width, height;
int curframe, maxframe;
int framecount, framedelay;
int dir;
int alive;
int pathx1, pathx2;
int pathy1, pathy2;
int speed;

public:

//Constructor
OCTOROCK()
{
x, y = 0;
width, height = 0;
curframe, maxframe = 0;
framecount, framedelay = 0;
dir = 0;
int speed = 0;
alive = 0;
pathx1, pathx2 = 0;
pathy1, pathy2 = 0;
}

void setUp(int px, int py, int pwidth, int pheight,
int pcurframe, int pmaxframe, int pframecount,
int pframedelay, int pdir, int pspeed, int palive,
int ppathx1, int ppathx2, int ppathy1, int ppathy2)
{
x = px;
y = py;
width = pwidth;
height = pheight;
curframe = pcurframe;
maxframe = pmaxframe;
framecount = pframecount;
framedelay = pframedelay;
dir = pdir;
speed = pspeed;
alive = palive;
pathx1 = ppathx1;
pathx2 = ppathx2;
pathy1 = ppathy1;
pathy2 = ppathy2;

}

//Responsible for updating the octorock
void updateOctorock()
{
if(alive)
{
//Give octorock a path to follow, only dealing with x axis for now
if(x > pathx2)
{
dir = LEFT;
}
else if(x < pathx1)
{
dir = RIGHT;
}

//Move the octorock
if(dir == UP)
{
x += 0;
y -= speed;
}
if(dir == DOWN)
{
x += 0;
y += speed;
}
if(dir == LEFT)
{
x -= speed;
y += 0;
}
if(dir == RIGHT)
{
x += speed;
y += 0;
}
}
}

//Responsible for drawing the octorock;
void drawOctorock()
{
//Is it alive?
if(alive)
{

//South
if(dir == DOWN)
{
if(++framecount > framedelay)
{
framecount = 0;

if(++curframe > 1)
{
curframe = 0;
}
}
}

//North
/*else if(dir == UP)
{
if(++framecount > framedelay)
{
framecount = 0;

if(++curframe > 3)
{
curframe = 2;
}
}
}*/

//Left
else if(dir == LEFT)
{
if(++framecount > framedelay)
{
framecount = 0;

if(++curframe > 5)
{
curframe = 4;
}
}
}

//Right
else if(dir == RIGHT)
{
if(++framecount > framedelay)
{
framecount = 0;

if(++curframe > 5)
{
curframe = 4;
}
}
}

if(dir == RIGHT)
{
al_draw_bitmap_region(octorock_images[curframe], 0, 0,
al_get_bitmap_width(octorock_images[curframe]),
al_get_bitmap_height(octorock_images[curframe]),
x - mapxoff, y - mapyoff, NULL);
}
else
{
al_draw_bitmap_region(octorock_images[curframe], 0, 0,
al_get_bitmap_width(octorock_images[curframe]),
al_get_bitmap_height(octorock_images[curframe]),
x - mapxoff, y - mapyoff, ALLEGRO_FLIP_HORIZONTAL);
}
}
}

//Sees if the octorock got attacked by link
void detectCollision()
{
int playerx;
int playery;

int x1;
int x2;
int y1;
int y2;

if(alive)
{

x1 = x;
y1 = y;
x2 = x1 + width;
y2 = y1 + height;

if(inside(playerx, playery, x1, y1, x2, y2))
{
{
hearts -= 1;
}
{
alive = 0;
}
}
}
}

void octoPosition()
{
cout << "X Pos: " << x << endl;
cout << "Y Pos: " << y << endl;
}
};

OCTOROCK octorock[1];


The problem is that when I shoot my projectiles, my enemy gets shot out along with the projectile sprite. I have no clue why this is happening.

I have console window running keeping track of all postions and it seems like the swordbeam and octorock are sharing variables. If they are separate classes then how so?

Edited by ISDCaptain01

##### Share on other sites

Heres a video of the glitch

##### Share on other sites

Are you sure you don't have some globals variables named exactly like in your classes or something? I can't see anything wrong with the code, maybe i am missing something... also the bug might be elsewhere, who knows. Did you tried debugging it? The error shoud be pretty oblivious, find what's changing the enemy location when shooting the sword.

Edited by Vortez

##### Share on other sites

If you're using Visual Studio, use a debug build and make sure to enable all the run-time checks (especially to check for out of bounds writes).

Finding the error would also be easier if the code wouldn't be so C-ish and cluttered.

-Stop declaring uninitialized variables

Seriously, what's the point of creating uninitialized variables and then assign stuff in the next line? Eventually you might want to start writing const correct code and that simply won't work if you stick with that. A similar thing goes for constructors. Embrace initializer lists.

-Don't assign values you'll never use

Not only are px and py in movebeam() completely pointless, they are also first assigned values and then overwritten without these values ever having been used. The function as about twice as long as it should be, only due to doing lots of pointless things.

-Don't declare at the top of the function, but at point of first use

That you way you would have noticed that n in drawbeam has become completely unused and pointless.

-Avoid useless clutter

What's the point of px and py in drawbeam?

-There's more types than "int"

alive doesn't track types of being alive (which should be an enum) or a degree of being alive. It's a bool. Why create doubt about the usage and meaning of a variable by not using the appropriate type for it?

-Vectors are nice

They would also prevent moving into a direction turning into a messy if/else-copy/paste orgy (if left and right do the same thing, why is this not one block for both?).

Finding bugs just from looking at code is a LOT easier if the code is clean and well written, without unnecessary clutter that makes everything look more complicated than it actually is. You're trying to find a bug in your code and your code being at least 3-4 times longer than it needs to be makes it at least 3 times harder to find it.

I can't see anything obvious that should result in the bug to describe (potentially for all the above reasons), so the obvious first step would be setting up breakpoints that trigger if the rock position is assigned a value that greater or smaller than a reasonable value, then check the call stack to see who's responsible for it.

Yeah I understand, and I appreciate the criticism. Im just gonna scrap the class and rewrite over again from scratch testing it fully.

##### Share on other sites
I'm on my phone and can't see all of your code, but from looking at the video, I wonder if it's your collision code. Maybe you put "=" instead of "==".

##### Share on other sites

Just curious. You set a lot of class variables as private. Any reason why you do that?

##### Share on other sites
^Orogonally they were publoc, I thought I should make them private just to see if that was the cause of this bug. Im still very much a beginner when it comes to O-O programming.

@Squared
Good idea, ill take a look.

##### Share on other sites

Where are the variables (or constants?)

swordbeamUp, swordbeamDown, ... octorock_images[curframe]

etc. declared?

I suppose those are global stuff, which seems a little shady.

I agree with Vortez ... the code that uses the classes is probably more interesting than the classes themselves.

Edited by DareDeveloper

##### Share on other sites

well I am trying to solve it. Heres what Im doing now. I scrapped the swordbeam and all projectiles from my game. Now im reimplementing the octorock class with better incapsulated code:

class OCTOROCK
{

private:
SPRITE sprite;
public:

//Constructor
OCTOROCK()
{
}

//Destructor
~OCTOROCK()
{
}

//Set the position of the octorock
void setPosition(int x, int y)
{
sprite.x = x;
sprite.y = y;
}

//Set the dimensions
void setDimensions(int width, int height)
{
sprite.width = width;
sprite.height = height;
}

//Set the frames
void setFrames(int curframe, int maxframe, int framecount, int framedelay)
{
sprite.curframe = curframe;
sprite.maxframe = maxframe;
sprite.framecount = framecount;
sprite.framedelay = framedelay;
}

//Set the speed of the octorock
void setSpeed(int speed)
{
sprite.xspeed = speed;
sprite.yspeed = speed;
}

//set the direction of the octorock
void setDirection(int dir)
{
sprite.dir = dir;
}

//is it alive?
void isAlive(int alive)
{
sprite.alive = alive;
}

//moves the octorock
void moveOctorock()
{
if(sprite.dir == RIGHT)
{
sprite.x += sprite.xspeed;
sprite.y += 0;
sprite.curframe = 4;
}
else if(sprite.dir == LEFT)
{
sprite.x -= sprite.xspeed;
sprite.y += 0;
sprite.curframe = 6;
}
else if(sprite.dir == UP)
{
sprite.x += 0;
sprite.y -= sprite.yspeed;
sprite.curframe = 2;
}
else if(sprite.dir == DOWN)
{
sprite.x += 0;
sprite.y += sprite.yspeed;
sprite.curframe = 0;
}
}

//Draw the octorock
void drawOctorock()
{
al_draw_bitmap(octorock_images[sprite.curframe],
sprite.x - mapxoff, sprite.y - mapyoff, NULL);
}
};


##### Share on other sites

Your original code looked fine. It may not have even been the classes that was causing the problem. Without seeing the full code, as Vortez pointed out, it may have just been an issue with variables outside the classes. Depending on what you passed the objects, you may have inadvertently been giving the same data to both so it was doing the glitch of drawing the enemy at the player's location and moving it forward.

##### Share on other sites
You know, your problem can be somewhere else.

I noticed that on all classes the first variables are int x, y.

This can create really weird behaviours in case of bad pointer management, but one that can easily be mistaken for something else, since the accesses to x and y will all seem to be valid!

For the code snippet:

You really should take a look at this snippet to understand what I'm talking about!
The output is just under the code itself (you won't even need to compile it).

So, before going around doing architecture breaking changes, make this (extremely simple) test:
class OCTOROCK
{
private:

int width, height; //SWAP
int x, y; // SWAP
int curframe, maxframe;
int framecount, framedelay;
int dir;
int alive;
int pathx1, pathx2;
int pathy1, pathy2;
int speed;

If your monster's glitch changes (if it start to glitch differently), there you are! Bad pointer management is probably the culprit! Edited by dejaime

##### Share on other sites
If you still can't find the problem, put a break point in the code that fires the projectile and step through the code one line at a time keeping the variables in a watch window. I agree that it's either bad pointer management or you put an assignment somewhere and didn't notice.

##### Share on other sites

Swapping the variables is a good idea to get a better idea if the variables are overwritten "by name" or "by address".

Anyway, if you already know which variable changes, any decent debugger lets you set a breakpoint to when this variable changes and have a condition for the new value. It's a lot less painful than stepping through code that might run dozens of frames before the bug happens while manually staring at the watch window.

##### Share on other sites

I tried finding the bug and just couldn't, also I wasn't happy with the overall implementation of it, so I decided to nuke it and code it much cleaner this time.

##### Share on other sites

For those of you still wondering, heres what the new octorock class looks like now:

class OCTOROCK
{

public:

SPRITE sprite;
int pathx1, pathx2;
int pathy1, pathy2;
bool isExplode;

//Constructor
OCTOROCK()
{
}

//Destructor
~OCTOROCK()
{
}

//moves the octorock
void moveOctorock()
{
if(sprite.alive)
{
//Make sure the octorock does not leave its specified path
if(sprite.x > pathx2)
{
sprite.dir = LEFT;
sprite.curframe = 6;
}
else if(sprite.x < pathx1)
{
sprite.dir = RIGHT;
sprite.curframe = 4;
}
if(sprite.y > pathy2)
{
sprite.dir = UP;
sprite.curframe = 2;
}
else if(sprite.y < pathy1)
{
sprite.dir = DOWN;
sprite.curframe = 0;
}

//Move the octorock according to its direction.
if(sprite.dir == RIGHT)
{
sprite.x += sprite.xspeed;
sprite.y += 0;
//sprite.curframe = 4;
}
else if(sprite.dir == LEFT)
{
sprite.x -= sprite.xspeed;
sprite.y += 0;
//sprite.curframe = 6;
}
else if(sprite.dir == UP)
{
sprite.x += 0;
sprite.y -= sprite.yspeed;
//sprite.curframe = 2;
}
else if(sprite.dir == DOWN)
{
sprite.x += 0;
sprite.y += sprite.yspeed;
//sprite.curframe = 0;
}
}
}

//Detects if the player collides with the octorock
void detectCollision(SPRITE *spr)
{
//Variables to record everyones bound box dimensions
int playerx, playery, playerw, playerh;
int top, bottom, left, right;

int heartcount = 0;
int heartdelay = 200;

if(sprite.alive)
{
//record players box
playerx = spr->x;
playery = spr->y;
playerw = playerx + spr->width;
playerh = playery + spr->height;

//record the octorocks box
top = sprite.y;
left = sprite.x;
bottom = top + sprite.height;
right = left + sprite.width;

//Check if they collide
if(accurateInside(playerx, playery, playerw, playerh, left, top, right, bottom))
{

//If the players attacking frame is active during collision
if(spr->curframe == 8 ||
spr->curframe == 9 ||
spr->curframe == 10 ||
spr->curframe == 11)
{
//Kill the octorock
sprite.alive = 0;
cout << "octorock killed" << endl;
al_play_sample_instance(killInstance);
isExplode = true;

}
else
{
//flinch a bit and lose 1 heart
if(++heartcount > heartdelay)
{
hearts -= 1;
heartcount = 0;
//al_play_sample_instance(hurtInstance);
}

if(spr->dir == RIGHT)
{
spr->x -= 15;//8;
hearts -= 1;
al_play_sample_instance(hurtInstance);
}
else if(spr->dir == LEFT)
{
spr->x += 15;//8;
hearts -= 1;
al_play_sample_instance(hurtInstance);
}
else if(spr->dir == DOWN)
{
spr->y -= 15;//8;
hearts -= 1;
al_play_sample_instance(hurtInstance);
}
else if(spr->dir == UP)
{
spr->y += 15;//8;
hearts -= 1;
al_play_sample_instance(hurtInstance);
}

}
}
}
}

//Draw the octorock
void drawOctorock()
{
if(sprite.alive)
{
if(sprite.dir == RIGHT)
{
if(++sprite.framecount > sprite.framedelay)
{
sprite.framecount = 0;

if(++sprite.curframe > 5)
{
sprite.curframe = 4;
}
}
}

if(sprite.dir == LEFT)
{
if(++sprite.framecount > sprite.framedelay)
{
sprite.framecount = 0;

if(++sprite.curframe > 7)
{
sprite.curframe = 6;
}
}
}

if(sprite.dir == UP)
{
if(++sprite.framecount > sprite.framedelay)
{
sprite.framecount = 0;

if(++sprite.curframe > 3)
{
sprite.curframe = 2;
}
}
}

if(sprite.dir == DOWN)
{
if(++sprite.framecount > sprite.framedelay)
{
sprite.framecount = 0;

if(++sprite.curframe > 1)
{
sprite.curframe = 0;
}
}
}

//Finally draw the octorock
al_draw_bitmap(octorock_images[sprite.curframe],
sprite.x - mapxoff, sprite.y - mapyoff, NULL);
}
}

};


It works perfectly, I have multiple enemies on the map and no problem. Collision is a bit amateurish but so am I

If anybody cares to see:

Edited by ISDCaptain01

##### Share on other sites

Just curious. You set a lot of class variables as private. Any reason why you do that?

wat

##### Share on other sites
I think i found out the bug today guys. Basically what happened was that i declared an array of octorocks:
OCTOROCK octorocks[4];

But what i did wrong was that initialized it like this
octorock[1].x =......
octorock[2].x =......
octorock[3].x =......
octorock[4].x =......

What i did wrong is that i didnt access octorock[0] and did a memory violation by going out of bounds in tbe array with octorock[4].

##### Share on other sites

Just curious. You set a lot of class variables as private. Any reason why you do that?

wat

In a simple answer, data hiding. It is usually common practice to make class members (variables) private and only allow access by way of constructors(mainly for initializing the class object) and class methods (functions).

I think i found out the bug today guys.

I'm glad to hear you may have found it. It is looking good so far, IMO.

Edited by BHXSpecter

##### Share on other sites

I think i found out the bug today guys. Basically what happened was that i declared an array of octorocks:
OCTOROCK octorocks[4];
But what i did wrong was that initialized it like this
octorock[1].x =......
octorock[2].x =......
octorock[3].x =......
octorock[4].x =......
What i did wrong is that i didnt access octorock[0] and did a memory violation by going out of bounds in tbe array with octorock[4].

Don't worry. Mistakes like this are quite common. That's why I tend to look to see if I've made silly mistakes first when debugging. I hate it when I end up making major changes when the original bug just turns out to be a missing minus or something. Glad you found the answer.

##### Share on other sites

Just curious. You set a lot of class variables as private. Any reason why you do that?

wat

In a simple answer, data hiding. It is usually common practice to make class members (variables) private and only allow access by way of constructors(mainly for initializing the class object) and class methods (functions).

Yes.. Except he's asking why they are private, not public. I guess it was a typo.

##### Share on other sites

My apologies. Meant to quote just Buckeye and didn't realize I had quoted your post. It wasn't aimed at you. Again, I'm sorry, I should have paid closer attention to what I was quoting before submitting it.

##### Share on other sites

I think i found out the bug today guys. Basically what happened was that i declared an array of octorocks:
[...]
What i did wrong is that i didnt access octorock[0] and did a memory violation by going out of bounds in tbe array with octorock[4].

So it was indeed bad pointer management!
These kind of symptoms are really common in these cases.

##### Share on other sites

Thought Id show everybody how it looks now: