Topics

1

Graphics / View/RenderWindow API change [SVN] (issues + solution)

« on: April 21, 2008, 11:07:10 am »

I just updated my SFML from SVN sources, I had a version from April 05th before (which is before the API change in sf::View).
I had to change my view setup from view.Rect = ... to view.SetCenter / view.SetHalfSize to make it compile. And then, all my SFML sprites and text are gone.

I was gonna scream in this forum, but after some trials, I found if I submitted my View each frame, instead of once, I saw the sprites behind my OpenGL stuff. So I was starting to blame RenderWindow for losing its view, and SFML for losing its Z.

Then, I found my mistake. The method RenderWindow::SetView was previously SetView(View *view), and now SetView(const View &view).

Previous (working) code:

Code: [Select]

void Game::SetupStuff()
{
    sf::View view;
    view.Rect = sf::FloatRect(0, 0, viewWidth, viewHeight);
    m_RenderWindow->SetView(&view);
}

New (working) code:

Code: [Select]

void Game::SetupStuff()
{
    const sf::FloatRect rect(0, 0, viewWidth, viewHeight);
    sf::View *view = new sf::View(rect);
    m_RenderWindow->SetView(*view);
}
I should change it to avoid allocation by having Game hold a sf::View member, but that's the idea: you have to keep the View instance somewhere, do not use a local variable.

Hope this helps someone

Oh, and is there a reason not to provide a View::SetRect(const FloatRect &newRect) method? That would be nice for me, as 1) I compute width and height and not halves 2) my view starts at 0, 0 and finish at width, height, 3) that would make the setup one single call, best readability .

2

General discussions / Introduction and comments

« on: April 03, 2008, 01:32:20 pm »

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!