Messages

16

General / Re: LNK 1112 compiling SFML 2.0 to VS2012

« on: February 03, 2013, 04:49:21 pm »

That looks an awful lot like it's in the startup code that, among other things, initializes global variables before main is entered.

17

General discussions / Re: A new logo for SFML

« on: February 02, 2013, 06:42:35 am »

Just fooling around a bit.  The text that makes everything up is from the source of SFML.

18

Window / Re: What is the sense of setView(getView())?

« on: February 01, 2013, 08:05:24 pm »

couldn't this be made more efficient by just changing m_cache.viewChanged to true?

Unlikely.  Trust your optimizer.  Since setView and getView are likely to be inlined, there should be no difference in the code.

Actual generated code:

; 305  :         // Set the default view
; 306  :         setView(getView());

        mov     BYTE PTR [edi+345], 1

19

Graphics / Re: Failed to load image message contains wrong file name

« on: January 30, 2013, 04:37:14 pm »

I am trying to load an image from file to use as a sprite, this worked in debug but not the release

Are you linking against the release version of the libs?

20

General / Re: Proper input handler Class

« on: January 29, 2013, 03:11:03 pm »

So 1 Click with the mouse results in many "Pressed"-True values from my Input Class.

You can process many events per main-loop iteration.  You only store one of them in your Input class.

Your pressed function doesn't differentiate between mouse buttons and keys.  In fact, it erroneously checks the event key code when there was a mouseButtonPressed event.  The return value can be completely unrelated to whether a mouse button was pressed or not.

Besides, which:

If I click on an Entity, and drag it over (or not for the first tests), I want a copy to be made and given to another list, wich is full of "world" sprites.

Once you're in the dragging state, you should only care about the mouseMoved event to keep the dragged item in the right spot on the screen and mouseButtonReleased to know when the user is finished dragging.

I would get rid of your ill-advised Input class until you better understand how the event system works.

21

Graphics / Re: [StillNotSolved] Drawing a 2D Pixel matrix

« on: January 28, 2013, 09:43:42 pm »

loadFromFile has a return value.  Have you checked it and verified the load is actually working?

The drawn sprite is not shown correctly

Can you be a little more descriptive?  Works fine for me.

22

Graphics / Re: Drawing a 2D Pixel matrix

« on: January 27, 2013, 05:26:32 pm »

You're encountering a problem that stumped me early on too.

The crux of the problem is that OpenGL coordinates are not really pixel coordinates as one might expect.  0,0 refers to a corner of a pixel at the origin.  0.5, 0.5 refers to the center of that pixel.  In order to make sure a vertex is displayed at a pixel coordinate, you draw it at the center of the pixel.

           if (i <= Alt/2+200 && i >= Alt/2-200 && j <= Amp/2+200 && j >= Amp/2-200)
                mapaBits[i][j] = sf::Vertex(sf::Vector2f(j+.5f, i+.5f), sf::Color::Cyan);
            else
                mapaBits[i][j] = sf::Vertex(sf::Vector2f(j+.5f, i+.5f), sf::Color::White);

23

System / Re: [2.0] Using a thread to load game resources

« on: January 22, 2013, 06:10:31 am »

Updating to the latest source had no effect.

I did manage to get it  working using the following (Windows specific) code, though.

#include <Windows.h>
#include <thread>
#include <SFML/Graphics.hpp>

struct LoadTexture
{
    sf::Texture& texture ;
    bool & success ;
    std::string filename ;

    LoadTexture(sf::Texture& t, bool& s, const std::string& fname )
        : texture(t), success(s), filename(fname) {}

    void operator()()
    {  
        wglMakeCurrent(wglGetCurrentDC(), wglGetCurrentContext()) ;
        success = texture.loadFromFile(filename) ;
        wglMakeCurrent(NULL, NULL) ;
    }
};

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "sf::Thread test");

    bool success = false ;
    sf::Texture green ;

    {
        sf::Thread thread(LoadTexture(green, success, "GreenTile.png")) ;
        thread.launch() ;
    }


//    success = green.loadFromFile("GreenTile.png") ;

    if ( !success )
        return 0 ;

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

        window.clear() ;
        window.draw(sf::Sprite(green)) ;
        window.display() ;
    }
}

[edit:
And now I see sf::Context which somehow escaped me when I looked earlier.  That would provide a much better solution.]

24

System / Re: [2.0] Using a thread to load game resources

« on: January 21, 2013, 08:34:14 pm »

I didn't want to cut out anything relevant (and trust me - I've cut out a lot already).

Instead of worrying about cutting out anything "relevant" you cut it down to minimal.  If the problem isn't still exhibited, you know it was something that you left out.  Add stuff back in until you find what triggers the issue.  Now you have minimal code that still reproduces the error.

I my case the problem is with sf::RenderTexture (vide my last post's edit note). I don't see any sf::RenderTexture in your code.

Would you imagine that sf::RenderTexture uses sf::Texture internally?

25

Graphics / Re: 2D Water

« on: January 21, 2013, 08:19:42 pm »

So both SFML and OpenGL treat in the lower left corner as 0, 0?

OpenGL doesn't treat lower-left corner as (0, 0). It treats it like you tell him to treat it: it depends on many states that you set (projection matrix, texture coordinates, ... it also depends how you load your texture).
SFML generally treats the upper-left corner as (0, 0).

My OpenGL experience is limited.  I keep meaning to spend more time delving into it, but the time is hard to come by. 

It is my understanding that, yes, you can specify to OpenGL what it treats as the origin but, by default, it treats the lower left as origin.  (That can't be done with FBOs though, can it?)

Because inverting the y-coordinate and calling display() on the secondBuffer fixes the problem I got

It's probably a side-effect, what you need is most likely a glFlush() (that's what display() does). And you won't have to invert Y coordinates anymore.

I'm a little confused by this.  What is the line m_texture.m_pixelsFlipped = true; intended to do if it doesn't affect the way SFML interprets the Y coordinate?

After rooting around in the code a bit, I didn't find anywhere pixelsFlipped would be set to false, and in the above code, putting a secondBuffer->display() call above the event loop worked fine.  Perhaps this is is something that should be set in the default constructor instead of in display?

Relevant thread:
http://en.sfml-dev.org/forums/index.php?topic=1273.msg8106#msg8106

26

System / Re: [2.0] Using a thread to load game resources

« on: January 21, 2013, 06:35:05 pm »

You don't exactly get the concept of minimal code, do you?

The following exhibits similar behavior for me.

#include <SFML/Graphics.hpp>

struct LoadTexture
{
    sf::Texture& texture ;
    bool & success ;
    std::string filename ;

    LoadTexture(sf::Texture& t, bool& s, const std::string& fname)
        : texture(t), success(s), filename(fname) {}

    void operator()()
        { success = texture.loadFromFile(filename) ; }
};

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "sf::Thread test");

    bool success = false ;
    sf::Texture green ;

    {
        sf::Thread thread(LoadTexture(green, success, "GreenTile.png")) ;
        thread.launch() ;
    }
//    success = green.loadFromFile("GreenTile.png") ;

    if ( !success )
        return 0 ;

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

        window.clear() ;
        window.draw(sf::Sprite(green)) ;
        window.display() ;
    }
}

Been awhile since I've updated to the latest SFML sources.  I'll do that later today.

27

General / Re: Problem with choppy/laggy/jerky scrolling in SFML2 (binary inside)

« on: January 21, 2013, 05:12:53 pm »

It is perfectly smooth here.

28

Graphics / Re: 2D Water

« on: January 21, 2013, 12:48:04 am »

Wow thank you very much! That did the trick! I don't really understand why though. Would you mind explaining that to me? Because I don't actually touch the renderTexture secondBuffer (ie I never draw() to it) I always use firstBuffer, call display() on that one and then swap them.
You where also right about inverting the mouse y-coordinate. Why is that? I always though in texture coordinates the top left corner of a texture is (0, 0) is that wrong?

A look into the source will show that a call to display can change the way SFML interprets the coordinates in the texture, so not calling display before drawing it to something may result in the y-coordinates being inverted.

OpenGL treats the lower left corner of a screen (or texture) as the origin by default.  SFML doesn't.  So one must keep track of whether one is talking to SFML or OpenGL (for instance, with a shader.)

29

Window / Re: Best Game Loop for an Input Manager

« on: January 19, 2013, 11:42:29 pm »

What are you saying? That I should rename the function or that I should not use events?

Yes.  isKeyPressed suggests to me that it returns true if a key is currently pressed.  It doesn't suggest to me that it returns true if there was a recent key press event.  It is also a little counter-intuitive if you're using a library (like SFML) with an isKeyPressed that does not deal with events.

From what I now know off the top of my head I thought to just change while(window.pollEvent()) to if(window.pollEvent()) and that seems to fix this problem as expected, but does this make things less efficient? Every single example of a game loop I've seen always uses while(window.pollEvent()) and google doesn't have anything on this topic.

If you want to deal with events, you might keep a vector of keys pressed per loop iteration and check that vector when the function is called -- obviously it would need to be cleared at the beginning of the next iteration.  Otherwise, you might actually check to see if the key is currently pressed, which seems to be what krzat is recommending.

30

Graphics / Re: 2D Water

« on: January 19, 2013, 08:25:19 pm »

Everything works perfectly fine if I only use one rendertexture. But if I use two (or more) and swap the drawing between them the texture sometimes seems to be flipped along the x-axis (this appears randomly, sometimes there is a pattern, sometimes there's not...) Does anybody has a explanation for this and maybe a way that I can avoid it?

You need to display the textures before they're drawn.  IOW, secondBuffer->display must be called before you draw it on first->Buffer.  You also need to invert the y-coordinate when you're calculating the value for mouse in your event loop.