Messages

1

General discussions / Re: A new name for RenderTarget::convertCoords

« on: December 16, 2012, 08:19:32 am »

Just noticed this thread. The decision may have been made, but what about targetToGlobalCoords/globalCoordsToTarget? "global" should be obvious enough for a C++ programmer.

2

General / Re: Having issues with animation speed.

« on: December 16, 2012, 07:42:43 am »

Don't worry too much about the second method; basically it is just the same thing as the first, except instead of two methods you would have one method with a big if/else inside it. The first method is the better way to do it and I probably shouldn't have mentioned the other way to make things simpler. Here is my example above rewritten this way for completeness, though:

Code: [Select]

//object

class Object : public sf::Sprite {
public:
    void Update(bool isEvent, sf::Event* e, float time) {
        if(isEvent) { // or e != NULL
            if(e->type == [whatever triggers your fade])
                isFading = true;
        }
        else
           fadeBy(fadePerSec * time);  // or however you fade
    };
private:
    bool isFading;
};

// run loop
Object obj;
sf::Event event;
while (win.isRunning()) {
    while(win.pollEvent(event)) {
        obj.Update(true, &event, 0.0f);
    }
   
    obj.Update(false, NULL, clock.restart());


As to the rest of your question, it sounds lke you are on the right track. The exact flags and how they are set would depend on the exact behavior desired; probably you would set the isFading flag to true in your handleEvent method, and once the fade is complete your class might set the flag to false to signal that it is complete.

3

General / Re: Having issues with animation speed.

« on: December 14, 2012, 08:10:59 am »

I see what you're doing now.  what you basically need to do is separate your event-handling code from your update code.  There are two ways you could do this:

The first (and probably best) way to do this is to have separate Update() and HandleEvent() functions.  The Update() function is what is called outside the event loop and would take the time and advance the game objects' states by the appropriate time.  The HandleEvent() function would be what is called within the event loop, and instead of advancing object state it sets flags (i.e. isFading) based on what the events signal.

Alternately, you could keep the single update() method and create some way to signal to it that you are advancing time instead of handling a received event.  There are a couple of ways to do this; for example, you could pass a pointer to the event object and have the pointer be NULL on non-event updates or you could have a separate isEvent parameter to the function.

In both cases, you are distinguishing the logic of advancing time versus handling an event.  That way, you aren't advancing the time more than once per frame, and all events only get handled once (if you look, you'll see that your code will handle the last event received in a frame twice: in the event loop and then immediately afterward, and even more if the next frame has no events.)

The way this works is that when in the "handling events" stage of your frame, you modify the state of your object.  For example, when the event means for you to start fading, all it would do is set an isFading flag to true.  This is all the event handling needs to do.  Then, in the Update stage, your object checks the isFading flag and if it is true fades the screen by the appropriate amount.

Here's a bit of pseudocode to explain:

Code: [Select]


//object

class Object : public sf::Sprite {
public:
    void HandleEvent(sf::Event e) {
        if(e.type == [whatever triggers your fade])
            isFading = true;
    };

    void Update(float time) {
        fadeBy(fadePerSec * time);  // or however you fade
    };
private:
    bool isFading;
};

// run loop
Object obj;
sf::Event event;
while (win.isRunning()) {
    while(win.pollEvent(event)) {
        obj.handleEvent(event);
    }
   
    obj.Update(clock.restart());  // I pass the time in my update function; you set it as an attribute of your ScreenManager, which works too.

    win.draw(obj);
}




4

General / Re: Having issues with animation speed.

« on: December 11, 2012, 06:29:46 am »

I'm still not clear on why you need the update call in your event polling loop.  You are entirely correct that the Mouse events are causing the loop call to be called multiple times.  Just do the update outside of the event loop.

My guess is that you are concerned about events slowing down the frame time?  If so, two things: one, events probably won't slow your loop all that much (especially if they aren't handled), and two, you are already using a sf::Clock to measure the amount of time elapsed from the last frame: pass that time to your update function, and have your update function calculate the change in alpha per second instead of per frame (changePerSecond * timeElapsedInSeconds).

5

General / Re: SFML 2.0 Debug libraries in Code::Blocks

« on: October 19, 2012, 04:18:22 pm »

That all still seems weird, since as I understand it make (at least, linux make) does support targets, i.e. "make install", "make debug", "make clean".  But at this point it's a problem for CMake.  Thanks for the help!

6

General / Re: SFML 2.0 Debug libraries in Code::Blocks

« on: October 19, 2012, 04:02:02 pm »

Also if you had read the official tutorial you'd have already had that information...

I read it...at some point... 

Note that if you generate a workspace for an IDE that supports multiple configurations, such as Visual Studio, [CMAKE_BUILD_TYPE] is ignored and you automatically get all the available build types in it.

Yeah, this makes it sound like CMake should just provide "Debug" as a build target in my Code::Blocks project.  Is it working for anyone else?  I'll try to play with it over the weekend.

7

General / Re: SFML 2.0 Debug libraries in Code::Blocks

« on: October 19, 2012, 02:35:49 pm »

Ah, thanks. I knew it would be something simple like that. I thought I had said I was using Code::Blocks (w/MinGW), but I guess I didn't. Thanks!

8

General / SFML 2.0 Debug libraries in Code::Blocks

« on: October 19, 2012, 04:33:40 am »

Hi, I think I'm missing something.  I recently downloaded SFML 2.0 and ran CMake and compiled the SFML libraries, but I'm confused as to how I should go about generating debug libraries.  There's no option in the "Build Target:" menu for "Debug" as there was in 1.6 (IIRC; it's been a while since I compiled 1.6).  Is there something I need to do to generate debug libraries?

9

SFML projects / Re: Tiny Bomber - a game for Ludum Dare #23

« on: April 28, 2012, 03:02:38 am »

Very fun!  I like how much skill is required to throw a tiny little bomb.  It would be good to eventually add a hint that you can throw bombs up, since that seems to be so much of the (start of) the game.

Also, are you limiting the framerate at all?  The game was pegging one of my laptop's processor cores something awful.

10

General / Re: Clock and openGL

« on: April 28, 2012, 02:27:35 am »

Building on what Cornstalks recommended, are you still resetting the Clock at the end of the game loop?  If so, then your elapsed time will not include the time it took to update all of your sprites (and possibly the draw time, depending on your exact code).  You might make sure that you reset the clock the next instruction after the call to GetElapsedTime.  If you don't do that, then your sprites will move more slowly than they need to, and it will only get worse as you add more sprites.