Messages

1

Window / Re: Significant memory leak in SFML when creating multiple windows

« on: June 19, 2014, 02:44:04 pm »

It seems I missed the part of the post where you state that that snippet does actually leak. It's so insultingly minimal, I can't believe modern drivers suck so hard that even that goes wrong. If I am not mistaken, this wgl thing is Microsoft stuff, isn't it? Perhaps it's yet another scheme to shun people away from OpenGL and over to DirectX.

2

Window / Re: Significant memory leak in SFML when creating multiple windows

« on: June 18, 2014, 04:22:42 pm »

Has the memory leak issue been fixed as of 2.1? Texture loading on my side fails with an "out of memory" error when I create a window, load a texture, destroy the window and loop this process multiple times. I will now try to make a minimal example to reproduce this error.

3

Feature requests / Re: Monitor API

« on: June 02, 2014, 04:50:22 pm »

Using SFML to render to a projector too .

4

Feature requests / Monitor API

« on: May 30, 2014, 03:31:05 pm »

Hi,

From the documentation, it seems SFML still does not offer an API to inspect the system's monitors (correct me if I am wrong). I think the library would benefit from something like it, and a quick search on the forums yields a few threads where people ask about the feature.

The API could be something like what GLFW offers: http://www.glfw.org/docs/latest/group__monitor.html. Essentially, it allows you to enumerate the system's monitors and query details about each of them, such as their position and dimensions within the bigger virtual screen, the video modes they support, and so on.

5

General / glxext.h compile error - SFML 2.1, 64-bit linux, gcc 4.8.2

« on: January 06, 2014, 06:17:19 pm »

Hi,

I've been following the tutorial on compiling SFML 2.1 with cmake, but I have stumbled upon the following error during the build process:

[ 33%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/Linux/GlxContext.cpp.o
In file included from /home/jeanne/tmp/SFML-2.1/src/SFML/Window/Linux/GlxContext.cpp:33:0:
/home/jeanne/tmp/SFML-2.1/src/SFML/Window/glext/glxext.h:670:22: error: ISO C++ forbids declaration of 'GLXContextID' with no type [-fpermissive]
 typedef GLXContextID ( * PFNGLXGETCONTEXTIDEXTPROC) (const GLXContext context);
                      ^
/home/jeanne/tmp/SFML-2.1/src/SFML/Window/glext/glxext.h:670:22: error: typedef 'GLXContextID' is initialized (use decltype instead)
/home/jeanne/tmp/SFML-2.1/src/SFML/Window/glext/glxext.h:670:26: error: 'PFNGLXGETCONTEXTIDEXTPROC' was not declared in this scope
 typedef GLXContextID ( * PFNGLXGETCONTEXTIDEXTPROC) (const GLXContext context);
                          ^
/home/jeanne/tmp/SFML-2.1/src/SFML/Window/glext/glxext.h:671:67: error: 'GLXContextID' has not been declared
 typedef GLXContext ( * PFNGLXIMPORTCONTEXTEXTPROC) (Display *dpy, GLXContextID contextID);
                                                                   ^
src/SFML/Window/CMakeFiles/sfml-window.dir/build.make:310: recipe for target 'src/SFML/Window/CMakeFiles/sfml-window.dir/Linux/GlxContext.cpp.o' failed
make[2]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/Linux/GlxContext.cpp.o] Error 1
CMakeFiles/Makefile2:155: recipe for target 'src/SFML/Window/CMakeFiles/sfml-window.dir/all' failed
make[1]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

I first ran cmake, checked that all the dependencies were met, and then went with the defaults. Then I ran make to get the library built, but instead got the above error. The cmake output is:

$ cmake .
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib64/libX11.so
-- Found OpenGL: /usr/lib64/libGL.so  
-- Found Freetype: /usr/lib64/libfreetype.so  
-- Found GLEW: /usr/lib64/libGLEW.so  
-- Found JPEG: /usr/lib64/libjpeg.so  
-- Found OpenAL: /usr/lib64/libopenal.so  
-- Found SNDFILE: /usr/lib64/libsndfile.so  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jeanne/tmp/SFML-2.1

This is all on a 64-bit installation of Arch linux, gcc version 4.8.2. Could anyone provide some light on this issue? Thanks in advance for any help you may provide.

6

SFML projects / SFML Haskell Bindings

« on: February 27, 2013, 08:19:21 pm »

Hello there. It seems people are announcing their bindings on the forum, so I'll do the same here.

Project page: https://github.com/jeannekamikaze/SFML
Docs: http://shellblade.net/docs/SFML/index.html
Installation instructions: https://github.com/jeannekamikaze/SFML/wiki

The bindings are pretty much stable; I'm just keeping up with changes to SFML/CSFML and adding minor tweaks. The library ships with a bunch of demos showing example usage of the library.

My plan is to upload a package to Hackage (the Haskell package repository) when SFML 2.0 is finally released. At the moment github is the only access to the bindings.

It would be cool if you mentioned these bindings somewhere on this site. Perhaps add a "Haskell" section to the "Other Languages" forum and move this thread over there.

Regards,
Jeanne-Kamikaze

7

C / Re: sfIpAddress size

« on: November 09, 2012, 01:05:15 pm »

Oh well, I forked the project and made the changes there. Took me just 2 minutes . I'm liking your fromSFMLAddress and toSFMLAddress helpers.

8

C / Re: sfIpAddress size

« on: November 07, 2012, 09:50:55 pm »

When you said

Now I remember why I did it this way: when you call sfIpAddress_toString() I can return a direct pointer to this member. Otherwise I would have to allocate a memory area, and let the caller manage its lifetime. Would be very inconvenient.

Why ? Can't you make a function that takes a char* and writes the string in there ? No need to allocate anything on the library side.

It's not SFML that needs changing, just CSFML. If you don't have time then I could do it.

9

C / Re: sfIpAddress size

« on: November 07, 2012, 07:59:39 pm »

You don't need to do that, although it's public, you should never access it directly. The only API that you should know is the set of sfIpAddress_xxx functions.

True. I'm reimplemeting some of the functions however. For instance, I don't really have to call C to initialise an address to 0. And yes, I can afford the maintenance.

Why? Who cares? And don't answer "it's slow" if you haven't tested it seriously

I personally don't care, but it's a multimedia library. Real-time systems will be built on it, and as a library provider you should ensure that what you ship runs half decent. It would suck to profile my application only to find out that the bottleneck is in the underlying API, and not because I'm making a bad use of it but simply because it is inherently slow. And no, there aren't any alternatives; SFML is the multimedia library.

10

C / Re: sfIpAddress size

« on: November 07, 2012, 05:37:46 pm »

But wait, so every time I use stuff like sfUdpSocket_send it's gonna parse the string address into a dword ?

Edit: This is indeed the case. Why not cache the dword in sfIpAddress then to avoid having to reparse the string on every call ?

11

C / Re: sfIpAddress size

« on: November 07, 2012, 05:30:36 pm »

Ah! Good to know then. Maybe state that in the docs ?

12

C / Re: sfIpAddress size

« on: November 07, 2012, 04:27:12 pm »

Maybe you were thinking IPV6. And no, it's not really important, unless the C code accesses a byte other than the first 4 of course. It also looks confusing in my opinion.

13

C / sfIpAddress size

« on: November 07, 2012, 04:19:44 pm »

sfIpAddress represents an IPV4 address according to the documentation, yet it is 16 bytes long (at least on x86):

typedef struct
{
    char address[16];
} sfIpAddress;

On the other hand, an IpAddress is 4 bytes:

class SFML_NETWORK_API IpAddress
{
    ...
private :

    ////////////////////////////////////////////////////////////
    // Member data
    ////////////////////////////////////////////////////////////
    Uint32 m_address; ///< Address stored as an unsigned 32 bits integer
}

Shouldn't sfIpAddress be 4 bytes as well, or am I missing something ?

14

Feature requests / Re: Rewrite the entire library in C

« on: October 04, 2012, 05:14:47 pm »

It's not that big of a deal anyway as these are the only problematic classes and I've been told of a way to make the api more or less pure while minimising the number of background mallocs at the same time. Not perfect but quite passable.

15

Feature requests / Re: Rewrite the entire library in C

« on: October 04, 2012, 05:07:51 pm »

No, I want a pure implementation of the *Shape classes.