Messages

The debugger should show you that it crashes because gui_ProgressBarHP is a nullptr.

The gui doesn't know about the existence of the progress bar. It only has the panel as child widget while the panel in turn has the progress bar as child. So you would have to get the progress bar from the panel:

Code (cpp) Select Expand

gui_panelInfo->get<tgui::ProgressBar>("info_health");

Alternatively you can pass "true" as second parameter to the get function. This will search for the widget recursively.

Code (cpp) Select Expand

gui.get<tgui::ProgressBar>("info_health", true);

You will have to build SFML yourself, TGUI 0.7 requires at least SFML 2.2.
I didn't knew debian was still shipping with such an old sfml version, I assumed anyone would have at least 2.3 since that is what Ubuntu LTS ships.

Widgets are stored in shared pointers which will be destroyed as soon as nobody holds a pointer to the widget anymore. So if you still have a pointer in your own code then it will continue to exist, but if you have no pointer to it then after removeAllWidgets the gui shouldn't have a pointer to it anymore either so they should be destroyed and the memory freed.

You will still have to use an sf::Texture, but if you want multiple widgets to use this texture without copying it every time then you can wrap it in a tgui::Texture:

Code (cpp) Select Expand

sf::Texture sfTexture;
// load sf::Texture from memory
tgui::Texture texture{sfTexture}; // sfTexture is copied here and is no longer needed from this moment on
picture1->setTexture(texture); // texture is given to picture1 without copying the sf::Texture
picture2->setTexture(texture); // texture is given to picture2 without copying the sf::Texture
// texture no longer has to be stored because the pictures will share its contents

I don't really know how and where to document the behavior so that you can find it. It documented somewhere though: the Picture class takes an tgui::Texture as parameter for which the constructor contains the following documentation when passing an sf::Texture:
"The texture will be copied, you do not have to keep the sf::Texture alive after calling this function" (https://github.com/texus/TGUI/blob/0.8-dev/include/TGUI/Texture.hpp#L110).
I know that the abstractions make the documentation a lot harder to find, but it saves me a lot of extra functions in widgets or renderers.

TGUI has its own tgui::Texture class which can be shared between widgets.
If you load a picture by filename then it will use an internal texture manager that keeps track of which files were loaded already and reuse the same texture when it is used multiple time. If you however pass an sf::Texture then it has no idea when you are reusing the same texture (as it doesn't store a pointer to it), so a copy will always be made. You could share the tgui::Texture manually if you care about this by first copying the sf::Texture to a tgui::Texture and then passing this tgui::Texture to your widgets (which will only copy the tgui::Texture wrapper and share the internal sf::Texture).

At least in 0.8-dev (the class has the same purpose in 0.7 but is slightly different), widgets just take the tgui::Texture as parameter which can get implicitly converted from either a filename or an sf::Texture. Classes like tgui::Texture and tgui::Color are mainly just an abstraction that allow implicit conversions (e.g. when a widget needs a color, you can pass either an sf::Color or a string like "red" because the parameter is defined as a tgui::Color).

You can't use TGUI 0.7 with VS2012 and SFML 2.1, it requires at least VS2013 and SFML 2.2.

Ok, I finally understood the setup. I actually don't see any reason why it wouldn't work.
But the zip file you downloaded is almost 3 years old so I can't make any guarentees that what it contained is really correct. I used to distribute SFML libraries with TGUI back then because there were bugs in SFML 2.1 and SFML 2.2 that affected TGUI. So I actually doubt that these libraries are the real SFML 2.1, they are probably a version somewhere inbetween 2.1 and 2.2.

I would really just get the latest versions (SFML 2.4.1 and TGUI 0.6.10), what you have is 3 years old and contains many bugs. If possible I even recommend updating the compiler and use TGUI 0.7.2, but I understand if the compiler is not something you consider updating. The libraries on the other hand should be up-to-date or else I won't be able to support you much. Both SFML 2.4.1 and TGUI 0.6.10 still support VS2012.

I have binaries for TGUI 0.6 here but I have no idea for which SFML version they are compiled so you will likely have to compile TGUI yourself. That way you can also use any SFML version you want as long as it is 2.2 or higher. I removed support for SFML 2.1 some time ago.

Edit: If you really need SFML 2.1 you can always download https://github.com/texus/TGUI/archive/v0.6.1.zip and build that one instead of the latest TGUI version. But you will have to build TGUI yourself no matter what you choose, unless you update the compiler and download a binary for TGUI 0.7.

I'm linking with the SFML that is packaged with TGUI.

TGUI doesn't come packaged with any SFML version. Where did you download it exactly?

I'm using SFML 2.1

SFML 2.1 has to be linked differently from later versions when linking statically (they changed it somewhere between 2.2 and 2.4). If you use a newer SFML version then you must also link to opengl, glew, jpeg, etc.

The SFML version used to build TGUI has to match perfectly with the SFML version you are using in your project. Based on the errors I would say that SFML > 2.1 was used when compiling TGUI and you are using SFML 2.1 in your project. You might want to try to recompile TGUI.

Edit: I thought it was a typo initially, but you should really update to TGUI 0.6.10, there have been many bug fixes since 0.6.1.

These linking errors are not coming from TGUI, if you link SFML statically you also have to link SFML dependencies yourself.

If your project didn't give these errors before you linked TGUI then it would indicate that you are using an older SFML version while TGUI was compiled against the latest version.

Btw, you don't have to define TGUI_USE_STATIC_STD_LIBS.

Also, I noticed CPU-usage spikes even in idle

I've made a large internal change in 0.8-dev, hopefully what I changed is related to this and will have fixed it.

I can't reproduce the cpu lag though, not even with calling setPosition on every widget every time the scrollbar moves.
The scrollbar generates up to 30-50 events per seconds here when being moved and each of my 50 labels is moved when this happens.
The 570 fps I have during idle only goes down to 530 fps while scrolling.

But having a CustomPanelClass that doesn't call setPosition the whole time will of course perform better in any case.

I really need to write a tutorial about how to write custom widgets some day, I didn't even understood why this went wrong until I saw the exact error.

You have to add the following in the declaration of your CustomPanelClass:

Code (cpp) Select Expand

typedef std::shared_ptr<CustomPanel> Ptr;

The Borders class should be available because you indirectly include Panel, for the Clipping class you have to add the following on top of your source file:

Code (css) Select Expand

#include <TGUI/Clipping.hpp>

Design wise I would store the board as a grid. Based on the kind of errors that I found you are not doing that and are instead drawing the pawn "manually" based on where you set their position. I would instead generate the sprites at runtime every frame.

You would just have a grid of integers (e.g. vector<vector<int>> or even better use std::array instead of std::vector if the grid is a fixed size). Every cell in the grid has a value depending on what it contains, e.g. 0 when empty, 1 when there is a pawn, 2 if there is a queen. To draw on the screen you just loop over every cell in the grid and determine if you need to draw something there or not and you create a sprite and draw it (the texture that the sprite uses should of course be loaded upfront).
You may already have something like a grid to determine where there are pawns, but I'm suggesting to also use it for drawing. This ensures that what you see visually always represents the internal state. The only tricky part would be to not draw the one that you are dragging.

There isn't much room for OOP for the game itself, you just need a simple grid. Maybe other part of the code can use OOP, but you should only use it when you feel it becomes more structured and easier to maintain, not just because you arbitrary choose to. You should see for yourself, I don't know what else you are storing outside the grid that you need to have for the player and computer.

Whether to use the keyboard or the mouse depends a lot about the game, in case of chess the mouse is a lot more intuitive so you don't get much choice. The mouse isn't any harder to handle than the keyboard, it's just that implementing dragging and dropping an object takes a bit of effort.

Playing is a lot better now. But you will still have to test it a lot and find the bugs in it because it does go wrong from time to time.
In a few minutes I saw the following things happening:
- The pawn of the opponent was immediately placed back to where it came from after moving. The square where it moved to is occupied according to the game (you can't move a pawn there if you have one right in front of it), but the pawn is still drawn on the wrong location. See the attachment if my explaination is unclear, the pawn should be at c4 but it is at b5 (Black was configured as NWC-North).
- At one point the opponent started using my pawns. So during black's turn a white pawn was e.g. moved from b2 to b1.

It looks nice but it is still buggy (sometimes you can't move a piece, the program hung once, etc).

I think the next thing you should do is fix the movement. When you select a piece and place it in an invalid position it should be moved back where it came from. Optionally you can even highlight the places where you can put it down. And don't allow to pick up a piece of the opponent. By just making these changes the game will already be a lot better.

The most important parts of the game are probably already implemented so you just have to finalize it and make it a bit more user-friendly. Keep up the good work.

Btw, the zip files contains the dlls which are needed to run the exe, but in the github files these dlls are still missing so you still have to unzip the zip file to play the game. Once all files are there on github it won't be necessary to have the zip file there anymore.

I looked into 0.8 source code and it seems like Panel::draw has the same parameters, why would not custom widget work without changing the code?

The draw function is the same, I was talking about mouseOnWidget, leftMousePressed and leftMouseReleased which take a sf::Vector2f instead of two floats.

I tried your code, but overrided "draw" function moves the panel itself, not the widgets on panel.

The code is indeed wrong (I didn't test it and just wrote what I expected it to be). You indeed can't just call Panel::draw, instead you should try to just copy the contents of Panel::draw into CustomPanel::draw and add the states.transform.translate line right above the drawWidgetContainer call. That should move just the widgets and not the panel itself. Note that you also have to include "TGUI/Clipping.hpp" in your source file.

Ok, the custom widget should have a similar performance to the ListBox of 0.8-dev, so it should work smoothly.

It worries me a bit that you still saw lagging in 0.8 earlier when calling setPosition on every label. That would indicate that the layout system itself is too slow to handle the many updates per second. Or maybe your mouse is just sending more MouseMoved events than normal, it could also be an interesting measurement to see how many events are generated per seconds. But in the end I'll just have to profile the code to find out for certain where most time is really being spend.

The idea of using a custom widget is to avoid calling setPosition. Apparently the function call has too much overheat so the widgets have to be moved without the function being called for every pixel the scrollbar moves. To do this, we will translate the widgets when drawing. You will call setPosition once to place them in the panel, but when the scrollbar moves you will not call setPosition again and instead dynamically change where the widget is drawn.

Instead of using tgui::Panel, you use your own CustomPanel class that inherits from tgui::Panel. This class needs access to the scrollbar somehow (e.g. it has a pointer to the scrollbar as a member variable). You have to override the draw function (adding draw as a member function of your class) like this:

Code (cpp) Select Expand

void CustomPanel::draw(sf::RenderTarget& target, sf::RenderStates states) const {
    states.transform.translate({0, -(float)scrollbar->getValue()});
    Panel::draw(target, states);
}

That will move all widgets up with scrollbar->getValue() pixels when drawing.

When handling events, the panel must also know about the fact that the widgets aren't located where they claim to be, so mouseOnWidget has to be implemented like this in your class:

Code (cpp) Select Expand

bool CustomPanel::mouseOnWidget(float x, float y) const {
    Panel::mouseOnWidget(x, y + scrollbar->getValue());
}

The same has to be done for leftMousePressed and leftMouseReleased.

Note: this code is based in 0.7, to do the same in 0.8-dev just have a look at how the parameters of the functions are in the tgui::Panel class.

Edit: can you check one more thing? Does the lag also occur when you have a ListBox with some items in it (which is very similar situation to having a scrollable panel of labels)?

Could you send some (minimal) code in which the lag and high cpu usage occur?
I don't have time to look at it right now, but then I can have a look later and see if I can reproduce it and find out what is causing it.

They are part of the renderer now, so you have to call widget->getRenderer()->setTextColor instead of widget->setTextColor.

If you use themes then there are indeed some differences with 0.7, other than that most things should be very similar.

For me it is much easier to build them as I have everything set up for 0.7 and thus just have to change a few variables. But I run windows in a virtualbox on my laptop so building the library is extremely slow (but I just run it in the background so it doesn't matter much to me how long it takes).

I assume you need the 32-bit version: https://www.dropbox.com/s/e7kfugbyq3myfbp/TGUI-0.8-dev-vc14-32bit-for-SFML-2.4.1.zip?dl=1
But I also have the 64-bit version just in case: https://www.dropbox.com/s/se1xi0o7isyicqa/TGUI-0.8-dev-vc14-64bit-for-SFML-2.4.1.zip?dl=1

No, I don't have precompiled versions for it and it would take too long for me to generate them. So you would have to compile 0.8 yourself.

Edit: if it is not urgent then maybe I can generate them for you and send them in a few hours from now.

Could you perhaps try with 0.8-dev and see if it is better there? The setPosition function works differently there and it should be much faster.

If not then I might be able to tell you how to implement the scrolling in a more performant way in 0.7 (because the example that you based yourself on was a very naive implementation), but it will require you to add a custom widget. So if the problem is solved by using 0.8-dev then maybe it is not worth the effort.

dealWithTextEntered either has to be a function without parameters or have an sf::String (or std::string) as parameter. The return type of the function has to be "void". The function can only have different parameters if they are bound by passing them to the connect function, as explained in the tutorial.

Could you also show the declaration of dealWithTextEntered?