Sign in to follow this  

Does Dev-C++ have some sort of weird cache that prevents changes from compiling?

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

Ok, this might take a bit of explanation. I am using Dev-C++ 4.9.9.2 as my IDE, which comes with MinGW 3.4.2. My language is C++ and I'm using SDL for graphics. I am trying to learn some basic collision detection, so my plan is to have two balls bounce around the screen (and each other), Pong-style. I have two files in my project: 1) main.cpp 2) ball.h The first one is self-explanatory. The second is the header file that has my ball class declaration and implimentation. I'll include them in their entirety at the end of this post. For now, here is the Ball class declaration:
class Ball
{
     
  public: 

  // default constructor            
  Ball();

  // alternate constructor
  Ball(int,int,int,int,int);   
      


  // position of ball on screen
  int xpos, ypos; 

  // velocity of ball
  int xspeed, yspeed; 

  // time that ball was created
  int birth; 

  // color of ball, either 0 (orange) or 1 (blue)
  int color; 
  



  // calculates which frame of animation
  int GetCurrentFrame(); 

  // finds animation cell on bitmap that corresponds to frame
  int GetCurrentCell(); 

  // returns proper Rect for current anim. cell
  void GetSrcRect(SDL_Rect * src); 
      
};

Ok, and here is the default constructor:
Ball::Ball()
{
            
 xpos = 312; // ensures that the ball appeares in
 ypos = 232; // mid-screen on 640x480
 
 xspeed = 0;
 yspeed = 0;
 
 color = 0;
 
 birth = SDL_GetTicks();
            
}

Ok, so over in main.cpp, I have declared a ball globally:
Ball ball;
And I have a DrawScene() function which draws the ball to the screen.
void DrawScene()
{

  SDL_Rect src;
  
  ball.GetSrcRect(&src);
  
  SDL_Rect dest;
  dest.x = ball.xpos;
  dest.y = ball.ypos;
  SDL_BlitSurface(image, &src, screen, &dest);
  
  SDL_Flip(screen);
}

So, I run it the first time and everything seems to work fine. The ball isn't moving, which is good, because the default constructor sets the speeds to 0. The ball is orange, which is good because that's what color = 0; corresponds to. The animation is working perfectly (the ball sort of flashes slowly). The only problem is, the position is all wrong. The ball is appearing in the lower-right corner of the screen rather than the direct middle of the screen. So exit out of the program and return to Dev-C++. I take another look at the default constructor. I found that the reason the ball was appearing in the wrong place is that I've entered the wrong values for xpos and ypos. Instead of 312,232 I entered 632,472. Duh! So, I just changed them to 312 and 232. I then rant he program again, and unfortunately that didn't seem to work. The ball was appearing in the lower-right again. I thought that perhaps I didn't save ball.h properly. It's part of my project and so it should save automatically when I hit "compile", but whatever. I went back to ball.h and hit CTRL+S to save it. Then I opened ball.h in a separate program (notepad) just to make sure that it worked. It did. The proper values were there. So I compiled and ran it again. No dice. The ball was still in the lower-right corner. So I figured, maybe the reason it's in the lower-right has nothing to do with the fact that the original xpos and ypos I had in there were 632 and 472, respectively. Perhaps that was just a coincidence, and therefore there is perhaps something fundamentally wrong with my code. To test this, I decided to set the x and y of the destination SDL_Rect explicitly:
void DrawScene()
{

  SDL_Rect src;
  
  ball.GetSrcRect(&src);
  
  SDL_Rect dest;
  dest.x = 312; 
  dest.y = 232; 
  SDL_BlitSurface(image, &src, screen, &dest);
  
  SDL_Flip(screen);
}

Notice how I replaced the ball.x with the constant 312 and ball.y with the constant 232. I compiled it, rant it, and it worked. As expected, the ball was in the exact middle of the screen. Just to make sure, I tried it again. I went back to the DrawScene() function in main.cpp and I changed dest.x from 312 to 0 and dest.y from 232 to 0. I compiled it, and ran it, and as expected the ball now appears in the top left corner (at 0,0). So, by now I'm convinced that there is something wrong with my class code, because when I explicitly set dest.x to 312 it works fine. When I set dest.x to ball.xpos and dest.y to ball.ypos, the ball goes to the lower-right. Up until this point anyway. Just for kicks, I tried using the original DrawScene() again:
void DrawScene()
{

  SDL_Rect src;
  
  ball.GetSrcRect(&src);
  
  SDL_Rect dest;
  dest.x = ball.xpos;
  dest.y = ball.ypos;
  SDL_BlitSurface(image, &src, screen, &dest);
  
  SDL_Flip(screen);
}

But this time, the ball did not appear in the lower-right like it did before. Not, it appeared in the top left! Which is exactly the same place it was when dest.x and dest.y were both explicitly set to zero! Which just happened to be the last position they were in! So, *something* appears to be "saving" the position of ball the last time it ran, and it is overriding the values I set in the default constructor. If I use numberical constants for dest.x and dest.y, the program works as expected. However, whenever I try to pull the dest.x and dest.y data from the ball object (ball.xpos and ball.ypos), it doesn't work. It instead just uses the x and y values from the last time I ran the program. I have no idea how it's doing that, mind you. So, I wanted to figure out what data, if any, main.cpp is getting from the ball object. So, I entered some printf()'s to have it print ball.xpos and ball.ypos to a text file:
void DrawScene()
{

  SDL_Rect src;
  
  ball.GetSrcRect(&src);
  
  SDL_Rect dest;
  printf("X: %d\n", ball.xpos);
  printf("Y: %d\n", ball.ypos);
  dest.x = ball.xpos;
  dest.y = ball.ypos;
  SDL_BlitSurface(image, &src, screen, &dest);
  
  SDL_Flip(screen);
}

I compiled it, ran it. And you know what? Now it works. When I have those printf()'s in there, all of a sudden the whole thing works. WHY? I HAVE NO IDEA. Arrgh! So at this point I don't know if it's a bug with the compiler, IDE, or my code. I'm totally stumped. I'll leave those printf()'s in there if I HAVE to, but I'd much rather figure out what the heck I'm doing wrong. Here are both files in their entirety: main.cpp:
#include <stdio.h>
#include <stdlib.h>
#include "ball.h"

#include <SDL/SDL.h>

void Slock(SDL_Surface *screen);
void Sulock(SDL_Surface *screen);
void DrawPixel(SDL_Surface *screen, int x, int y, Uint8 R, Uint8 G, Uint8 B);
void DrawScene();

Ball ball;

SDL_Surface *image;
SDL_Surface *screen;

int start_time = SDL_GetTicks();


int main(int argc, char *argv[])
{
    
    srand(SDL_GetTicks());

  // initialize SDL
  if ( SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO) < 0 )
  {
    printf("Unable to init SDL: %s\n", SDL_GetError());
    exit(1);
  }
  atexit(SDL_Quit); // shut down SDL when program returns
  

  // set video mode
  screen=SDL_SetVideoMode(640,480,32,SDL_HWSURFACE|SDL_DOUBLEBUF);
  if ( screen == NULL )
  {
    printf("Unable to set 640x480 video: %s\n", SDL_GetError());
    exit(1);
  }
  int done=0;
  
  image = SDL_LoadBMP("image.bmp");

  while(done == 0)
  {
    SDL_Event event;

    while ( SDL_PollEvent(&event) )
    {
      if ( event.type == SDL_QUIT )  {  done = 1;  }

      if ( event.type == SDL_KEYDOWN )
      {
        if ( event.key.keysym.sym == SDLK_ESCAPE ) { done = 1; }
      }
    }

   
    DrawScene();
  }

  return 0;
}




void Slock(SDL_Surface *screen)
{
  if ( SDL_MUSTLOCK(screen) )
  {
    if ( SDL_LockSurface(screen) < 0 )
    {
      return;
    }
  }
}

void Sulock(SDL_Surface *screen)
{
  if ( SDL_MUSTLOCK(screen) )
  {
    SDL_UnlockSurface(screen);
  }
}


void DrawPixel(SDL_Surface *screen, int x, int y, Uint8 R, Uint8 G, Uint8 B)
{
  Uint32 color = SDL_MapRGB(screen->format, R, G, B);
  switch (screen->format->BytesPerPixel)
  {
    case 1: // Assuming 8-bpp
      {
        Uint8 *bufp;
        bufp = (Uint8 *)screen->pixels + y*screen->pitch + x;
        *bufp = color;
      }
      break;
    case 2: // Probably 15-bpp or 16-bpp
      {
        Uint16 *bufp;
        bufp = (Uint16 *)screen->pixels + y*screen->pitch/2 + x;
        *bufp = color;
      }
      break;
    case 3: // Slow 24-bpp mode, usually not used
      {
        Uint8 *bufp;
        bufp = (Uint8 *)screen->pixels + y*screen->pitch + x * 3;
        if(SDL_BYTEORDER == SDL_LIL_ENDIAN)
        {
          bufp[0] = color;
          bufp[1] = color >> 8;
          bufp[2] = color >> 16;
        } else {
          bufp[2] = color;
          bufp[1] = color >> 8;
          bufp[0] = color >> 16;
        }
      }
      break;
    case 4: // Probably 32-bpp
      {
        Uint32 *bufp;
        bufp = (Uint32 *)screen->pixels + y*screen->pitch/4 + x;
        *bufp = color;
      }
      break;
  }
}



void DrawScene()
{

  SDL_Rect src;
  
  ball.GetSrcRect(&src);
  
  SDL_Rect dest;
  printf("X: %d\n", ball.xpos);
  printf("Y: %d\n", ball.ypos);
  dest.x = ball.xpos;
  dest.y = ball.ypos;
  SDL_BlitSurface(image, &src, screen, &dest);
  
  SDL_Flip(screen);
}

ball.h:
#include <SDL/SDL.h>

class Ball
{
     
  public: 
            
  Ball();
  Ball(int,int,int,int,int);   
      
  int xpos, ypos;
  int xspeed, yspeed;
  int birth;
  int color;
  
  int GetCurrentFrame();
  int GetCurrentCell();
  void GetSrcRect(SDL_Rect * src);    
      
};





Ball::Ball()
{
            
 xpos = 312;
 ypos = 232;
 
 xspeed = 0;
 yspeed = 0;
 
 color = 0;
 
 birth = SDL_GetTicks();
            
} // end of Ball constructor


Ball::Ball(int _xpos, int _ypos, int _xspeed, int _yspeed, int _color)
{
            
 xpos = _xpos;
 ypos = _ypos;
 
 xspeed = _xspeed;
 yspeed = _yspeed;
 
 color = _color;
 
 birth = SDL_GetTicks();
            
} // end of Ball constructor




int Ball::GetCurrentFrame()
{
 
 int interval = (SDL_GetTicks() - birth) % 1160;
 int frame = interval / 20;
 
 return frame;    
    
} // end GetCurrectFrame


int Ball::GetCurrentCell()
{
    
 int cell = GetCurrentFrame();
 if(cell > 29)
  {
          
   int sub = (cell - 29)*2;
   cell -= sub;        
          
  }   
  
  return cell;
    
} // end GetCurrentCell


void Ball::GetSrcRect(SDL_Rect * src)
{
     
 src->x = GetCurrentCell() * 16;
 src->y = color*16;
 src->h = 16;
 src->w = 16;
     
} // end GetSrcRect

Share this post


Link to post
Share on other sites
Are you using F9 or "compile" to compile? The thing about .h files is that they're headers and in order to recompile them you must do a full rebuild with Ctrl+F11. Has caused me a minor irritation before, too, it's absolutely maddening when you keep changing the code and you don't know why nothing happens.

If that's not it, ehm...

EDIT: My guess is when you forced a new dependency on ball.h from main.cpp, it recompiled.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by uncle_rico
Ok, this might take a bit of explanation. I am using Dev-C++ 4.9.9.2 as my IDE, which comes with MinGW 3.4.2. My language is C++ and I'm using SDL for graphics. I am trying to learn some basic collision detection, so my plan is to have two balls bounce around the screen (and each other), Pong-style.

I have two files in my project:

1) main.cpp
2) ball.h

The first one is self-explanatory. The second is the header file that has my ball class declaration and implimentation. I'll include them in their entirety at the end of this post. For now, here is the Ball class declaration:
*** Source Snippet Removed ***
Ok, and here is the default constructor:
*** Source Snippet Removed ***
Ok, so over in main.cpp, I have declared a ball globally:

Ball ball;

And I have a DrawScene() function which draws the ball to the screen.
*** Source Snippet Removed ***
So, I run it the first time and everything seems to work fine. The ball isn't moving, which is good, because the default constructor sets the speeds to 0. The ball is orange, which is good because that's what color = 0; corresponds to. The animation is working perfectly (the ball sort of flashes slowly). The only problem is, the position is all wrong. The ball is appearing in the lower-right corner of the screen rather than the direct middle of the screen.

So exit out of the program and return to Dev-C++. I take another look at the default constructor. I found that the reason the ball was appearing in the wrong place is that I've entered the wrong values for xpos and ypos. Instead of 312,232 I entered 632,472. Duh! So, I just changed them to 312 and 232.

I then rant he program again, and unfortunately that didn't seem to work. The ball was appearing in the lower-right again. I thought that perhaps I didn't save ball.h properly. It's part of my project and so it should save automatically when I hit "compile", but whatever. I went back to ball.h and hit CTRL+S to save it. Then I opened ball.h in a separate program (notepad) just to make sure that it worked. It did. The proper values were there.

So I compiled and ran it again. No dice. The ball was still in the lower-right corner.

So I figured, maybe the reason it's in the lower-right has nothing to do with the fact that the original xpos and ypos I had in there were 632 and 472, respectively. Perhaps that was just a coincidence, and therefore there is perhaps something fundamentally wrong with my code. To test this, I decided to set the x and y of the destination SDL_Rect explicitly:
*** Source Snippet Removed ***
Notice how I replaced the ball.x with the constant 312 and ball.y with the constant 232. I compiled it, rant it, and it worked. As expected, the ball was in the exact middle of the screen.

Just to make sure, I tried it again. I went back to the DrawScene() function in main.cpp and I changed dest.x from 312 to 0 and dest.y from 232 to 0. I compiled it, and ran it, and as expected the ball now appears in the top left corner (at 0,0).

So, by now I'm convinced that there is something wrong with my class code, because when I explicitly set dest.x to 312 it works fine. When I set dest.x to ball.xpos and dest.y to ball.ypos, the ball goes to the lower-right. Up until this point anyway. Just for kicks, I tried using the original DrawScene() again:
*** Source Snippet Removed ***
But this time, the ball did not appear in the lower-right like it did before. Not, it appeared in the top left! Which is exactly the same place it was when dest.x and dest.y were both explicitly set to zero! Which just happened to be the last position they were in!

So, *something* appears to be "saving" the position of ball the last time it ran, and it is overriding the values I set in the default constructor. If I use numberical constants for dest.x and dest.y, the program works as expected. However, whenever I try to pull the dest.x and dest.y data from the ball object (ball.xpos and ball.ypos), it doesn't work. It instead just uses the x and y values from the last time I ran the program. I have no idea how it's doing that, mind you.

So, I wanted to figure out what data, if any, main.cpp is getting from the ball object. So, I entered some printf()'s to have it print ball.xpos and ball.ypos to a text file:
*** Source Snippet Removed ***
I compiled it, ran it. And you know what? Now it works. When I have those printf()'s in there, all of a sudden the whole thing works. WHY? I HAVE NO IDEA. Arrgh!

So at this point I don't know if it's a bug with the compiler, IDE, or my code. I'm totally stumped. I'll leave those printf()'s in there if I HAVE to, but I'd much rather figure out what the heck I'm doing wrong.

Here are both files in their entirety:

main.cpp:
*** Source Snippet Removed ***

ball.h:
*** Source Snippet Removed ***


I'm clueless. Maybe my brain isnt working, or maybe I missed something. But I am clueless.

One random suggestion:
The destination rect for the ball... Add the x, y, and also try adding the the ball's width and height to w and h. Don't know why, might work though.

If it won't work, get code::blocks. I hope the link works, but most likely it won't because I got... Nevermind that. It's almost the same as Dev-Cpp, but much much less buggy and more highlighting. I like it, and I, too, switched over from dev-cpp.

Good luck... This is actually weird.

C++

Share this post


Link to post
Share on other sites
Holy ****ing shit you guys are awesome. That worked perfectly. Dammit, I can't believe it was that simple. I was doing all these tests and crap for nothing. Rating++ for both of you.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Dev-Cpp does that? But won't including the header force a rebuild of it?

Anyways, good you solved your problem. It's interesting, how did that not happen to me? I had used dev-cpp once....

C++

Share this post


Link to post
Share on other sites

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