Messages

106

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 07, 2012, 10:13:07 pm »

Doubly confirmed.

107

Graphics / Re: Sprite not showing when Shape are being drawn, SFML 2.0

« on: November 07, 2012, 12:05:27 am »

Appears to be the same issue as http://en.sfml-dev.org/forums/index.php?topic=9561.0

108

SFML projects / Re: SFML-Sidescroller: Version 0.07 released!

« on: November 06, 2012, 03:01:05 am »

I've noticed if you edit the config.lua to modify backgroundStarsCount to anything other than -1, periodic crashes ensue (of the sort that require killing the program via the task manager.)  This was true of the last version as well, I just never got around to reporting it.

109

General / Re: Turn basesd games and sf::Keyboard

« on: November 04, 2012, 06:27:50 pm »

In this code, our functions are only called the moment when the keys are just pressed, so in order to activate them again, one must release the key then press it again.

That's not quite true.  By default KeyPressed events are continuously generated for keys which are held down, so processing when (event.type == sf::Event::KeyReleased) is probably closer to what the OP wants.

110

General / Re: Turn basesd games and sf::Keyboard

« on: November 03, 2012, 10:36:22 am »

In turn-based games, game flow is partitioned into well-defined and visible parts, called turns. A player of a turn-based game is allowed a period of analysis (sometimes bounded, sometimes unbounded) before committing to a game action, ensuring a separation between the game flow and the thinking process, which in turn presumably leads to better choices. Once every player has taken his or her turn, that round of play is over, and any special shared processing is done. This is followed by the next round of play. In games where the game flow unit is time, turns may represent such things as years, months, weeks or days.

From:
http://en.wikipedia.org/wiki/Turns,_rounds_and_time-keeping_systems_in_games

111

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 02, 2012, 05:28:55 pm »

Mm..  when I made the change to test, I didn't notice he specified only changing the first draw order and not the second.  If I only change the first draw order and comment out the thickness change, I do, indeed, also get the goofed up rendering.

112

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 02, 2012, 04:23:53 am »

The error was occuring in the second draw.  If you parse the images from left to right, the order matches that shown in the code.  Thus the "// not rendered correctly" comment in the code.

Although, I didn't try the reverse order without setting the thickness.

[edit:  Nope.  Everything renders correctly no matter which order is used if the thickness isn't set for me. ]

113

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 01, 2012, 11:43:08 pm »

Sure.

#include <SFML/Graphics.hpp>

const sf::Vector2f box_size(100.0f, 30.0f) ;
const sf::Vector2f box_pos(10.0f, 100.0f) ;
const sf::Vector2f text_pos(10.0f, 10.0f) ;

sf::Text text ;

void waitForEnter( sf::RenderWindow& w)
{
    bool waiting = true ;
    while ( waiting )
    {
        sf::Event event ;
        if ( w.pollEvent(event) && event.type == sf::Event::KeyPressed )
            if ( event.key.code == sf::Keyboard::Return )
                waiting = false ;
    }
}

int main()
{
   sf::RenderWindow window(sf::VideoMode(150, 150), "Test");
   sf::RectangleShape box(box_size) ;
   box.setPosition(box_pos) ;

   box.setOutlineThickness(2.0f) ;  /* REQUIRED FOR RENDERING FAILURE */

   sf::Font font ;
   font.loadFromFile("sketchflow.ttf") ;
   text.setString("abcdefgh") ;
   text.setFont(font) ;

   // rendered correctly.
   window.clear() ;
   window.draw(box) ;
   window.draw(text) ;
   window.display() ;

   waitForEnter(window) ;

   // not rendered correctly.
   window.clear() ;
   window.draw(box) ;
   window.draw(text) ;
   window.display() ;

   waitForEnter(window) ;
}

If I run this as-is I see:


If I substitue a sprite for the sf::Text object, I see:


If I never set the outline thickness, everything would render correctly.

114

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 01, 2012, 10:22:35 pm »

Sprites do not render correctly after an untextured shape. (I get the shape of the sprite with the general color of the texture, unless the rectangle is not rendered due to alpha settings, in which case the sprite renders normally.)

Using a default constructed texture for the rectangle, there is no change rendering text from not using a texture at all.  For the sprite, nothing is rendered at all, even in the cases where the rectangle is not rendered due to alpha settings.

Just creating a texture (or textures) has no effect at all, as one would expect.

When drawing all 3, as long as the sprite is rendered after the text, it is always rendered correctly, and the same is true of the text, if the sprite is rendered prior to it.  The only thing that seems to be affected is what's rendered directly after an untextured (or default-textured) shape.

115

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 01, 2012, 09:53:21 pm »

Actually, if you load a texture for rect, the text does display correctly.  I typo'd the texture's file name and didn't notice it.

116

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 01, 2012, 09:44:33 pm »

The only thing that affects the color of the quads is the text color.

117

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 01, 2012, 08:28:55 pm »

I'm using a Radion HD 5750 (and version 12.10 of the drivers,) and I experience the same problem using the latest source.  Well, not quite the latest -- I haven't updated for the static library fix.  While playing around with the code Kylotan provided to show the issue, I found that changing either of the background or outline alpha settings to 0 (or setting the outline thickness to 0) caused the text to display properly.  I also noticed that drawing the rectangle elsewhere on the screen still seems to screw up the display of the text.

When I put together some code to test multiple scenarios in one run, that behavior disappeared, so I suspect it had something do with the initial state of the graphics subsystem.

This was the code for reference:

#include <SFML/Graphics.hpp>

struct Scenario {
    sf::Color background ;

    sf::Color box_fill ;
    sf::Color box_outline ;
    sf::Vector2f box_position ;
    sf::Vector2f box_size ;
    float box_outline_thickness ;

    sf::Text text ;
};

void doScenario(sf::RenderWindow& window, const Scenario& s) ;

int main()
{
    sf::RenderWindow window(sf::VideoMode(150, 150), "Test");

    sf::Font font ;
    font.loadFromFile("sketchflow.ttf") ;
   
    sf::Text text("abcdefgh", font) ;
    text.setPosition(sf::Vector2f(10.0f,10.0f)) ;
    text.setCharacterSize(20) ;

    const sf::Color bg(10, 30, 10) ;
    const sf::Vector2f offTextPos(10.0f, 100.0f) ;
    const sf::Vector2f throughTextPos(10.0f, 25.0f) ;
    const sf::Vector2f onTextPos ( 10.0f, 10.0f ) ;

    const sf::Color fill_alphaOff(128, 128, 128, 0) ;
    const sf::Color fill_alphaOn(128, 128, 128, 255) ;
    const sf::Color fill_alphaMid(128, 128, 128, 128) ;

    const sf::Color outline_alphaOff(255, 255, 255, 0 ) ;
    const sf::Color outline_alphaOn(255, 255, 255, 255) ;
    const sf::Color outline_alphaMid(255, 255, 255, 128) ;

    const float thicknessOn = 2.0f ;
    const float thicknessOff = 0.0f ;
   
    const sf::Vector2f rectSize(100, 30) ;

    Scenario scenarios[] =
    {
        // bg color, box_fill, box_outline, box_position, box_size, box_outline_thickness
        { bg, fill_alphaOn, outline_alphaOn, onTextPos, rectSize, thicknessOn, text },
        { bg, fill_alphaOn, outline_alphaOn, throughTextPos, rectSize, thicknessOn, text },
        { bg, fill_alphaOn, outline_alphaOn, offTextPos, rectSize, thicknessOn, text },

        { bg, fill_alphaOn, outline_alphaOn, offTextPos, rectSize, thicknessOff, text },
        { bg, fill_alphaOff, outline_alphaOn, offTextPos, rectSize, thicknessOn, text },
        { bg, fill_alphaOn, outline_alphaOff, offTextPos, rectSize, thicknessOn, text },

        // text shows correctly only for these two cases:
        { bg, fill_alphaOff, outline_alphaOn, offTextPos, rectSize, thicknessOff, text },
        { bg, fill_alphaOff, outline_alphaOff, offTextPos, rectSize, thicknessOn, text }
    };

    for ( unsigned i=0 ; i<sizeof(scenarios)/sizeof(scenarios[0]); ++i )
        doScenario(window, scenarios[i]) ;
}

bool processEvents( sf::RenderWindow & window )
{
    bool continueProcessing = true ;
    sf::Event event ;
    while ( window.pollEvent(event) )
    {
        switch (event.type)
        {
        case sf::Event::Closed:
            continueProcessing = false ;
            window.close() ;
            break ;

        case sf::Event::KeyReleased:
            continueProcessing = false ;
            break ;
        }
    }
    return continueProcessing ;
}

void doScenario( sf::RenderWindow& window, const Scenario& s )
{
    sf::RectangleShape rect ;

    rect.setPosition(s.box_position) ;
    rect.setSize(s.box_size) ;
    rect.setFillColor(s.box_fill) ;
    rect.setOutlineColor(s.box_outline) ;
    rect.setOutlineThickness(s.box_outline_thickness) ;

    const sf::Text & t = s.text ;

    while ( window.isOpen() && processEvents(window) )
    {
        window.clear(s.background);
        window.draw(rect) ;
        window.draw(t) ;
        window.display() ;
    }
}
 

Result:

118

General / Re: Handling lowercase tilde? (`) accent key?

« on: November 01, 2012, 04:09:10 am »

In the same way that the Add key is not called the "Equal" key, the Tilde key is not called the "Accent" key.  You only need one way to refer to a key.

119

General / Re: Deciding which Container to use for a Manager Class.

« on: October 31, 2012, 03:12:39 pm »

Because you shouldn't compare deletion of pointer elements to deletion of data elements

It doesn't matter whether they're pointers or not.  The only thing that matters is whether relative order must be preserved (provided objects are copyable/moveable, of course.)

but you have to compare deletion of pointer elements in a vector to deletion of pointer elements in another container.

If I'm speaking about the performance of a vector in a circumstance compared to the performance of a vector in another circumstance, I don't see that the performance of another container is germane.

Neither of which are the case for the given problem, so if you actually want to point out things independently from the actual topic

Wasn't.  The specific remarks I made were tailored specifically to the OP's code in the first post and the following posts (all of which mentioned pointers in some way.) So, in fact, I was pointing out something dependent on the actual topic and posts therein.

I'm just a little bit confused why when I say "If A, then B" you have to come back and say "But A is not a given." If.

At any rate, I don't feel like discussing this further is likely to be productive, so there will be no further discussion from me on this subject.

120

General / Re: Deciding which Container to use for a Manager Class.

« on: October 31, 2012, 10:04:25 am »

I can't full agree.

Sure you can.  You noted a possibility that the relative order of elements in the vector may be important...  so did I.

and the relative order of elements in the vector isn't important

The OP was making a blanket statement that deletion from vectors was always expensive, which isn't true.  Considering he was using a vector of pointers, it seemed worth pointing out.