Messages

1

Graphics / Re: SFML 2.1 (Linux/Ubuntu 14.04) Program crashes when allocating sf::Font on heap

« on: September 13, 2014, 11:44:28 am »

Alright so the problem is fixed, but the problem was not on my side it seems. I had compiled the latest version of SFML, straight from the repo. But I now downloaded the source of the stable 2.1 version, compiled it and rebuilt my program and now it works just fine.

2

Graphics / SFML 2.1 (Linux/Ubuntu 14.04) Program crashes when allocating sf::Font on heap

« on: September 12, 2014, 12:52:55 pm »

So I'm trying to create a small resource managing class where I simply map filepaths to textures/fonts. But when I started testing my resource manager by loading fonts into sf::Text objects things started crashing, a lot. So before I write too much text I'll just give you a minimal example of what works and what does not.

                sf::RenderWindow m_window(sf::VideoMode(800, 600), "Test");

                std::unique_ptr<sf::Font> font = std::unique_ptr<sf::Font>(new sf::Font());

                if(!font->loadFromFile("a_font.ttf"))              // This line causes a crash, see below for output
                        std::cout << "ERROR" << std::endl;

                sf::Text text;
                text.setFont(*font);
                text.setString("Test");
                text.setCharacterSize(24);
                text.setColor(sf::Color::Red);

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

                        m_window.clear();
                        m_window.draw(text);
                        m_window.display();
                }
 

Which gives the error

*** Error in `/gameBinaryDirectoryPathIsHere/': malloc(): memory corruption: 0x000000000062a470 ***
 

And a GDB backtrace

#0  0x00007ffff6ec8bb9 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff6ecbfc8 in __GI_abort () at abort.c:89
#2  0x00007ffff6f05e14 in __libc_message (do_abort=1,
    fmt=fmt@entry=0x7ffff7014668 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff6f139b6 in malloc_printerr (ptr=0x62a470,
    str=0x7ffff70107da "malloc(): memory corruption", action=<optimized out>)
    at malloc.c:4996
#4  _int_malloc (av=0x7ffff7251760 <main_arena>, bytes=392) at malloc.c:3447
#5  0x00007ffff6f15230 in __GI___libc_malloc (bytes=392) at malloc.c:2891
#6  0x00007ffff6643aa0 in ft_mem_qalloc ()
   from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#7  0x00007ffff6643ae8 in ft_mem_alloc () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#8  0x00007ffff664482e in FT_New_Library ()
   from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#9  0x00007ffff663f5c4 in FT_Init_FreeType ()
   from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#10 0x00007ffff7ba727f in sf::Font::loadFromFile(std::string const&) ()

 

In my real code I use a std::unordered_map<std::string, std::unique_ptr<sf::Font> > but the results here are the same. So then you might think "Why not put the resources on the stack, since STL map's doesn't invalidate its elements", and then we get this:

                std::unordered_map<std::string, sf::Font> fontMap;
                sf::Font font;

                if(!font.loadFromFile("assets/a_font.ttf"))
                        std::cout << "ERROR" << std::endl;

                fontMap["assets/a_font.ttf"] = font;

                sf::Text text;
                text.setFont(fontMap["assets/a_font.ttf"]);
                text.setString("Test");
                text.setCharacterSize(24);
                text.setColor(sf::Color::Red);

                while (m_window.isOpen())
                {
                        sf::Event event;
                        while (m_window.pollEvent(event))
                        {
                                if (event.type == sf::Event::Closed)
                                        m_window.close();
                        }
                        m_window.clear();
                        m_window.draw(text);
                        m_window.display();
                }
 

Which appears to run "fine", window opens and stays open, yet there's no text displaying. And when I close the window I get a segfault which doesn't say much (in gdb) other than pointing to the destruction of the std::unordered_map. Although in this case I'd rather have my resources on the heap since (in my opinion) it makes management/usage of them easier.

Finally, the below example works just fine to have some sort of reference:

                sf::Font font;

                if(!font.loadFromFile("assets/a_font.ttf"))
                        std::cout << "ERROR" << std::endl;

                sf::Text text;
                text.setFont(font);
                text.setString("Test");
                text.setCharacterSize(24);
                text.setColor(sf::Color::Red);

                while (m_window.isOpen())
                {
                        sf::Event event;
                        while (m_window.pollEvent(event))
                        {
                                if (event.type == sf::Event::Closed)
                                        m_window.close();
                        }
                        m_window.clear();
                        m_window.draw(text);
                        m_window.display();
                }
 

3

General / Re: Why does SFML provide multiple header files for some dependencies?

« on: June 24, 2014, 09:10:37 pm »

Dependencies headers need ot be distributed only for people who want to recompile your library, not for the end users (just in case it was not clear).

Some cross-platform libraries handle platform-specific differences in their build system rather than preprocessor tests in their code. For example, they use CMake, autotools, scons or any other meta-build system, to configure their sources and adapt them to the target platform. That's why there can exist several versions of the headers of a given library.

OpenGL headers are shipped with your compiler (on Windows), that's why SFML doesn't provide them.

Ah I see. I just took another look at the source of libsndfile and they are indeed using autoconf and a .h.in file which will generate different header files depending on the platform so thanks for clearing that up.

But do libraries mention this at any point, or do you have to dig through the source to find out whether or not you're fine with one version (for all platforms) of the header files?

4

General / Re: Why does SFML provide multiple header files for some dependencies?

« on: June 24, 2014, 08:25:42 pm »

Do those "other dependencies" overlap with SFML's dependencies?
If not, then I don't see the problem.
If there is overlap, then I still don't really see the problem, since you include some SFML headers and link dynamically and then also include some header from a dependency and link dynamically. The headers shouldn't conflict if it's the same underlying library and the runtime linker will sort out the dynamic libraries.
Unless you want to use two different versions of a shared dependency I don't see how there would be much of a concern.
Is there a specific problem that you are having?

I think you've missunderstood my question. I'm not having any problems with SFML or dependencies, I'm just interested in knowing how to go about when packacking external dependencies with your projects so that other users (on different platforms) may use it as well. Which is why things such as platform-specific header files for some the libraries SFML use confuses me since I would expect that a single header file with #ifdefs would be enough. Also the example with OpenGL to which no headers nor library files are included, why is that the case?

5

General / Re: Why does SFML provide multiple header files for some dependencies?

« on: June 24, 2014, 08:05:36 pm »

I'm wondering why, if you are using SFML, you worry about underlying dependencies like libsndfile at all..?
Isn't the whole point (or at least a large part of it) that you include the SFML headers only and don't worry about the underlying dependencies?

Because I have dependencies other than SFML and I'm wondering how I should include those with the project.

6

General / Why does SFML provide multiple header files for some dependencies?

« on: June 24, 2014, 07:50:32 pm »

I'm in the process of developing a  little engine project of my own and got some questions regarding how to package the code base in order for it to be used by others (such as SFML). My understanding is that you provide the header files for the dependencies, which is platform-independent as there (should) be #ifdef's and similar depending on the platform it is compiled on. Then platform-specific library files (.dll, .framework, .lib and whatnot) are provided which is what the project will link against. On Linux platforms neither headers nor library files are provided since they might vary between distros and it's better to just use the versions that the distro repos provide.

But as I'm going through the SFML extlibs/headers folder I've noticed that platform specific header files are provided for libsndfile and libfreetype, why is that the case? Shouldn't a library that is cross-platform take care of this in a single header file using #ifdefs or similar? I've also noticed that no OpenGL headers are provided, I assume that the lack of them means that the header files are different depending on both graphics drivers and operating system. As otherwise couldn't they just be packaged per-platform like libsndfile (still don't understand why this is the case though)?

Anyone that could help bring me some clarification on this issue? Even though it might not be super specific to SFML itself.

7

General / Re: Why doesn't SFML use ALuint to identify sources/buffers?

« on: June 04, 2014, 03:16:11 pm »

It would be unsafe if you compiled on an exotic platform, where the chosen native type wouldn't match the specification. This is very unlikely to happen, unless you're doing very specific stuff, so you can consider that it is always safe. That's what I do, and I've never heard anyone reporting problems with that in 7 years of SFML.

So with the example of unsigned ints, you're assuming no one is compiling on a platform on which sizeof(unsigned int) != sizeof(GLuint)   or ALuint for that matter.  Or in the event that somebody does, hope that it doesn't cause any issues?

A quick google gives http://stackoverflow.com/questions/12285502/do-i-have-to-use-opengls-datatypes-glint-clchar-for-a-cross-platform-ga and http://stackoverflow.com/questions/8932912/whats-the-advantage-of-using-gluint-instead-of-unsigned-int both of which makes it sound like differences in native type sizes aren't that uncommon.

But to wrap this up, seeing how I already use C++11 should I be using the fixed size types that the std provides if I want to stay clear of "possible" buggy behaviour. Or should I stick to using API defined types in the .cpp files where their usage doesn't add dependencies or hurt the overall codebase, and native types in publicy exposed header files where I need to store identifiers/similar to things in external API's/specifications/libraries?

8

General / Re: Why doesn't SFML use ALuint to identify sources/buffers?

« on: June 04, 2014, 02:42:15 pm »

Whether it is safe or not depends on what you do with it.

This is what I'm having trouble understanding, what operations would be considered "Unsafe"? Since I regularly see projects passing native types to OpenAL/GL but I can't really see any pattern for "safe usage" other than native types are used where an API defined type can't be used without creating dependencies (a header file included by the client). I realize this may not really be too specific to SFML anymore but think you'd be able to give me an idea of when usage of native types in OpenAL/GL functions is considered safe/okay?

9

General / Re: Why doesn't SFML use ALuint to identify sources/buffers?

« on: June 04, 2014, 08:44:58 am »

Use the API's types as much as you can. But if, like SFML, you can't expose these types in public headers (because you don't want to expose GL / AL headers to the user), then replacing them with their native equivalent is the only choice you have.

To know whether it is safe or not, you have to look at the definition of the type. Since OpenGL and OpenAL are specifications, not libraries, you have to look at the spec documents. For OpenGL, types are defined by a fixed size and a description. So theoretically it would be safer to use sf::Uint32 for GLuint, for example. In practice this is not a problem, as long as you're playing with "common" processors.

Ah well that makes sense. And going by http://www.openal.org/documentation/openal-1.1-specification.pdf would mean that ALuint and GLuint are equal, thus anything representing an unsigned 32-bit integer would be safe to use I assume?

Also, "then replacing them with their native equivalent is the only choice you have". With the example of OpenAL sources/buffers, wouldn't that be unsafe if "unsigned int" on that platform isn't an unsigned 32-bit integer?

Finally, how I tend to see it at the moment I use native types (if I can't use the API  types) in an API function if the function wants the values passed by value, seeing how as far as I know whatever values I pass will get converted to the type of that parameter (presumably an API type). Whereas functions wanting a pointer, such as alGenSources or glGenBuffers is where you should use the API defined types since you're giving the API a value which it expects to be exatcly of X bits size. Would this be a fair/logical assumption?

10

General / Why doesn't SFML use ALuint to identify sources/buffers?

« on: June 04, 2014, 07:48:37 am »

Just something that struck me while looking through the SFML source since it's an issue I'm currently having. I find myself trying to wrap API defined types in small classes in order to hide OpenAL dependencies which I feel will get out of hand when I get to writing OpenGL code. But SFML just uses a pointer to a regular unsigned int where the  OpenAL API expects an ALuint pointer, would this be safe on all platforms?

Just to get another idea of what I'm confused about; I have a Color class with floats as each of its components that I'm using to set the OpenGL clear color. Would this be safe since glClearColor expects GLfloat's and not regular float's? The general question is that I'm wondering how much I have to use the types defined by an API since it seems that SFML doesn't use them with every function call to the API using the types.

11

General / Re: How does SFML resolve dependencies?

« on: May 02, 2014, 10:33:43 am »

SFML never exposes any OpenAL in the headers so you don't need to include and link OpenAL yourself.
When compiling a program with SFML Audio you never compile or link any code from OpenAL directly.
Your library probably has some headers that include or call OpenAL which is why it tries to look for the headers and symbols from it.

Ah yes, I looked into the SFML source again and noticed how it forward declared usage of internal dependencies. I believe this is known as the pImpl idiom or opaque pointer idiom, so I'll be researching those next. Thanks for the help!

12

General / How does SFML resolve dependencies?

« on: May 02, 2014, 01:44:18 am »

I'm currently developing a little library of my own, which uses OpenAL (amongst others) like SFML. So when I compile my library I dynamically link against the OpenAL Soft .so file and create my own .so file, no problems.

But when I create a test program and link against only my own library, and include the headers of my own library; it doesn't work. Undefined symbols to OpenAL as well as it not finding its headers. (It works when I manually add these to the compilation settings of the test program; linking and including OpenAL).

However using SFML audio would only require you to link to the SFML modules, such as sfml-audio, and not manually adding OpenAL to the linking settings. So I assume SFML automatically links the dependencies it has when you link against it in your program, but how is this achieved? I've looked into libtool, pkg-config, ld options and whatever things google might suggest without much success.

So I thought I'd finally ask here to see how you do it, since I can seem to figure it out on my own :/

13

General / Re: [C++] Compiling SFML under Windows 7 with MinGW throws errors

« on: April 19, 2013, 10:45:30 am »

Try to generate your build files in a path which doesn't contain special characters (like 'ö').

Indeed, I just looked over the error and noticed the lack of "ö"'s in the path. I'm pretty sure this is the error, I just tried redownloading the SFML source and CMake as exploit3r suggested, but I'll try changing the path now which should hopefully fix it, I'll make an edit to this post if it works.

EDIT: SUCCESS!

14

General / Re: [C++] Compiling SFML under Windows 7 with MinGW throws errors

« on: April 19, 2013, 10:10:58 am »

Are you sure that the CMake configuration step succeeded? Have you tried to restart from scratch?

Yes, I'm pretty sure the CMake succeeded, and yes I have tried redoing it all again (I'll do it once more and show my results below).

Using the CMake-gui and pressing "configure" after selecing MinGW makefiles on the popup window:

Code: [Select]

The C compiler identification is GNU 4.7.2
The CXX compiler identification is GNU 4.7.2
Check for working C compiler: C:/Program Files/MinGW/bin/gcc.exe
Check for working C compiler: C:/Program Files/MinGW/bin/gcc.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler: C:/Program Files/MinGW/bin/g++.exe
Check for working CXX compiler: C:/Program Files/MinGW/bin/g++.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Looking for sys/types.h
Looking for sys/types.h - found
Looking for stdint.h
Looking for stdint.h - found
Looking for stddef.h
Looking for stddef.h - found
Check size of void*
Check size of void* - done
Found OpenGL: opengl32 
Found Freetype: C:/Users/Administratör/Desktop/LaurentGomila-SFML-86897a8/extlibs/libs-mingw/x86/libfreetype.a (found version "2.4.4")
Found GLEW: C:/Users/Administratör/Desktop/LaurentGomila-SFML-86897a8/extlibs/libs-mingw/x86/libglew.a 
Found JPEG: C:/Users/Administratör/Desktop/LaurentGomila-SFML-86897a8/extlibs/libs-mingw/x86/libjpeg.a 
Found OpenAL: C:/Users/Administratör/Desktop/LaurentGomila-SFML-86897a8/extlibs/libs-mingw/x86/libopenal32.a 
Found SNDFILE: C:/Users/Administratör/Desktop/LaurentGomila-SFML-86897a8/extlibs/libs-mingw/x86/libsndfile.a 
Configuring done

Pressing "configure" again and then "generate"

Code: [Select]

Configuring done
Generating done

Going to the directory where I wanted to "build the binaries" and running "mingw32-make":

Code: [Select]

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Med ensamrätt.

C:\Users\Administratör>cd Desktop

C:\Users\Administratör\Desktop>cd CompiledSFML

C:\Users\Administratör\Desktop\CompiledSFML>mingw32-make
CMake Error: Target DependInfo.cmake file not found
Scanning dependencies of target sfml-system
CMake Error: Directory Information file not found
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj
G__~1.EXE: error: @CMakeFiles/sfml-system.dir/includes_CXX.rsp: No such file or
directory
G__~1.EXE: error: C:\Users\Administrat¸r\Desktop\LaurentGomila-SFML-86897a8\src\
SFML\System\Clock.cpp: No such file or directory
G__~1.EXE: fatal error: no input files
compilation terminated.
src\SFML\System\CMakeFiles\sfml-system.dir\build.make:57: recipe for target 'src
/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj' failed
mingw32-make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj]
Error 1
CMakeFiles\Makefile2:107: recipe for target 'src/SFML/System/CMakeFiles/sfml-sys
tem.dir/all' failed
mingw32-make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
Makefile:115: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

C:\Users\Administratör\Desktop\CompiledSFML>

And there it is again :/

15

General / [SOLVED][C++] Compiling SFML under Windows 7 with MinGW throws errors

« on: April 19, 2013, 09:57:55 am »

I'm currently trying to compile SFML on a school computer but now I'm stuck at some weird errors. I have done exatctly as you're supposed to do, use CMake, select MinGW Makefiles and go to the "Build Directory" and run  "mingw32-make" to compile SFML. However when running "mingw32-make" it gives a bunch of errors and stops:

Code: [Select]

C:\Users\Administratör\Desktop\CompiledSFML>mingw32-make
CMake Error: Target DependInfo.cmake file not found
Scanning dependencies of target sfml-system
CMake Error: Directory Information file not found
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj
G__~1.EXE: error: @CMakeFiles/sfml-system.dir/includes_CXX.rsp: No such file or
directory
G__~1.EXE: error: C:\Users\Administrat¸r\Desktop\LaurentGomila-SFML-86897a8\src\
SFML\System\Clock.cpp: No such file or directory
G__~1.EXE: fatal error: no input files
compilation terminated.
src\SFML\System\CMakeFiles\sfml-system.dir\build.make:57: recipe for target 'src
/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj' failed
mingw32-make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj]
Error 1
CMakeFiles\Makefile2:107: recipe for target 'src/SFML/System/CMakeFiles/sfml-sys
tem.dir/all' failed
mingw32-make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
Makefile:115: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

C:\Users\Administratör\Desktop\CompiledSFML>

Any idea what may be causing this to happen?