Messages

I know that I have to copy DLLs, I said that to indicate that the program uses corrects DLLs. And yes I run it from command prompt in both cases. I'll take a look at the Trello page, thanks

Yes, I compiled both librairies in dynamic, in both debug and release, but when I compile the program in Debug, it asks for debug DLLs, so I assume that doesn't lies to that. The segfault is not very friendly, I cannot get it again when I run my program with gdb, but when I run the program normally I get it.

By the way, how can I help you to improve TGUI? I have got some free time these times, so maybe I can fix things or do work you don't have time to, and push it on you Github. I really like TGUI, and I would be glad to contribute to it!

Hi,
When I run the following code, I get a segfault at the end of the program, I guess when the tgui::Gui instance is destroyed.

Code Select Expand


#include <TGUI/TGUI.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI window");
    tgui::Gui gui(window);
    tgui::Picture::Ptr pic = tgui::Picture::create("Black.png");
    pic->setPosition(bindWidth(pic), 0.f);
    gui.add(pic);
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
            gui.handleEvent(event);
        }
        window.clear(sf::Color::White);
        gui.draw();
        window.display();
    }
    return 0;
}


The debugger tells me that the segfault comes from the line 110 in SFML's Texture.cpp (that's the only relevant information that the call stack gives), at this line:

Code Select Expand

110        glCheck(glDeleteTextures(1, &texture));

The code above is the minimal one that can reproduces the segfault, the image doesn't matter.
It seems to be related to the bindWidth(pic), when I give an expression independant from pic as layout for setPosition(), the segfault dissapears.

Note: I have to run the project two times to get the segfault, the first time everything works fine.

I run on Windows 7, with TGUI 0.7 and last SFML sources, with Mingw GCC 4.8.

Thanks

Thank you! 

I noticed that the new view system doesn't take in account the viewport. Or if it does, I have issues to correctly set the view of TGUI.
In the exemple, I have a resizable window, and a function that set a viewport every time the window is resized. The goal is to keep a certain ratio in the view of the window. That trick works fine with native SFML stuff and TGUI 0.6, but since the last version I'm not longer able to do this.

I assume that the concerned code is between line 101 and 106 of Gui.cpp.

As I can see, all my issues has been fixed, thank you too!

Yes, that was that, after recompiling TGUI that work fine, thanks! 

Thanks for the update, I downloaded it from Github. But another issue pop up, my texts where clipped in the underline. So I downloaded the last SFML release on Github and I compiled it, like you said in another topic on this forum.
But now I have to manually set the autoSize to true on my Labels to display them, otherwise the labels have a null size, problem that I hasn't with my previous version of SFML. So I don't understand where my issue come from.
And that's not dependant from my project, the bug pop up too in the Full Example.

I don't totally understand your code, but that work pretty good! Thank for your motivation and your reactivity.
(You just wrote m_background and m_size in place of m_Background and m_Size :p)

Yes, I suspected that this line was involved in my bug, thank you for your answer!

EDIT: Your proposal change nothing, as I can see in my case, the label have exactly the same behavior.
And I seen that the amplitude of the clipping depends on the TextSize, beyond 250 in my exemple the clipping is negligible, but under this value it's very annoying. Anyway, there is a bug ^^

Okay, I linked an exemple and the font I use.
I see that this is caused by the line with the comment HERE, and when I remove the "*0.5f", the label get a good behavior...
(And I heard that my computer emit a noize when my exemple run, and the noize become more high-pitched when I decrease the size of the window... ^^')

I've a little issue when I resize my viewport. I explain: I allow the player of my game to resize the window, and my view should keep a 16:9 ratio. So I write a little fonction who resize the viewport when a window resizing event is thrown, and allow the view to be always in 16:9. The fonction return the float rect to assign to the viewport, and here is its code:

Code Select Expand


FloatRect handleResize(Event::SizeEvent size)
{
    unsigned int iw = size.width;
    unsigned int ih = size.height;
    float fh(ih), fw(iw);//If size is in a 16:9 ratio, it won't change.
    if(iw/16 < ih/9)//Taller than a 16:9 ratio
        fh = iw * (9.0/16.0);
    else if(iw/16 > ih/9)//Larger than a 16:9 ratio
        fw = ih * (16.0/9.0);
    float scalex = fw/iw;
    float scaley = fh/ih;
    return FloatRect((1-scalex)/2.0f, (1-scaley)/2.0f, scalex, scaley);
}

But that make a litlle problem, the widget are strangely resized, like you can see inn the attached file, and that clip the content, here a label. The background of the label is grey in the picture. The proportions in the picture between the two windows are preserved. How can I fix that? Should I handle the resize in another way, or disable the resizing?
(Texus: I speak french at first, and I can see you're belgian, so can I speak with you in french?)

I suspected that there was a problem, but I couldn't see where  . And that worked because I just used some labels.
I'll look at the views, if I can do what I want with it my project will be much simpler!
Thank you for your fast reply

In my project I need to draw the gui with some render states, and I seen that that's no possible in TGUI v0.6.
So I changed a bit Gui.cpp, and now I can do stuff like this in my project:

Code Select Expand


Transform transform;
transform.scale(Vector2f(scalingFactor, scalingFactor));
m_gui.draw(true, transform);

But I don't know if you purposely don't implemented this feature. Is that a good idea?
I attached the modified files.