Topics

1

Graphics / Error when loading sf::Texture in another thread

« on: February 21, 2016, 04:23:05 pm »

Heya!

I am trying to load an sf::Texture in another thread. According to my googling etc, it seems to me like this should be allowed, as seen in both of these threads: http://en.sfml-dev.org/forums/index.php?topic=10452.0 http://en.sfml-dev.org/forums/index.php?topic=10344.0

So my first question is: Is it totally legit to load an sf::Texture in another thread?

Now, after seeing that it might indeed be allowed, I thought my code was the one that was broken, but then I tried the minimal example found in one of those threads, namely this:

#include <SFML/Graphics.hpp>

struct LoadTexture
{
    sf::Texture& texture ;
    bool & success ;
    std::string filename ;

    LoadTexture(sf::Texture& t, bool& s, const std::string& fname)
        : texture(t), success(s), filename(fname) {}

    void operator()()
        { success = texture.loadFromFile(filename) ; }
};

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "sf::Thread test");

    bool success = false ;
    sf::Texture green ;

    {
        sf::Thread thread(LoadTexture(green, success, "GreenTile.png")) ;
        thread.launch() ;
    }
//    success = green.loadFromFile("GreenTile.png") ;

    if ( !success )
        return 0 ;

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

        window.clear() ;
        window.draw(sf::Sprite(green)) ;
        window.display() ;
    }
}
 

This however exhibits the exact same problem.

The problem I get is a segfault. When backtracing it in GDB, I see the following:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeb013700 (LWP 20915)]
0x00007ffff697e80f in _int_malloc () from /usr/lib/libc.so.6
(gdb) ba
#0  0x00007ffff697e80f in _int_malloc () from /usr/lib/libc.so.6
#1  0x00007ffff69803d4 in malloc () from /usr/lib/libc.so.6
#2  0x00007ffff724b0e8 in operator new (sz=8) at /build/gcc-multilib/src/gcc-5.3.0/libstdc++-v3/libsupc++/new_op.cc:50
#3  0x00007ffff7548ce8 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#4  0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#5  0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
#6  0x00007ffff754768e in sf::Context::Context() () from /usr/local/lib/libsfml-window.so.2.3
#7  0x00007ffff7548cf3 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#8  0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#9  0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
#10 0x00007ffff754768e in sf::Context::Context() () from /usr/local/lib/libsfml-window.so.2.3
#11 0x00007ffff7548cf3 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#12 0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#13 0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
....
This goes on for thousands of stackframes
 

I am using self-compiled sfml 2.3 and I have tried building my application with both clang and gcc, same result.

Am I missing something obvious on what I need to do to make it possible to load sf::Textures in other threads, or is this not possible at all atm? In the other threads there was talk about a bug related to glFlush() but it seems to have been fixed years ago.

Any ideas appreciated, thanks.

2

SFML game jam / Competition style voting?

« on: June 13, 2014, 10:25:39 am »

Hello!

I want to raise a question that I don't think have been discussed yet. Should future game jams be voting/winner based?

What I mean by this is that all submissions are voted upon after the jam time is over. After the voting period is over, the results are shown and the one with the most votes win. Votes could be made on the basis of enjoyment when playing/theme relevance/concept or even possibly things like code neatness. This would of course be decided and made clear before the jam starts.

Personally I would like this. My arguments for this are:

• It would serve as a motivator to make the games more fun/polished. This is good since the final results could become a bit more attractive both for the participant to show others, and also for the SFML community to show outsiders.
• It would turn the current post-deadline anticlimax to an event with a resolution and a conclusion. The two last jams (this one especially with so few participants ) ended very anticlimactic imo. The results are in, and some people try them out, people talk a little bit about it and then that's it. A voting evaluation would make it feel more complete.
• It would create more incentive to provide builds for various platforms. This is related to the previous discussion on providing binaries. When you want to attract votes, it makes sense to make it playable for as many people as possible. The drawback with this argument though is that people who are not able to provide binaries for popular platforms might be at an unfair disadvantage. This is also irrelevant if there would be a build service provided for the jam entries.

All in all, I think it would be a fun idea and create a bit of "spirit"! For those of you who think that it would be too "serious" and too "competitive", keep in mind that the vote/competition part of it wouldn't necessarily have to be serious and something big. Just a fun addition. It would still mainly revolve around making games with SFML.

A possible drawback is that it creates more maintenance load on the arrangers since they have to also organise the voting and whatnot related, and at least this time around, time was of a concern for many people involved. However, I think that whoever decides to arrange the next jam, ought to make sure they have time for it, so then it could be okay.

What do others think?

3

Feature requests / Remove GLEW dependency in favour of glLoadGen

« on: March 22, 2014, 08:51:03 am »

Hello!

This is not purely a feature request, but more like a suggestion. I have no idea if it has been suggested before or not as the search function still doesn't work for me.

Anyhow, I stumbled upon this project called glLoadGen which can be used as a replacement for GLEW and similar libraries. It is not a library in itself, but merely a lua script which accepts parameters telling it which gl version is desired, and which extensions are to be used. Then it spits out a header/source pair which contains the desired functions/enums and they can directly be used in your project. No external linking nor runtime library loading required!

I thought this sounded pretty awesome so I tried it out in my own project and it was super easy to switch. It took me about 15 minutes. I just ran this:

lua LoadGen.lua -style=pointer_c -spec=gl -version=3.2 -profile=core core_3_2

Then I included those, and replaced the glewInit call with ogl_LoadFunctions and then included the generated header instead of glew. No sweat, blood nor tears.

The licensing of the script is MIT licence and I don't think there is any particular licence on the generated files. At least I couldn't find any info on it.

I thought this would fit SFML well since it aims to be simple for newbies, and we all know that newbies hate to deal with external libraries, linking errors and stuff like that, and glew can be pretty nasty on that front. SFML even had special hacky solutions to make this easy in the past, but with this, the dependency could perhaps be dropped entirely.

So is there anything that I have missed in my excitement about this approach? Has this been discussed before? Or is it indeed a good idea?

Let me know.

EDIT: here is a link
The licensing of the script is MIT licence and I don't think

4

Audio / Bug in the Audio Module with listeners?

« on: March 03, 2014, 08:10:57 am »

I hope this hasn't been discussed before, I couldn't search because I get an error every time I try (DATABASE ERROR Please try again. If you come back to this error screen, report the error to an administrator.).

Anyway, I am curious on this thing which might be a flaw in SFML.

It is regarding the function Listener::setDirection which is implemented like this:

void Listener::setDirection(float x, float y, float z)
{
    priv::ensureALInit();

    float orientation[] = {x, y, z, 0.f, 1.f, 0.f};
    alCheck(alListenerfv(AL_ORIENTATION, orientation));
}
 

Now, what it does is defining two vectors that are passed to OpenAL. The first vector (which is the one given by the user) is the "at" vector which is the direction the listener is facing in the scene. The second vector is the "up" vector which points to the upside relative to the listener. This can be thought of as having the "at" vector pointing out from your nose, and the "up" vector pointing up the top of your head.

Anyway, the function _always_ uses the (0, 1, 0) vector for up which to me looks like it poses a problem. Because the OpenAL specification states this about setting the orientation:

. OpenAL expects two vectors that are linearly
independent. These vectors are not expected to be normalized. If the two vectors are
linearly dependent, behavior is undefined.

The important bit being that they have to be linearly independent. However, with the implementation in SFML, if you would call setDirection(0.0f, 1.0f, 0.0f) or even setDirection(0.0f, 0.5f, 0.0f) etc, they would be linearly dependent and would according to the OpenAL specification cause undefined behaviour.

Is there something I am missing or is this just overlooked by SFML?

5

SFML projects / Feather Kit - A C++ Game Framework

« on: January 21, 2014, 04:36:01 pm »

Hello!

For the last year or so, I have been spending time developing a modular lightweight game framework for C++. I am posting this thread here as a first peek out into the public to hopefully get some user feedback and opinions on the library. It is a quite lengthy post, including a description of features. If you're uninterested in reading the features, skip to the "Live demos" part.

featherkit.therocode.net

I have developed this framework for my own use and for educational purposes, and my aspiration is that this library would turn into something useful for other people as well. During the past year I have added various components to the library at the same time as using it. It was even used by a few people in a private game jam LAN. So I feel that the library has reached a point where it would be beneficial to get more users into it, to let it mature more.

So, what is Feather Kit really?

As stated, it is a framework. It is not an engine. What I mean by that, is that it is not a tied-together system, a ready application to just stuff content into to make a game. Rather, it is a toolbox with various independent components that you can pick and select from to help you build your game. It contains no gluing code and it is up to every user to use the tools in the way he/she finds best. Following this philosophy, the amount of dependencies are kept to a bare minimum, to make as few assumptions about the user's system/platform as possible.

The general idea of these components is that they should deal with problems often encountered in game development and provide solutions for these in a clean, lightweight and object oriented way.

It is divided into independent modules. Here is a list of the current modules and some of their features.

Entity system
The entity system right now consists of a way to create and store entities along with an arbitrary number of attributes. Right now it only deals with entity data, not entity logic but some kind of component based logic system is planned. Entity templates can be created and loaded from JSON files.
Example on how to set and get attributes on an entity:

entity->setAttribute<glm::vec2>("velocity", glm::vec2(1.0f, 4.0f));
bool isScared = entity->getAttribute<bool>("isScared");
entity->addToAttribute<uint32_t>("health", 20);
 

Messaging
The messaging module contains a message bus, and a general message class. This lets various parts of your game communicate with each other without explicit dependencies. Built heavily on C++11 features such as variadic templates to provide a really clean messaging interface with almost no boilerplate code. Most dispatching logic is also handled compile time which makes for a really low runtime overhead. Read more here: http://blog.therocode.net/2013/09/messaging-using-variadic-templates/

Example on how to define a message:

struct EntityMoved_tag{};//                              id      position
using EntityMovedMessage = fea::Message<EntityMoved_tag, size_t, glm::vec2>;
 

Example on how to send a message:

messageBus.sendMessage(EntityMovedMessage(1337, glm::vec2(5.0f, 2.0f)));
 

Render2D
This module aims to be a complete tool to render 2D graphics for a game. It is build on raw OpenGL and in a sense it reinvents a lot of what SFML can do. I chose to write this part from scratch to be able to more easily take Feather Kit to more exotic platforms. Right now it contains sprite rendering with animated sprites, tile maps, text rendering, with an inheriting interface to add new drawables. It supports a camera and a viewport, blend modes and shaders. More features and some cleanup are planned.

Structure
A module dedicated to structuring the code base of your game. Contains a general application class which helps you take command line arguments and create a main loop. It also lets you compile to emscripten to run your game in the browser without having to tailor your code to work with the asynchronity of the web. There is also a game statemachine and a general tree class which can be used as a quadtree, octree or NTree.

User Interface
I wanted Feather Kit to not be strictly dependent on any sub-system. So this module is mostly about reinventing a window class and an input handler. It does not however implement it from the bottom up. Instead it uses a backend approach where it translates the window/input things from the underlying backend to a more general Feather Kit format. That way you can by changing about 4 lines of code make your game run on SFML instead of SDL or any other platform which has a backend implemented for it. Furthermore it also implements an action handler where you can bind raw input to actions, and store that configuration to file.

So that's all modules there are for now, but planned modules (that will be added Some Day™) include a resource manager, audio, 3D rendering and networking.

I have also made the effort to make Feather Kit work out of the box with Emscripten. Emscripten lets you compile C++ code into javascript for direct deployment on the web.

Live demos

Alright, congratulations if you read this far, haha. Here are a few examples of what you can create without that much effort with the help of Feather Kit. They are all built for the web using Emscripten and if you have a reasonably new browser they should work.

Interactive textures: http://featherkit.therocode.net/wip/ (steer with WSAD)
Tilemap, actions, animations and lights: http://pallkars.net/~zagabar/bladepit/ (steer with WSAD and click the mouse to fire)
Tilemap and animations: http://featherkit.therocode.net/tutorials/tilesanimationexample.html (press space to get past the first screen)

End section

That is pretty much it. I would be very happy to get some feedback so you are very welcome to test it out if you have time. There is documentation and tutorials (more will be written) on the website. If you need help getting started or have general feedback or feature requests, there is an official forum and an IRC channel. Everything can be found on the website.

Keep in mind that the library is still very new, and has not received user feedback or haven't been used that much so a few quirks and bugs could exists, but I'll do my best to fix them as soon as possible. I also aim to be open for criticism and take all suggestions open mindedly to make this library as good as possible.

Thanks for reading!

6

General / FindSFML.cmake broken with mingw?

« on: August 01, 2013, 01:24:33 am »

Hello!

I am having issues with the FindSFML.cmake and i am not sure if it is me doing something wrong or the file itself not working. I want to link to SFML in my project, on both windows and linux. On linux it works fine, but on windows it fails (using mingw).

In the CMakeLists.txt I use the following to find SFML:

find_package(SFML 2 COMPONENTS window system REQUIRED)

This works fine on linux, but on windows i get the following error:

Could NOT find SFML (missing: SFML_WINDOW_LIBRARY SFML_SYSTEM_LIBRARY)

I built SFML from the source using mingw with the default settings, followed by a "make install" which installed SFML to the default location in programs (x86).

Despite this, i managed to get it to run by calling:
find_package(SFML REQUIRED)
include_directories("${SFML_INCLUDE_DIR}")
link_directories("${SFML_INCLUDE_DIR}/../lib")
...and then linking to the libs manually (i.e. sfml-window sfml-graphics etc)

So even if it works, it seems to me like it isn't the way it should be. Any ideas on something i am doing wrong, or is this actually an issue with the find module?

Thanks.

7

Feature requests / Nacl support

« on: May 10, 2012, 09:56:22 am »

Hey!

I think it would be awesome if SFML was ported to work on NaCl. Google's Native Client technology. This is a framework that makes it possible to compile and run native C/C++ code directy as an applicaton in the browser, with openGL ES 2.0 rendering. The only browser that supports it as of now is chrome, however they aim to have more browsers implementing it.

It handles window creation, getting an openGL context and events (key, mouse, gamepad) so I suppose one would have to make a bridge between their API that provides such (the pepper API) and SFML as well as have SFML use openGL ES. The rest shouldn't need much work.

As I have myself worked a bit with NaCl I'd gladly aid the porting procedure should it be decided to be done. I suppose it would have to wait for the openGL ES porting too.

But I strongly suggest that this is considered since it would mean that applications written in sfml could with a very little effort be deployed over the web as applications. Google has shown a quake port to native client and they claim the performance loss is only about 5%-10%.

What do you think?

8

Graphics / Proper ways of handling GL states with mixed rendering

« on: March 20, 2012, 03:53:03 pm »

When using sfml with mixed rendering, as in you have your own implemented openGL rendering which happens before or/and after calls to the sfml draw() method, it might often mess things up. For instance I know many people who use sfml to handle events/creating a window and drawing text while taking care of the rest of the rendering by themselves. Most if not all of those people have run into problems with the text not displaying properly, or their own rendering breaking after trying to draw text. I myself too have had problems with this. Apparently this is due to openGL states becoming changed and not reset by the draw method.

This seems to me as a quite big limitation when you want to use sfml in any project which needs any form of rendering which is not able to do with the sfml shapes/sprites classes and this is not a rare case. Even now, knowing this problem I still don't know how to handle it properly; which states to set before and after the draw method and it is often frustrating to solve.

What is the thought behind this behaviour and is it fixable? Perhaps it is intended even? To me it would make sense that sfml would set the things it needs for rendering, and then reset it back to the states they had to not conflict with other components. If this would add too much of an overhead, perhaps the RenderWindow could have a flag for it? Or as the very least, would this be documented so that the users would properly know which states they should themselves reset after calling the sfml draw method? It is a way too common problem.