Messages

76

Graphics / Making a Map from a file, stack overload error

« on: July 31, 2011, 07:34:00 am »

You typically get a stack overflow one of two ways:

1)  Having an array on the stack that's way too big

Code: [Select]


int func()
{
  int waytoobig[100000];  // bad idea to put all this on the stack!
}


or

2)  Having a function that's infinitely recursive (calls itself) -- or a series of functions that loop into calling themselves.

Code: [Select]


void func1()
{
  func2();
}

void func2()
{
  func1();
}

// func1 calls func2
//  and func2 calls func1
//  so this will suck up stack space until you run out


Are you doing either of these?

77

Graphics / anything look wrong with this code?

« on: July 31, 2011, 04:23:02 am »

Once you erase() something from a vector, all existing iterators of that vector become invalid.

That means:

Code: [Select]


        if (DetectCollision.BoundingBoxTest((*iterP)->getSprite(), (*iterA)->getSprite()))
        {
//...
            pProjectileVector->erase(iterP);  // iterP is no longer valid after this call
//...
            iterP--;  // this is meaningless.  Next loop iteration, iterP will be bad/invalid
//  same problem with iterA


iterP--; is a bad idea anyway.  A general rule of thumb is that if you need to have something that "undoes" the for loop increment, then you probably shouldn't be using a for loop.

To get a valid iterator after an erase, use erase's return value.

This code should work (untested):

Code: [Select]


vector<Projectile*>::iterator iterP = pProjectileVector->begin();
while( iterP != pProjectileVector->end() )
{
    vector<Asteroid*>::iterator iterA = pAsteroidVector->begin();
    while( (iterA != pAsteroidVector->end()) && (iterP != pProjectileVector->end()) ) // have to check iterP in this loop, too
      // since it could reach the end of the vector as well
    {
        if (DetectCollision.BoundingBoxTest((*iterP)->getSprite(), (*iterA)->getSprite()))
        {
            delete *iterP;
            iterP = pProjectileVector->erase(iterP);  // iterP =
            delete *iterA;
            iterA = pAsteroidVector->erase(iterA);  // iterA =
            Asteroids.setAsteroidCount(Asteroids.getAsteroidCount()-1);
        }
else  // no collision
{
            ++iterA;
   }
    }

if(iterP != pProjectileVector->end())
   ++iterP;
}


78

Graphics / Collision Class

« on: July 31, 2011, 02:45:33 am »

then what are the main reasons for using SFML?

SFML is primarily an I/O lib.  Input from the user, output to the user, and I/O over a network.

Things like collision are far to specialized and vary greatly depending on how the underlying game/physics engine works.

If you want a collision/physics library, there are some available.  Box2D is popular (easily found on google).  I think there have even been example projects posted on the board that were SFML+Box2D.

79

Graphics / [Solved] Is the refreshing optimized?

« on: July 24, 2011, 06:07:10 pm »

+1 to everyone else.

Dirty Rects is an antiquated concept.  Today's machines are designed to redraw the full screen every frame because that is what is expected/required of most programs (it's all 3D hardware now, and dirty rects simply don't apply to a 3D environment)


So yeah, don't worry about it.  Just redraw the whole thing every frame.

80

Graphics / Question on Gifs

« on: July 24, 2011, 08:52:31 am »

Yes, but they won't animate.

I think if you try to load an animated gif, you only get the first frame.  Either that or it fails to load.

81

Graphics / Sprite boundaries

« on: July 24, 2011, 07:03:19 am »

If you want to check to see if the move is valid before you move, then you shouldn't call move directly like you are.

You should do something like this:

Code: [Select]


sf::Vector2f move( x_to_move, y_to_move );

if(move.x < 0) // moving left
{
  // check to make sure they're not moving off the left bound
}
else if(move.x > 0) // moving right
{
  // check to make sure they're not moving off the right bound
}

// do the same for y

if( move_is_within_bounds )
  Ship.Move(move);


82

Graphics / Sprite boundaries

« on: July 24, 2011, 06:27:18 am »

What difference does it make whether or not the sprite is rotating?

It still has an x/y coord, and that x/y coord can just as easily be checked to see if it's within the window bounds.

83

Graphics / Simulating character movement - How do? [SOLVED]

« on: July 22, 2011, 06:03:24 pm »

Yes I am the same Disch from the cplusplus.com forums.  

84

Graphics / Simulating character movement - How do? [SOLVED]

« on: July 22, 2011, 04:46:20 pm »

You might also want to set a framerate limit so that the speed at which your player moves does not depend on the speed of the user's computer.

If you set the FPS limit to 60, and he's moving at 1 pixel per frame, then he'll move 60 pixels per second.

85

Graphics / Simulating character movement - How do? [SOLVED]

« on: July 22, 2011, 02:25:03 am »

Whether or not the key is down has nothing to do with events.  So take that out of your event loop.

You want something like this:

Code: [Select]


while(game_running)
{
  while( events )
  {
    // check the events
    //   the only event you're probably interested in is the Close
    //   event
   
    //  you do NOT want key events
  }

  // now that you're outside the event loop, see what keys are down

  // move object based on whatever keys are down

  //  draw / display
}


86

General discussions / [CPP Source] - Load Assets using PhysicsFS

« on: July 21, 2011, 04:33:14 pm »

Some other things I notice:

- you're using new[], but you're cleaning up with delete.  You should be cleaning up with delete[].  You probably are leaking massive memory as a result.

Remember:
new -> delete
new[] -> delete[]

Don't mix-and-match

- I don't think your font loader will work because I'm pretty sure the memory buffer has to stay available for the lifetime of the font (since it does continual seeks/reads and character data is needed).  In your case you're deleteing the buffer right away which will cause sf::Font to read from a bad pointer.

87

General discussions / [CPP Source] - Load Assets using PhysicsFS

« on: July 21, 2011, 03:00:48 am »

You know... I actually helped design sf::InputStream for just this kind of thing.

Using it, you wouldn't have to dump the whole file to memory before loading it.  You could just load it normally.

What's more, you wouldn't have to write separate loaders for images/sounds/fonts/whatever.

See this thread:

http://www.sfml-dev.org/forum/viewtopic.php?t=5007

88

Feature requests / ResourceStream class for custom resource loading

« on: July 20, 2011, 02:30:20 am »

I'm a little surprised I didn't notice this earlier... but there's an issue with name continuity.

right now we have Seek() and GetPosition().

Logically, one would expect the inverse of GetPosition to be SetPosition.  Having Seek as the inverse is kind of counter-intuitive.

That said, I find Seek/Tell to be more intuitive for Files/Streams than Get/Set Position.  But really I don't think it matters as long as one style is consistent.

Is it too late to rename one of these?

89

Feature requests / ResourceStream class for custom resource loading

« on: July 18, 2011, 10:29:21 pm »

Fonts, mostly.  Font files can be huge, and the glyph data is scattered about.  When reading font data it will only want to get data from the glyphs it needs, so it will need to seek around the file to find them.

You could probably leave out seeking in an implementation and music playback and image loading would likely still work fine.  But it depends on the file.

90

Feature requests / ResourceStream class for custom resource loading

« on: July 18, 2011, 05:50:28 pm »

Awesome!

*thumbs up*