Messages

16

Feature requests / Re: Why not set sf::Window style at runtime?

« on: September 05, 2014, 07:41:07 pm »

@CypherStone: Some OpenGL objects survive, but for example Framebuffer objects get destroyed. Additional, I recently introduced a bug by assuming that Query objects would stay valid after recreating the window.

@Tank: Thanks.

17

Feature requests / Why not set sf::Window style at runtime?

« on: September 02, 2014, 10:28:04 pm »

When I create a new window, I can specify whether I'd like a title bar, is resizable, and so on. But I'd like to change that at runtime. This way, I could toggle between windowed mode and fullscreen mode just by removing the window frame and maximizing it. That would allow me to continue using all my OpenGL objects which would get destroyed when recreating the window. Doing this at runtime is possible on Windows and Linux. I don't know about Mac yet.

18

General / Re: Does sf::Context need to be in scope?

« on: March 16, 2014, 11:26:56 am »

That's right. I called glFinish() from the worker thread after glBufferData() calls to wait for the buffers to be uploaded completely. After that I swap the buffer ids of the model instance that the main thread reads. So it should use the old buffer until then. Here is a short code example to illustrate.

struct Model {
    GLuint positions, normals, texcoords;
};

// worker thread
void Load(Model &model)
{
    Model loaded;
    // generate buffers and fill them from disk
    // ...

    // wait for buffer upload to finish
    // main thread shouldn't be affected
    glFinish();

    // swap buffers
    Model old = model;
    model = loaded;

    // delete old buffers
    glDeleteBuffers(1, old.positions);
    glDeleteBuffers(1, old.normals);
    glDeleteBuffers(1, old.texcoords);
}
 

19

General / Re: Does sf::Context need to be in scope?

« on: March 15, 2014, 02:56:00 pm »

Thanks for your advice. Please read my second post. I already tried using glFlush() or even glFinish() but that didn't help either. Is has something to do with how SFML creates the second OpenGL context, I think.

20

General / Re: Does sf::Context need to be in scope?

« on: March 14, 2014, 02:12:37 am »

This is another issue, I still have. The uninitialized buffers gets drawn for one frame, before the data is fully uploaded. I already tried using glFlush() and even glFinish() without any effect.

However, when I move sf::Context context; out of the function and place it as first command in the worker thread, the behavior is more random. As I said the buffers were sometimes correct, sometimes empty and sometimes completely distorted. And that not for just one frame but until I updated them again, which resulted in one of the three cases again.

Do you have any idea how I could debug this issue?

21

General / Does sf::Context need to be in scope?

« on: March 13, 2014, 09:30:57 am »

I recently implemented a worker thread in my application to upload large vertex buffers to the GPU asynchronously. Therefore, I first tried to just call sf::Context context; as first command in the thread, before entering a loop that calls functions where OpenGL calls are used inside.

void Worker()
{
    sf::Context context;
    while (running) {
        Buffer(); // uses OpenGL calls
    }
}

But I got undefined results. The uploaded meshes were drawn distorted, completely empty, or correct sometimes. So I moved the context creation inside the Buffer() function and that solved my issue.

However, it might be slow to create a new context every time the function gets called, where I only need one. Do I have the pass context object as function parameter to be visible in scope of the function body? Why can't I used it as I first intended?

22

Feature requests / Re: How to find out if window has focus?

« on: August 07, 2013, 02:20:08 pm »

Is this going to be integrated in SFML? I think novemberdobby has cross plattform code for this.

23

Feature requests / Re: How to find out if window has focus?

« on: May 11, 2013, 05:41:07 pm »

I just tested it on Linux, and I get a GainedFocus event at the very start of the program - do you not on Windows?

I'd assume if the window were to open without getting focus, a GainedFocus event will not be created.

I double checked that. On my Windows 8 machine, there is never a gained event at startup.

It yields always the lost event if the window doesn't have the focus. So when you create it, you should be able to assume that it starts with the focus on the window and when it's lost, you'll get the lost event.
But maybe I didn't understand you clearly enough. In which situation do you don't have the focus, but also haven't received a lost event?

It's when the window is created in background. The operating system decides whether that happens. Of course there is no lost event since the window never had focus before.

I had similar problems, so I added a function for testing focus directly.

Thanks a lot. Sadly that's not cross platform. I'll use that code, but my feature request to implement that for all platforms in SFML remains.

24

Feature requests / Re: How to find out if window has focus?

« on: April 28, 2013, 06:30:18 pm »

Just run any task from within a window in background, it's window will be in background, too. There's nothing special about Visual Studio. It won't make sense to provide a minimal example. If you need one, just use the minimal code to open a window in SFML and run the code from within a task with it's window not focused. I copied the following line from the window tutorial.

sf::Window App(sf::VideoMode(800, 600, 32), "SFML Window");

It's just that a SFML window, like any other window, isn't guaranteed to be opened with focus. Currently in SFML there is no way to keep track of the focus state from the beginning. Only after the focus state changed the first time, the programmer can keep track.

Therefore a bool sf::Window::IsFocused() function would be very useful.

25

Feature requests / How to find out if window has focus?

« on: April 28, 2013, 06:09:22 pm »

I use the debugging tools of Visual Studio. Therefore my application is run from within the Visual Studio task. Whenever the window of Visual Studio is in background thus hasn't the focus, the window of my application has no focus neither. I guess this is typical behavior of Windows.

Therefore the window of my application sometimes opens with focus and otherwise without. Normally I would track focus changes by sf::Events but since it's created in that state, there is no focus change at all. So I have no chance to check if the window has or hasn't focus, have I?

There should be a function in SFML for fetching the focus state of a window at any time!

26

Feature requests / Re: Basic arithmetic expressions for vector types

« on: March 23, 2013, 11:55:26 pm »

The problem is: To implement the requested operators, one needs to provide implicit conversions between vectors of different types.

What about returning the given vector type then?

sf::Vector2i operator/ (const sf::Vector2i dividend, float divisor)
{
    return sf::Vector2i((int)(dividend.x / divisor), (int)(dividend.y / divisor));
}

27

Feature requests / Re: Basic arithmetic expressions for vector types

« on: March 23, 2013, 08:41:17 pm »

In my personal opinion the first line is much less intentional then the second line. With all these explicit casts the code looses expressiveness and clarity.

Vector2i result = static_cast<Vector2i>(static_cast<Vector2f>(windowsize) * factor);

Vector2i result = windowsize * factor;

If you want to store the result in the vector itself, it becomes even worse because you can't use the *= operator.

windowsize = static_cast<Vector2i>(static_cast<Vector2f>(windowsize) * factor);

windowsize *= factor;

But that's just my sense of neat coding. You have reasons for these operators to not exist, and that's understandable.

28

Feature requests / Re: Basic arithmetic expressions for vector types

« on: March 23, 2013, 07:30:57 pm »

There are many cases where you need to multiply integer vectors with floats.

Let's say there are framebuffers and for each of them there is a float representing their scale. 1.0 would mean window size, 4.0 would mean four times supersampling and 0.5 would mean sampling at half resolution. To set the right render area, we must multiply the integer vector from window.getSize() by the relative framebuffer size which is a float.

29

Feature requests / Re: Basic arithmetic expressions for vector types

« on: March 23, 2013, 04:03:23 pm »

Let Vector2i / float = Vector2f like int / float = float in standard C and C++.

You could store the result in an Vector2i again anyway, for something like this Vector2i /= float, since the copy constructor from Vector2i to Vector2f and vice versa already exists in SFML.

30

Feature requests / Basic arithmetic expressions for vector types

« on: March 23, 2013, 12:06:49 pm »

Please implement some operators for SFML's vector types. For example I want to divide a "Vector2i" by a float. I often run into these problems and have to write small helper functions every time. Implementing these operators isn't much effort and would be much more intentional.

The only misunderstanding for my part I can think of is that we aren't supposed to use SFML's vector types ourselves. You you please specify they are only for the interface to SFML or for general usage?

Do you plan to implement these operators?