Main Menu

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.

Show posts Menu

Messages - texus

I just tried replacing my project file with yours and correcting the paths to TGUI and SFML and it still worked fine here. (I only had to remove some extra libs you were linking to in release mode, but those can't be the issue because they weren't linked to in debug mode)

Those are the binaries I generated, does this run on your system?

Try copying all dlls from those binaries next to what you are generating and see if that changes anything.

The only difference between your system and mine that I can think of is the Visual Studio version. I'm using VS2022 with the v140 compiler, while I assume you are still using Visual Studio 2015 directly. While it shouldn't make a difference, it is possible that this is part of the problem. Is there a reason why you still need to use VS2015?
Can you share your Visual Studio project that is giving you this error?
Are you linking dynamically to freetype? Do you also get this error when the freetype dll is present next to the exe?

I have build TGUI with the same libraries, can you check if you also get the problem when replacing your TGUI files with the ones from ?
Help requests / Re: Global font
23 June 2022, 23:06:52
Did you change the font in the renderer of the button? If you change the font in the theme or via getSharedRenderer() then it is applied on any button, even those from other states.

If a font is set in the renderer, then the widget will use that one.
If the renderer has no font, then it selects the font from the parent widget (if it has one).
If neither font exist, then the default font is used.

Setting the font of the renderer overwrites the font on all widgets connected to that renderer immediately.
Calling Gui::setFont or setting the renderer font of a container will cause all child widgets to inherit the font and change to the new font unless their renderer specified a different font.
Calling Font::setDefaultFont font only affects new widgets, not existing ones.

(I really need to do something about this forum, since I updated the forum software I've had a lot of issues with notifications. I didn't get any notice about this topic. You might find quicker help on Discord)
The ugly text rendering will need to be investigated further. It looks like bad anti-aliasing.
Edit: maybe the framebuffer needs a multisample attachment, such as described in the "Off-screen MSAA" section on

Try disabling GL_CULL_FACE before rendering TGUI, having that enabled also seems to remove the text. I see your code enabling it right after the shadow manager, so maybe that is the problem instead of the shadow manager itself (which I haven't tested here yet).
The error seems to be the GL_DEPTH_TEST capability.

I don't really get why it works without the framebuffer and not with one, but the reason it only renders the button background and not the text is because they both have the same depth and OpenGL only draws the first one. This is why rendering a Label still works, it has nothing behind it.

I will fix this in TGUI later, for now just call the gui.draw() function like this:
Code (cpp) Select

Edit: The latest TGUI 0.10-dev release now handles GL_DEPTH_TEST and you no longer have to disable it yourself with that version.
Thanks. I have the code working and can reproduce the problem now.
I will try to find the issue tomorrow.
QuoteThis project uses my own engine. If you have time and will to build it, I can send you a github page.
If you send me a link to the github page then I will build it (or copy the relevant code). I need to know exactly what the Framebuffer class is doing in order to debug this, so I would need to see the source code.
QuoteTGUI doesn't like framebuffers?
It's possible. I don't have much experience with OpenGL, so it hasn't really been tested what exactly you need to do to mix TGUI's rendering with your own.

It would be helpful for me if you could create a sample project that uses framebuffers and TGUI, then I can investigate further what has to be changed to make it work.

The only difference that I can think of between rendering images and rendering text, is that the texture used for the text is created on the fly while the ones used for images are created upfront. So maybe something is going wrong with texture creation within the gui.draw call.
Can you create a small example project (just a single cpp file) that shows the issue?
Then I'll check if I can reproduce it here and see if I can find why no text is rendered.
Are you using OpenGL in your own code? I think this is a conflict between sfml-graphics and your OpenGL code (maybe you are trying to use OpenGL >= 3 while sfml-graphics uses OpenGL 2.1).

When using the SFML_GRAPHICS backend, TGUI doesn't use OpenGL directly and forwards all drawing calls to sfml-graphics, so it is not possible to get such an OpenGL error unless you are calling OpenGL in your own code (or if there is an incompatibility with the libraries that are linked).

I would suspect that you get the same error if you replace gui.draw() with rendering an sf::Text or sf::Sprite.
Are you using sfml-graphics in your project? You should use the SFML_GRAPHICS backend instead of SFML_OPENGL3 in this case.
The SFML_OPENGL3 backend was created in case you just wanted sfml-window with OpenGL but without sfml-graphics.
Help requests / Re: Animations
15 May 2022, 10:01:01
You can use "button->setEnabled(false)" to disable the button which makes the button unclickable, but that might also change the look of the button depending on the theme, which might be undesirable.
One other thing you could do is temporarily disable the signal callback with "button->onPress.setEnabled(false)".

Does each state have its own Gui object, or is there only a single Gui object that is shared between all states? (it is recommended to only have a single Gui per window)
Every Gui object contains a std::chrono::steady_clock which starts counting on the first call to draw(). Any calls you make to draw() afterwards will check the elapsed time since the last draw call and update animations with this amount of time.

So it sounds like when you go back to the previous stack, the elapsed time passed to the widgets is the entire time you spend within the last state, and hence the animations finish immediately. But that would only be the case if there was a Gui per state.

There might be multiple solutions to this (e.g. manually control the time of TGUI instead of letting the Gui handle it), but I would first need to better understand how things happen exactly before I can make suggestions on how to fix this.
Help requests / Re: Animations
14 May 2022, 22:53:04
I seem to have missed this topic somehow. Do you still have those questions?