Messages

16

General / Re: How to load images in a dedicated thread?

« on: December 30, 2013, 03:47:41 pm »

Thank you for your explanations so far.

... the porting effort is very small anyway.

Why is there a porting effort? I would've assumened, that both sf::Thread as well as std::thread is platform independent.

I tried firering a thread each time i load an image, but i think that the thread creation overhead is too big (there was still a noticeable lag). My other approach was to create the thread only once and to call launch each time i want to load an image. That however didn't work. Maybe i shouldn't call launch more than once?

Anyway, i'm not creating an sf::Image, but a sf::Texture. My understanding is that not only reading the image from disk, but also copying it to the graphics memory is a heavy operation. I'm describing this because of the weird errors i got. Is it possible, that i'm not allowed to access the graphics card from two different threads?

If you have a good understanding of the C++11 threading library, you can also use the high-level operation std::async() which returns a std::future.

That sounds very interesting, i will look into that.

17

General / Re: How to load images in a dedicated thread?

« on: December 30, 2013, 02:43:51 am »

Why not use sf::Thread?

I'm displaying one image after another, with a few seconds in between; enough time to load the next image. If i do that sequentially there is a small but noticeable lag in the animation of the image. Therefore i would like to do that in another thread. Now what would be a good design for that?

18

General / How to load images in a dedicated thread?

« on: December 30, 2013, 01:35:42 am »

Hi, i'm writing an application where i want to load images throughout the hole time,
the application runs. Loading images however slows the application noticebly for a moment.
Therefore, i want to load the images in a dedicated thread. But i'm having trouble to figure
out the best approach to do that.

Just to clarify:
I'm not  having trouble with the Thread data type and C++ programming,
but i'm seeking help with my code design.

Thanks~

19

Graphics / Re: Zooming like in googlemaps

« on: June 02, 2012, 02:19:11 pm »

Well, i figured it out, the following code does the trick:

Code: [Select]

178         case sf::Event::MouseWheelMoved:
179             {
180                 view.zoom (event.mouseWheel.delta > 0 ? 0.5f : 2.f);
181                 zoom_factor = view.getSize ().y / window->getSize ().y;
182
183                 sf::Vector2f newpos (window->getSize().x, window->getSize().y);
184                 newpos /= 2.f;
185                 newpos -= sf::Vector2f (sf::Mouse::getPosition(*window).x, sf::Mouse::getPosition(*window).y);
186                 newpos *= event.mouseWheel.delta > 0 ? zoom_factor : zoom_factor / 2.f;
187                 view.move (event.mouseWheel.delta > 0 ? -newpos : newpos);
188                 break;
189             }
The trick is, the zoom i'm just about to apply is not enough, i have to scale
the vector by the overall zoom of the view.

20

Graphics / Re: Zooming like in googlemaps

« on: June 02, 2012, 01:48:12 pm »

Ok, well, i forgot to present the idea of what i'm doing, here it comes:

First, i calculate the vector between the mouse position and the center
of the screen. Then i scale that vector by the zoom to be applied. Lastly,
i move the view with that vector.

newpos *= zoom makes more sense, i guess, but it didn't work either.
Does it make a difference, if i zoom first and move then? Theoretically,
i mean? However, i tried it and i played around a little with subtle changes
in the ordering of things or the multiplication versus differentiation
without finding the desired result.

I think, the idea presentet above is right, but it seems like i'm missing
something or have to work around some quirks or so...

21

Graphics / Zooming like in googlemaps

« on: May 31, 2012, 07:32:21 pm »

I would like to be able to zoom like in googlemaps, meaning that the mouse
cursor does not only stay at the same screen coordinates while zooming, but
also on the same map coordinates.

The relevant code in the event handling section looks somewhat like this:

Code: [Select]

178         case sf::Event::MouseWheelMoved:
179             {
186                 float zoom = event.mouseWheel.delta > 0 ? 0.5f : 2.f;
187                 sf::Vector2f newpos (window->getSize().x, window->getSize().y);
188                 newpos /= 2.f;
189                 newpos -= sf::Vector2f (sf::Mouse::getPosition(*window).x, sf::Mouse::getPosition(*window).y);
190                 newpos /= zoom;
191                 view.move (-newpos);
192                 view.zoom (zoom);
194                 break;
195             }
I played around with some of the parameters, but i can't get it to zoom towards
the mouse position. Any suggestions?

22

Graphics / How to sync a position from one View to another?

« on: August 08, 2011, 08:03:36 pm »

ok, i did it. Looks very good. Thank you again.

23

Graphics / How to sync a position from one View to another?

« on: August 08, 2011, 05:05:06 pm »

ok, i did it. Looks very good. Thank you again.

24

Graphics / How to sync a position from one View to another?

« on: August 08, 2011, 04:55:09 pm »

Thanks for your reply, i will try that.

However, i was hoping to get a solution for similar problem i'm having out of this.
When a unit is selected, i draw a rectangle around it. When zooming in
or out, the line becomes very thick or thin to not even visible any more or
that only one or two sides of the rectangle are visible, which looks very ugly.
I was going to try this with another view, but ran into the very same problems.

But i think i can deal with this with your suggestion and modifie the thickness
of the line according to the zoom level.

Anyway, are there future plans, to facilitate such tasks?

25

Graphics / How to sync a position from one View to another?

« on: August 08, 2011, 04:26:03 pm »

In my game, the player may zoom the view in and out. However, it is
possible, to zoom out far enough, that the unit's are'nt visible anymore
(they become too small).

Anyway, i want to have a dot on top of each unit, that does'nt change its
size when zooming. I created another view for that purpose, it is called
'overview'. When the default view changes its position, the overview gets the
new position as well:

Code: [Select]

overview.SetCenter (view.GetCenter ());
A zoom to the view is not applied to the overview.
The dot is created on the fly:

Code: [Select]

window->Draw (sf::Shape::Circle ((*unitIterator)->Position, 5.f, sf::Color::Green));

However, the dot is only on top of the unit, when the view is not zoomed.
When zooming out, the dot is not on top of the unit anymore. I kind of get
the idea, why this is so. But i have no idea, how to get the dot being on
top of the unit no matter what the zoom is.

Any suggestions?

26

Graphics / engine design question

« on: June 18, 2011, 03:16:16 pm »

Splitting the world into many small worlds should be the right aproach.
Inside those small worlds, you would've to check all objects against each
other.

That also solves the second problem: Keep track of the currently visible
small part of the world. Only draw the objects in that one (and maybe in
adjacent ones).

27

Graphics / What happened to the Rotation of a Sprite?

« on: June 18, 2011, 02:55:18 pm »

After some time fiddeling with my animation function, it does again
what i want it to do. However, I'm not really happy with it. I know, this is
some ugly piece of code, but i give my best to document what is going on.

Code: [Select]

// this function is called every frame in my game, to determine the new
// position and rotation of the unit.
void
Unit::Animate (float TimeSpan)
{
    // Position is the current position of the unit, Course is its destination.
    // Both are vector2f's.
    if (Position == Course) return;

    // The angle between the position and the course
    float angle = atan2 (Course.y - Position.y, Course.x - Position.x) * 180.f / PI + 90.f;
    if (angle < 0) angle += 360.f;

    // The distance, the unit should move towards its destination
    float distance =  Speed * TimeSpan * 3.6;

    // Get the actual Rotation (the Rotation will be set to the Sprite, before it is drawn)
    Rotation = Sprite.GetRotation ();

    // If the unit is oriented towards its destination, move straight
    if (abs (abs (angle) - abs (Rotation)) < 0.1)
    {
        // If the unit is almost at its destination, meaning closer then
        // distance away, just put it directly to its destination
        if (pow (distance, 2) > distance_pow_2 (Course, Position))
        {
            Position = Course;
        }
        // Else, move towards its destination
        else
        {
            sf::Vector2f direction = Course - Position;
            normalize (direction);
            direction *= distance;
            Position += direction;
        }
    }
    // Else, update the Rotation and move in that direction
    else
    {
        // turn is the amount in degrees, by which the unit should turn.
        // The formula is non-trivial, and i can't explain it without making
        // a drawing. Please just believe, that this is doing the right thing.
        float turn = asin (distance / (2.f * Probs->TurningRadius)) * 180.f / PI;

        // Similar to above, if the unit is almost oriented towards its
        // destination, just set the angle.
        if (abs (abs (Rotation) - abs (angle)) < abs (turn))
        {
            Rotation = angle;
        }
        // Else, rotate the unit. First, the direction in which the unit should
        // turn must be computed, it should choose the smaller turning circle.
        // This is also non-trivial, i didn't even
        // bothered to understand the proof, why this is doing the right thing,
        // but it works.
        else
        {
            float rot = 360.f - Rotation;
            float x = sin (rot * PI / 180.f);
            float y = cos (rot * PI / 180.f);
            sf::Vector2f front (x, y);
            front += Position;

            // Sarros' Rule
            float det = front.x * Course.y + Position.x * front.y + Course.x * Position.y -
                Position.y * front.x - front.y * Course.x - Course.y * Position.x;

            // Finally, update the Rotation
            Rotation += (det > 0) ? -turn : turn;
        }

        // Now move by distance along the new Rotation
        float rot = 360.f - Rotation;

        float x = sin (rot * PI / 180.f);
        float y = cos (rot * PI / 180.f);
        sf::Vector2f front (x, y);
        normalize (front);
        front *= distance;
        Position -= front;
    }
}

Ok, so this code works, i can see the unit moving on my screen as i want it
to. However, there are several things in the code, that don't make sense to
me, they are only there, because it works that way.

I have the strong feeling, that SFML and the standard C++ trigonometry
functions have a different understanding of angles. And SFML 2.0 made it
even worse!

The first thing to notice is that C++ functions deal with angles in radians,
whereas SFML Rotations use degrees. This can be dealt with fairly easy
with all these ugly PI / 180.f resp. 180.f / PI.

But now to the things that don't make sense to me.

Up in the beginning, when i compute 'angle', i have to add 90 degrees,
to make it match with the SFML Rotation. Why?

In the turning block, before i can feed the Rotation to the C++
trigonometry functions, i have to invert the Rotation.
(float rot = 360.f - Rotation;) Why?

In the end, when updating the Position, i have to use -=, whereas when
moving straight, i use +=. Why?

I'm open to the possibility, that i'm doing something retarded here.
I that case, i hope someone will explain it to me.

28

Graphics / What happened to the Rotation of a Sprite?

« on: June 12, 2011, 10:13:06 pm »

Rotations are inverted on Y axis

yeah, i figured that. But my animator still behaves weird...

See here for a more detailed discussion about the topic.

Has this issue already been addressed in the current version?

29

General / Upgrading to SFML 2.0

« on: June 12, 2011, 07:45:53 pm »

I can't modify the resolution of the OS-specific timing functions, I can only take what they give me

You can put such details in the OS specific implementation and hide it to the API. I thought this was the general approach.
The timing functions on unix have microseconds resolution. Thus, the API providing milliseconds resolution seems to me, that's what you did.

30

Graphics / What happened to the Rotation of a Sprite?

« on: June 12, 2011, 07:34:45 pm »

After upgrading to SFML 2.0, i can't get my animating function working.

What it does is to move a Sprite to it's destination (Course) by turning first,
until the Sprite is rotated towards its destination, and then moving straight.

The turning doesn't work any more. Either it rotates, or it moves in the
wrong direction (depends on the condition, det is checked for; either > or <).

Code: [Select]

void
normalize (sf::Vector2f& v)
{
    v /= (float) sqrt (pow (v.x, 2) + pow (v.y, 2));
}

float
distance_pow_2 (const sf::Vector2f& v1, const sf::Vector2f& v2)
{
    return (float) pow (v2.x - v1.x, 2) + pow (v2.y - v1.y, 2);
}

void
Unit::Animate (float TimeSpan)
{
    if (Position == Course) return;

    float angle = atan2 (Course.y - Position.y, Course.x - Position.x) * 180.f / PI + 90.f;
    //float angle = atan2 (Position.x - Course.x, Position.y - Course.y) * 180.f / PI;
    if (angle < 0) angle += 360.f;

    //std::cout << "angle: " << angle << std::endl;

    float distance =  Speed * TimeSpan * 3.6;

    Rotation = Sprite.GetRotation ();
    //std::cout << "Rotation: " << Rotation << std::endl;

    if (abs (abs (angle) - abs (Rotation)) < 0.1) // move straight
    {
        if (pow (distance, 2) > distance_pow_2 (Course, Position))
        {
            Position = Course;
        }
        else
        {
            sf::Vector2f direction = Course - Position;
            normalize (direction);
            direction *= distance;
            Position += direction;
        }
    }
    else // turn
    {
        float turn = asin (distance / (2.f * Probs->TurningRadius)) * 180.f / PI;

        if (abs (abs (Rotation) - abs (angle)) < abs (turn))
        {
            Rotation = angle;
        }
        else
        {
            float x = sin (Rotation * PI / 180.f);
            float y = cos (Rotation * PI / 180.f);
            sf::Vector2f front (x, y);
            front += Position;

            // Sarros' Rule
            float det = front.x * Course.y + Position.x * front.y + Course.x * Position.y -
                Position.y * front.x - front.y * Course.x - Course.y * Position.x;

            Rotation += (det < 0) ? -turn : turn;
        }

        float x = sin (Rotation * PI / 180.f);
        float y = cos (Rotation * PI / 180.f);
        sf::Vector2f front (x, y);
        normalize (front);
        front *= distance;
        Position -= front;
    }
}

Position and Course are vector2f's, i hope the rest is clear.

After i got it working with SFML 1.6, i was hoping, i'll never have to fiddle with this code again.
I hate trigonometry...