# My Code(cont'd, debugging)

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

## Recommended Posts

Hi all! It's me with the mario clone again. I made luigi jump forward over the moving box. Here, download it and try: clicky. I wanted to discuss the game. All source included. Note: I disabled the background for faster moving. Try it out. Mostly all of the new action takes place in DrawGame(...), so look there. It's easy to restore it to its previous state, since I simply added some code on the go. EDIT: Just so you know if luigi made the jump or not, the box starts over if he couldnt jump over. Dont worry about mario, he isnt affected.

##### Share on other sites
Hi I was the guy who suggested the obstacle idea, it’s nice to see that you implemented it very well I think this could be a very nice clone and I would like you to keep me posted on the development. As for your question about collisions (in previous post) I started think about the 1st app you showed, that if you where to make a game out of this it would look a bit more professional if you didn’t have the head collisions.

[BUG] when you start the game if you don’t move Mario, Luigi makes the jump but he is surrounded with white. I think it could be a transparency problem but I am not sure.

##### Share on other sites
Oh yeah I saw that... Its surely a transperancy problems since all the backgrounds are white. I draw the color key in the end of UpdateGame(), so I'm not sure why that happens. Anyway I'll get back to this, but right now I'm in a hurry.

lol

##### Share on other sites
Looks great so far just a couple things I noticed when looking at the code:

It looks like in your DrawGame function you load the box image and free it every frame. With only 3 sprites on the screen you probably won't notice it much but this will slow you down a whole lot later. Try loading it once at the begining and reusing the same surface.

Also in your UpdateGame function you call SetColorKeys each frame. You only need to call this once when you first load the image. I can't tell because it is kind of confusing to me but it looks like you may also be loading images each time they change direction etc. This should be avoided and all of your surfaces should be loaded and colorkeyed once when the game initializes and then freed once when the game ends.

Just a few suggestions that might help make your code a little clearer:

Try making a player class to encapsulate the code specific to a player. This will make the game code much easier to read as well as allow you to make specific changes to players that won't affect the way other parts of the game work. You also get to re-use the same class for Mario and Luigi making your life much easier.

For a DetectCollision function, you already do a bounding box collision detection of sorts but it relies on an SDL_Surface and then an X and Y position. This implies that the collision rectangle will always be the full size of the surface. At some point you will probably have more than one sprite on a surface which will break this collision function. You could modify it to instead accept 2 SDL_Rect structures and see if those collide. You would have to write it yourself of course but you already have most of it done.
bool My_IntersectRect( const SDL_Rect& BoxA, const SDL_Rect& BoxB );

I hope some of that helps.

##### Share on other sites
Back!

Collision
I cant get this to work... The sides only work if the two colliding sprites are running at the same speed. And the top/down detection doesnt work :(... I really need help with this, and sorry, I but have NO idea how to work with rects. Help me! Lol. Anyways, if you guys can atleast point me into the right direction of collision detection... Anyways, say I know about rects. How would I have my SDL_Surfaces* turned into rects? Thanks for any help, this is the part that is most confusing.

Uhhh.... Yes, the box I have move is loading and freeing every frame. Thats because I was just trying some tricks and stuff, and didnt want to set it all over the code so I can clean it up later. The characters switch their .Char's every left or right by using the other SDL_Surface*. However, in SetImage() I load a file to every surface so no, I'm not loading every time I change directions.

Player Class
I see what you are saying... I'll keep that in mind, but maybe once I kinda get the hang of the game.

For now i'm off to fix the box, the colorkeys, and the other known, I'll come back here every 5 mins or so.

##### Share on other sites
Hmm, I seem to have found out the collisions problem. The boxes have to move at the same speed cuz I have the sides equal each other, not be in each other.

##### Share on other sites
For collision detection in this instance you don't really need to know where or how they collided, just that they have. Getting the basic collision down first is more important than where right now anyway. Later you can perform more detailed checks on how they collided after performing the simple one below.

As for getting a rectangle from a surface, the only pieces you need are the surface->w and surface->h members because the x and y are the sprites x and y coordinates.

In the past I have used a temporary rectangle to test for collision with the coordinates I WANT to move the sprite to so that if a collision is detected the move does not happen.

From there, assuming you have 2 rectangles to check collision from:
bool My_IntersectRect( const SDL_Rect& BoxA, const SDL_Rect& BoxB ){    // check to see if the boxes are in the same horizontal space    if ( BoxA.x > BoxB.x + BoxB.w || BoxB.x > BoxA.x + BoxA.w )        return FALSE;    // check to see if the boxes are in the same vertical space    if ( BoxA.y > BoxB.y + BoxB.h || BoxB.y > BoxA.y + BoxA.h )        return FALSE;    // They occupy at least some of the same space so there was a collision    return TRUE;}

You can make collision rectangles for all 3 sprites and then when you want to move one, check it against the other rectangles.

I think lazy foo has some tutorials that might help you out as well here.

Hope that helps.

##### Share on other sites
Thanks, now i seem to get it. Only problem, I have the collision detection function all ready, but it doesnt work for the height:
if (((x1 + sprite1->w) > x2 && (x1 + sprite1->w) < (x2 + sprite2->w)) &&        (y1 >= (y2 - sprite2->h) &&         y1 <= (y2 + sprite2->h)))	    return IMG1ONLEFT;        if ((x1 < (x2 + sprite2->w) && x1 > x2) &&         (y1 >= (y2 - sprite2->h) &&         y1 <= (y2 + sprite2->h)))	    return IMG1ONRIGHT;		// Height -- These dont work, the above do!		if (((y1 + sprite1->h) > y2 && (y1 + sprite1->h) < (y2 + sprite2->h))&&        (x1 + sprite1->w) >= x2 &&        x1 <= (x2 + sprite2->w))        return IMG1ONTOP;            if ((y1 < (y2 + sprite2->h) && y1 > y2)&&        (x1 + sprite1->w) >= x2 &&        x1 <= (x2 + sprite2->w))        return IMG1ONBOTTOM;	        return 0;

What I dont get is why the width works, but the height doesnt, when all i do is change the x to y and the w to h. it should work, no?

##### Share on other sites
You should break the collision detection up into 2 parts. First a broad check just to see if the rectangles intersect like I posted above. Then, based on direction of movement etc. you can figure out the type of collision. If you try to do it all at once it becomes confusing real quick and not useable by any other entities. I am assuming you will be having other moving objects later on so try to be generic now to allow more specific checks when you need them.

As it is now I don't see any use for why you need to know which side the collision happened on as all it does is stop movement which a basic check for a simple collision will do that anyway.

I can't stress enough how much simpler you will make things on yourself and people trying to help you by using a player class instead of free functions. It makes it very difficult to follow the logic the way it is now.

• 15
• 10
• 9
• 49
• 12
• ### Forum Statistics

• Total Topics
631389
• Total Posts
2999726
×