SFML community forums
General => General discussions => Topic started by: Laurent on November 25, 2008, 11:46:55 pm
-
Hi
I'm starting to think about releasing SFML 1.4, so I'd like to have the last feedbacks about important bugs to fix, or things to change for this release.
Thanks :)
-
The only thing I would be worried about is having the Mac OS X port in sync with the Windows and Linux ports. Other than that, everything seems golden.
-
The MacOS X port should be ok for the next release ;)
-
Hi!
Cool Idea to release 1.4 sometime soon. If you could manage to get it out before ~10. of december (including C and Python bindings) we could probably have all the improvements ready for Ubuntu 9.04.
One small thing I do actually miss would be the mr-proper target callable from toplevel makefile otherwise it seems quite fine from my few tests.
EDIT:// the other thing, not only *.so but also include files going to INSTALDIR would be nice to have, too.
-
Hi Christoph.
C++ and C SDKs should be ok for 10 of december, unless someone founds an important bug to fix.
I don't think PySFML will be ready, its maintainer doesn't seem to be very active and there's apparently much to be done to upgrade this binding to 1.4.
Regarding the makefile fixes you suggested, I plan to include all of them before the release, don't worry ;)
-
OK we'll se then.
Thanks for including the makefile stuff anyway ;)
Seems SFML will be ready well before I do some release on my game (https://savannah.nongnu.org/projects/spaceshooter/) so I can now go for some of the improvements :)
-
Is rendering to image ready ?
-
No. I don't have enough time to include such big features for the moment, so 1.4 won't contain what's not closed in the current task-list.
-
Wonderful, I've been using SFML for a school project and a new release may help stability. (I haven't been up to date on my SVN updates :oops:). Any features? If all the things I've seen on the to-do list are done then you guys are in good shape.
-
So have you changed your mind to expose sf::Drawable 's Matrix ?? :wink:
I would like to see sf::Drawable to give information about their drawing area. This feature is already there:
Text has GetRect
Sprite has GetSubRect
Shape's bounding box can be calculated easily by adding points
PostFX is a special case though
I just need one virtual call in sf::Drawable for all of this.
-
So have you changed your mind to expose sf::Drawable 's Matrix ??
No ;)
Like I said, I prefer providing all the necessary herlper functions rather than raw matrix access. Aren't the new TransformToGlobal and TransformToLocal functions enough ?
-
So have you changed your mind to expose sf::Drawable 's Matrix ??
No ;)
Like I said, I prefer providing all the necessary herlper functions rather than raw matrix access. Aren't the new TransformToGlobal and TransformToLocal functions enough ?
Wow, you're fast :shock: .
Sry, I haven't checked the svn. I think that's enough
-
I would like to see sf::Drawable to give information about their drawing area. This feature is already there:
Text has GetRect
Sprite has GetSubRect
Shape's bounding box can be calculated easily by adding points
PostFX is a special case though
I just need one virtual call in sf::Drawable for all of this.
This is exactly what I'm planning to do (not for 1.4 though), and it's in the task list ;)
-
Aren't the new TransformToGlobal and TransformToLocal functions enough ?
To clarify, these functions return the top left and bottom right points of an object, right?
-
To clarify, these functions return the top left and bottom right points of an object, right?
No. You pass in a point and it's converted to the other frame of reference. Your point can be anywhere.
If you pass 0,0 to the TransformToGlobal function then you get then position of the upper left corner of the object in screen coordinates, only if you haven't changed the object's center (using SetCenter).
-
Aren't the new TransformToGlobal and TransformToLocal functions enough?
These functions are useful, don't get me wrong, but they aren't enough. They don't work for an object drawn as part of another object, do they?
-
If you pass 0,0 to the TransformToGlobal function then you get then position of the upper left corner of the object in screen coordinates, only if you haven't changed the object's center (using SetCenter).
If you passed 0, 0 to TransformToLocal, would you get the lower left corner of the object's bounding box in screen coordinates (assuming SetCenter was unchanged if that's needed)?
Edit:
Or does this rather change a point on the object to and from the global, or world's, perspective to the local, or object's, perspective?
If the above is true, then how does rotation and scale affect the result of these functions?
Sorry for the bother, but I'm just trying to learn as much as I can about the SVN version of SFML before SFML 1.4 comes out.
-
If you passed 0, 0 to TransformToLocal, would you get the lower left corner of the object's bounding box in screen coordinates (assuming SetCenter was unchanged if that's needed)?
No. You would get the upper left corner of the screen moved, rotated, and scaled the same way as your object (or inversely depending on how you're considering it).
For example, if you have an object that's 100 by 100 pixels, then you can convert a global mouse coordinate using TransformToLocal. After the transform, you can test for a click inside the object by doing x >= 0 && x <= 100 && y >= 0 && y <= 100. This will work even if the 100 by 100 object is scaled and rotated. It's quite useful.
The only problem is that it only considers the last transform. If you have Drawables drawing Drawables it fails.
-
The only problem is that it only considers the last transform. If you have Drawables drawing Drawables it fails.
I see your point. The matrix for each drawable should probably be fully accessible through helper functions.
-
BTW, I think what I said earlier about SetCenter was wrong. I'm pretty sure it gets treated in the matrix like everything else and isn't a special case. Sorry.
The matrix for each drawable should probably be fully accessible through helper functions.
Right now it is accessible to inherited classes, which is nice. I'm current passing the matrices down the hierarchy and multiplying them, which means I can still check for mouse clicks using global coordinates. It's not a bad system. Laurent has said he might completely hide/remove matrices in the future (http://www.sfml-dev.org/forum/viewtopic.php?p=4991#4991), though.
-
TransformToGlobal and TransformToLocal won't work for nested drawables, you're right. I'll have to think about it.
-
TransformToGlobal and TransformToLocal won't work for nested drawables, you're right. I'll have to think about it.
Currently I just pass each objects' matrix the update function of its members. I think it works quite well, actually. The first object in the hiearchy is passed the identity matrix.
void ClassX::Update(double dt, const sf::Matrix3& mat)
{
const sf::Matrix3 m = this->GetMatrix() * mat; //Add in our matrix.
Object1.Update(dt, m); //Update member objects.
Object2.Update(dt, m);
...
I just hope that if you get rid of the GetMatrix() protected function in the future, you replace it with something equivalent.
-
Hi!
Cool Idea to release 1.4 sometime soon. If you could manage to get it out before ~10. of december (including C and Python bindings) we could probably have all the improvements ready for Ubuntu 9.04.
One small thing I do actually miss would be the mr-proper target callable from toplevel makefile otherwise it seems quite fine from my few tests.
EDIT:// the other thing, not only *.so but also include files going to INSTALDIR would be nice to have, too.
I've fixed the makefiles, everything should be fine now. If I forgot one of your requests please let me know :)
-
Have you added a way to load subsets of images yet?
-
Have you added a way to load subsets of images yet?
No.
Everything that is done is in the roadmap, just use the advanced search :
"due in version" --> 1.4
"status" --> all closed tasks
-
I've fixed the makefiles, everything should be fine now. If I forgot one of your requests please let me know :)
I just checked r944 and it seems to work.
As you said (as far as I remember but I can't find the thread quickly) you won't consider linking the SFML libraries against each other when they need some symbols of other libs it's maximum I could want with 1.4 -- so I'm really happy with this release.
EDIT://
Well, could you set the soname of CSFML to 1.4, too? it's currently 1 ;)
EDIT3://
CSFML seems to not have gotten the goodies in SFML, could you do these things there too? Need not be 1.4 but they would certainly be good ;)
EDIT2://
There is actually an very grave bug in SFML's code. You do now symlink to $(DESTDIR)/libsfml-*.so.1.4 and not to ./libsfml-*.so.1.4 .
Would you consider something along *wrong* ?
EDIT4://
The patch was actually wrong http://paste.debian.net/22798/ is fixed up ;)
-
CSFML seems to not have gotten the goodies in SFML, could you do these things there too?
Done.
I'm a little bit confused about EDIT2 and EDIT4. What is right and what is wrong, actually?
-
CSFML seems to not have gotten the goodies in SFML, could you do these things there too?
Done.
I'm a little bit confused about EDIT2 and EDIT4. What is right and what is wrong, actually?
Hm what I want is the behaviour introduced by http://paste.debian.net/22798/ -- when you use destdir now, the symlink contains the absolute path. I do really prefer having an relative path in the symlinks (symlink: libsfml-system.so -> libsfml-system.so.1.4)
Rationale: If you do an 2 Step install, first building the lib, installing to an temporary directory moving the libs somewhere else and placing them there in /usr/lib -- the thing all distributions do -- you will get /usr/lib/libsfml-system.so linking to /home/user/build/sfml/lib/libsfml-syste.so.1.4 or something like that which is not what one would want.
I guess this should not break anything, libsfml*.so is pointing now to the corresponding *.so.1.4 in the same dir.
-
Great idea to release 1.4
I had to download the 950 SVN version because of that old Release-mode program crash that had something to do with "Illegal instruction".
Anyhow, great work, thanks for this awesome lib.
-MartÃn
p.s.: http://www.sfml-dev.org/forum/viewtopic.php?p=5222#5222 this is probably easy to fix.
-
Hm what I want is the behaviour introduced by http://paste.debian.net/22798/ -- when you use destdir now, the symlink contains the absolute path. I do really prefer having an relative path in the symlinks (symlink: libsfml-system.so -> libsfml-system.so.1.4)
The paste expired, but you can get the patch at http://testing.coders-nemesis.eu/sfml_symlinks.patch if you still want it ;)
-
Hm what I want is the behaviour introduced by http://paste.debian.net/22798/ -- when you use destdir now, the symlink contains the absolute path. I do really prefer having an relative path in the symlinks (symlink: libsfml-system.so -> libsfml-system.so.1.4)
Rationale: If you do an 2 Step install, first building the lib, installing to an temporary directory moving the libs somewhere else and placing them there in /usr/lib -- the thing all distributions do -- you will get /usr/lib/libsfml-system.so linking to /home/user/build/sfml/lib/libsfml-syste.so.1.4 or something like that which is not what one would want.
I guess this should not break anything, libsfml*.so is pointing now to the corresponding *.so.1.4 in the same dir.
Oups, i hadn't seen this post, and i already made some changes in CSFML makefiles. Could you tell me if I made the right changes ?
edit : rev 953.
-
Thank you :)
-
I've been watching this thread with so much anticipation since it was started. One of the reasons I rewrote OTO for SFML was for the potential cross-platformability. What's the current estimated release date for 1.4? Sorry, I'm just a little curious/excited about this version.
-Leeran Z. Raphaely
-
Everything is ready, I just have to find some time to finish the new tutorials and pack/upload the archives.
If you're too curious/excited you can also get the current SVN revision and make your own private release :)
-
Not for 1.4, sorry :(
-
OK I prepared a set of debian (actually ubuntu) packages of SFML1.4
For all users of Ubuntu 8.10 you can use the following apt-sources lines:
deb http://ppa.launchpad.net/christoph-egger/ubuntu intrepid main
deb-src http://ppa.launchpad.net/christoph-egger/ubuntu intrepid main
More information on https://launchpad.net/~christoph-egger/+archive
All this will enter the official path as soon as the debian release is out (maybee I find an way for ubuntu to get around this)
-
What's the status on the release?
-
All the packages are done, the documentation is ready and there's just one more tutorial to write before I can release SFML 1.4. It should be done in the next few days.
-
All the packages are done, the documentation is ready and there's just one more tutorial to write before I can release SFML 1.4. It should be done in the next few days.
Sounds great, looking forward to it.
-
can't wait!
Just download the sources from svn :P
-
I'm mostly excited for the Xcode tutorials. I've wanted to port my game to Mac OS X for a long time, but I don't even know where to begin on Mac development.
-
The Xcode tutorial is already online ;)
-
The Xcode tutorial is already online ;)
When will the files be uploaded? I've been looking around for game libraries, and SFML seems to be the one I need, so I'm quite excited :)
-
Everything you need is online.
-
Can you tell us which tutorials were updated since 1.3 ?? It kinda sucks to re-read everything, since I started 2 days ago and read everything from 1.3.. xD
Thanks.
-
Everything you need is online.
Wonderful! Thanks!
-
Can you tell us which tutorials were updated since 1.3 ?? It kinda sucks to re-read everything, since I started 2 days ago and read everything from 1.3.. xD
Just look at the change log ;)
-
The frameworks that are included in with the SDK seem to be invalid. The They don't follow the conventional pattern for frameworks (with the aliases in the root), and sfml-audio had some files with truncated names in it. Also, I couldn't get it work when trying to build a project linking to them, while it worked perfectly when I had built them myself.
-
Indeed... and all the symbolic links are broken/missing...
I'm going to tell this to Laurent.
-
The packages have been updated.
-
Congratulations on release 1.4 Laurent, keep up the good work!