Messages

1

General discussions / Making SFML binary compatible across versions

« on: September 21, 2008, 09:26:22 pm »

Oh ok, well,, so far I'm very impressed with it and with all the effort and while I'm sad to know i can't use it to replace SDL with it for now, I'll be looking forward to it becoming stable.

Cheers, and thanks for all the effort.

No, I'm sorry to tell you that SFML is not a mature and stable API. It's still young and will be improved a lot in the future. Maybe the 1.x versions should have been 0.x, you're right.

2

General discussions / Making SFML binary compatible across versions

« on: September 21, 2008, 09:01:57 pm »

This is not good to know. I thought SFML being at version 1.+ had a stable binary interface.
So it means it's pretty much unusable under unix unless you link statically..

3

General discussions / Making SFML binary compatible across versions

« on: September 21, 2008, 06:03:04 pm »

I see SFML doesn't hide the private scope of its classes, can't this create binary compatibility issues in case you want to change them across minor versions? (as in, symbol size changes won't link)

Usually most C++ libraries (such as Qt), to avoid this, allocate the private scope separatedly like this:

myclass.h

Code: [Select]

class MyClassPrivate;

class MyClass {
     MyClassPrivate *p;
public:
    void methods();
    MyClass();
    ~MyClass();
}

myclass.cpp

Code: [Select]

class MyClassPrivate {
public:

      member variables
};


MyClass::MyClass() {

     p = new MyClassPrivate;
}

MyClass::~MyClass() {

    delete p;
}


Well, hope this is of any use.
Cheers!

4

General discussions / Saner unix install

« on: September 21, 2008, 05:52:47 pm »

Besides, I'm not a Linux user and my point of view is definitely biased
So, the question is : what would be the benefits of using autotools (except that it will scare Windows users and make me unable to maintain the Linux build) ? Do the Debian packages use anything else than the provided makefiles ?

Currently, the debian packaging is there, but it's not very usable to developers because it has no way to inform them where SFML is located.
So, let me give you a brief on what i believe should be the correct way to distribute SFML for unix systems.

Originally, the only "correct" way to distribute a package was using autotools.  As you know, libraries and includes in unix systems can be installed anywhere, like /usr/include /usr/local/include , /opt/pkg/include/ or even the bizarrre locations in OSX. This proved to be a mess when distributing a library because whoever was going to use it had to know where your favorite unix installed it.

Because of this, autotools introduced a system where your library provided "Scripts" written in a strange mixture of M4/sh that, when running autoconf would include them into the configure phase.  This way, scripts would detect where the library is.
This system was in place for more than a decade or two. it "worked" but sice autotools is a mess, a lot of projects either had no choice or didn't use it and wrote their own library detection code (checking common install paths or forcing the user to tell where libraries were installed). Until a few years ago, this was the only choice.

Fortunately, and now backed by the freedesktop people, an extremely handy tool called pkg-config was developed. pkg-config is very simple script where you can query information about your app, given it's unique unix name.  

http://pkg-config.freedesktop.org/wiki/

So, transforming sfml to use pkg-config shoudl be easy and straightforward.
You can keep using makefiles if you like, just the way you are now, or move to something more advanced such as scons, but the procedure is the same.

1) Check for the existence of pkg-config. pkg-config should be available in the path normally when invoked, if not, fail.

2) Check for the existence of every dependence using pkg-config. All sfml dependencies are already in pkg-config database, so just run similar to:

pkg-config openal --exists
pkg-config openal --atleast-version=0.0.5
(or a version you know it's compatible)

and check the program exit status value for 0 , if not 0 then it means openal is either not installed, or not the version needed by sfml, so fail compilation.

then, you must request pkg-config the compiler and linker flags to use the library with

pkg-config openal --cflags
pkg-config openal --libs

and add them to our CXXFLAGS / LIBS in the makefile.

So, finally, when you are done compiling and you are asked to "make install", you must generate and install (besides includes and libs) an "sfml.pc" file in $(PREFIX)/lib/pkgconfig that will inform applications compiling against SFML where the library is located and how to compile against it. It's simple!

Right now the debian install doesn't include pkg-config info, so it's pretty useless even if debianized.

Also, another feature of pkg-config is that it helps you when you want to upgrade your library and break api compatibility. Imagine you want to make SFML 2.0 . just make pkg-config provide a "sfml2" package, and include /usr/include/SFML2 and link against libsfml-audio2.so for example.

About build system, if you want to use something more complex than makefiles (but not nearly as messy as autotools) , that will also run under windows/mac using native compilers i'd recommend you to take look at:

scons (a python framework, the most advanced build system and used by most complex projects today)
cmake (a metabuild system that generates makefiles)
omake (a build system a bit similar to scons based on make syntax)

Well, hope any of this is of use.

Cheers!

5

General discussions / Also

« on: September 20, 2008, 06:49:37 pm »

adding to that, the build system and sources for some reason seem to be linux only, so compilig under bsd or opensolaris didn't work for me.

6

General discussions / Saner unix install

« on: September 20, 2008, 06:13:34 pm »

Hi! This is a request for a saner unix install,
Is there any hope of autotools , dependency detection, pkg-config support, debian friendly building, etc? Also any hopes of pestering distro mantainers to package it?

Because otherwise distributing something for unix using SFML is pretty difficult..

7

Feature requests / Clipboard Support

« on: July 12, 2008, 09:00:11 am »

I would have to agree with Laurent, this is jsut far outside the scope of SFML, and far from cross-platform.

Why? I know i have no vote here, but still I don't really see any factible argument of why NOT:

Pros:

-Can copy/paste clipboard into/from the game from/to th e native OS in a cross platform way, useful for complex in-game or app GUIs
-It's a very simple feature, easy to mantain, great for those who write their own in-game UIs

Cons:

"far from cross platform" <- makes no sense to me
"far outside the scope of SFML" <- it has uses in games and apps programed in SFML, plus it's easy to do
"makes no sense since developers deploy their stand alone gui libraries" <- haven't seen the case yet

8

Feature requests / Clipboard Support

« on: July 09, 2008, 07:45:22 am »

Sounds to me more like something that would be good as a very leightweight stand-alone library - for one thing, your example usage doesn't actually make sense yet in absense of a GUI package.

Most professional games have their own portable UI Libraries. Also, most audio applications (many using SDL like renoise, schism, etc) write their own libraries.
In any case, I'm not sure why you assume that whoever makes a game UI will be always using a standalone library.
Interacting with the OS native clipboard is an extremely simple feature but which is of use for those who would like text copied from/to their game or app, so i don't see why not supporting it natively in SFML.

It is already a need myself and other developers already have and had in the past.

9

General / [Solved] SFML and Multi Threading

« on: July 04, 2008, 08:12:09 am »

However, not all the classes have been designed and tested with a multi-thread architecture in mind, so there might be some code which requires explicit synchronization or special care regarding concurrent access. And I'll be glad to improve SFML if you can find such issues

This is great to know, and I will undoubtly make sure to let the developers know of any problems I may find.

Also, I wanted to ask... SDL has this really bad problem that resizing a window destroys the opengl context and there is nothing that can be done about it (textures/arrays and anything other on video memory are lost). do you know if SFML works around this issue properly?

Thanks!

10

Feature requests / Clipboard Support

« on: July 04, 2008, 08:07:19 am »

Well, clipboard hasn't much to do with multimedia programming. If you want to write portable apps requiring more OS-related features, you'd rather use a cross-platform GUI framework like wxWidgets or Qt.

Actually, I believe it has a lot to do.. first, most custom audio applications have custom UIs and don't like to rely on "native" looks (wxwidgets/qt). http://www.chibitracker.com is an app of mine which is an example of this.

Second is that not only applications but several games have pretty advanced built-in UI toolkits where you edit options or even multi player chat, set server IP addresses or hostnames, etc. Such toolkits will undoubtly benefit from a simple portable clipboard api so text can be copied from or pasted into the game.

Many years ago I worked on this project as lead engineer: http://www.regnumonline.com.ar , and by the time I found the lack of clipboard support in SDL limiting, as our GUI had to be very complex (as of with any MMO) as it was impossible to copy/paste text into it.

Cheers!

11

Feature requests / Clipboard Support

« on: July 03, 2008, 10:37:11 pm »

It would be really awesome to get portable clipboard support, which is something i very much miss in SDL. I write like to write portable audio apps as hobby and this is a feature i miss a lot.

Cheers!

12

General / [Solved] SFML and Multi Threading

« on: July 03, 2008, 08:39:10 pm »

Hi! I intend to give a try to SFML at the small game studio were i´m working at.
We tried to use SDL for portability, but it really has a lof of design limitations, so I´m wondering the same things about SFML.

First of all, how multi-threaded is SFML? In modern games that utilize OpenGL, it is very common that one thread handles keyboard, logic, and many OS ops, and another thread exclusively does scene culling and rendering, as this scales into multicores and modern game consoles. So, is it possible in SFML to move the graphics to a separate thread (And get the OpenGL context with it) while the rest of SFML runs in the main thread?
Because as said before, SDL is not designed and not able to do this, and this is a very important feature needed for modern 3D engines.

Thanks in Advace!