You are not logged in.
Why has SFML been "upgraded" to v1.99? Isn't this a beta version of v2.0? The official release version of SFML is still at 1.6.
Of course, this upgrade has screwed up all my SFML projects! gotta back it out. thanks.
Microsoft stole my computer, Linux gave it back.
Offline
same problem here. sfml1.99 (or, in that case, sfml1.99-git) isn't supposed to be a released version. I also couldn't find any mention of it in the mailing list. Could someone please revert to the last official release (1.6).
Offline
Have any one of you created a bug report?
The devs are likely to see a bug report before a forum thread.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Hey, I'm responsible for that upgrade. I made the decision because SFML1 is completely unmaintained and basically breaks all the time. Laurent (upstream) has stated that he will not develop or fix SFML1 any further. Along with the glew update I made the decision to upgrade to a stable git version. I simply do not have the energy to keep patching SFML1 along with its broken bindings.
I work with SFML2 almost every day and I know that SFML1 has many bugs in comparison and they will never be fixed.
I uploaded the last packaged version to AUR: http://aur.archlinux.org/packages.php?ID=49606
If you feel up to the task, adopt it and fix it up but know that upstream won't accept your patches because SFML1 is basically dead.
I recommend porting your projects to SFML2 if possible. Failing that, fix the glew, gcc and possibly libpng caused errors in SFML1.
Sorry for the trouble but hopefully you can understand my decision.
Offline
hm.. I guess eventually i'll upgrade my projects to SFML2. But for now,
i think i read somewhere some time ago that i can downgrade my arch
packages, if i still have them. I guess i do, because i never deleted them.
Can somebody please give me a hint, how i do that?
Offline
Offline
They are in /var/cache/pacman/pkg/ but it will break with a new glew/libpng/openal/any other updated libs. In fact, it is already broken by the glew update. Either fix the sfml1 AUR package or upgrade your projects.
Offline
svenstaro, while I understand why you did it, a headup at least on the mailing list beforehand would have been appreciated, as there are major incompatibilities between 1.6 and 1.99-git(aka. 2.0 alpha).
Btw. it seems like I am in a relatively rare position where migrating to 1.99 isn't THAT easy I had a completely working engine and game in 1.6, but now, whilst it DOES compile it also is completely buggy ...
Offline
This caught me off guard too, but I have to say I was only using 1.6 because that was what was in the official repos. I've only updated one of my projects so far, but there were only two new includes and one function rename I had to do.
Thanks for your work, Svenstaro
Offline
svenstaro, while I understand why you did it, a headup at least on the mailing list beforehand would have been appreciated, as there are major incompatibilities between 1.6 and 1.99-git(aka. 2.0 alpha).
Btw. it seems like I am in a relatively rare position where migrating to 1.99 isn't THAT easy I had a completely working engine and game in 1.6, but now, whilst it DOES compile it also is completely buggy ...
All times in sfml are now uint32_t and not float and also they are now milliseconds and not seconds. Be aware of that.
Also I am sorry for not announcing this. It was fairly short notice because of the glew rebuild.
If you really need sfml1, fix up the package in AUR. It was the last one that was in community and is now broken.
Last edited by Svenstaro (2011-06-13 18:41:43)
Offline
The timer's change was one of the first things I noticed, once I was able to recompile. Not sure wether it's a sfml or box2d's issue, but my sprites also all rotated in the inverse direction after the upgrade (Which took me some time to figure out. I just kept wondering why everything reacted in such a weird way .
I'm nearly done with migrating anyway, so I'll stick with 1.99/2.0 now. My last remaining issue is that nothing seems to render on my Acer Aspire One anymore (but it works fine on my desktop comp). Might be due to some error I introduced when I migrated all the Rect calls though.
Anyway, thanks for maintaining SFML
Offline
Not sure wether it's a sfml or box2d's issue, but my sprites also all rotated in the inverse direction after the upgrade (Which took me some time to figure out. I just kept wondering why everything reacted in such a weird way .
Same thing happened to me. In the end I only figured it out after writing a quick rotation demo app..
Offline
seriously I think sfml should be taken off the repos and moved completely to AUR, instead of having an alpha version whose API is randomly broken every now and then.
from http://www.sfml-dev.org/forum/viewtopic … t&start=30
PostPosted: Fri Jul 08, 2011 5:18 pm Post subject: Reply with quote
Don't forget that:
- SFML 2 is not even in alpha state so I can change whatever I want, whenever I want Laughing
- once SFML 2 is officially released, I won't break the API anymore in the 2.x branch
_________________
Laurent Gomila - SFML developer
Offline
Well, in one way, you are right. On the hand, however, if you do any SFML-based development you are probably tracking upstream either way (or you are using SFML 1's pre-built binaries directly from sfml-dev.org) since SFML 1 is hopelessly broken and Laurent said himself that SFML 2 is already more stable than SFML 1.
Since nobody wanted to maintain SFML 1 in AUR it was deleted. I know for sure that SFML serves at least me and my projects as well as their other developers in [community]. I would suspect that there are more people that use it and that those who do use it are aware of the recurring API breakages.
So, unless you feel deeply insulted by its pure existence in [community] I would like to keep it there with the usual 1 to 2 bumps per month. It will eventually be stable.
Offline
nah .. I don't feel insulted. I just thought that it was a halfway stable beta with a halfway stable API. Laurent's answer is somewhat frightening, as it implies that we just can't assume the code we write (or port) at the moment is going to work a couple of days in the future and might necessitate some heavy rewrite.
As I said in an earlier answer, I *do* understand why Arch moved to 1.99-git. I guess I'll just blacklist it in pacman.conf and keep on using the current version. I can still port it to 2.0 when it's released.
Edit:even Laurent Gomila says 2.0 should not be used at this point in time http://www.sfml-dev.org/forum/viewtopic … 5047#35047
Last edited by SammyF (2011-07-16 10:42:02)
Offline
As you probably know, I would *not* have done anything to the sfml package if it hadn't been for the Glew rebuild which pressured me into doing *something*. Now that we are where we are, we might as well just use it and help upstream development by reporting regressions and other bugs and comment on recent design decisions.
Offline
Is the SFML1.6 package still available anywhere? I've just made a release and I'm getting reports of build errors on Arch systems. I'd completely forgot I'd pinned glew and sfml to the 1.6 stable (for me) version. I can't move my project to 2.0 until it's released officially and the majority of distro's are running it.
Offline
Either do a static build or supply your own shared SFML libs and use LD_LIBRARY_PATH with that. I do not recommend installing SFML 1.6 on a system-wide basis as it's very broken and even brings its own libpng and libjpeg.
Offline
Thanks Svenstaro. I'll look into supplying a static or bundle instead. Would probably be easier for end users than compiling anyhow.
Offline
I still have an issue related to this. My game is SFML 1.6 based. Until SFML 2.0 is officially released and supported in the major distros (Fedora, Bunty, Debian) any move to 2.0 just now is just nuts. Laurent is still fiddling with the API and keeps saying "soon" for the release with no ETA whatsoever. So 1.99-git is not an option and I can't see whyit's been allowed into the official repos.
Previously I hunted down the old 1.6 arch builds and ran with them (I've honestly never hit a bug in 1.6 in 2 years of development but I'm hardly stressing it). Of course now libpng1.5 has come along and burst my bubble. So my options are.
1) Download sfml1.6 source and install it.
2) Move to 1.99
3) Move from arch.
Option 1 seems the only viable alternative but the comment above about it bringing it's own libpng seems iffy. Is it that dodgy?
Offline
Sfml1 is broken and fixing it will take some work. Also you are making quite a drama out of this. Why not take the sfml1 package in AUR and try building it? I maintain sfml2 in Arch because it serves me well and because I don't want so fix sfml1. See my reasoning above for more detail.
Offline
Thanks for the reply Svenstaro. I've just installed the package from sfml-dev.org and it works great with no problems with libpng so I'm back in action. I suppose I'm making a kind of drama out of it because I believed a distro should only ship stable packages in the core repo's. I realise now sfml is in Community so it can be whatever you want it to be. I'll get back in my cage now. Thanks for your efforts.
Offline
You should realize that in general packagers can do whatever they want as long as they make the most reasonable choices all things considered. Also, which package did you install from sfml-dev.org? They don't have any packages for Arch as far as I am aware. If you refer to the statically linked versions then it might work for now as long as you don't link multiple things with different libpng/libjpeg versions. Keep in mind that sfml1 always used inbuilt deps instead of system ones. That is one of the reasons it was such a pain to maintain.
Offline
I just got the standard 1.6 package here.
http://downloads.sourceforge.net/sfml/S … -64.tar.gz
then done a sudo make install which copied the supplied precompiled libs into /usr/local/lib.
Currently my game (tractionedge.sf.net) is distributed as source only so it's up to the user to install sfml themselves.
Offline
That is not the proper way to install it and you should probably just make a static build for your users.
Offline