Translate French pages into English.

[dorkfish]

Would it be possible for one of you French speakers to translate the French wiki articles into English? I was able to struggle through reading the sprite animation article, but I (and probably many others) would appreciate having the articles in English.

[woskaz0n]

Yes, would be really nice  

[Hiura]

That would be a nice exercise for me to translate a few pages.  :!:

But I haven't a lot of free time these days. So witch article would you like first ?

[zarka]

http://translate.google.com/translate_t

works quite well for me when i want to check out the French articles

[dorkfish]

These would be great to start with:

http://www.sfml-dev.org/wiki/fr/sources/frame_anim_animated
http://www.sfml-dev.org/wiki/fr/sources/tileset
http://www.sfml-dev.org/wiki/fr/sources/layer

Eventually the entire french wiki should be translated to english, so the same information is available to everybody.

zarka:
Google Translate might provide a passable translation, but translation software just doesn't do nearly as good a job as a human translator.

[Hiura]

For the second link, I say : Warning !
Here (french) I explain that the TileSet system is not optimised at all. Because it use std::map, it need to make a lot of test in the render function.

For example, if your TileSet is 150 height and 80 width, it's doing 12.000 std::map::find each time the TileSet is refreshed. In a 60Hz game, it is a least 300000 calls a second !

So, if you _really_ want, I can translate it, but know it : I dislike this article.
 :wink:  [understood : make your own system.]


About the ''Frame, Anim, Animated : Classes pour gérer vos sprites animés' article, I have no objections.

About this one, I'm asking myself why the author make some typedef but doesn't use them.  :shock: Moreover, I heard once that std::container are not designed for inheritance. Can someone confirms it please ?

[dorkfish]

I'd say go ahead and translate them, then we English speakers can also have a chance to nitpick the articles and see what improvements we can come up with.

Edit: I should note that I've only really read the article about animation, so I don't know what state the other two are in.

[Wizzard]

Start with the animation tutorial; a lot of English users have trouble when it comes to making an animation system.

[Hiura]

Start with the animation tutorial; a lot of English users have trouble when it comes to making an animation system.

Ok, I'll do that as soon as possible.

[Hiura]

I've translated the source part of Frame, Anim and Animated classes. I've made some changes.
[Here : http://www.sfml-dev.org/wiki/en/sources/frame_anim_animated ]
But I've some 'conception trouble'. (See the three fixme.)

I think the two firsts question can be answered by 'yes', but I'd like to have your opinion.
For the last one, I think that some feature like SetImage must not be a public function. But is it the only one ? Is it not logically better not to inherit from sf::Sprite ? ... What d'you think ?

PS : the second part of the article (ie how to use the classes)  is not yet translated, but it's planned.  :wink:

[Imbue]

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.

[Imbue]

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?

[Hiura]

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?

That's right. But we can make some function, and have an attribute 'sf::Sprite my_sprite' private. [Twice the work...]

[Laurent]

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?

I think this is a false problem.
It's not different from any other example of encapsulating an object into a class. It's just that sf::Sprite has many useful functions, and you usually want to provide the same in your wrapper class; 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

[Hiura]

Yes. Thanks.

What is really a sprite ?
The sf::doc says

Sprite defines a sprite : texture, transformations, color, and draw on screen.

That's it.

And What is a Animated object (represented by Animated class) ?
It's not a kind of sprite. It's an animation with some feature like : positioning, rotating, ...

So Animated may not inherit from sf::Sprite. But can it inherit from sf::Drawable :?:
Because it need to be draw on a window.
sf::doc :

Abstract base class for every object that can be drawn into a render window.

It seams to me to be right. But I don't know how to do. And I'm not sure.

PS : Laurent, there is one 'mistake' in the doc : http://www.sfml-dev.org/documentation/1.4/classsf_1_1Sprite.htm#0f52de16559efc4bf748a14f43318c7b . But there is no doc for sf::Drawable::Render.