Topics

16

General discussions / sf::Shader -- API to set uniforms

« on: March 29, 2014, 05:36:02 pm »

Hello,

Several times in the past it has been requested that sf::Shader support more setParameter() overloads, in order to be able to specify other GLSL uniform types.

We recently opened issue #538, where we started to discuss about a possible API to possibly support one or more the following GLSL types:

• 4x4 matrices (const float[16])
• 3x3 matrices (const float[9])
• signed and unsigned integers
• booleans
• arrays

The straightforward approach would be the addition of further setParameter() overloads. This has the problem that for some types there are ambiguities (e.g. float[9] and float[16] are the same types in parameter lists), so we would have to introduce wrappers. Also, the code may not be very expressive, as you can't infer from the function name which type is modified -- the question is, whether the polymorphism provided by overloads is an advantage or not. I think it is, see below.

Another idea is to provide named functions such as setFloat(), setMatrix3x3() and so on. This looks nice and expressive at first, but it comes with the drawback that it makes generic code more difficult. In particular, if we want to provide support for GLSL arrays (which can consist of almost any GLSL type), we effectively have to duplicate all the existing functions, which is of course not ideal.

That's why I personally tend to be in favor of further setParameter() overloads, combined with new types to clearly distinguish the parameters. A function template setParameterArray() or similar could be used to set a uniform array, and deduce from the parameter type which GLSL type is being set. This would avoid a large part of the code duplication.

Generic code also makes it significantly easier for SFML or an extension library to provide support for higher-level data (i.e. GLSL structs), and possibly other types like NxM matrices.

What do you think? Are there other ideas? If you are interested, consider also reading the discussion on GitHub.

17

SFML projects / C++ and Game Development Articles

« on: January 23, 2014, 02:03:06 pm »

Hello

Once I'm not writing about a library or a game. On my homepage, I added an Articles section which I use to write about a few topics related to C++ and Game Development. I will probably focus on the C++ part, but I have no concrete plans yet.

The articles won't appear in a regular fashion, it's not a blog with monthly or weekly updates. I'm writing them when I find time and a good topic to investigate, and I personally like this approach more than an enforced schedule where quality might suffer. I'm also open for suggestions, and I might improve the articles over time.

Anyway, the first article is about RAII, my favorite topic
Since this topic appears again and again on the forum and there are so many people doing memory management wrong, I tried to come up with a summary about the whole topic and a detailed analysis of its advantages, as well as an investigation of all the counter-arguments. The article is an extension of the post Why RAII rocks that I started. This thread is a nice example of a discussion about RAII, and I tried to extract the arguments of both sides and confront them with each other, creating an overview about the whole issue. Thanks to all the people who contributed in that and other discussions, you've really helped to gather good points. I hope the article helps us in the future, so that we might refer to it instead of repeating the same arguments again and again.

Links:

• Article site: www.bromeon.ch/articles/
• First article: www.bromeon.ch/articles/raii.html

18

General discussions / GLFW 3

« on: July 13, 2013, 05:08:34 pm »

Hello

I just saw that GLFW 3 was released a few weeks ago, it is quite different from earlier versions. Have you ever considered using it or parts of it for SFML? It provides a lot of features you currently use or you might add in the future:

• OpenGL and OpenGL ES context creation
• Very sophisticated window management
• Input handling: Keyboard, mouse, joystick (might solve the keyboard issue)
• Support for multiple monitors
• Clipboard text support
• High-resolution timer

It would mean another dependency, but you could drastically reduce your code and wouldn't need to reinvent the wheel. Also, GLFW is a pretty lightweight C library.

On the other hand, I might imagine that over the years, you have found specific workarounds and code to handle functionality uniformly across operating systems. There might also be crucial features it does not provide. Anyway, just wanted to bring this into discussion, no need to decide soon

19

Graphics / OpenGL FBO rendering - when to call glFlush()

« on: June 05, 2013, 09:38:53 am »

This question is not directly related to SFML, more to OpenGL.

If I have two FBOs and switch them alternately to render with a shader multiple times, do I need to call glFlush() before each switching to be sure that everything is rendered before the texture is read again? Because when I omit it, it seems like the data is not ready yet. I also noticed that sf::RenderTexture::display() calls glFlush().

The problem is, flushing the whole OpenGL pipeline is terribly slow. Can't multipass shaders be applied without flushing?

20

Network / How can sf::Packet fail?

« on: April 04, 2013, 11:27:55 am »

The sf::Packet operators << and >> return a reference to the packet and thus allow to test it for validity. Assume that the socket's receive() function is tested for sf::Socket::Done, therefore the transmission itself is successful.

For the sf::Packet::operator>>, are logic errors (bugs) the only way it can fail -- when received data is not interpreted the way it has been sent? So we don't need to check the packet in a correctly-written program?

And in which cases can sf::Packet::operator<< fail?

Are there any differences with respect to sf::Packet validity for TCP and UDP? To which extent can UDP datagrams be corrupted at the level of SFML? Again, we assume that receive() returned sf::Socket::Done.

21

Audio / Correct Y audition

« on: March 27, 2013, 11:42:03 pm »

The listener's up vector is hardcoded to +Y, and the direction is -Z by default.

When comparing with the head of a user, we get the following right-handed coordinate system:

• Y: up
• Z: out of the screen, towards user
• X = Y×Z: right

The 2D graphical coordinate system (the screen's plane in 3D) is however as follows:

• X: right
• Y: down

Normal headphones cannot differentiate heights (only left/right). But to align correctly with graphics coordinates, shouldn't the listener's up vector actually be in -Y direction?

If I emit a sound on the screen, do I have to flip the Y difference between sound and listener in order to have a correct height audition?

22

SFML website / Promote SFML 2 instead of SFML 1.6

« on: January 16, 2013, 10:11:36 am »

Hi,

Almost every newcomer begins to use SFML 1.6, because it is declared as "current version" on the website, and they get the impression that SFML 2 is unfinished or beta, although much more mature than 1.6. Guys like eXpl0it3r have to argument in every second post why SFML 2 is better and should be used instead. I actually agree with him, and also often advise people to switch.

The website should really be changed accordingly. I know you will do it anyway when SFML 2 is released, but since we don't know exactly when this is going to happen, it may be better to promote SFML 2 RC already. We also avoid that people who begin now with SFML have to port everything as soon as they have learned the basics.

I am also aware that SFML 2 RC isn't complete regarding the tutorials, yet this should be outweighed by SFML 2's advantages. Using the SFML 2 doc, examples and 1.6 tutorials, most parts can still be learned reasonably. Otherwise, there is still the forum to ask.

23

Window / KeyPressed and KeyReleased events fire twice on Linux

« on: January 02, 2013, 01:59:08 pm »

Sometimes when I release a key, 3 events are fired: KeyReleased, KeyPressed and KeyReleased in this order. I could reproduce the problem on Ubuntu 12.04 LTS, on Windows it doesn't seem to appear. I use the Git revision dd48427.

Small and complete example:

#include <SFML/Window.hpp>
#include <iostream>

int main()
{
        sf::Window window(sf::VideoMode(640, 480), "SFML Test");
        window.setKeyRepeatEnabled(false);
       
        sf::Clock clock;
       
        int i = 0;
        for (;;)
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        switch (event.type)
                        {
                                case sf::Event::Closed:
                                        return 0;
                                       
                                case sf::Event::KeyPressed:
                                        if (event.key.code == sf::Keyboard::F)
                                                std::cout << ++i << "\tPressed \t"
                                                << clock.getElapsedTime().asMilliseconds() << std::endl;
                                        break;
                                       
                                case sf::Event::KeyReleased:
                                        if (event.key.code == sf::Keyboard::F)
                                                std::cout << "\tReleased\t"
                                                << clock.getElapsedTime().asMilliseconds() << std::endl;
                                        break;
                        }
                }
               
                window.display();
        }
}

Output (this was luck, sometimes you need really long until the bug appears). You see the problem at the 6th release event.

1       Pressed         3583
        Released        4355
2       Pressed         5262
        Released        6740
3       Pressed         7244
        Released        8220
4       Pressed         8782
        Released        9740
5       Pressed         10222
        Released        11339
6       Pressed         11781
        Released        13100
7       Pressed         13100
        Released        13100
8       Pressed         13650
        Released        14547

24

General / Random access iteration benchmark

« on: December 25, 2012, 01:05:48 pm »

Continued from http://en.sfml-dev.org/forums/index.php?topic=10046.msg69235#msg69235

I have written a benchmark to compare iteration through random access containers. The code is rather complex, because I tried to make the comparison as fair as possible. Every iteration is executed multiple times, and the different iterations are executed in random order to reduce uneven conditions.

Comparison
Iterations: iterator, operator[]
Containers: std::vector, std::deque
Element types: int, std::string

Code

#include <SFML/System/Clock.hpp>
#include <iostream>
#include <iomanip>
#include <string>
#include <vector>
#include <deque>
#include <map>
#include <array>
#include <functional>
#include <algorithm>
#include <cstdlib>

inline void compute(int& v)         { v = (v + 25) % 13; }
inline void compute(std::string& v) { v = "x"; }

template <typename Container>
sf::Time testIterator(Container& c)
{
        sf::Clock clock;
        for (auto itr = c.begin(), end = c.end(); itr != end; ++itr)
                compute(*itr);

        return clock.getElapsedTime();
}

template <typename Container>
sf::Time testIndex(Container& c)
{
        sf::Clock clock;
        for (std::size_t i = 0, size = c.size(); i != size; ++i)
                compute(c[i]);

        return clock.getElapsedTime();
}

template <typename T>
void benchmark(std::map<std::string, sf::Time>& times, const std::string& type, std::size_t elements)
{
        std::vector<T> vector(elements);
        std::deque<T> deque(elements);

        std::array<std::function<void()>, 4> array =
        {
                [&] () { times["vector<" + type + ">  iterator"] += testIterator(vector); },
                [&] () { times[" deque<" + type + ">  iterator"] += testIterator(deque);  },
                [&] () { times["vector<" + type + ">  index   "] += testIndex(vector);    },
                [&] () { times[" deque<" + type + ">  index   "] += testIndex(deque);     },
        };
       
        // Make sure the single tests are executed in random order
        std::random_shuffle(array.begin(), array.end());
        std::for_each(array.begin(), array.end(), [] (std::function<void()>& fn) { fn(); });

        // Prevent optimization of unused containers
        if (std::rand() < 0)
                std::cout << vector[std::rand() % vector.size()] << deque[std::rand() % deque.size()];
}

int main()
{
        std::map<std::string, sf::Time> times;

        const std::size_t outer = 10000;
        const std::size_t inner = 100000;
        for (std::size_t m = 0; m < outer; ++m)
        {
                benchmark<int>        (times, "int   ", inner);
                benchmark<std::string>(times, "string", inner);
        }

        for (auto itr = times.begin(); itr != times.end(); ++itr)
                std::cout << itr->first << " " << std::setw(6) << std::right << itr->second.asMilliseconds() << "\n";

        std::cin.get();
}

Results
VC++ 10, Release mode, without debugger, NDEBUG defined

 deque<int   >  index     10779
 deque<int   >  iterator   4884
 deque<string>  index     20268
 deque<string>  iterator  14991
vector<int   >  index      4711
vector<int   >  iterator   4764
vector<string>  index     13953
vector<string>  iterator  13459

g++ 4.6.2 (MinGW), -std=c++0x -O2 -DNDEBUG

 deque<int   >  index      5456
 deque<int   >  iterator   4914
 deque<string>  index     45758
 deque<string>  iterator  42905
vector<int   >  index      4896
vector<int   >  iterator   4908
vector<string>  index     42874
vector<string>  iterator  42547

Conclusions
For std::vector, both index operator and iterator take more or less the same execution time.
For std::deque, iterator is a clear winner, especially on VC++.

Tell me when you see any flaws in the code or the compiler flags. Of course, the rather simple operations in the loop are not representative of every possible iteration use case. However, the more complex the loop body becomes, the more time it takes to execute, while iteration itself becomes more negligible.

Since iterators are not slower, I suggest to follow the simple rule:
Use iterators when you iterate and index operator when you need random access.

25

SFML website / Slow and aborted loading of forum pages

« on: November 10, 2012, 10:10:09 am »

Recently, the loading of SFML forum pages is often slow. With both IE 9 and Firefox 16, pages sometimes take 10 seconds or more to load. With IE, it happens often that an action (like post/edit) is not sent at all -- the loading aborts after some seconds.

I don't know why this happens, if it's just my configuration, but it only happens since a few weeks. Has anyone experienced similar issues?

26

General discussions / Why RAII rocks

« on: October 09, 2012, 07:22:06 am »

This post continues the discussion from a project thread.

In order to get an overview of the topic, have a look at my article about RAII. The article gathers all the arguments and counter-arguments from this thread, and investigates the fundamental problem of memory management in a detailed manner.

Yes there is; stack vs. heap. You're limited on stack space.

You can use the heap (or freestore) without manual memory management, take a look at the RAII idiom.

new and delete cause headaches even if used correctly, just try to implement a function with several dynamic allocations and multiple return paths/exceptions.

27

General discussions / sf::Font incomplete loading

« on: October 06, 2012, 01:37:25 pm »

According to the documentation, sf::Font is not loaded completely in loadFromMemory() and loadFromStream(), I remember you saying that glyphs are loaded on demand. I think the same applies to loadFromFile(), so I would state in the doc that SFML requires read access to the file throughout the font's lifetime.

Furthermore, wouldn't it be more consistent with respect to sf::Music, if the functions were called open...() instead of load...()? Like this, the semantics are directly visible.

28

General discussions / Origins: Coordinates vs. fractions

« on: September 08, 2012, 04:41:53 pm »

Hi, I would like to discuss something that just came to my mind. In SFML, the origins of graphical objects -- accessed with sf::Transformable::setOrigin() and sf::Transformable::getOrigin() -- are stored as coordinates in the local coordinate system, with same scale (but different origin) as the global coordinate system.

Have you ever considered a fractional approach instead? That is, origins that lie inside the object have values in [0, 1]. To get the coordinates, the origins are multiplied with the object size (retrieved via getLocalBounds()). I know this doesn't perfectly fit into the current sf::Transformable API, since size is not part of it, but it's more a general consideration.

The advantage of fractional values is the consequence that a texture's (or generally object's) size and origin become orthogonal properties, one doesn't depend on the other. Thus, it becomes very easy to express proportions. For example, a centered origin would be (0.5, 0.5), the right-upper corner would be (1, 0). On the downside, absolute distances are more difficult to express, like "10 pixels past the right border". But they depend already now on the local rect, one cannot make them orthogonal properties anyway.

29

Graphics / Tight shapes have incorrect outlines

« on: August 10, 2012, 09:45:16 pm »

If a convex SFML shape covers a very small area, the edges are drawn outside the shape. I don't know whether this is an OpenGL limitation or a bug internal to SFML.

Minimal and complete example:

#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow window(sf::VideoMode(640, 480), "SFML Shape Bug");

        sf::ConvexShape shape(3);
        shape.setPoint(0, sf::Vector2f(0.f, 0.f));
        shape.setPoint(1, sf::Vector2f(0.1f, 100.f));
        shape.setPoint(2, sf::Vector2f(0.f, 200.f));

        shape.setPosition(100.f, 100.f);
        shape.setFillColor(sf::Color::Transparent);
        shape.setOutlineThickness(1.f);
        shape.setOutlineColor(sf::Color::Yellow);

        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::KeyPressed || event.type == sf::Event::Closed)
                                return 0;
                }

                window.clear();
                window.draw(shape);
                window.display();
        }
}

30

General / FindSFML: Order of components is important

« on: July 07, 2012, 09:13:33 am »

When one wants to find SFML to build it with g++, it is necessary to specify the SFML components in the right order. That is, libraries depending on others precede them.

I suggest to change the example given in FindSFML.cmake:

Code: [Select]

find_package(SFML COMPONENTS system window graphics)and to write

Code: [Select]

find_package(SFML COMPONENTS graphics window system)instead. You should also emphasize the issue with g++.

See also this thread.