Messages

61

General discussions / SFML 1.4

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

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.

62

General discussions / SFML 1.4

« on: November 28, 2008, 11:13:54 pm »

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.

63

General discussions / SFML 1.4

« on: November 28, 2008, 10:52:06 pm »

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?

64

General discussions / SFML 1.4

« on: November 28, 2008, 10:46:40 pm »

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

65

SFML wiki / Translate French pages into English.

« on: November 28, 2008, 09:33:07 am »

What if at some point in development a public variable needs to be limited to a certain range?

Check/assert that's it's within range inside of the Set function? I guess that's a valid reason to avoid public inheritance of sf::Drawable.

66

SFML wiki / Translate French pages into English.

« on: November 27, 2008, 11:20:59 pm »

I think this is a small problem with SFML's design. If you don't publicly inherit from the sprite, then how do you position, rotate, scale, and center?

then you feel like you should inherit from sf::Sprite to save writing a lot of one-line functions. So that's probably more a laziness issue than a design problem in SFML

I agree that laziness is part of it. It's also part of what makes a pragmatic programmer. (Is it lazy to use SFML instead of OpenGL directly?) The bigger issue in my mind is the violation of the DRY principle. Having hundreds of one liner Get/Set functions for a myriad of classes is just asking for a maintenance nightmare, IMHO.

This is why using a public matrix class would be nice. Then the total issue of location and positioning could be made into one Get/Set function pair. There are other solutions though (e.g. virtual inheritance, templated interface classes).

If I'm right, we have only to define the Render function and it will be all right.

Yes, if you inherit from sf::Drawable, then anything you draw in the Render function is shifted. So just draw the sprite member in the Render function. That's it.

If you only inherit from sf::Drawable and have a sf::Sprite as a member, then you'll never need to move the member sprite at all. You just draw it in sf::Drawable::Render and SFML takes care of the rest. You don't need to know any OpenGL.

That does mean that you're paying twice for positioning (Animated's position and the sprite's position), but it should work as expected and give a clean interface.

67

SFML wiki / Translate French pages into English.

« on: November 26, 2008, 07:53:52 pm »

Is it not logically better not to inherit from sf::Sprite ? ... What d'you think ?

I think this is a small problem with SFML's design. If you don't publicly inherit from the sprite, then how do you position, rotate, scale, and center?

68

SFML wiki / Translate French pages into English.

« on: November 26, 2008, 07:44:50 pm »

1)About the const: I think that class needs const added in many places. All the GetX functions should probably be const too.

Does this class requires a sf::Clock as attribute ? The class could be totally handle by itself, ie Update won't require any more parameter.

2)I would advise to leave it how it is. By passing a float each frame you, you gain a lot more control over your program's logic. For example, making the whole program run in slow motion for special effects is trivial. It can also be very great for debugging. If your game records all inputs and frame times, then it's deterministic and you can replay any recorded session (in case of crash or odd behavior).

Just my two cents.

69

Audio / Error when I start the first Audio-Tutorial

« on: November 24, 2008, 08:30:35 pm »

That would be great. The fewer DLLs to keep track of, the better.

70

Audio / Error when I start the first Audio-Tutorial

« on: November 24, 2008, 08:07:08 pm »

The included OPENAL32.DLL depends on MSVCR80.DLL which isn't included with SFML. Two out of the three XP computers I tested on did not have it installed. I got a "The application failed to initialize properly" error until I installed the MS redistributables.

In any case I highly recommend using Dependency Walker before publishing anything.

71

Feature requests / Manually setting Z-order

« on: November 22, 2008, 07:00:53 pm »

BTW, Laurent, whats the rational for hiding GetMatrix()?

Thanks.

72

Feature requests / Manually setting Z-order

« on: November 22, 2008, 06:59:27 pm »

Sure, say I'm looking at a side view of a person. This person's body has a left leg and a right leg. Since this is a side view, on leg should be drawn before (under - obstructed by) the body, and one leg should be drawn after (above) the body. That's still doable, but means the hierarchy is transversed several times and the code becomes messy.

So consider a tree like this for a character's lower body facing right (draw order parenthesized):

Code: [Select]


          body(3)
        /      \
left leg(2)    right leg(4)
left foot(1)   right foot(5)

So body needs to draw one leg, itself, and then the other leg. One leg draws it's child first, one leg draws it's child after. With a more complicated hierarchy, draw may have to be called multiple times on the some member. In a real situation I'd have the legs split, and also arms, and a head to deal with, at the very least.

More to the point, I'd like my character animation to simply read some rules from an XML file and do the right thing. I suppose the current situation could still be made to work OK, but it would be much easier to specify a Z order to SFML and make the transversal once.

I know that with SMFL the way it is now, I can draw anything. If you're going for an absolute minimal approach, I can respect that and work around it. I just think it would be cool to give the end user a choice of draw order, and passing a Z value to OpenGL. I suppose if you want to implement software rendering in the future, then Z order may be a bad thing.

Thanks.

73

Feature requests / Manually setting Z-order

« on: November 22, 2008, 10:26:56 am »

If you have any suggestions on how to otherwise accomplish this, please tell me.

Order the list of sprite yourself. std::sort or std::list::sort should do the trick.

Thanks, for you suggestion, but I think you missed the point of my example. SFML does give a "scene graph" like quality, and you can have complicated object hierarchies by using recursive sf::Drawable::Render calls. This nearly forces an arbitrary Z ordering, though.

If I instead throw my objects in a sorted container (like std::set) I lose this scene graph quality and would have to re-implement it myself. Honestly, I may and do just that. If I hack GetMatrix() to be public, it shouldn't be too tough to make a reasonable 2d scene graph.

74

Feature requests / Manually setting Z-order

« on: November 22, 2008, 09:19:54 am »

Sure, here's my current situation:

Drawables have a nice feature where any calls to Render inside of another Render inherit their parent's transformations. This make Drawables nice for creating hierarchies for character animation. For example, if you have a "body" object owning an "arm" object (which in turn owns a "hand" object), SFML can propagate any changes to the body's position down to the arm (Internally I believe this is just using OpenGL's matrix stack). The biggest problem of doing it that way is that it makes controlling draw order (and therefor Z order) difficult.

If you have any suggestions on how to otherwise accomplish this, please tell me.

On an only slightly related topic, why is sf::Drawable::GetMatrix() protected and not public? I feel that Matrices are a higher level concept and should be allowed for more use by the end user. The alternative is a call to GetPosition(), GetScale(), GetCenter(), and GetRotation(). Doesn't that seem like a lower level interface with less encapsulation?

BTW, I'm a noob at all this, so I'm definitely open to any suggestions.

Thanks.

75

Feature requests / Manually setting Z-order

« on: November 22, 2008, 05:51:36 am »

Will SFML ever support a real Z-order system?

Since SFML uses OpenGL it seems like this should be an easy thing to add.

Perhaps add a method to sf::Drawable like SetZ(float z)? If it's left at zero then the Z order is determined by the render order, otherwise it's predetermined by z.

Seems like a simple enough thing, it would really help in some situations.

Thanks.