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 ... 33
Feature requests / Re: Diagonal resize cursors on Linux
« on: July 25, 2020, 05:35:05 pm »
Yes, I can send a PR for this.
I guess I'll just implement the fall back to the double arrows on macOS for now, if anyone wants it differently then it could still be changed later.

Edit: see PR #1688

Feature requests / Diagonal resize cursors on Linux
« on: July 12, 2020, 05:51:22 pm »
I would like to change the mouse cursor when the mouse is at the corner of a child window in my gui, but SFML doesn't support diagonal arrows on Linux (Cursor.hpp#L65-L66).

I know that this is because X11 doesn't support those double arrows, but could directional arrows (e.g. XC_bottom_left_corner) perhaps be added?
The following would be useful, but only the last 4 are required to add support for diagonal resizing on linux.
- SizeLeft
- SizeRight
- SizeTop
- SizeBottom
- SizeTopLeft
- SizeTopRight
- SizeBottomLeft
- SizeBottomRight

On linux, all of those exist.

On windows, none of those exist. It should be easy to just display the double arrow if one of those directional sizes are requested though.

On macOS, all of those should also exist, but are undocumented just like the diagonal double arrows. I'm not sure if they are ever used on mac though, maybe it would be better to fall back to double arrows here as well (for my gui I would only try to set those directional cursors in Linux anyway and use double arrows on Windows and macOS).

Is there any chance that those cursors could be added to SFML, even though they are specific for Linux?
I've already changed my code to just load those cursors directly and only use SFML when loading other cursors, but it would be nice if I could set those cursors via SFML as well in future SFML versions (as I now have to link with Xlib myself).

Graphics / Re: weird behavior from my color picker (SFML & TGUI)
« on: March 31, 2020, 07:42:54 pm »
You should really reduce code to a minimum if you want people to help you find the issue. It takes too much time for someone who doesn't know the code to get started with it. The code isn't minimal at all: it uses plog, is spread over multiple files and contains many unnecessary things. Why do I need to press a button and check a checkbox before I can start trying something? If it is not related then it should be removed, the contents of the child window should just be the contents of the main window. If it would have been related, then it should explicitly be said so as it would help narrowing the issue.

Do the scrollbars have any influence on the issue for example? Print the scrollbar values when the issue occurs and hardcode these values instead of getting them from the scrollbars. If the issue still occurs, then the scrollbars can be removed. If it doesn't occur when hardcoding the values then at least you get some more information as to where in the code to look.

Your code has so many weird things going on that may or may not be related to your issue that it is hard to even pinpoint the issue for someone who doesn't know the code. Printing the ColorHue variable for example shows that you are trying to store 360 values in a 8-bit variable. You seem to know this already because it has a comment next to it that you should prevent overflow, but you should probably fix this first as these kind of issues might contribute to the real issue or at least waste time of people trying to look for the issue. You also imply in your previous post that HSV(0, 20, 13) would be bright red, but it is actually much closer to black if you look it up. Even the debug print is confusing since you print the values in S, V, H order instead of H, S, V. The image you use is also a bit confusing: Normally white is at the left side (because an S value of 0 gives you white to black, with no hue).

Values in HSV are usually limited to (360, 100%, 100%), but it doesn't seem to be the case in your code (and the magic numbers don't make it easier to understand what the code is actually using). The fact that the HSV class stores its values as doubles made me think that it might use values between 0 and 1 for S and V, and looking at the ColorTest function at the bottom of ColorHeader.h shows that the assumption was right. Yet your code stores them as uint8_t with values from 0 to 255. If this isn't the main issue then at least it is part of it.

If your input is HSV(0, 20, 13) and your output is RGB(243, 247, 247), like you showed in your last post, and you believe that the given output is incorrect for the provided input then you could have minimized your code to this:
int main()
    HSV hsv = HSV(0, 20, 13);
    RGB rgb = HSVToRGB(hsv);
    std::cout << (int)rgb.R << " " << (int)rgb.G << " " << (int)rgb.B << std::endl;

That is how much you could have reduced the code. And then you probably would have been able to find the issue yourself.
Changing the HSV parameters to (0, 0.2, 0.13) does print the correct RGB values in this code.
If there are other issues in the code then at least this one would be dealt with and you can handle them one at a time by minimizing the code around some issue instead of trying to fix them all at once.

General discussions / Re: GUI with SFML
« on: February 29, 2020, 10:39:46 pm »
Make sure there are no conflicting options checked (e.g. if c++98 is also checked).
There are actually several places where you can set these options. Under "Settings > Compiler..." you can set it globally for all your projects (not recommended). Under "Project > Build options..." you find the settings for your current project. But on the left side of the window you can select whether you are viewing options for Debug, Release of both. So make sure you aren't e.g. only adding the option in release while building your option in debug mode.

Have a look at the build log to see which parameters are passed to g++.
In the build log you can see which options are actually being used. Your error clearly mentions that you don't have c++14 enabled, so either the -std=c++14 option won't appear here or there will also be e.g. some -std=c++98 in the same command that overwrites it.

General discussions / Re: GUI with SFML
« on: February 28, 2020, 05:55:36 pm »
lambda capture initializers only available with -std=c++14 or -std=gnu++14
You need to add "-std=c++14" to your compiler options in order to use TGUI. Where you do this depends on how you are compiling, but if you are using codeblocks then you can do this in the "Compiler flags" in the "Project build options" as shown in the tutorial (https://tgui.eu/tutorials/0.8/codeblocks/#using-tgui).

General discussions / Re: GUI with SFML
« on: February 27, 2020, 06:44:18 pm »
What fails exactly?

General / Re: Undefined Reference to TGUI functions
« on: January 17, 2020, 07:05:06 pm »
Are you linking with tgui?
In cmake that would be like "target_link_libraries(your-target PRIVATE tgui)".

Window / Re: Unicode in window titles doesn't work properly (Linux)
« on: October 31, 2019, 06:00:48 pm »
It works for me when replacing u8 by L:
sf::RenderWindow window(sf::VideoMode(300, 200), L"Unicode: naïve こんにちは");

I've noticed in the past that sf::String works more reliably when using wide-strings instead of UTF8 strings on linux (unless you manually use sf::String::fromUft8 and sf::String::toUtf8).

Graphics / Re: sf::text not handling characters correctly
« on: October 07, 2019, 10:56:32 am »
isn't there some universal way to work in both cases?
Not that I know of. The u16string and u32string from c++11 and especially the u8string from c++20 looked promising to store strings while being explicitly about the encoding (while std::string and std::wstring depend on the platform). But you can only use them to store strings in, as soon as you need to do something with it (like printing to to the screen) you need to manually convert them again anyway.

Using std::wstring sounded like the most universal ways to me. But I just tried and on manjaro with cinnamon it printed "?" in the terminal when using wstring and wcout in both XTerm and GNOME Terminal.
So if you want to print the text to the command line on both Windows and Linux then you might need some platform dependent code (unless there is some way that I don't know about yet, keep in mind that I never actually developed a program that uses unicode characters).

Using std::wstring will allow easier interaction with sf::String as you won't need to use code like the String::fromUtf8 to correctly display the characters, you would just be able to convert the std::wstring to an sf::String implicitly.

Then to output to the screen, instead of doing cout or wcout you would call a function that will call either one depending on the platform. As you can see, I don't know a very efficient way to go from sf::String to an UTF-8 std::string (the toAnsiString() function can't be used because it removed all non-ansi characters), but at least this method works. I didn't test the Windows implementation.
void output(const sf::String& str)
    const std::basic_string<sf::Uint8>& tmpBuffer1 = str.toUtf8();
    const std::string tmpBuffer2(tmpBuffer1.begin(), tmpBuffer1.end());
    std::cout << tmpBuffer2;
#else // Assuming Windows is the only other platform
    std::wcout << str.toWideString();
(You might need some changes if you want to add a newline behind it or if you mix it with other cout statements in your code)

I looked up how to use std::wcout on linux. It turns out you can use wcout on linux if you add something like the following line at the start of your code (whether you want to actually do so is up to you, this might fail if the locale is not installed + going this route will likely also result in platform dependent code).
std::locale::global (std::locale ("en_US.UTF-8"));

Graphics / Re: sf::text not handling characters correctly
« on: October 05, 2019, 11:05:40 pm »
Maybe there are better ways than what I'm going to say, but this is what I found out when trying to use unicode.

If a string is encoded as UTF-8, you can convert the string to an sf::String like this:
sf::String::fromUtf8(str.begin(), str.end())

You could force a UTF-8 encoding like this:
std::string str = u8"Opção olé";

This will however no longer compile when using c++20.
What you could do instead is manually encoding the bytes as UTF-8 (which will also assure that your code keeps working when your cpp file is saved with a different encoding):
std::string str = "Op\xc3\xa7\xc3\xa3o ol\xc3\xa9";

If you do that and change the creation of the text object to the following then it should work:
sf::Text text(sf::String::fromUtf8(str.begin(), str.end()), font);

When writing this I realized that this might break the std::cout though. Linux typically uses UTF-8 as locale, so it will work fine, but keep in mind that it is possible that on Windows the cout line might start spitting out garbage characters.

Note: if you don't care about Windows support and you assume that all the users of your program use the UTF-8 locale (which will be the case on practically any linux), then you don't have to encode the strings manually. Your code will work fine if you only add the sf::String::fromUtf8 part and leave the declaration of str like it is in your example.

Graphics / Re: Is clipping needed ?
« on: July 13, 2019, 05:44:14 pm »
I use the viewport method for clipping and if you encapsulate the code then it shouldn't make the rest of your code more complicated (at least it doesn't make it more complicated for my use case). The only real downside of the method is that you need to pass the new view to the clipping code every time the view is changed (but that only happens in one place in my code). The rest of the code doesn't need to care about how you do the clipping.

I've implemented my code in such a way that I just need to pass the render target and states (which all my draw functions have) to the constructor of the Clipping class together with the rectangle that should be clipped (relative to the render states). As long as the clipping object exists, all draw calls are clipped. The old view will be restored when the clipping object is destroyed. It works when a custom view and viewport were already set, so it even works recursively (two clipping objects can exist at the same time and things will only be drawn inside the intersection).
Clipping clippingObject(target, states, clippingRectTopLeft, clippingRectSize);
target.draw(drawable, states); // drawing will be clipped

Drawing to a RenderTexture will probably work just as well, as long as you encapsulate the rendering so that your code doesn't need to know whether it is drawing to the screen or to an intermediate texture.

The fix seems to be to change
sfml_bind_dependency(TARGET OpenGL FRIENDLY_NAME "OpenGL" SEARCH_NAMES "OpenGL" "GL")
sfml_bind_dependency(TARGET OpenGL FRIENDLY_NAME "OpenGL" SEARCH_NAMES "GL" "OpenGL")
in SFMLConfigDependencies.cmake.in (just swapping the "GL" and "OpenGL" strings).

With the current code, the OpenGl_LIB variable contained "/usr/lib/libOpenGL.so" and I got linking errors to GLX.
After the change, OpenGl_LIB contained "/usr/lib/libGL.so" and there were no more linking errors.

The libGL.so file is also the one the SFML links to. The "find_package(OpenGL)" call provides both OPENGL_gl_LIBRARY and OPENGL_opengl_LIBRARY values, but OPENGL_gl_LIBRARY is the one that SFML uses for target_link_libraries.

When linking static SFML libraries on linux, cmake doesn't automatically link to GLX (while it links fine to all other SFML dependencies).

The following simple cmake script is enough to reproduce it.
cmake_minimum_required(VERSION 3.5)

find_package(SFML 2 COMPONENTS graphics window system REQUIRED)

add_executable(Test main.cpp)
target_link_libraries(Test PRIVATE sfml-graphics)

The main.cpp file is practically empty:
#include <SFML/Graphics.hpp>
int main()
    sf::RenderTexture target;

Running make will give the following output:
(click to show/hide)

Changing SFML_STATIC_LIBRARIES to FALSE fixes it, so it only occurs when linking statically.
Adding "GLX" to the target_link_libraries line also fixes the issue.

Edit: Linking to "GL" (instead of "GLX") also fixes it (but linking to "OpenGL" doesn't).

SFML projects / Re: TGUI: GUI library for SFML
« on: April 06, 2019, 07:08:50 pm »
TGUI 0.8.5 has been released.

SVG support
It is now possible to uses SVG images:

Improved Gui Builder
The Gui Builder hadn't changed much since its release with 0.8.0, but many improvements have been added to it now. Just to mention a few:
- New start screen
- Keyboard shortcuts
- Properties now have types
- Right click popup menu
- Shows lines when widgets are aligned
- Widget hierarchy window (this was contributed)
- More widgets

General / Re: CMake android build errors
« on: March 29, 2019, 01:57:26 pm »
I have no issues when using NDK 17b which I downloaded manually some time ago.

However if I install the ndk-bundle by running `./sdkmanager "ndk-bundle"` and run the same command (but with the new NDK directory) then I get some errors about the compiler it tries to use. So maybe your issue could also be solved by downloading the NDK manually instead of using the ndk-bundle from the SDK.

Edit: the tutorial also states that when using NDK 18 or above, "-DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang" should be added to the cmake command (and ndk-bundle seems to download NDK 19).
I seem to also get the errors when downloading NDK 19c manually, but 17b and 18b works fine for me. But my errors occur after the place where it fails for you, so downgrading NDK might not solve your issue.

Pages: [1] 2 3 ... 33