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.

Topics - user31182

Pages: [1]
Graphics / sf::Text local bounds
« on: January 04, 2019, 08:58:17 pm »

Question about how to interpret the result of getLocalBounds() when called for an sf::Text object.

I've got 4 strings which I am calling getLocalBounds() on, and the results are:

[left, top, width, height]

[ 0, 3, 32, 8 ]
[ 0, 3, 35, 8 ]
[ 0, 3, 33, 8 ]
[ 0, 3, 122, 11 ]

The top variable is always 3. I would have expected it to be zero. What is the interpretation of this?


Graphics / SFML Drawing Hierarchies
« on: December 26, 2018, 01:16:42 pm »
I'm not really sure where to direct this question, so I guessed graphics as the most appropriate subforum.

I'm attempting to implement a kind of GUI toolkit for SFML. This project actually started some months ago now. I'm aware that such things already exist but I wanted a GUI library to do a specific thing which is why I started my own.

I put this project on hold and then had another idea for something else recently so I've started work on it again. I didn't actually get very far in the first place.

So far I have something like this:

1: A base class which inherits sf::Drawable. This class also adds an "event" function which events are passed to
2: Some gui objects, textbox, button, context menu, which inherit from the base class
3: Some of my gui objects are nested, ie; the context menu has context menu items

My question is about drawing these objects.

All the gui objects have a sf::RectangleShape which is used to draw the background of the object.

The override draw method calls

sf::RenderTarget target;

This is just to show the basic principle of how everything is going to work.

At the moment, for all my objects, I have a setPosition method which changes the sf::RectangleShape position.

For my example of context menu, which has a parent-child relationship in that several context menu items are children of the parent, I am unsure of how to proceed here.

One possibly solution is to use absolute positions, which is what sfml seems to want to use. In this way, if the position of the context menu is changed, then the positions of all the child items would also have to be changed.

This doesn't seem like a good solution, since I would prefer to store the relative locations of the child objects relative to the parent rather than the absolute position in the window.

Is there a better way of approaching this problem?

Window / Window (not resizable) - resizeing without create() & close()
« on: December 25, 2018, 11:41:47 pm »

Currently writing an app in SFML which loads an image from file and displays it.

I know I'm not doing something quite right as I get strange results. Allow me to explain the problem...

I open an SFML window, with a "default" videomode of 800x600.

The reason is that the user chooses the image to display so the VM resolution (size) is not known at start time and it is not constant during the runtime of the app.

... You can probably see where this is going, and guess what the problem is?

At some point during the app runtime the user chooses an image to display. If the image is smaller than 800 x 600, I want the (non-resizable) window to change size such that it crops itself to fit the image. To clarify, I have set sf::Style::Titlebar and sf::Style::Close to make the window "non-resizable".

First I tried to:

1: Load the image into a texture
2: Create sprite and set texture
3: Change window size to match the size given by the texture
4: Draw the sprite

I "cout" the texture size, the sprite global bounds, the sprite scale and the window size. They all agree except sprite scale which is 1.0.

However the image does not fill the window. It is smaller than the window.

My code is simple and I can provide it, but without an image to test it on (perhaps I can find one online which we can agree to all use?) it won't give the same results for everyone who runs the code...

Since this didn't work, my suspicions were that the video mode (which is larger than the texture size) was causing the issue.

In other words, the VM is 800 x 600, and the BMP image is 640 x 480... Therefore when I call window.resize(640, 480) a 800 x 600 VM is "mapped" onto a display area of 640 x 480... So obviously the bitmap will be scaled down by the same factor and it will appear smaller than 640 x 480.

This appears to be what is happening.

So the second thing I tried was:

1: Calling window.close()
2: Calling window.create() with a new VM which is the correct size (same size as sprite)

Since I was doing this in a loop it creates a flickering effect as the window is destroyed and re-made over and over.

I can sort of resolve this issue by checking to see if the window needs to be created again, rather than doing it each time... However this still causes a flickering when the "user image choice" is changed between different size images.

Is there a solution to this in SFML or would changing the VM without destroying the window require a new patch to SFML?

I assume the videomode has something to do with allocating memory for OpenGL somewhere? Is it possible for me to resize the "opengl surface" while also resizing the window?

Alternatively is this a bug in SFML?

General / How to fix the CPU hidden symbol linker error?
« on: August 03, 2016, 09:16:12 pm »
I understand there is a well known about error which occurs on ubuntu 16.04 systems when attempting to compile and link a C++ program with the SFML libraries. The linker error is:

hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-linux-gnu/5/libgcc.a(cpuinfo.o) is referenced by DSO

There is supposed to be a fix, see here: http://web.archive.org/web/20160509014317/https://gitlab.peach-bun.com/pinion/SFML/commit/3383b4a472f0bd16a8161fb8760cd3e6333f1782.patch

However I do not understand what I'm supposed to do using this information.

Currently I compile using the following command:

g++ --std=c++11 -Wall main.cpp -lsfml-graphics -lsfml-window -lsfml-system -o a.out

What should I do to fix this linker error?

PS: Sorry to start a new thread on this - I did bump an older thread but the fix there had something to do with cmake, and I'm not using a cmake system here.

Audio / Continuous Audio for Synthersys
« on: June 13, 2016, 02:02:13 pm »
Hi all,

I am trying to figure out a way to use the SFML toolkit in a real-time audio synthesis project. (As a kind of experiment, just for fun.)

SFML would be handy since I can use the RenderWindow etc to create a basic UI.

It appears to me that there are 2 methods I could use.

The first is with sf::Sound and sf::SoundBuffer.

The second is with sf::SoundStream.

Let us consider a program which plays a 440 Hz sin wave when I press a key, such as the Z key on my keyboard, otherwise silence is played.

Let us discuss the first, first.


I have two possible ideas here, although I don't think either will work particularly well. The first idea is to generate a buffer, say for 0.1 s of sound, fill it as the event loop is processed by checking the elapsed time and filling in that duration of sin wave or silence depending on whether the Z key is pressed. Then every time the event loop "goes over" a 0.1 s interval, play the new buffer contents and start generating a new buffer to play.

This method has a problem. Typically, there will be a delay between the thread which is playing the audio finishing playing samples, and a new call to sf::Sound.Play() to play the new buffer. In addition, the sound playing will always be delayed by 0.1 s. (Which is quite large, and results in a horrendous 0.1 s low frequency noise being added to the signal by the continual stop/starting.)

To reduce this problem, one could allocate enough memory for 30 s of audio, press the keys, and then hear the output 30 s later. Obviously the problem here is you are limited to 30 s of audio, and you can't hear what you're playing until afterwards.

The only resolution would be to detect when the playing thread has finished, and then immediately play some new buffer. This will reduce delays, but there will still be some, and I am unsure if this can be done... I think there may be a better way.


After attempting to implement the first method, and finding essentially that "it doesn't work very well", as you probably suspected, I did some more researching and found the sf::SoundStream object.

Is this the correct object to use for this task?

I have had a look at the VOIP example, but found this didn't really help much as there is a load of network stuff there which makes it difficult to decipher what is happening if one is not familiar with network programming.

After studying this example, I found a further problem which is that this example appears to work by recording sound samples on one PC and sending them to another. Hence it doesn't really matter too much if there is an associated delay. (I am not sure what this delay might be. I assume less than ~ 0.2 s, but it won't really matter for a phone conversation so long as it's not "too" large.)

Going back to sf::Soundstream, it is my understanding that I must overload the "onGetData" and "onSeek" functions in my own derived class.

What are these functions supposed to do, and how should I overload them? I assume the onGetData() function should "generate new samples", but how many? Where should I store these samples? How can I discard old samples which are no longer required? What if I want to simultaneously record a .wav file to media?

Finally, what does the "onSeek" function do? Why would I need to "seek" in an audio bitstream if I am writing something like a synthesizer?

Apologies for the long question, I tried to make it clear what I am asking.

By the way, I haven't actually asked the main question yet, which is; "is soundstream" the best method of implementing this? Is there another, better method? Perhaps I should be using another external library which is not SFML based at all?

Window / How thread safe is a sfml window?
« on: July 22, 2013, 06:21:14 pm »
I notice there is a section in the tutorials about threads and sfml.

The example is how to use a thread to render on a sfml window.

I presume that this is thread safe?

How safe would be event handling in the same loop?  I assume this must be safe, because events must be handled somewhere, whether this be in the main loop or the rendering loop.

This is a question about sfml generally, although I am mostly interested in OpenGL rendering and event processing. How thread safe are these things?

What sort of things are and are not thread safe. If something isn't thread safe, what is likely to be the best way of making it so? (Mutex, atomic operations, etc)

System / Why is there no thread.join() with SFML threads library?
« on: July 04, 2013, 02:06:45 pm »
I am working on a project with SFML, version 2, and I had been using std::thread for running some threads.

I am wondering why sf::thread does not require a join() function? And why is has a launch function whereas the standard library does not.

Also, since sfml is cross platform, what are the advantages and disadvantages between sf::thread and std::thread?

Apologies if this question has been answered before, the search isn't working at the moment. It displays an error message asking me to report the problem to an administrator. Hopefully and admin will see this, and then I will have done what the message told me to!

Pages: [1]