Messages

61

SFML projects / Re: Gemstone Keeper - An ASCII based Roguelike Shooter

« on: May 23, 2017, 11:40:08 pm »

Seems to work fine now. The program can be executed out of the box and I finished one level with keyboard and mouse without any issues (except that the controls don't really correspond well to my AZERTY keyboard).

Just a minor detail, the controls section in the readme is only aligned when a tab is aligned to 8 spaces.

62

SFML projects / Re: Gemstone Keeper - An ASCII based Roguelike Shooter

« on: May 23, 2017, 11:13:07 pm »

You should try making a .tar.gz (or .tgz) file instead of a .zip, that should preserve the file permissions.

63

SFML projects / Re: Gemstone Keeper - An ASCII based Roguelike Shooter

« on: May 23, 2017, 10:24:56 pm »

I had to change the permissions of the runGemstoneKeeper.sh and Gemstone-Keeper files to allow executing them.

When going into the cavern and clicking "start level", the game crashes with a std::bad_cast error after the screen faded to black. The backtrace does not show anything as the executable is not a debug build.

In the terminal output there is also a repeating error because "VFrame/depend/arial.ttf" can't be found.

64

General / Re: How to make a textbox

« on: April 04, 2017, 03:38:30 pm »

Unfortunately TGUI does not support horizontal scrolling in TextBox, only vertical. Although I don't think SFGUI or ImGUI have support for it either. For ImGUI there does seems to be an open issue for it with some hacky partially working code from 2015 though.

0.74 or 0.8

If you want to use TGUI then 0.7.4 is for when you want to be certain that my future patches don't break your code, 0.8-dev if you want to have the latest stuff but find it acceptable to from time to time make changes in your code when updating to a newer revision. The layout system is currently the only part that is still planned to get an overhaul in 0.8-dev in a few months, although there probably will be some other major changes that I will come up with afterwards.

shh, texus doesn't know yet

He does now

65

SFML projects / Re: TGUI: GUI library for SFML

« on: February 12, 2017, 01:16:11 am »

TGUI 0.7.3 has been released.

Because 0.8 is still going to be in development for a long time, I decided to make the creation of widgets slightly easier in 0.7. There are now static create functions similar to the ones in 0.8-dev (although in 0.7 they are only needed when not using a theme, in 0.8-dev themes are handled differently and you always create widgets like this).

Basically the following line

auto button = std::make_shared<tgui::Button>();

can now finally be written as follows in 0.7 as well:

auto button = tgui::Button::create();

66

General discussions / Re: SFGUI vs TGUI

« on: February 12, 2017, 12:52:06 am »

TGUI is the best of course

I'm still waiting for someone to actually try both of them and make a comparison. The only post I have seen by someone who tried both and said what she thought was wrong about them only had arguments against tgui that are no longer relevant.

67

SFML projects / Re: One Room - 37th Ludum Dare Jam

« on: December 13, 2016, 01:10:26 pm »

I finished the game but I cheated on the phone initially. After it wouldn't work with the pin from the egg I eventually gave up and looked at the resources for the image of the unlocked phone and continued with that information. I managed to complete the game with no further trouble. I realize now that the pin on the piece of paper is not exactly the pin and I have figured it out, but I think that one was too difficult because I didn't have any reason to doubt that that number was the correct one. With the briefcase on the other hand it is obvious that you have to change something because you can't type letters. But I really liked the concept of the game.

68

SFML projects / Re: TGUI: GUI library for SFML

« on: October 25, 2016, 02:58:44 pm »

No, I'm too busy with TGUI and university assignments that I don't even have time for other projects

69

SFML projects / Re: TGUI: GUI library for SFML

« on: October 25, 2016, 02:50:36 pm »

There is now a C binding and a .Net binding available for TGUI 0.8-dev.

Note that these bindings are still experimental (they have only briefly been tested) and TGUI 0.8 itself is still in an early stage of development.

70

SFML projects / Re: TGUI: GUI library for SFML

« on: October 19, 2016, 12:40:28 pm »

RichEditBox or RichTextBox is not planned. They will probably only be added if someone else writes and contributes them.

RichText will be added in the future but it will probably take more than a year before I will look at it.
In case you didn't know there is code available for such a widget (RichTextLabel.hpp) which is based on https://bitbucket.org/jacobalbano/sfml-richtext. You have to include "TGUI/Widgets/devel/RichTextLabel.hpp" in your code to use it. It will have to be rewritten before I accept it as part of the gui though, it hasn't been tested for a while and part of its code doesn't fit with the rest of the gui.

71

SFML projects / Re: TGUI: GUI library for SFML

« on: September 29, 2016, 11:04:11 am »

Both forms should be allowed because they do different things.

When a value is passed, a copy of the value is stored and later passed as parameter. You could use std::ref to pass a reference to the variable though.

When the result of an std::bind is passed, the bound function will be called when the callback occurs.

So the first line will call getValue() each time the button is pressed.
The second line calls getValue() and passes the value to the connect function as a constant. No matter what getValue() would returns when the button is pressed (it not being called), the parameter of your callback function will be a constant in this case: the value it had when the connect function was called.
So you will likely want to use the first one.

72

DotNet / Create Font and Texture from cPointer

« on: September 24, 2016, 05:02:11 pm »

I'm writing a .Net binding for TGUI and I can't find a way to receive fonts and textures from my c++ code.

The Font and Texture class provide a constructor to create them from a cPointer, however their access specifiers don't allow using them. The one in Font is 'private' because it isn't used outside the class while the one from Texture is 'internal' because it is used in the RenderTexture constructor to get the texture from C.

I basically have to do something similar as that line in the RenderTexture constructor but with both fonts and textures, but these font and texture constructors can't be used outside the SFML.Net code.

Is there any chance that these constructors could be specified as 'protected internal'? That way they still can't be used under normal circumstances but if someone needs them they can inherit from the class and pass the cPointer from there.
Or is there another solution that I am overlooking?

73

General / Re: [TGUI] Why can't I pass a void* function pointer to tgui__button.connect?

« on: September 10, 2016, 04:48:57 pm »

It should look like this:

std::function<void()> func

The void is the return type and between the brackets you can put the parameters (none in this case).

74

General / Re: [TGUI] Why can't I pass a void* function pointer to tgui__button.connect?

« on: September 10, 2016, 04:34:38 pm »

In c++ you shouldn't use void* unless you know what you are doing. There is no way TGUI could know what 'func' is or how many parameters it would have. You should use an std::function to store the function, so the parameter would have to be std::function instead of void*.

The best place to ask questions about TGUI is on the TGUI forum (or any other way mentioned on the contact page) because then I will get notified about your question immediately.

75

C / Re: How to release a sfml-program for several distribution?

« on: August 22, 2016, 04:54:03 pm »

I always wonder with that, how are SFML's dependencies handled? Can I compile this on Debian and then really run it on Ubuntu, Arch and Gentoo? What if runtime libs differ?

I have tried compiling an application in the past that ran on both ubuntu and arch linux. I never really knew which dependencies to ship so I just copied the ones that were asked for when starting the app. The result was that a year later on a different system it sometimes missed some library.
So I decided to take a more detailed look into this today and these are my findings (some information may be incorrect, these are simply my observations). Since I do not have ubuntu I used docker from arch linux.

There are 2 problems with distributing the executable:
1) You can only run the executable on newer systems (or the same) as the one you compile with.

(click to show/hide)

You cannot ship libc with your application. If you attempt to do this then you get an error like this:

./Game: relocation error: /mnt/lib/libc.so.6: symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

Shipping ld-linux-x86-64.so isn't possible (adding it to the lib doesn't do anything).

But if you do not ship libc.so then it will use the one from the operating system. Since libc is backwards compatible this is fine when the executable was created with an older libc version. But it the libc version used to compile the programs and libraries is newer then you will be greeted with an error like this:

./Game: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.18' not found (required by /mnt/lib/libstdc++.so.6)

2) Not all dependencies should be shipped.

(click to show/hide)

When copying all dependencies that ldd shows, you will either get a similar GLIBC_PRIVATE error that I showed earlier or it will simply lead to a segfault (debugger says the crash happens in libc.so).

The following libraries could NOT be included with my application:
- libc.so.6
- libdl.so.2
- libGL.so.1
- libpthread.so.0
- libdbus-1.so.3
- libgcc_s.so.1
- libm.so.6
- libstdc++.so.6

A third problem might be 32bit vs 64bit, I didn't test with that but I doubt that my 64bit app will just run on a 32bit linux.

The following test program should run out of the box on anything newer than ubuntu 14.04 (only tested running on arch linux):
https://www.dropbox.com/s/jacna15uyttfwov/linux64-binary-test.tar.gz?dl=1

This is the code that I have in my cmake script to set the RPATH

Code: [Select]

set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_INSTALL_RPATH "$ORIGIN/lib/:$$ORIGIN/lib/")