Author Topic: SFML 1.4 (Read 28637 times)

Imbue · « **Reply #15 on:** November 28, 2008, 10:52:06 pm »

Quote from: "Laurent"

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?

Wizzard · « **Reply #16 on:** November 28, 2008, 11:05:01 pm »

Quote from: "Imbue"

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.

Imbue · « **Reply #17 on:** November 28, 2008, 11:13:54 pm »

Quote from: "Wizzard"

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.

Wizzard · « **Reply #18 on:** November 28, 2008, 11:41:53 pm »

Quote from: "Imbue"

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.

Imbue · « **Reply #19 on:** November 28, 2008, 11:52:11 pm »

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.

Quote from: "Wizzard"

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, though.

Laurent · « **Reply #20 on:** November 29, 2008, 10:09:08 am »

TransformToGlobal and TransformToLocal won't work for nested drawables, you're right. I'll have to think about it.

Imbue · « **Reply #21 on:** November 29, 2008, 09:37:28 pm »

Quote from: "Laurent"

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.

Code: [Select]

    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.

Laurent · « **Reply #22 on:** December 02, 2008, 05:35:27 pm »

Quote from: "christoph"

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

lzr · « **Reply #23 on:** December 03, 2008, 04:16:40 am »

Have you added a way to load subsets of images yet?

Laurent · « **Reply #24 on:** December 03, 2008, 07:45:13 am »

Quote from: "lzr"

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

christoph · « **Reply #25 on:** December 03, 2008, 05:20:00 pm »

Quote from: "Laurent"

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

Laurent · « **Reply #26 on:** December 03, 2008, 11:10:55 pm »

Quote

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?

christoph · « **Reply #27 on:** December 04, 2008, 06:21:36 pm »

Quote from: "Laurent"

Quote
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.

nitram_cero · « **Reply #28 on:** December 07, 2008, 01:22:11 pm »

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.

christoph · « **Reply #29 on:** December 08, 2008, 10:13:27 pm »

Quote from: "christoph"

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