Welcome, Guest. Please login or register. Did you miss your activation email?

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.

Messages - texus

Pages: 1 [2] 3 4 ... 33
SFML projects / Re: TGUI: GUI library for SFML
« on: January 30, 2019, 07:30:15 pm »
The biggest work would be creating a new TabsProperties.hpp file inside the "include" directory (the one inside the "gui-builder" directory obviously). You can have a look at other widgets (e.g. "ListBoxProperties.hpp") for examples on how this file should look. The properties needed in "updateProperty" can be found in the Tabs::load function from src/TGUI/Widgets/Tabs.cpp while the properties in the "initProperties" function also include the ones found in the Tabs::rendererChanged function.

Once you have that file, the last few changes are easy:
- Include TabsProperties.hpp in GuiBuilder.cpp

- Add the following in the GuiBuilder constructor:
m_widgetProperties["Tabs"] = std::make_unique<TabsProperties>();

- In GuiBuilder::loadToolbox, add the following to the creation of the "widgets" variable:
{"Tabs", []{ return tgui::Tabs::create(); }}

- You also need to add a file called "Tabs.png" to the resources/widget-icons folder.

SFML projects / Re: TGUI: GUI library for SFML
« on: January 29, 2019, 07:00:50 pm »
one thing needed is the gui builder, or just an example on how to add all the gauges
What do you mean with adding all the gauges?

Files created by the gui builder can be imported in code by executing

The gui builder still needs a lot of work, it has been neglected a bit since it was released. This might be something that I could improve in the next version.

SFML projects / Re: TGUI: GUI library for SFML
« on: January 28, 2019, 08:03:26 pm »
A lot of new features have been added to TGUI in the last 6 months:

TGUI 0.8.1

MenuBar got support for submenus and for disabling menu items.

TGUI 0.8.2

A new TreeView widget was added.

Changing the text styles in the ChatBox widget also became possible.

TGUI 0.8.3

TGUI 0.8.3 brought several new features, the biggest one being the ListView which has been the most requested widget for quite a while.

Label also got a vertical scrollbar, TextBox got the option to use a horizontal scrollbar (as alternative to the default word-wrapping) and EditBox got the ability to set a fixed suffix behind the string (e.g. for displaying units).

Further releases

Currently there are no plans yet for what will be added in 0.8.4, it could be another release bringing new features but it could also be the start of a period with mostly bugfixes.

The changes made in the last patch releases make it clear that TGUI isn't following SemVer, that however doesn't mean that I don't care about compatibility. The TGUI 0.8.x branch will continue to be backwards compatible with earlier TGUI 0.8.x releases, but an exception to this rule is being added. Since neither the TreeView nor the ListView class received any feedback or testing during development other than my own tests, I do not want to guarantee 100% API stability for these classes. I will however still try to keep things compatible for these two widgets.

Graphics / Re: Sprite clipping not working correctly (HD 2500)
« on: December 02, 2018, 06:23:19 pm »
The getSize().y has type "unsigned int". Adding it to an "int" still results in an "unsigned int" here.

The following code should print a very high number:
std::cout << -t1.getSize().y+(int)pp << std::endl;

For the very same reason that the following prints a large number. An "unsigned int" doesn't just become an "int" by putting a "-" in front of it.
unsigned u = 600;
std::cout << -u << std::endl;

When you created the temporary value you probably used type "int" so you were first casting the result to an "int" (which becomes the number you expected since the value of the "unsigned int" was too large to be represented in an "int"). In this case you would be converting the negative number to a float (which is what happens when calling setPosition since its parameters are floats). If you put "-t1.getSize().y+(int)pp" directly in setPosition then it instead converts the very large number to a float, placing the sprite far outside your screen.

The following code should thus work:

Window / Re: SFML: Transparent Window Background?
« on: November 01, 2018, 01:40:39 pm »
Do you only need it for linux? I hacked some code together that seems to work (for both the case where only the background has to be transparent and the case where the entire contents has to be transparent).

The downside is that it required a modification in SFML:
diff --git a/src/SFML/Window/Unix/WindowImplX11.cpp b/src/SFML/Window/Unix/WindowImplX11.cpp
index da697505..abbdd00e 100644
--- a/src/SFML/Window/Unix/WindowImplX11.cpp
+++ b/src/SFML/Window/Unix/WindowImplX11.cpp
@@ -573,13 +573,17 @@ m_lastInputTime  (0)
     int height = mode.height;
     // Choose the visual according to the context settings
-    XVisualInfo visualInfo = ContextType::selectBestVisual(m_display, mode.bitsPerPixel, settings);
+    //XVisualInfo visualInfo = ContextType::selectBestVisual(m_display, mode.bitsPerPixel, settings);
+    XVisualInfo visualInfo;
+    XMatchVisualInfo(m_display, m_screen, 32, TrueColor, &visualInfo);
     // Define the window attributes
     XSetWindowAttributes attributes;
     attributes.colormap = XCreateColormap(m_display, DefaultRootWindow(m_display), visualInfo.visual, AllocNone);
     attributes.event_mask = eventMask;
     attributes.override_redirect = (m_fullscreen && !ewmhSupported()) ? True : False;
+    attributes.border_pixel = 0;
     m_window = XCreateWindow(m_display,
@@ -589,7 +593,7 @@ m_lastInputTime  (0)
-                             CWEventMask | CWOverrideRedirect | CWColormap,
+                             CWEventMask | CWOverrideRedirect | CWColormap | CWBorderPixel,
     if (!m_window)

After that the following code should give the result shown in the images above:
#include <SFML/Graphics.hpp>

// Comment this define to only make the background transparent and keep all other things drawn to the window opaque

const unsigned char backgroundOpacity = 150;

int main(int argc, char* argv[])
    sf::Image backgroundImage;

    sf::RenderWindow window(sf::VideoMode(backgroundImage.getSize().x, backgroundImage.getSize().y, 32), "Transparent Window");
    window.setPosition(sf::Vector2i((sf::VideoMode::getDesktopMode().width - backgroundImage.getSize().x) / 2,
                                    (sf::VideoMode::getDesktopMode().height - backgroundImage.getSize().y) / 2));

    sf::Texture backgroundTexture;
    sf::Sprite backgroundSprite;

    sf::RenderTexture renderTexture;
    renderTexture.create(backgroundImage.getSize().x, backgroundImage.getSize().y, 32);

    while (window.isOpen())
        sf::Event event;
        while (window.pollEvent(event))
            if (event.type == sf::Event::Closed || (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape))


        sf::Sprite renderTextureSprite(renderTexture.getTexture());
        renderTextureSprite.setColor({255, 255, 255, backgroundOpacity});
        window.clear({0, 0, 0, backgroundOpacity});
        window.clear({0, 0, 0, backgroundOpacity});
    return 0;

Graphics / Re: Porting from CImg - Vertcal axis now inverted
« on: October 08, 2018, 10:38:19 pm »
It's not a bug (and the bug you linked to only happened after copying a texture and is already fixed in 2.4.2). You have to call "renderTexture.display();" after drawing to the render texture (https://www.sfml-dev.org/documentation/2.5.0/classsf_1_1RenderTexture.php#af92886d5faef3916caff9fa9ab32c555).

General / Re: Travis build file?
« on: August 15, 2018, 08:34:51 pm »
The SFML_LINUX folder in my script is where SFML will be installed to. This can be any folder you choose. You probably need to create this folder yourself first, in my case it always exists because it is specified as a cache dir and travis will create it for you in such case.

When you build SFML (which you download e.g. with "git clone"), CMAKE_INSTALL_PREFIX specifies which folder SFML will be installed to:
Code: [Select]
When running "make install", the SFML headers and libraries will be placed under this $HOME/SFML_LINUX folder.

When building your own project afterwards, you just specify in which folder SFML was installed with SFML_DIR:
Code: [Select]

General / Re: Travis build file?
« on: August 15, 2018, 10:08:09 am »
My travis.yml file is probably too complicated, but maybe it can helps to have another example to look at: https://github.com/texus/TGUI/blob/0.8/.travis.yml (there are different stages and jobs, but you only need to look at e.g. the "Linux (gcc 4.9)" job).
I don't have the scripts inside the yml itself, the actual script to build and use SFML can be found at https://github.com/texus/TGUI/blob/0.8/tests/travis_linux.sh.
(I just realized that it doesn't use SFML_DIR yet when building TGUI itself, but at the bottom of the script you find a cmake call where SFML_DIR is used, so that one is how you would have to call cmake on your project).

It might also help to show what error you are getting on travis, maybe someone else already encountered them (I've had plenty of cases where it build locally but failed on travis in the past, usually by stupid mistakes).

SFML projects / Re: TGUI: GUI library for SFML
« on: August 06, 2018, 08:30:17 am »
There shouldn't be a 0.9-dev branch for quite a while.
Usually by the time a new branch becomes stable, I already planned to rewrite certain parts in the next version or I even already started development of the new version locally. This is not the case this time. New features should still be added to 0.8 as long as possible.
I'm currently not spending a lot of time programming, only when bugfixes need to be made, so there may not be any really big changes in the near future for 0.8 either.

SFML projects / Re: TGUI: GUI library for SFML
« on: August 05, 2018, 11:13:33 pm »
TGUI 0.8.0 has been released!

An experimental gui builder has been added (again, since the form builder used to exist in early TGUI versions but was removed in 0.7 as the API wasn't stable enough yet to maintain it). This time it should be here to stay.

Other changes include:
- Global default text size for more consistent texts in widgets
- A theme can be made the default to use it for all new widgets
- Renderers are decoupled from widgets, making them truly shared
- BitmapButton widget to have an icon next to the button caption
- RangeSlider widget to have two thumbs on a slider
- ScrollablePanel widget to have a Panel with automatic scrollbars
- Panel widget was split in Group, RadioButtonGroup and Panel widgets
- HorizontalLayout, VerticalLayout and HorizontalWrap to arrange widgets
- Relative layouts were improved

Many more improvements have been made, but I didn't keep track of them and I'm not going to read through a 120.000 lines long diff file or read all 543 commit messages :)

General / Re: 2.5 linker error
« on: June 02, 2018, 02:31:13 pm »
You need to update Visual Studio to use the libraries from the download page: https://en.sfml-dev.org/forums/index.php?topic=24044.msg163201#msg163201

General / Re: [iOS] SFMLConfigDependencies.cmake looks for OpenGL
« on: April 11, 2018, 08:17:30 pm »
I never noticed that the FindSFML.cmake didn't support iOS. It always found SFML fine when building my library (I just had to manually set the dependencies as it found the macOS ones by default if they were installed). But it turns out that it also complains about not being able to link against OpenGL when building a final executable (which I didn't test earlier). So the change to SFMLConfig.cmake just made the failure happen at an earlier point and thus makes the error more visible.

I had a look at fixing SFMLConfig.cmake myself but I can't figure out how I can get cmake to find the right dependencies in the right places.

Fixing it in FindSFML.cmake was easier. I'm already shipping a slightly modified version of FindSFML.cmake with my library (the goal was to make it obsolete now SFMLConfig.cmake exists), so I just fixed that FindSFML.cmake file to link to the right libs on iOS.

General / [iOS] SFMLConfigDependencies.cmake looks for OpenGL
« on: April 08, 2018, 09:08:29 am »
When using the latest SFML version from github, I can't use SFMLConfig.cmake to find SFML when building for iOS.
On iOS the sfml-window target has to link to OpenGL ES but the SFMLConfigDependencies.cmake always looks for OpenGL, so CMake gives the following error on find_package(SFML ...)
CMake Error at /Users/texus/Desktop/SFML/build-iOS/SFMLConfigDependencies.cmake:34 (set_property):
  set_property could not find TARGET OpenGL.  Perhaps it has not yet been
Call Stack (most recent call first):
  /Users/texus/Desktop/SFML/build-iOS/SFMLConfigDependencies.cmake:55 (sfml_bind_dependency)
  /Users/texus/Desktop/SFML/build-iOS/SFMLConfig.cmake:117 (include)
  /Users/texus/Desktop/SFML/cmake/toolchains/iOS.toolchain.cmake:211 (find_package)
  CMakeLists.txt:175 (find_host_package)

Graphics / RenderTexture texture flipped after copying
« on: November 13, 2017, 07:26:56 pm »
Since commit 6b71456, copying a texture from a render texture causes it to be flipped.

Code to reproduce:
#include <SFML/Graphics.hpp>

int main()
    sf::RenderWindow window(sf::VideoMode(400, 200), "SFML Window");

    sf::RectangleShape shape{{100, 100}};

    sf::RenderTexture rt;
    rt.create(200, 200);

    sf::Sprite s1(rt.getTexture());

    sf::Texture t = rt.getTexture(); // Copy texture before passing it to sprite
    sf::Sprite s2(t);
    s2.setPosition({200, 0});

    while (window.isOpen())
        sf::Event event;
        while (window.pollEvent(event))
            if (event.type == sf::Event::Closed)


The attached images show how it looked before and after commit 6b71456.

General / Re: TGUI Bad Alloc using example code
« on: November 03, 2017, 07:53:07 am »
I assumed you were using 0.8 because you linked the example code for that version.
TGUI 0.7 and 0.8 are not compatible at all, although this simple example compiled, it did something completely different. The "50%" means "parent.width / 2" in 0.8 while it means "50 mod 0" in 0.7. The division by 0 might somehow be causing the crash. I have been able to reproduce it in 0.7 and will fix it in 0.7.6 as the code shouldn't crash for something like this.

Pages: 1 [2] 3 4 ... 33