Public Group

Why are my two classes sharing variables? C++

This topic is 1744 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

• What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 14
• 14
• 45
• 22
• 27
• Forum Statistics

• Total Topics
634044
• Total Posts
3015213
×