TGUI: a c++ GUI for SFML (with Form Builder)

[netrick]

I will keep doing it myself. Btw, is there a way to re open child window after it was closed?

And on the bug:
when I disabled vsync, everything is great. However, the bug is present with vsync enabled (especially with fast moves, but with normal ones it is visible too). Do you have any idea? Could you look yourself with enabled vsync and doing fast moves? This bug is especially visible when doing quick top-down moves. When I enable vsync, the bug is so annoying. The thing is, I need vsync for my fast paced game.

EDIT:
With setFrameratLimit(60) the bug doesn't happen too! And at @60Hz Vsync there is the bug... I don't know, do you have any idea?

EDIT2:
I have an idea... I looked into TGUI source and the reason may be it uses window events. I just think that it *may* work better when using tracking window focus + using real time mouse input. I will try it, but please let you look into this vsync issue too.

[texus]

is there a way to re open child window after it was closed?

If you change the callbackID of the child window and you thus allow it to send callbacks then you are responsible for destroying the window (see tutorial). So you could choose to cancel the closure for instance.
Otherwise, if you want the window to really disappear, but you don't want the window to be recreated every time, then instead of destroying it you could just hide it.

Maybe it would be better if you make a video so that I can see the bug. I think I am able to reproduce it but it doesn't look that bad to me so perhaps its worse on your pc. To me the mouse goes of by only 1-3 pixels.

But I don't think it can be solved easily. My code is pretty simple: when mouse goes down remember the position, when mouse moved check how far the mouse moved and move the window accordingly. So there isn't much place for mistakes there. I only notice that I am using floats there, but that is not so easy to adjust and even with rounding the numbers (which I just tried) the result stays the same.
It looks more like the screen doesn't update enough to follow the mouse.

[netrick]

I'll make a video tommorow and also test the drag and move code which uses real time OS mouse input. However, the bug happens on linux with vsync in windowed and fullscreen mode. BUT, on windows, with vsync on, it only happens in fullscreen mode. I think it's a bigger problem here.... I tested in Guild Wars on windows, and the bug is also there, of course only on full screen vsync. Strange.... But I just don't know why on linux this happens also on windowed vsync.

And another thing that I don't understand is why vsync causes this bug and limiting to 60 fps using waiting at the end of frame doesn't. Clearly there is something going on with window events while vsynced, but it's different on windows and linux... I hope real time input will solve it.

edit:
From my research, it looks like that vsync indeed causes mouse lag related to double buffering in some way. And it also may be that you will only get mouse moved event 60 times a second and it isn't "you get it when you ask". but rather "vsync makes an event for you every 1/60th and you won't get exactly at the time". Of course, setting frame limit to 60 using timers, gives you "you get event when you ask for it". I think real time mouse input not based on event is a solution, but currenctly I'm fixing some bug in my drag and move code so I can't tell for sure... This is wrong, the input lag  is not based on input - the app gets input perfectly right (even just window events), but just the display() operation lags, because it waits for vsync. And the mouse moves independent of your app, so that causes the lag. It's not a bug in TGUI, it's just classic vsync input lag.

Well the solution may be to use triple buffering - which would be a question to Lauren. But, I doubt we will see it quickly...

edit2:
No, at least in my poor drag and move code real time os input didn't help... The question is why on windows the bug is only on fullscreen vsync while on linux it happens on both windowed and fullscreen vsync...

edit3:
When using both vsync and framerate limit @ 60, the bug is... not present. I don't get it, I have no idea what's going on and why on Windows in windowed vsync the bug isn't present....

[FRex]

Just a tip : Laurent said you're never supposed to use both framerate and vsync at once.

[netrick]

So, I think I know it now. Indeed, vsync makes input lag, because you give the window.display() command and it displays a bit later (and with limiting fps using internal timers, window.display() will display on screen instantly). I also know why on windows xp in windowed mode the vsync doesn't cause input lag. The thing is that on all pre-vista windows, vsync in windowed mode isn't true vsync - it's more like limiting fps using internal timers (not exactly, but the point is there is no input lag). On windows vista/7 however, in windowed vsync there is an input lag. The solution? Well, there are few:

1) Don't use vsync at all (it depends on the game really if it looks good without it)
2) Just limit framerate @60 fps using internal timers (but this still keeps tearing in some cases)
3) It's especially used by FPS gamers and it seems to work in 2D games too. Enable vsync AND enable framerate limit to 59 FPS (screen framerate - 1). This is the approach I'm going to use in my game.
4) vsync + triple buffering - impossible in sfml, reduces input lag to minimum but it is still there.

Sorry for that wall of text in my poor english, I hope you get. In case you have something to add on this topic, I would be very glad to hear it. Thanks and merry christmas mate!

@FRex
Well, it is commonly used approach especially by FPS gamers. It is the only way to avoid both tearing and input lag. The only. The vsync + triple buffering approach helps, but still leaves small input lag. And I tested it on amd, nvidia, windows and linux and I didn't see anything wrong - but I've seen no tearing and no input lag. Maybe it's in theory not fully defined behaviour, but well, it works.

[texus]

Sorry for that wall of text in my poor english, I hope you get. In case you have something to add on this topic, I would be very glad to hear it. Thanks and merry christmas mate!

I have nothing to add to that. Its just good to know that the problem wasn't in tgui and I am glad that you could solve the problem. Merry Christmas to you too.

[netrick]

Is it possible to set texture rect in tgui::Picture? And draw it multiple times before drawing the whole gui? I mean in the single loop run I do:

I have a picture object.
- picture.set rect and position
- picture.draw
- picture. set rect and position
- picture draw
- do it a few times
- call tguiWindow.draw() and have all those pictures drown (like normal sf::Sprite)?

Currently I have a panel, on panel I render using sf::Sprite but this way child window is drown under the sfml sprites and it looks ugly. I need have layer #1 panel, layer #2 images, layer #3 childwindow and the only way to do it is to have images managed by tgui but tgui::Picture doesn't inherit from sf::Sprite and probably don't have that multiple draw behaviour so I'm stuck.... How can I do it?

The only way I can think of is to render those images using sfml to a render texture and set this texture as tgui::Picture, but I'd like to avoid it because render texture in sfml has serious problems on intel cards right now and it won't be fixed soon.

EDIT:
Oh I see that the intel gpu render texture isue has been fixed. That's great. However I'd still like to hear an answer on my tgui::Picture questions, as if there is a way to do it the code would be much cleaner.

[texus]

Picture wasn't really made for advanced usage like setting a rectangle, it is just a simple wrapper around sf::Texture and sf::Sprite.

If the rectangle is a specific cell in the picture (the picture can be divided in several rows and columns and you want to draw just one cell of it) then you can use tgui::SpriteSheet.

No way is provided to split the drawing in two parts. All objects are rendered at once.
But from what I read in your description you won't need to do this. If you can use the SpriteSheet then the pictures will be drawn on the panel and the child window will be drawn on top of it.

[netrick]

Okay. It is indeed a tileset, so SpriteSheet looks good for it, however - it can have only one visible rectangle at once if I'm correct. So if my tileset has 128 tiles, I will need 128 SpriteSheets, yes?

That would be a very big memory waste :/ Tileset is big.

This is all because i need to display all tiles from tileset in a grid as GUI element. It's not for a map render but for editor, and honestly I have no idea.

edit:
I have an idea. Can multiple SpriteSheets share one texture (tgui::Picture)?

edit2:
I know! I will create custom object called "TileSheet" and I will just almost copy-paste sprite sheet code, but it will just hold a pointer to tgui::Picture, so I will just create an array and set the pointer trough a loop (I will only to do it at start up, so no performance problem). Hail open source!

But if you have an idea for easier way of doing it, feel free to tell me about it

[texus]

There is an internal texture manager in tgui. The same filename won't be loaded twice.
Just load the 128 SpriteSheets, they will all use the same texture. There shouldn't be any memory waste.

[netrick]

Oh lol. That's great, amazing job.

EDIT (as always):
I have another question. In my game I need key pressed event repeating to be set to false all the time. Of course, it must be enabled when edit box is active. So my question is as follows:
Is it possible that editbox send callbacks when it's focused and unfocused? So I can handle it and enable/disable it when needed.

Thanks in advance!

[texus]

Is it possible that editbox send callbacks when it's focused and unfocused? So I can handle it and enable/disable it when needed.

I am afraid not. This is part of the new callback system. Focused and Unfocused callbacks are only send in v0.6.

I know that its not optimal, but you will probably have to find a way by constantly call isFocused and check if the status changed.

[netrick]

Hmm does the object know when it gains/loses focus? If yes, then maybe I can easily add one function to editbox code and recompile TGUI?

[texus]

The objects have objectFocused and objectUnfocused functions.
EditBox already has objectUnfocused so you will only have to add the objectFocused function.
If you add the function to EditBox then it will automatically be called, you don't have to do anything else.

From inside these functions you could send your custom callback.

if (callbackID > 0)
{
    Callback callback;
    callback.object     = this;
    callback.callbackID = callbackID;
    callback.trigger    = 50;  // Set the trigger to something to identify the callback
    m_Parent->addCallback(callback);
}

[netrick]

Thanks. I have three questions:

1) Is there a way to get names of all objects that exist in panel/window?

2) If in panel there is added object called for example "object5", and I add another "object5" of the same type to the panel what will happen?
 - the former "object5" wil be overwritten?
- or the former "object5" will be kept without changes?

3) What happens if I delete an object which doesn't exist?