SFML community forums
General => SFML wiki => Topic started by: dorkfish on November 22, 2008, 10:31:28 pm
-
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. :)
-
Yes, would be really nice :D
-
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 ?
-
http://translate.google.com/translate_t
works quite well for me when i want to check out the French articles :)
-
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.
-
For the second link, I say : Warning !
Here (french) (http://www.siteduzero.com/forum-83-337671-3133292-map-en-sfml-moins-rapide-qu-en-sdl.html#r3133292) 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 (http://www.sfml-dev.org/wiki/fr/sources/layer), 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 ?
-
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.
-
Start with the animation tutorial; a lot of English users have trouble when it comes to making an animation system.
-
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.
-
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:
-
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.
-
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?
-
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...]
-
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 ;)
-
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.
-
I just go through the source and I think I've understood the working of sf::Drawable.
If I'm right, we have only to define the Render function and it will be all right. But I know nothing of OGL, so I cannot do anything. I can copy the sf::Sprite::Render but I don't know if there will be some thing to do (except remove the myIsFlipped[X/Y] adjustments). Or if it will be some changes in the future versions.
-
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 (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself). 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.
-
Having hundreds of one liner Get/Set functions for a myriad of classes is just asking for a maintenance nightmare, IMHO.
What if at some point in development a public variable needs to be limited to a certain range?
-
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.
-
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.
Moreover there is a loop-like :
If we look at the function call stack in the next example we see a kind of redundancy with Draw call.
int main(...) {
Animated a(...);
// ...
/* Main loop */ {
// ...
// Drawing.
window.Clear();
window.Draw(a);
window.Display();
}
// ...
}
If Animated::Render is
/* ... */ {
Target.Draw(my_own_sprite);
}
The stack will be :
main
sf::RenderTarget::Draw <--> sf::Window::Draw
sf::Drawable::Draw <--> Animated::Draw
sf::Drawable::Render <--> Animated::Render
sf::RenderTarget::Draw
sf::Drawable::Draw <--> sf::Sprite::Draw
sf::Drawable::Render <--> sf::Sprite::Render
It's twice or so longer than copying sf::Sprite::Render in Animated::Render :
main
sf::RenderTarget::Draw <--> sf::Window::Draw
sf::Drawable::Draw <--> Animated::Draw
sf::Drawable::Render <--> Animated::Render
PS : to me, the stack size does not really matter, but the principle of these redundancy calls does.
-
I had some free time today. I try and succeed the inheritance of sf::Drawable.
I've updated the wiki. Just have a look, and give me your feedback please.
-
The article is translated, with some changes.
Have fun. :)
PS : I also added PausableClock article.