Show Posts
1
SFML projects / packageable things
« on: November 29, 2012, 03:42:16 pm »
Hello,
As far as I know there's nothing in the linux distro I use that's using SFML yet.
So I was wondering if there are games, small-games, or even toy-games yet around that are packageable?
Same question for libraries? I know the friend libraries are not stable yet, but are there some advanced enough to be considered packageable?
And then the last question but not least. We currently provide SFML 1.6.
So the options are:
- stick with 1.6 only
- provide both 1.6 and a more recent version
- remove 1.6 (nothing seems to use it so I think we can do), and provide only a more recent version
If we provide 2 versions next to each other, it would be fine to rename SFML 2.0 libs with the major verison number like -lsfml2-system etc. libsfml-system.so.2.0 can live next to libsfml-system.so.1.6 but what about the libsfml-system.so lymlink, it has to choose which to point to. If I've understood correctly, SDL 2.0 will include the 2 in the basename of the link for this issue.
But there are a lot of things using SDL 1.X, while I don't see much using SFML 1.6. So maybe just removing 1.6 is just the easiest solution.
If we provide a more recent version: SFML 2.0 RC1, or GIT?
Seems like the RC1 is quite old, and it seems there are no SFML 2.0 RC2 around or planed.
The release freeze is soon (not the same soon than this soon, because the date is known), so I've one remaining week to potentially help prepare things.
As far as I know there's nothing in the linux distro I use that's using SFML yet.
So I was wondering if there are games, small-games, or even toy-games yet around that are packageable?
Same question for libraries? I know the friend libraries are not stable yet, but are there some advanced enough to be considered packageable?
And then the last question but not least. We currently provide SFML 1.6.
So the options are:
- stick with 1.6 only
- provide both 1.6 and a more recent version
- remove 1.6 (nothing seems to use it so I think we can do), and provide only a more recent version
If we provide 2 versions next to each other, it would be fine to rename SFML 2.0 libs with the major verison number like -lsfml2-system etc. libsfml-system.so.2.0 can live next to libsfml-system.so.1.6 but what about the libsfml-system.so lymlink, it has to choose which to point to. If I've understood correctly, SDL 2.0 will include the 2 in the basename of the link for this issue.
But there are a lot of things using SDL 1.X, while I don't see much using SFML 1.6. So maybe just removing 1.6 is just the easiest solution.
If we provide a more recent version: SFML 2.0 RC1, or GIT?
Seems like the RC1 is quite old, and it seems there are no SFML 2.0 RC2 around or planed.
The release freeze is soon (not the same soon than this soon, because the date is known), so I've one remaining week to potentially help prepare things.