Recent posts

#91

Help requests / Re: bindParentSize ?

Last post by texus - 07 October 2023, 18:49:57

The bind functions require you to know the widget, but you can do it when the layout is a string because that gets parsed again after the widget is added to a parent.

So something like this should work:

Code (cpp) Select Expand

ptr->setSize("min(parent.width, parent.height)*0.16", "min(parent.width, parent.height)*0.16");

#92

Help requests / bindParentSize ?

Last post by Nafffen - 07 October 2023, 18:43:04

I there a way to define a size binding to a parent size without actually knowing it ?
I would like to do something like this :

Code Select Expand

    auto min = tgui::bindMin(tgui::bindParentWidth(ptr), tgui::bindParentHeight(ptr));
    ptr->setSize(min*0.16, min*0.16);
    //...somewhere else in the code...
    gui.add(ptr)


#93

Help requests / Re: Strange crash since new bu...

Last post by texus - 04 October 2023, 22:08:38

This looks like a bug in TGUI. I'm assuming either launchAllLoading or launchSceneBase causes the focused widget to change. Your callback function gets called at the "m_focusedWidget->keyPressed" line, and probably does something that sets m_focusedWidget to a nullptr. After that, the "m_focusedWidget->canHandleKeyPress" line gets executed, but by that time m_focusedWidget is a nullptr.

So I need to add another check inbetween the keyPressed and canHandleKeyPress line to deal with this case.
Update: The issue has been fixed in the latest version.

#94

Help requests / Strange crash since new build

Last post by Nafffen - 04 October 2023, 19:44:11

I face a crash bug since I went from build baf9c5e73935453e357a9e8bda8df86bb83ed3e0 to last build (789aca88603268af99a416af6c0f11be1d03a7b8)
I cant manage to see where the bug is, this is the callstack :

Code Select Expand

libtgui-d.so.1.0.0!tgui::Container::processKeyPressEvent(tgui::Container * const this, tgui::Event::KeyEvent event) (/home/user/Desktop/dev/fc/external_deps/TGUI/src/Container.cpp:1252)
libtgui-d.so.1.0.0!tgui::BackendGui::handleEvent(tgui::BackendGui * const this, tgui::Event event) (/home/user/Desktop/dev/fc/external_deps/TGUI/src/Backend/Window/BackendGui.cpp:181)
libtgui-d.so.1.0.0!tgui::BackendGuiSFML::handleEvent(tgui::BackendGuiSFML * const this, sf::Event sfmlEvent) (/home/user/Desktop/dev/fc/external_deps/TGUI/src/Backend/Window/SFML/BackendGuiSFML.cpp:219)
GuiManager::event(GuiManager * const this, const sf::Event & event) (/home/user/Desktop/dev/fc/fc_game/src/Graphics/GuiManager.cpp:88)
SceneLogin::loop(SceneLogin * const this) (/home/user/Desktop/dev/fc/fc_game/src/Scenes/SceneLogin.cpp:169)
Application::run(Application * const this) (/home/user/Desktop/dev/fc/fc_game/src/Core/Application.cpp:259)
main() (/home/user/Desktop/dev/fc/fc_game/src/Core/Application.cpp:56)

And vsc debugger told me there is a segmentation fault in the line :

Code Select Expand

            const bool bHandled = m_focusedWidget->canHandleKeyPress(event); // TGUI_NEXT: Have keyPressed return a bool


Code Select Expand

m_focusedWidget seems to be nullptr (I dont understand that because there is a checking if just before)

The idea of my code was to lunch a callback when user presses enter when focusing an editbox.
In the Constructor of my object :

Code Select Expand

    m_editBoxEmailSignIn->onReturnKeyPress(&SceneLogin::trySignIn, this);
    m_editBoxEmailSignIn->setFocused(true);


Code Select Expand

void SceneLogin::trySignIn(){
    //TODO: remove backdoor
    if(m_editBoxEmailSignIn->getText() == "dev"){
        this->m_continueLoop = false;
        this->m_appli.launchAllLoading();
        this->m_appli.launchSceneBase({0, 0});

        return;
    }

    //bla bla bla

The strange thing is the crash only appears when the above condition

Code Select Expand

if(m_editBoxEmailSignIn->getText() == "dev"){ is true, if user doesnt input "dev", then the program doesnt crash.

I am not even sure if this is about my code or something, could you give me your thoughts ?

#95

Help requests / Re: Texture upside down with A...

Last post by Nafffen - 03 October 2023, 21:34:17

The upside down issue is no longer here !
+ Better performance

#96

Help requests / Re: Texture upside down with A...

Last post by Nafffen - 03 October 2023, 19:26:26

Thank you very much !

#97

Help requests / Re: Texture upside down with A...

Last post by texus - 03 October 2023, 19:14:05

I've updated the CanvasSFML class to no longer copy the sf::Texture. This should provide better performance. With some luck it might even affect the upside-down issue.

In the SFML code, I can see a bug in the OpenGL ES implementation when copying the texture (or at least something that looks like a bug on first sight). In GLES, Texture::update is implemented by calling copyToImage() (which is very slow), and in Texture::copyToImage() the m_pixelsFlipped variable isn't accessed if SFML_OPENGL_ES is defined while it is being used when GLES isn't used (i.e. on desktop). So it looks to me like the GLES implementation doesn't properly flip the pixels.

This however doesn't explain the github issue, which has a flipped texture even without any copies. So maybe the issue is still somewhere else. I might look further into the SFML issue later, but that will require some testing with Android so it might take some time.

EDIT: The github issue does contain a copy of sf::Texture, so that is where the issue lies. I tried rendering an sf::RenderTexture on Android without copying the texture and that image indeed isn't flipped.

#98

Help requests / Re: Texture upside down with A...

Last post by Nafffen - 03 October 2023, 19:03:33

Yep you are right it's indeed flipped, my bad I should have looked into SFML's github issue (I just looked through forum)
I though SFML was ok because I had several other sf::RenderTexture not upside down.
I don't know where exactly SFML is broken but having a sf::Sprite directly using a sf::RenderTexture seems to be working
Thank you anyway, I'll wait the bug fix
About the performance issue, is there anything I can do to manage it ?

#99

Help requests / Re: Texture upside down with A...

Last post by texus - 03 October 2023, 18:30:32

Are you certain that it works with just SFML? Can you try the code from https://github.com/SFML/SFML/issues/2419 ?

#100

Help requests / Re: Texture upside down with A...

Last post by texus - 03 October 2023, 14:00:25

Resizing the canvas will call "renderTexture.create(newSize)", while "clear", "draw" and "display" are just forwarded to the renderTexture.

The only thing that could be different with using SFML directly is that in order to render the canvas contents to the screen I just access "renderTexture.getTexture()" and render that texture. So maybe that texture is still flipped on Android (i.e. when using OpenGL ES instead of when using desktop OpenGL). I'll try to check that later.

Performance-wise, the slowdown is probably me copying the sf::Texture (that I get with the "renderTexture.getTexture()" call), in the display() function, to a different location so that it works together with the other rendering code.