Sign in to follow this  
CraazyDave

Trouble moving sprites

Recommended Posts

I am trying to make a game in SDL but I am avoiding at all costs to have any part of SDL in the main. Instead I have a class GameEngine with all the SDL functionality.

My problem is that I need to tie together the keyinputs that I check in GameEngine and call in the main method to the blitting of the Sprite.
It all should be straightforward but for some reason it does not work for me.

Now the problem I am having is that the x and y values that I use to change the position of the Sprite does not update with my keypresses.

The Method that checks the events:
[code]

bool GameEngine::events()
{
std::cout << spriteField.size() << std::endl;

int xVel = 0;
int yVel = 0;

while(SDL_PollEvent(&event))
{
if(event.type == SDL_QUIT)
{
exit();
return true;
}
if(event.type == SDL_KEYDOWN)
{
switch(event.key.keysym.sym)
{
case SDLK_UP:
yVel -= 5;
break;
case SDLK_DOWN:
yVel += 5;
break;
case SDLK_RIGHT:
xVel -= 5;
break;
case SDLK_LEFT:
xVel += 5;
break;
}
}
if(event.type == SDL_KEYUP)
{
switch(event.key.keysym.sym)
{
case SDLK_UP:
yVel += 5;
break;
case SDLK_DOWN:
yVel -= 5;
break;
case SDLK_RIGHT:
xVel += 5;
break;
case SDLK_LEFT:
xVel -= 5;
break;
}
}

for(int i = 0; i < spriteField.size(); i++)
{
spriteField[i].setVel(xVel, yVel);
spriteField[i].move();
}
}

return false;
}
[/code]

Any help with figuring out why it does not work would be very helpfull.

Share this post


Link to post
Share on other sites
Try changing your second if to an else if. I have never used SDL but from what I can see if you have a key down and than release it the events will cancel as it is an if statement and not an else if.

Share this post


Link to post
Share on other sites
[quote name='XXChester' timestamp='1311619888' post='4840121']
Try changing your second if to an else if. I have never used SDL but from what I can see if you have a key down and than release it the events will cancel as it is an if statement and not an else if.
[/quote]


That wont have an effect, as the event will only return a result once per call, AKA, it's not going to change during the processing of that code.
However, you are onto what I think the problem is. In the event loop you are increasing the velocity on key down, but then decrementing velocity on key up. That means on a key press ( an down and up event ) you are immediately increasing the velocity, then in the very next event literally milliseconds away, you are descreasing velocity.


So, in the event of a keypress, the following is happening.

velocity set to 0

key down, velocity increased by 5

milliseconds later, next event in loop is keyup event, velocity reduced back to 0.


This is most likely not the logic you actually want. That said, in the event of a key held down, your sprite should move. In this case, without seeing more code ( specifically setVel() and move() ) there is no way to know eactly where the problem is.

Share this post


Link to post
Share on other sites
[quote name='Serapth' timestamp='1311620372' post='4840127']
[quote name='XXChester' timestamp='1311619888' post='4840121']
Try changing your second if to an else if. I have never used SDL but from what I can see if you have a key down and than release it the events will cancel as it is an if statement and not an else if.
[/quote]


That wont have an effect, as the event will only return a result once per call, AKA, it's not going to change during the processing of that code.
However, you are onto what I think the problem is. In the event loop you are increasing the velocity on key down, but then decrementing velocity on key up. That means on a key press ( an down and up event ) you are immediately increasing the velocity, then in the very next event literally milliseconds away, you are descreasing velocity.


So, in the event of a keypress, the following is happening.

velocity set to 0

key down, velocity increased by 5

milliseconds later, next event in loop is keyup event, velocity reduced back to 0.


This is most likely not the logic you actually want. That said, in the event of a key held down, your sprite should move. In this case, without seeing more code ( specifically setVel() and move() ) there is no way to know eactly where the problem is.
[/quote]


I changed it to else if, and I can agree why that would be preferable but it made no difference. So here is the setVel() and Move()
[code]
void Sprite::setVel(int xv, int yv)
{
xVel += xv;
yVel += yv;

std::cout << "setVel" << x << " " << y << std::endl;
}
[/code]

And:

[code]
void Sprite::move()
{
x += xVel;
y += yVel;

std::cout << "move is" << x << " " << y << std::endl;
}
[/code]

And nothing special happens in them. I could poste the entire main, GameEngine and Sprite class if needed

Share this post


Link to post
Share on other sites
[quote name='Serapth' timestamp='1311620372' post='4840127']
[quote name='XXChester' timestamp='1311619888' post='4840121']
Try changing your second if to an else if. I have never used SDL but from what I can see if you have a key down and than release it the events will cancel as it is an if statement and not an else if.
[/quote]


That wont have an effect, as the event will only return a result once per call, AKA, it's not going to change during the processing of that code.
However, you are onto what I think the problem is. In the event loop you are increasing the velocity on key down, but then decrementing velocity on key up. That means on a key press ( an down and up event ) you are immediately increasing the velocity, then in the very next event literally milliseconds away, you are descreasing velocity.


So, in the event of a keypress, the following is happening.

velocity set to 0

key down, velocity increased by 5

milliseconds later, next event in loop is keyup event, velocity reduced back to 0.


This is most likely not the logic you actually want. That said, in the event of a key held down, your sprite should move. In this case, without seeing more code ( specifically setVel() and move() ) there is no way to know eactly where the problem is.
[/quote]

Basically what you stated is exactly what I was thinking about the events canceling each other but I am not sure why I thought the else if would fix that.

As for the problem Crazy, you are probably still having the same problem even though they are split into separate functions because the way you are handling the events is probably the same...on key down; do this, on key up; do this. You may want to post how you are calling these functions. Also a little background on the type of game might help, reading the code I am assuming it is a sort of racing game or space game and that is why you have -velocity calculations on key up opposed to just stopping the sprite all together, correct?

Share this post


Link to post
Share on other sites
[quote name='XXChester' timestamp='1311681574' post='4840459']
[quote name='Serapth' timestamp='1311620372' post='4840127']
[quote name='XXChester' timestamp='1311619888' post='4840121']
Try changing your second if to an else if. I have never used SDL but from what I can see if you have a key down and than release it the events will cancel as it is an if statement and not an else if.
[/quote]


That wont have an effect, as the event will only return a result once per call, AKA, it's not going to change during the processing of that code.
However, you are onto what I think the problem is. In the event loop you are increasing the velocity on key down, but then decrementing velocity on key up. That means on a key press ( an down and up event ) you are immediately increasing the velocity, then in the very next event literally milliseconds away, you are descreasing velocity.


So, in the event of a keypress, the following is happening.

velocity set to 0

key down, velocity increased by 5

milliseconds later, next event in loop is keyup event, velocity reduced back to 0.


This is most likely not the logic you actually want. That said, in the event of a key held down, your sprite should move. In this case, without seeing more code ( specifically setVel() and move() ) there is no way to know eactly where the problem is.
[/quote]

Basically what you stated is exactly what I was thinking about the events canceling each other but I am not sure why I thought the else if would fix that.

As for the problem Crazy, you are probably still having the same problem even though they are split into separate functions because the way you are handling the events is probably the same...on key down; do this, on key up; do this. You may want to post how you are calling these functions. Also a little background on the type of game might help, reading the code I am assuming it is a sort of racing game or space game and that is why you have -velocity calculations on key up opposed to just stopping the sprite all together, correct?
[/quote]

Allright. I did some thinking and I figure that the else if is unnecessary so I commented it away to try and see what happened.

RIght now what happens everytime I press a key I see that it changes the xVel and yVel in setVel() and changes are made to the values affected in move() but when the values are taken to the bliting method they are the
of the dafault value.
If that makes any sense.

I'll just post the classes that is involved in the movement:

GameEngine.cpp:
[code]
#include "SDL.h"
#include "GameEngine.h"
#include "Image.h"
#include "Sprite.h"
#include <vector>
#include <string>
#include <iostream>

GameEngine::GameEngine(int h, int w)
{
SCREEN_HEIGHT = h;
SCREEN_WIDTH = w;

SDL_Init(SDL_INIT_EVERYTHING);

screen = SDL_SetVideoMode(SCREEN_HEIGHT, SCREEN_WIDTH, 32, SDL_SWSURFACE | SDL_DOUBLEBUF);

SDL_ShowCursor(SDL_DISABLE);
}

void GameEngine::log(std:: string log)
{
std::cout << log.c_str() << std::endl;
}

void GameEngine::update()
{
//Update screen and rect
SDL_Flip(screen);
SDL_UpdateRect(screen, 0, 0, 0, 0);
}

void GameEngine::fill()
{
SDL_FillRect(getScreen(), NULL, 0x000000);
}

void GameEngine::blit(SDL_Surface * i, SDL_Rect rect)
{
SDL_BlitSurface(i, NULL, screen, &rect);
}

void GameEngine::exit()
{
SDL_Quit();
}

bool GameEngine::events()
{
std::cout << spriteField.size() << std::endl;

int xVel = 0;
int yVel = 0;

while(SDL_PollEvent(&event))
{
if(event.type == SDL_QUIT)
{
exit();
return true;
}
if(event.type == SDL_KEYDOWN)
{
switch(event.key.keysym.sym)
{
case SDLK_UP:
yVel -= 5;
break;
case SDLK_DOWN:
yVel += 5;
break;
case SDLK_RIGHT:
xVel -= 5;
break;
case SDLK_LEFT:
xVel += 5;
break;
}
}
/*else if(event.type == SDL_KEYUP)
{
switch(event.key.keysym.sym)
{
case SDLK_UP:
yVel += 5;
break;
case SDLK_DOWN:
yVel -= 5;
break;
case SDLK_RIGHT:
xVel += 5;
break;
case SDLK_LEFT:
xVel -= 5;
break;
}
}*/

for(int i = 0; i < spriteField.size(); i++)
{
spriteField[i].setVel(xVel, yVel);
spriteField[i].move();
}
}

return false;
}

int GameEngine::checkFPS()
{
const int tickInterval = 1000/30;
nextTick = SDL_GetTicks() + tickInterval;

delay = nextTick - SDL_GetTicks();

return delay;
}

void GameEngine::delayProgram(int delay)
{
if(delay > 0)
SDL_Delay(delay);
}

SDL_Surface * GameEngine::getScreen()
{
return screen;
}

void GameEngine::addSprite(Sprite s)
{
spriteField.push_back(s);
}

SDL_Rect GameEngine::createTempRect(int x, int y)
{
SDL_Rect rectTemp;
rectTemp.x = x;
rectTemp.y = y;

return rectTemp;
}

[/code]

Sprite.cpp:
[code]
Sprite::Sprite(int xv, int yv, bool b)
{
xVel = 0;
yVel = 0;
player = b;
x = xv;
y = yv;
rect.setRect(x, y);
w = rect.getW();
h = rect.getH();
}

void Sprite::setImage(Image img)
{
i = img;
}

Image Sprite::getImage()
{
return i;
}

void Sprite::tick(std::vector<Sprite> spriteField)
{
for(int i = 0; i < spriteField.size(); i++)
collision(spriteField[i]);
}

void Sprite::setVel(int xv, int yv)
{
xVel += xv;
yVel += yv;

std::cout << "setVel" << x << " " << y << std::endl;
}

void Sprite::move()
{
x += xVel;
y += yVel;

std::cout << "move is" << x << " " << y << std::endl;
}

bool Sprite::collision(Sprite other)
{
int leftA, leftB;
int rightA, rightB;
int topA, topB;
int bottomA, bottomB;

//Calculate the sides of rect A
leftA = x;
rightA = x + w;
topA = y;
bottomA = y + h;

//Calculate the sides of rect B
leftB = other.x;
rightB = other.x + other.w;
topB = other.y;
bottomB = other.y + other.h;

//If any of the sides from A are outside of B
if(bottomA < topB)
{
return false;
}

if(topA > bottomB)
{
return false;
}

if(rightA < leftB)
{
return false;
}

if(leftA > rightB)
{
return false;
}

//If none of the sides from A are outside B
return true;
}

void Sprite::log(std::string log)
{
std::cout << log << std::endl;
}

Rect Sprite::getRect()
{
return rect;
}

int Sprite::getX()
{
return x;
}

int Sprite::getY()
{
return y;
}
[/code]

and the main.cpp:
[code]
int main(int argc, char * args[])
{
GameEngine g(1000, 800);

bool quit = false;

//Create images.
Image i(true, "pong_player.bmp");
Image background(false, "pong_middle.bmp");

//Sprite
Sprite s1(150, 200, true);
s1.setImage(i);
g.addSprite(s1);

while(quit == false)
{
int delay = g.checkFPS();

//Fill screen with black
g.fill();

g.blit(s1.getImage().getSurface(), s1.getRect().get());
//Blit the background
g.blit(background.getSurface(), g.createTempRect(500, 0));

//Update the screen
g.update();
//Check for events
quit = g.events();

g.delayProgram(delay);
}

g.exit();
return 0;
}
[/code]

And I'm not trying to make a particularly sofisticated game, I'm trying to make a reversed version of Pong where you try to avoid the ball instead of hitting it.

Share this post


Link to post
Share on other sites
Am I missing something? I see you are setting the xVel and yVel in your sprite class but I do not see those values referenced anywhere for rendering/updating

**EDIT**
removed first edit after another re-read
***EDIT** Edited by XXChester

Share this post


Link to post
Share on other sites
[quote name='XXChester' timestamp='1311694815' post='4840593']
Am I missing something? I see you are setting the xVel and yVel in your sprite class but I do not see those values referenced anywhere for rendering/updating

**EDIT**
removed first edit after another re-read
***EDIT**
[/quote]

Well I call the setVel method that sets what the velocity of the sprite should be in the events() method, and now that I look at it it perhaps should be xVel = xv not x += xv but I digress. And directly after that I call the move method() which in turn changes the x and y values.

And they are changed correctly when everytime I check.
By the way the move method I posted was incomplete from what I have been testing. I forgot to add the
[code]
rect.setRect(x, y);
[/code]
At the end of the method. And rect is of a class that contains a SDL_Rect and setRect(x, y); sets the x and y values of the rect. And that rect are then taken in the main method for the blitting of the sprite. Damn this is getting messy.

SO what is happening is that the keypresses are working but the rect does not change.

Share this post


Link to post
Share on other sites
[quote name='CraazyDave' timestamp='1311700069' post='4840664']
[quote name='XXChester' timestamp='1311694815' post='4840593']
Am I missing something? I see you are setting the xVel and yVel in your sprite class but I do not see those values referenced anywhere for rendering/updating

**EDIT**
removed first edit after another re-read
***EDIT**
[/quote]

Well I call the setVel method that sets what the velocity of the sprite should be in the events() method, and now that I look at it it perhaps should be xVel = xv not x += xv but I digress. And directly after that I call the move method() which in turn changes the x and y values.

And they are changed correctly when everytime I check.
By the way the move method I posted was incomplete from what I have been testing. I forgot to add the
[code]
rect.setRect(x, y);
[/code]
At the end of the method. And rect is of a class that contains a SDL_Rect and setRect(x, y); sets the x and y values of the rect. And that rect are then taken in the main method for the blitting of the sprite. Damn this is getting messy.

SO what is happening is that the keypresses are working but the rect does not change.
[/quote]

If it's not clear why this does not work, how would you achieve what I'm trying to do here? With moving a sprite while keeping all the SDL functionality away from the main.
Btw, I have gotten everything to work when I hardcode a movement for the sprites or if I have written the event loop in the main instead.

Share this post


Link to post
Share on other sites
[quote name='CraazyDave' timestamp='1311700069' post='4840664']
[quote name='XXChester' timestamp='1311694815' post='4840593']
Am I missing something? I see you are setting the xVel and yVel in your sprite class but I do not see those values referenced anywhere for rendering/updating

**EDIT**
removed first edit after another re-read
***EDIT**
[/quote]

Well I call the setVel method that sets what the velocity of the sprite should be in the events() method, and now that I look at it it perhaps should be xVel = xv not x += xv but I digress. And directly after that I call the move method() which in turn changes the x and y values.

And they are changed correctly when everytime I check.
By the way the move method I posted was incomplete from what I have been testing. I forgot to add the
[code]
rect.setRect(x, y);
[/code]
At the end of the method. And rect is of a class that contains a SDL_Rect and setRect(x, y); sets the x and y values of the rect. And that rect are then taken in the main method for the blitting of the sprite. Damn this is getting messy.

SO what is happening is that the keypresses are working but the rect does not change.
[/quote]

If it's not clear why this does not work, how would you achieve what I'm trying to do here? With moving a sprite while keeping all the SDL functionality away from the main.
Btw, I have gotten everything to work when I hardcode a movement for the sprites or if I have written the event loop in the main instead.

Share this post


Link to post
Share on other sites
This is getting messy and without using SDL myself I am running out of idea's, can you show me how you are rendering the sprite? Also can you post where you call rect.setRect(x,y) from please? Is this in an update call of your main loop or what?

Thanks.

Share this post


Link to post
Share on other sites
[quote name='XXChester' timestamp='1311701808' post='4840685']
This is getting messy and without using SDL myself I am running out of idea's, can you show me how you are rendering the sprite? Also can you post where you call rect.setRect(x,y) from please? Is this in an update call of your main loop or what?

Thanks.
[/quote]

I agree. This is getting to messy.
And I have posted the code for rendering a sprite. But for clarification:

In the while loop in the main i call the method blit from my GameEngine object.
[code]
g.blit(s1.getImage().getSurface(), s1.getRect().get());
[/code]
where the first argument is the SDL_Surface * that contains the acutal image. The other argument is the rect that contains the x and y values that should change depending on my keypresses.

If you want to see more of the rendering of the sprite then I do not see the point since it works and is unrelated to the issue. The issue is that the rect does not change at all when it should.

The setRect is made in the move method in Sprite which is called in the events method in GameEngine:
[code]
void Sprite::move()
{
x += xVel;
y += yVel;

std::cout << "move is" << x << " " << y << std::endl;

rect.setRect(x, y);
}
[/code]

Now since this is, as you said, getting messy perhapos I should start a new thread asking instead how I should implement the movement of a Sprite as I want it since this is not getting anywhere.

Share this post


Link to post
Share on other sites
Yeah sorry mate, it all looks fine to me (with the exception of the SDL code as I have never used it, so I cannot comment on it) so I cannot help. Hopefully someone else can come along and figure it out for you. Personally I would have the rendering handled within my sprite class so I know it is using exactly it's variables but as I do not know how to use SDL I cannot comment on whether this is even feasible.

Anyway sorry I couldn't help, best of luck.

Share this post


Link to post
Share on other sites
[quote name='XXChester' timestamp='1311704605' post='4840714']
Yeah sorry mate, it all looks fine to me (with the exception of the SDL code as I have never used it, so I cannot comment on it) so I cannot help. Hopefully someone else can come along and figure it out for you. Personally I would have the rendering handled within my sprite class so I know it is using exactly it's variables but as I do not know how to use SDL I cannot comment on whether this is even feasible.

Anyway sorry I couldn't help, best of luck.
[/quote]

You know what. Having the rendering in the Sprite class may not be impossible. I'll at least try it before I try something else or post another thread!

Share this post


Link to post
Share on other sites
I'm not 100% sure what that "spriteField" is, but when it is what I think, say a List of all the sprites, then your for loop may be the problem.

Try : [code] for ( int i = 0; i <= spriteField.size(); i++) [/code]

So it iterates correctly through all the Sprites, otherwise it will forget the last one. ( <= instead of <)

Share this post


Link to post
Share on other sites
Hidden
[quote name='skyskewz' timestamp='1311719981' post='4840854']
I'm not 100% sure what that "spriteField" is, but when it is what I think, say a List of all the sprites, then your for loop may be the problem.

Try : [code] for ( int i = 0; i <= spriteField.size(); i++) [/code]

So it iterates correctly through all the Sprites, otherwise it will forget the last one. ( <= instead of <)
[/quote]

Good point! Changed it and it seems to work but the movement does not show up then the rendering is done. So that should mean that there is nothing wrong, now anyway, with the event loop and that there is something with how I render the Sprite that does not work as it should.

Share this post


Link to post
[quote name='skyskewz' timestamp='1311719981' post='4840854']
I'm not 100% sure what that "spriteField" is, but when it is what I think, say a List of all the sprites, then your for loop may be the problem.

Try : [code] for ( int i = 0; i <= spriteField.size(); i++) [/code]

So it iterates correctly through all the Sprites, otherwise it will forget the last one. ( <= instead of <)
[/quote]

Hi! I don't think that is true. From 0 to < spriteField.size() there are n elements. From 0 to <= spriteField.size() the are n+1 elements. This means, there is one more sprite which he has not added in the vector. This should throw an index out of bounds exception.

Share this post


Link to post
Share on other sites
[quote name='ArthY303' timestamp='1311756249' post='4841006']
[quote name='skyskewz' timestamp='1311719981' post='4840854']
I'm not 100% sure what that "spriteField" is, but when it is what I think, say a List of all the sprites, then your for loop may be the problem.

Try : [code] for ( int i = 0; i <= spriteField.size(); i++) [/code]

So it iterates correctly through all the Sprites, otherwise it will forget the last one. ( <= instead of <)
[/quote]

Hi! I don't think that is true. From 0 to < spriteField.size() there are n elements. From 0 to <= spriteField.size() the are n+1 elements. This means, there is one more sprite which he has not added in the vector. This should throw an index out of bounds exception.
[/quote]

This is correct, the for loop is fine unless C++ has somehow changed it's size function since I last used it.

Share this post


Link to post
Share on other sites
[quote name='XXChester' timestamp='1311766777' post='4841053']
[quote name='ArthY303' timestamp='1311756249' post='4841006']
[quote name='skyskewz' timestamp='1311719981' post='4840854']
I'm not 100% sure what that "spriteField" is, but when it is what I think, say a List of all the sprites, then your for loop may be the problem.

Try : [code] for ( int i = 0; i <= spriteField.size(); i++) [/code]

So it iterates correctly through all the Sprites, otherwise it will forget the last one. ( <= instead of <)
[/quote]

Hi! I don't think that is true. From 0 to < spriteField.size() there are n elements. From 0 to <= spriteField.size() the are n+1 elements. This means, there is one more sprite which he has not added in the vector. This should throw an index out of bounds exception.
[/quote]

This is correct, the for loop is fine unless C++ has somehow changed it's size function since I last used it.
[/quote]

Yes well regardless how the for loop looks it seems to work. But still no movement

Share this post


Link to post
Share on other sites
[s]Hmm. Non-keystroke events occuring will reset the velocity of all sprites:

[code]
xVel = 0;
yVel = 0;
...
for(int i = 0; i < spriteField.size(); i++)
{
spriteField[i].setVel(xVel, yVel);
spriteField[i].move();
}
[/code]
Is this what you intend, or are you certain that only keystroke events are treated in ::events()?
Even if so, the moment you depress a key, the speed will still be reset for all sprites.[/s]

Nevermind. Apparently your setVel -function alters (but does not set) the velocity, so the above is invalid.
You do however, not output the velocity at setVel, but the position, x and y:

[code]
xVel += xv;
yVel += yv;
std::cout << "setVel" << x << " " << y << std::endl;
[/code]

Share this post


Link to post
Share on other sites
You are passing a lot of things by value. For example in GameEngine::addSprite the sprite is passed by value which means that the sprite you have in addSprite is a copy of the sprite you passed from the main function. You may consider passing by pointer (Sprite* s) or by reference (Sprite& s). When you do spriteField.push_back(s) a copy of s will be stored in spriteField. You may want to store pointers to sprites in spriteField instead (std::vector<Sprite*>). The problem when using copies is that when you change the copy the original object will not be affected. You update the sprites in spriteField but blit the sprites in main which is not the same sprites. Another problem with making copies of large classes like Image is that it is probably slow, unless you have implemented something special.

I also noticed a few other things that is unrelated to the problem you have.
[list]
[*]checkFPS() always return 33 (if we assume that the two calls to SDL_GetTicks() return the same value). The function looks more complicated so it looks like you trying to do something else.
[*]in update() you call both SDL_Flip(screen) and SDL_UpdateRect(screen, 0, 0, 0, 0). These two calls do the same thing so one can be removed.
[*]GameEngine::exit() is called from both events() and from main. Why not place the code that is in exit() in the the GameEngine destructor?
[/list]

Share this post


Link to post
Share on other sites
[quote name='Wooh' timestamp='1311775331' post='4841098']
You are passing a lot of things by value. For example in GameEngine::addSprite the sprite is passed by value which means that the sprite you have in addSprite is a copy of the sprite you passed from the main function. You may consider passing by pointer (Sprite* s) or by reference (Sprite& s). When you do spriteField.push_back(s) a copy of s will be stored in spriteField. You may want to store pointers to sprites in spriteField instead (std::vector<Sprite*>). The problem when using copies is that when you change the copy the original object will not be affected. You update the sprites in spriteField but blit the sprites in main which is not the same sprites. Another problem with making copies of large classes like Image is that it is probably slow, unless you have implemented something special.

I also noticed a few other things that is unrelated to the problem you have.
[list][*]checkFPS() always return 33 (if we assume that the two calls to SDL_GetTicks() return the same value). The function looks more complicated so it looks like you trying to do something else.[*]in update() you call both SDL_Flip(screen) and SDL_UpdateRect(screen, 0, 0, 0, 0). These two calls do the same thing so one can be removed.[*]GameEngine::exit() is called from both events() and from main. Why not place the code that is in exit() in the the GameEngine destructor?[/list]
[/quote]

Thanks for the tip! I am having a hard time figuring out pointers, are so used to coding in Java that I becomes difficult to use pointers for me. But you sure have a good point. I'll try to send the pointer to the things I am sending instead of a copy. And then see what happens.

And to other issues you mention. checkFps() should controll the framerate but if it allways returns 33 then It does not seem to do that.

The update function works, maybe I will change it later if I feel like it but it does not affect the program negatively as far as I know.

Good point about GameEngine::exit(), I'll do that

Share this post


Link to post
Share on other sites
[quote name='CraazyDave' timestamp='1312110681' post='4842804']The update function works, maybe I will change it later if I feel like it but it does not affect the program negatively as far as I know.[/quote]Yes, the function works perfectly fine. The thing is that now update() takes about twice as long time to execute than if you removed one of the calls. This might slow your program down. Maybe it's not a problem for a simple game but I still think it's a bit wasteful for no good reason.

Share this post


Link to post
Share on other sites
Hidden
[quote name='CraazyDave' timestamp='1312110681' post='4842804']
[quote name='Wooh' timestamp='1311775331' post='4841098']
You are passing a lot of things by value. For example in GameEngine::addSprite the sprite is passed by value which means that the sprite you have in addSprite is a copy of the sprite you passed from the main function. You may consider passing by pointer (Sprite* s) or by reference (Sprite& s). When you do spriteField.push_back(s) a copy of s will be stored in spriteField. You may want to store pointers to sprites in spriteField instead (std::vector<Sprite*>). The problem when using copies is that when you change the copy the original object will not be affected. You update the sprites in spriteField but blit the sprites in main which is not the same sprites. Another problem with making copies of large classes like Image is that it is probably slow, unless you have implemented something special.

I also noticed a few other things that is unrelated to the problem you have.
[list][*]checkFPS() always return 33 (if we assume that the two calls to SDL_GetTicks() return the same value). The function looks more complicated so it looks like you trying to do something else.[*]in update() you call both SDL_Flip(screen) and SDL_UpdateRect(screen, 0, 0, 0, 0). These two calls do the same thing so one can be removed.[*]GameEngine::exit() is called from both events() and from main. Why not place the code that is in exit() in the the GameEngine destructor?[/list]
[/quote]

Thanks for the tip! I am having a hard time figuring out pointers, are so used to coding in Java that I becomes difficult to use pointers for me. But you sure have a good point. I'll try to send the pointer to the things I am sending instead of a copy. And then see what happens.

And to other issues you mention. checkFps() should controll the framerate but if it allways returns 33 then It does not seem to do that.

The update function works, maybe I will change it later if I feel like it but it does not affect the program negatively as far as I know.

Good point about GameEngine::exit(), I'll do that
[/quote]

Ok, I have fixed checkFPS() and done as you suggested with the update() and the deconstructor. It all works perfectly. Have barely started the major changes you suggest but I'm getting there.

Share this post


Link to post
[quote name='Wooh' timestamp='1312113361' post='4842809']
[quote name='CraazyDave' timestamp='1312110681' post='4842804']The update function works, maybe I will change it later if I feel like it but it does not affect the program negatively as far as I know.[/quote]Yes, the function works perfectly fine. The thing is that now update() takes about twice as long time to execute than if you removed one of the calls. This might slow your program down. Maybe it's not a problem for a simple game but I still think it's a bit wasteful for no good reason.
[/quote]

I have done as you suggested with the update and deconstructor in GameEngine. It all works perfectly.

I Am about to start the major changes that you suggested.

Share this post


Link to post
Share on other sites

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