Introduction and comments

[Julien_v42]

First hello all here!

I'm a French game programmer (3 years of pro experience) who discovered SFML through a friend a while ago while searching for clean and fast-to-setup library for game developpement.
I'm working currently on two different projects using SFML: the first is an original board game (I mean like Reversi, not like Warhammer :wink:) and the other a much more ambitious game, not yet completely designed, but it will feature a very rich world, with active 'wild life' / NPCs and some music-based gameplay. Both projects have professionnal/commercial ambition.

(Now the history/blog part ) I'm coming from Allegro (great, but integration with OpenGL was still lacking last time I checked), then I considered SDL (seems very feature complete, but didn't appeal to me much), then found SFML.
So far, I'm quite satisfied with it, it's straightforward and working as it should whether I need OpenGL or use its 2D rendering facilities. So thanks to the developer(s) for that!

Now after the praise, some remarks. :twisted:
I've not read the whole forum(s) to check if somebody already made all them, sorry if it is the case.

+1 on the following feature requests :
 - change window icon
 - add a file archive support (not critical for me)
 - basic collision detection in sf::Sprite (ie sprite bounding box overlap)
 - animated sprite support

There is something I'm unhappy with ATM, it's the RenderWindow / Drawable tie in.
From what I understand, the only way to render a Drawable is by using RenderWindow::Draw(Drawable). Furthermore, there is no facility (collection) of Drawable in the RenderWindow (or elsewhere). So it means, to render my entities, I have to loop through them, get their Sprite instance and draw it using my window.
What I'd like to do, is have my entity class hold its own rendering code (ie a virtual Render() method), which can be either simply displaying a Sprite,  or some OpenGL stuff, or something else (if I use a model library for instance).
I can do just that of course, but then I have a dependency on RenderWindow in my class (the obvious way is to have either a reference to the RenderWindow instance stored in the entity class, or passed to Render as a parameter). This raise two issues for me. First if I don't use the RenderWindow in my Entity::Render() (which should be the case in most entities after first prototyping is over), I still pass/store useless references, secondly, it makes the class itself dependent on SFML, something I want to avoid since I aim at easy portability to different platforms.
What I'd like would be the ability to call a Sprite.Draw() method, without a RenderWindow instance, the way I can make calls to OpenGL. It would be perfectly OK to call a method in RenderWindow before and after that, like this:

Code: [Select]

RenderWindow.SpriteBatchStart()
foreach Entity in World
    Entity.Render()
RenderWindow.SpriteBatchEnd()


Currently, I'm avoiding this by referencing a global var, which isn't very pretty (extern RenderWindow *g_RenderWindow...).


About the Sprite class specifically now, it don't seem to have a 'hotspot' feature (maybe that's what is noted as 'fixed' in roadmap?), so I must add for instance half its size to the object coordinate before drawing. It hasn't got animation features as far as I know, so I'd have to switch Images myself, hold timings and hotspot information, etc if I want to use animated sprites. Neither has it got 'module' features, ie combining different parts/images, which is very useful for some kinds of games.

The conclusion to this is: currently, the sf::Sprite class is either too 'heavy' for me, if I want to control it from my code (it contains useless position information), or too 'light', if I want it to do all the stuff I need.

One question to finish this post, are there plans to include tilemaps/tilesets facilities, if not, how would you implement them using SFML? Using lots of Sprites? Or OpenGL quads?

Thanks for reading this long post and for any answers.
Be assured I appreciate the great work on SFML so far despite my criticism!

[Laurent]

Wow, that's a huge comment, thanks for your detailed feedback

+1 on the following feature requests :
- change window icon
- add a file archive support (not critical for me)
- basic collision detection in sf::Sprite (ie sprite bounding box overlap)
- animated sprite support

Changing window icon should be implemented quite soon, unless I encounter any problem with any OS.
I kind of dropped the file archive feature for now, I try to focus on fixing and improving the existing packages before implementing brand new ones.
I'm still thinking about how to implement a simple and fast interface for intersection tests and collision detection. It's quite important so it should be done relatively soon.
I won't provide support for animated sprite, it's too specific and I prefer to let every application define its own wrapper for it ; it's usually very easy to write.

From what I understand, the only way to render a Drawable is by using RenderWindow::Draw(Drawable)

Yes, a sprite is rendered in a window, like with many rendering APIs (SDL does this, you need to blit on the screen surface).

Furthermore, there is no facility (collection) of Drawable in the RenderWindow (or elsewhere)

Any sort of "scene" management is too high-level for SFML and is left to the user. SFML just provides a way to render simple 2D primitives, not to manage a complete scene.

So it means, to render my entities, I have to loop through them, get their Sprite instance and draw it using my window.

Ya, that's the usual way to draw things But once you have setup your wrapper around it, it should fit better your engine / application.

First if I don't use the RenderWindow in my Entity::Render() (which should be the case in most entities after first prototyping is over), I still pass/store useless references

But in the end you will use it, so what's the problem ? And I really don't think passing a reference to a function will slowdown your game. I even think the compiler is smart enough to remove the parameter from the stack if it's unused. You should focus on what's really important

secondly, it makes the class itself dependent on SFML, something I want to avoid since I aim at easy portability to different platforms.

What would you do to pass the screen surface with SDL ? If you don't want any public dependency on SFML, just wrap RenderWindow in your own custom class. If you want to optimize your interfaces for a single window, just store it in a singleton renderer or whatever
Having the ability to use multiple windows is an important feature of SFML, I can't just limit it. But why do you want SFML to do that for you, it would be much easier to just wrap it in a few custom classes / functions on your side
Like I said, use a singleton renderer to store the RenderWindow, and make your entities use it to render themselves.

About the Sprite class specifically now, it don't seem to have a 'hotspot' feature

What is a hotspot ?

The conclusion to this is: currently, the sf::Sprite class is either too 'heavy' for me, if I want to control it from my code (it contains useless position information), or too 'light', if I want it to do all the stuff I need.

sf::Sprite is really meant to be lightweight, it's just a set of rendering parameters used to display a part of an image.
In the other hand, what is missing when you want it to do all the stuff you need ?

One question to finish this post, are there plans to include tilemaps/tilesets facilities, if not, how would you implement them using SFML? Using lots of Sprites? Or OpenGL quads?

No plan to add it. I think the most efficient implementation would use an OpenGL display list of quads.

By the way, some AnimatedSprite and TiledBackground classes exist on older revisions on SVN (in AdvancedGraphics), if you can find them

Thanks for reading this long post

Thanks for the long feedback

[Julien_v42]

About the whole 'RenderWindow' dependency: I just find it strange to be able to just throw OpenGL commands from nearly anywhere while not being able to do the same with a sf::Sprite.
It's not really an issue, since I've worked around it to have my scheme working. I could as you say make a singleton renderer if I want to wrap around SFML.
BTW, I wasn't worried about speed optimization there, just about dependency. One of my projects is multiplatform already, and I'm forced to use preprocessor directives to implement platform specific stuff without too much overhead. I'd rather have common method prototypes with different implementations, which is not possible if I'm to pass window references around.
Enough said on the subject

For sf::Sprite, the only thing that's missing for me, since I'm not using animation ATM, is the hotspot handling. I don't know if it's what means

Changed the sf::Drawable center of rotation to be the center of translation and scaling as well

in the Roadmap.
The hotspot is the point of reference, from which the sprite is drawn. The coordinates of a sprite are usually given from that point instead of the top left corner. That seems to match your description of 'center of translation'.

For tilemaps, I'll checkout the SVN, it could give me a good starting point

Thanks for the quick answer!

[Laurent]

About the whole 'RenderWindow' dependency: I just find it strange to be able to just throw OpenGL commands from nearly anywhere while not being able to do the same with a sf::Sprite.

In fact, you don't really just throw OpenGL commands, you send them to the current context which is internally / globally stored by your OS implementation of OpenGL ; usually, there is one context by window.
You could have multiple contexts as well, and choose in which one you want to throw some of your OpenGL commands.
You would certainly end up to a similar design with a singleton renderer

The hotspot is the point of reference, from which the sprite is drawn. The coordinates of a sprite are usually given from that point instead of the top left corner. That seems to match your description of 'center of translation'.

Ok I see. That's exactly how it works now in SFML

[Julien_v42]

So, an innocent question :lol:, do you know when the next version will be released?
Put differently, should I grab the SVN work in progress or will you release the next version soon?

[Laurent]

The next version should be release quite soon, but I recommend you to get the SVN sources, as it's very simple

[Julien_v42]

OK I've checked out out the SVN sources, plus found the removed AdvancedGraphics dir.
The new Sprite::SetCenter() does what it should as hotspot

I will probably end up copy/pasting a lot of the tiled background code

[Laurent]

I will probably end up copy/pasting a lot of the tiled background code

Cool, it will finally be useful to someone