Messages

1

Graphics / Re: Convex shape doesn't always provide correct globalbounds

« on: May 08, 2012, 04:20:48 pm »

Well I can certainly do that, I thought that would be the point of globalbounds, I cannot think of a use for them if I can't count on them to be relatively accurate. Mind you I'm not looking for a "I'll get right on it" answer or anything. I'm just seeing if you see it that way, or if I'm misinterpreting the purpose of globalbounds. That said, I'm sure I can work around this issue doing as you said Laurent, I just wanted to see if this is an issue or not. Sounds like not, judging from the previous post. But please enlighten me on the use of globalbounds if not for minor collision checking.

thanks again,
Ben

2

Graphics / Re: Convex shape doesn't always provide correct globalbounds

« on: May 08, 2012, 02:51:40 pm »

Tank,
it also varies by the original orientation of the triangle and the dimensions, try it with these points for the triangle and see!

shape.setPoint( 0, sf::Vector2f( 0.0f, 100.0f ) );
shape.setPoint( 1, sf::Vector2f( 100.0f, 0.0f ) );
shape.setPoint( 2, sf::Vector2f( 200.0f, 100.0f ) );

The bounding rect is fine, and I'd expect the global to grow, just not as big as it is.

3

Graphics / Re: Convex shape doesn't always provide correct globalbounds

« on: May 08, 2012, 01:43:05 pm »

Thanks for the reply,
Tank, this does clearly illustrate that this is expected, and Laurent, I see your point, that no funny business is done, it's just the local rect transformed, however, how would you get an accurate collision from the bounding rect in this case? I thought ultimately that was the point of a bounding rect... it looks to me that the rect is scaled uniformly, why not just scale it in x or y by what it needs? Will it break something else?

4

Graphics / Convex shape doesn't always provide correct globalbounds

« on: May 07, 2012, 09:17:35 pm »

Not sure if this is a bug, or I'm doing something wrong here, but I'm stumped at the moment...
I've been working on some shape helpers and whenever I ask for globalbounds on a triangle with a 45 degree rotation, I get a larger bounding rect then I should be getting. It works fine for any 90 degree increment, but nothing in between (45 degrees is just an example).

Here is my main function, so you can reproduce the behavior.
What am I doing wrong here, or am I not understanding the getGlobalBounds() function?

thanks,

int main()
{
    sf::ConvexShape myTri(3);
    myTri.setPoint(0,sf::Vector2f(0,100));
    myTri.setPoint(1,sf::Vector2f(100,0));
    myTri.setPoint(2,sf::Vector2f(200,100));
    myTri.setFillColor(sf::Color::Black);
    myTri.setOrigin(100,50);
    myTri.rotate(45);

    sf::FloatRect bounds = myTri.getGlobalBounds();

    sf::RectangleShape myRect( sf::Vector2f(bounds.width, bounds.height) );

    myTri.move(bounds.width/2,bounds.height/2);


     sf::RenderWindow window(sf::VideoMode(1024, 768), "SFML window");

     // Limit the framerate to 60 frames per second (this step is optional)
     window.setFramerateLimit(60);

     // The main loop - ends as soon as the window is closed
     while (window.isOpen())
     {
        // Event processing
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Request for closing the window
            if (event.type == sf::Event::Closed)
                window.close();
        }

        // Clear the whole window before rendering a new frame
        window.clear(sf::Color(0,0,255));

        // Draw some graphical entities
        window.draw(myRect);
        window.draw(myTri);

        // End the current frame and display its contents on screen
        window.display();
     }

    return 0;
}
 

5

General discussions / Re: sf::Thread and know if it's running?

« on: April 17, 2012, 01:57:53 pm »

Much agreed...
Whenever dealing with passing variables around threads, I found creating setter's and getter's with the mutex lock and unlock around the variable, easiest to deal with. This way you never deal with lock and unlock individually ( yes I am aware of the Lock object as well ).

But Mars was asking about how to determine if a thread is running...

Personally, I'm a fan of only having a thread as long as you need it, and do not like  the open a thread now and keep brute forcing it 'alive'. But dealing with critical hardware myself at work, I understand the concern on running threads and wondering if they are running or not.

That said... here is what I've learned in dealing with threads:
First is the "isActive()" is a bit ambiguous. Often the better question is, "is this a deadlock, or race condition?"
Most will say best way to handle race conditions and deadlocks is to avoid them. This is definitely something to strive for but anyone working on a project with many people can tell you, you don't always have control on all of the factors involved. If you do however, make sure you think of all the ways out of your loops ( have sentinels for any condition if it's important, it's worth the extra checks ).

If it's really important to restart a hung thread, you could use a timer that is reset every loop and check that timer from another thread to see if it got past an arbitrary point, and terminate the 'stalled' thread. Again, it's better to figure out why the thread stalled, and add a sentinel for that condition, so the thread can exit on it's own.

If I was way off the mark and all you wanted to know was if the function ran through to completion and the thread object is just sitting idle, ( then like you said initially ) just set a Boolean that the function was finished. Boolean values are expected atomic in nature.

You can also call wait() but that is blocking, so if you are concerned of a deadlock that won't help.

hope that helped!
 

6

Graphics / sf::Shape Compile() is private.

« on: November 27, 2011, 07:57:18 pm »

Excellent!
I look forward to the release then.
Thanks again for the info.

7

Graphics / sf::Shape Compile() is private.

« on: November 27, 2011, 06:23:43 pm »

Fair enough...

I know SFML2 is still in development and many things will change. So one final question on the "future plans" for sf::Shape.

You just said the class will likely be changed soon, does that mean you will be likely adding more static shape functions, or is that outside the scope of what you are trying to provide in the sf::Shape class?

Or are you just referring to the simple nature of using something that is in development, and that it is simply in flux!

Again thanks for your time, I really like the API, so not really trying to give you a hard time or anything!

8

Graphics / sf::Shape Compile() is private.

« on: November 27, 2011, 05:48:48 pm »

Thanks for the fast reply Laurent. So that said, compiling at creation if possible would generally be preferred, so why not make Compile() protected, or even public for that matter! Not sure if I'm missing something about the class... Are we meant not to derive from sf::Shape?

9

Graphics / sf::Shape Compile() is private.

« on: November 27, 2011, 05:21:28 pm »

Laurent,
I was wanting to make a few shapes using the sf::Shape as the base class, but since the Compile() is private and not protected, this is not as clean as it could be. While I know I can (and already have successfully) create a function which creates the shapes I want, and I could even derive since you put in the check to compile before rendering, I assume that since you explicitly call Compile() in your static functions, there is a benefit of doing that over letting the render function handle it automatically. That said, was there a reason you made Compile() private?

Love SFML by the way, keep up the excellent work!  
thanks,
Ben (AKA The_Cleaner)