Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - cire

Pages: 1 2 3 [4] 5 6 ... 10
Graphics / Re: SFML2 Textures being overridden
« on: December 29, 2012, 06:22:20 am »
What exactly do you mean "alive"?

He means:  Have you verified the texture the sprite refers to is still valid when the problem occurs?  The texture must "live" as long as the sprite -- it's a mistake some new-to-SFML programmers make.

Sounds like it might possibly be another case of what's described here.

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)
« on: December 27, 2012, 03:58:59 pm »
In tgui v0.6 tgui::childWindow will be renamed to tgui::Type_ChildWindow for more clarity.

Can't you just use tgui::ObjectTypes::childWindow if you need that level of clarity?

Graphics / Re: sf::Text & sf::Rectangleshape display at diffrent positions?
« on: December 27, 2012, 10:51:05 am »
It's not a bug, it's a feature :P

Heheh.  Yes, I've found a couple other posts on the subject now.  Thank you, google.

I have to say, though, it is a bit counter-intuitive to have rect.setPosition(text.getPosition()) work the way it does!

Graphics / Re: sf::Text & sf::Rectangleshape display at diffrent positions?
« on: December 27, 2012, 10:03:23 am »
I played around with this a little and I'm not sure what the exact issue is, but there are two things that kind of stuck out at me. 

The first is that for a character size of 50, the glyph returned for a capital 'S' was 36 pixels in height.  That's a difference of 14 pixels.  Not coincidentally, that's the "top" value I got if I inspected the local bounding box for the text.  Because there are no vertices in that area at the top of the glyph, the bounding box returned by the VertexArray isn't what I would normally expect in a local bounding box, which is what sf::Text returns when asked for one.  A simple fix library-wise might be to have sf::Text::setPosition() and sf::Text::getPosition() account for the offset automatically.

Anyway, the long and short of it is that you need to apply an offset to counter the empty vertical space in the glyph.

Following is code which illustrates the issue (build as a console app to see the bounding box output:)

#include <SFML/Graphics.hpp>
#include <iostream>
#include <cmath>

void print(const sf::FloatRect & rect)
    std::cout << '{' << rect.left << ", " << rect.top << ", " << rect.width << ", " << rect.height << "}\n" ;

int main()
    sf::VideoMode vMode(800, 600) ;
    sf::RenderWindow window(vMode, "Blocks", sf::Style::Close);
    sf::Font font;
    if(!font.loadFromFile("sketchflow.ttf")){return 1;};

    sf::Vector2f center( floor(window.getSize().x / 2.0f), floor(window.getSize().y / 2.0f)) ;
    sf::Text text(sf::String("Text"),font);

    sf::FloatRect textBounds = text.getLocalBounds() ;

    // offset the text position.   text.setPosition(center) won't work correctly!
    text.setPosition(center.x-textBounds.left, center.y-textBounds.top) ;
    print(textBounds) ;

    sf::RectangleShape textRec(sf::Vector2f(textBounds.width, textBounds.height)) ;
    textRec.setPosition(center) ;

    textRec.setFillColor(sf::Color(0, 127, 63)) ;

    sf::FloatRect textRecBounds = textRec.getLocalBounds() ;

    print(textRecBounds) ;

        sf::Event event ;
            if(event.type == sf::Event::Closed)

        window.clear( sf::Color(63,0, 63) ) ;
        window.draw(textRec) ;
        window.draw(text) ;
        window.display() ;

The console output I get when i run this:
{-1, 8, 61, 25}
{0, 0, 61, 25}

General / Re: Random access iteration benchmark
« on: December 27, 2012, 12:21:16 am »
Does anyone have an explanation, why GCC needs 170 seconds to run the string tests, while VC++ manages it in 13-26 seconds?  ???

I'm not entirely sure if it's still the case, but VC++ has always used SSO, so this type of operation on a very small string is cheap.  GCC, on the other hand, has traditionally used a reference-counted copy-on-write implementation.  I would assume that's the difference you're seeing here.

If that is the case,
inline void compute(std::string& v) { v = "x"; }

being changed to:

std::string x("x");
inline void compute(std::string& v) { v = x; }

might be a better measure of iteration performance.

General / Re: Iterating through a list of pointers
« on: December 24, 2012, 06:45:54 am »
Why do you say a vector would be better? List is faster for iterating through than a vector.

I can't imagine a less true statement.  vectors are far faster for iteration than lists.  The only thing that really recommends a list is a large volume of insertions and removals at arbitrary points in the list, with relatively few full-list iterations.   It doesn't seem likely that is the case for you.

Graphics / Re: SFML and Sprites
« on: December 22, 2012, 05:15:12 pm »
Why are you calling window.display() in event processing code?

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)
« on: December 22, 2012, 04:54:40 pm »
Either is correct.  I don't know that there's a preferred form.  It would certainly vary by source, but I think appending the 's' is more common than not since it more closely resembles the actual pronunciation.

Graphics / Re: Question about Displaying Text
« on: December 21, 2012, 07:59:16 am »
The obvious optimization would be to remove the construction of the sf::Text object out of the function call.  Presumably the sf::Text object wouldn't need to be updated every frame, only drawn every frame, which would make pretty much everything in the function unnecessary on a per-frame basis.

General / Re: [Threading] findPath
« on: December 20, 2012, 10:33:22 pm »

Peruse the "Protecting Shared Data" section.

The main problem is that your mutex is defined in the Thread::Run definition instead of being used there.

General / Re: Drawing 100 items per frame cuts FPS by 400?
« on: December 18, 2012, 06:56:38 am »
In debug mode, I get around 115 fps with that code.  Compiled with optimizations I get around 1400 fps.

If I stop allocating and deallocating boatloads of dynamic memory and also stop constructing and copying a std::string, sf::String and sf::Text 100 times per frame, I get around 3500 fps.

Btw, deleting stuff you didn't allocate with new is bad mojo.

#include <sstream>
#include "SFML\Graphics.hpp"

const std::string fontName = "sketchflow.ttf" ;
sf::Font font ;

void drawText(sf::Text& text, float x, float y, sf::RenderWindow& window)
    text.setPosition(x,y) ;
    window.draw(text) ;

template <typename T>
std::string to_string(const T& value)
    std::ostringstream os ;
    os << value ;
    return os.str() ;

int main()
    sf::RenderWindow window(sf::VideoMode(800, 600), "My window");

    sf::Clock fps_clock;

    font.loadFromFile(fontName) ;
    sf::Text fpsDrawable ;
    fpsDrawable.setFont(font) ;

    std::string fps ;

        sf::Event event ;
        while ( window.pollEvent(event) )
            if ( event.type == sf::Event::Closed )
                window.close() ;

        fps = to_string(1.0f / (fps_clock.restart().asSeconds())) ;
        fpsDrawable.setString(fps) ;


        for(int i=0; i<19; i++)
            for(int j=0; j<5; j++)
                drawText(fpsDrawable,j*160,i*30, window);

    return 0;

Since the default font was removed from SFML, I added code to load a font.  You may have to modify that to run this code (or just remove it altogether if you're using an older version that still has the default font and it actually works for you!)

General / Re: Vector push_back call is an undefined reference
« on: December 12, 2012, 04:25:52 am »
That is a constructor declaration for Frame.

General / Re: Vector push_back call is an undefined reference
« on: December 12, 2012, 04:17:59 am »
Animator::addFrame is not the function referred to as undefined.

That would be the constructor for Frame.

General / Re: Vector push_back call is an undefined reference
« on: December 12, 2012, 03:17:56 am »
undefined reference to `Animator::Frame::Frame(float, sf::Rect<int> const&)

Generally that's a linker error indicating that the function's body is not defined, or that the source file it is defined in isn't included in the compilation/linking process.

Graphics / Re: patterned textures
« on: December 11, 2012, 07:46:28 am »

I don't know what "patterned" means but if you want the texture to repeat, then yes.

Pages: 1 2 3 [4] 5 6 ... 10