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

[texus]

1) getObjectNames

2) When you add an object with the same name (same type or not) then the previous object will remain unchanged. But this is a bad thing to do because the get or delete functions will only look for the first match.

3) The remove function won't do anything if the object doesn't exist.

[netrick]

Thanks. Uhm I'm stuck now with rendering tiles on panel.

Well, I think that sprite sheet isn't for me :/ Rendering 1200 32x32 tiles using sfml and texture rectangle gives me about 550-600 fps, and rendering 160 32x32 sprite sheets using the same tileset (AND disabling rendering of normal map), gives me 120-150 fps, so there is a serious performance problem. I don't know, I must find a way to do it with SFML speed on TGUI level. I can easily add tgui::PictureRect, but that will be still performance problem because it can't be used like that: set position -> draw -> set position -> draw -> drawTGUI. So I don't know, I have no idea why sprite sheets work so slow for me.

All I do in my sprite sheets drawing function is:
- I have 256 sprite sheets already loaded (every uses the same tileset) and every of them has a cell already set (sheet0 is tile 0 etc)
- Then, in my drawing function all I do is:
hide all sheets
set positions for visible sheets the same way I set positions for sfml sprites (so it's not performance problem)
call show() for visible sheets

I need hide and show at every call because it is in scrolled panel. But, after removing show and hide calls (so i always render every sheet) fps went up only to 180. So the bottleneck is in other place. Could you look into it, why sprite sheet is so slow?

[texus]

Is there a way to remove every object of one type from a panel?

Not directly, but you can use getObjects to get pointers to all objects, use object->getObjectType to find out if it has the correct type and then delete it with the remove function.

I think that sprite sheet isn't for me

Performance wasn't really important when I started, so there is indeed a lot to improve.

Ok, I have another suggestion to get this done:

window.updateTime(elapsedTime);  // You need to make this call if you don't use drawGUI
window.draw(panel);
// draw images directly with sfml
window.draw(childWindow);

The only problem with the above is that the child window should not be part of the panel and should be part of the window. But depending of the situation this isn't a problem.

[netrick]

Thanks, I will try it out.

All my childwindows belong to a window (I don't see a reason why they should belong to a panel), so it's not a problem.

EDIT:
I have an easier idea:

while (true) //main loop
{
draw panel background with pure sfml
draw tiles using sfml
call drawtgui which will handle all childwindows for me (and it will draw a transparent panel which won't hide tiles and the visible widgets on the panel like scrollbar don't interfere with tiles
}

I hope this one will work. But there is a little problem - I hope that panel background can be transparent in 0.5.

edit2:
It works! However I still don't understand something. Rendering only map (1200 tiles) - 550fps, rendering map + 160 tiles on panel using sfml - 450fps.

For sure there is something that I can improve in my render code, however fps now is fine.

[netrick]

What's the way of working with get object type? Because something doesn't work here:

        std::vector<tgui::OBJECT*> & objects = tgui.getObjects();
        for (int i = 0; i < objects.size(); i++)
        {
                if (objects[i]->getObjectType() == tgui::ChildWindow) correctChildWindow(objects[i]);
        }
 

And in the "if" line I get "error: expected primary-expression before ‘)’ token" and I have no clue what's wrong, probably I check type in wrong way.

EDIT:
Also, I think the design of this function has a flaw. Because when I get a pointer to a child window (but is OBJECT* actually), i can't use getTitlebarHeight(). Any idea on this one too? Maybe reinterpret cast? But I think that's a bad idea.

[texus]

What's the way of working with get object type? Because something doesn't work here

getObjectType returns a member of the ObjectTypes enum defined in TGUI.hpp.
This is the class name, but without the capital letter. So it should be tgui::childWindow instead of tgui::ChildWindow.
It seems like this isn't in any tutorial, I'll have to change that when I have some more time.
In tgui v0.6 tgui::childWindow will be renamed to tgui::Type_ChildWindow for more clarity.

I think the design of this function has a flaw. Because when I get a pointer to a child window (but is OBJECT* actually)

All you need is a static_cast. The reason why you get OBJECT* is because the window isn't allowed to make any difference between objects. If you are sure that it is a pointer to a child window (which you are because you check the object type first) then you can just do the following to get the pointer to it.

tgui::ChildWindow* child = static_cast<tgui::ChildWindow*>(objects[i])

[netrick]

Thanks a lot! I also looked into my c++ book and it says the ideal solution for my problem is to use dynamic cast (which was actually made for casting from base class pointer to child class pointer). However, in this case static cast is indeed enough.

[cire]

In tgui v0.6 tgui::childWindow will be renamed to tgui::Type_ChildWindow for more clarity.

Can't you just use tgui::ObjectTypes::childWindow if you need that level of clarity?

[texus]

That would be another possibility, yes.
My main concern is that childWindow looks to much like ChildWindow.
Either Type_ChildWindow or ObjectTypes::childWindow would solve that.

But I do prefer Type_ChildWindow because another reason for the change in v0.6 is that all enums will start with capital letters. Of course a possibility would still be tgui::ObjectTypes::ChildWindow, but this is getting a bit too long.

[netrick]

Anyway, what's the point of type being named differently than a class? Actually class is a type. I just don't get it, it's counter-intuitive to me. Just put all classes' names in enum and that's it. It's very clear that tgui::Label is a type.

[texus]

As far as I know you can't compare against a class.
And giving enum values the exact same name as the class isn't possible.

If you have an alternative solution then I would love to hear it. The only reason why there is an ObjectTypes enum is because I don't know any other (easy) ways.

[FRex]

Virtual method that returns magic number(enum maybe) or hashed string name of class(could choose some fast hash and just check it against all class names you have atm)? Maybe virtual and static methods that return same number so you'd do:

if(someptr->dynamicID==someclass::staticID)
{
//this someptr points at someclass
}
 

Maybe just use dynamic_cast for everything, not own type checking? That's why it's there.
Also, putting enums inside their own namespace or making them strong(since you're going c++11 anyway) so they don't collide with class names?
Sorry if you don't want input of someone who's sfg user, just say if you don't.
Edit: Oh, you already have virtual method that returns type, ops..

[texus]

Virtual method that returns magic number(enum maybe) or hashed string name of class(could choose some fast hash and just check it against all class names you have atm)?

Possible, but a simple enum that lists all types seems a lot easier to me.

putting enums inside their own namespace or making them strong so they don't collide with class names?

So instead of Type_ChildWindow it would by Type::ChildWindow. This looks nicer than using the underscore, but in the end it is as good as the same.

Sorry if you don't want input of someone who's sfg user, just say if you don't.

I appreciate any input.

EDIT:

if(someptr->dynamicID==someclass::staticID)
{
//this someptr points at someclass
}

That could be a solution.
Then you could just check against ChildWindow::Type or something like that.

[FRex]

dynamic cast was kind of created because people were rolling their own rtti(I think..), why not just use that and instead of doing

if(ptr->getObjectType==Type::ListBox)
{
//cast ptr to listbox ptr and do something
}
 

do that:

ListBox * ptr2;
if(ptr2=dynamic_cast<ListBox>(ptr))
{
//do something with ptr2, its valid for sure
}
 

[texus]

I learned something new today. I didn't knew what happened when casting to a wrong type.

I still prefer the first one, but as I don't have to do anything for the second one I can just let the user decide.
I will keep providing the Type::ObjectName so that people can check against the result of getObjectType() and those who want to use the dynamic_cast can do so.
That seems like a nice solution to me.