Messages

1

Window / sfml gui

« on: June 18, 2008, 04:22:14 pm »

I"ve been planning (dreading) to implement my own gui system for my current game.  It's had to more than simple as a level editor is integrated with the game.
A friend of mine recently point me to cegui.  I don't know how I missed this gem.  I was wonder how difficult it was to get cegui to work with sfml.

Did you write an SFML renderer?

Are you using the standard OpenGL renderer and having sfml to preserve it's state?

Did you run into any snags?

In effect I'm looking for a tutorial on how you chose to bring up cegui with sfml.

-caspin

2

Feature requests / stop calling sf::RenderWindow::Display

« on: April 10, 2008, 05:40:27 pm »

stop calling sf::RenderWindow::Display every frame.  It is truly as simple as that.

Your problems will arise when you actually want the window to update.  In theory you can use glViewPort to set which section of the screen gets drawn to so you could just render those sections, but that will get out of control fast.  Either you build a update rect around every thing that has changed, likely the whole screen, or you render your game multiple times.  Just figuring out which sections of you game have changed can be a problem.  You'll have to design your entire render system with the update rects in mind.

-use glViewPort to select which section of the screen you want updated
-work some magic with sf::View to make sure the right part of your game is render to update rect.
-call Display after each glViewPort/update rect is set.

-nick

3

Feature requests / Still possible

« on: April 10, 2008, 05:29:38 pm »

This could easily be done by hand.

At game start up use the original image and dither it down to the size that is needed by the resolution and use the newly generate sf::Image instead of the original.

Dithering well is very complex problem.  Do some research before just coding the first thing that comes to mind.  The may even be a generic library that could perform the dithering for you.  The sf::Image is open enough that you should be able to use the raw data or convert it to the needed format.

-nick

4

Feature requests / Good stuff

« on: April 10, 2008, 02:34:51 am »

I'm glad to see that stuff is done already..  I had to change my own class that worked it's magic around sf::View but all of it was a simplification.  I really like the sf::View's new interface.

I think the rotating view stuff should easily blend with the new sf::View, I don't see how it could have been implemented with the old one.  Maybe that was the reason it was removed .

I don't want to duplicate work again.  I would like to go in add the rotation stuff to the view in my own copy.  But I don't want to waste my time if that will be done in the library any time soon.

thanks for all the great work you've done with the library

-Nick

5

Feature requests / sf::Input architecture

« on: April 09, 2008, 05:12:33 pm »

Ok, i see now.  I had though the sf::Input was a POD class that the RenderWindow updated after it processed all of the input events.  It is actually performing the event processing.  I agree the Non-Copyable is the way to go with Input.

On another thought could I replace what sf::Input with my own window listener.  The window listener interface is marked as internal now so I couldn't.

I'm not really aching to see an enhancement where I can create my own input processor.  It may be just as easy to do it with sf::Input instead.

I was just putting the idea out there as an enhance to be done when all others have been completed ( that generally means never ).

-Nick

6

Feature requests / Enhanced sf::View

« on: April 09, 2008, 05:03:46 pm »

Really this is two suggestions, but they are tightly coupled to each other.

Convert MouseX/Y to worldX/Y.
This would have be done through the view.  I suppose it could be done through the sf::RenderWindow, but that would artificially limit which views could be used to translate the coordinates.  I am not suggesting this be done automatically, but be provided as a method of the sf::View class.

   The major hurdle here is the View will need to know the screen dimensions to correctly convert the coordinates.  I would suggest passing the App as a reference to the method so that it can access the window dimensions.  Or if that is sharing too much information, just a sf::Vector2i that stores the X and Y dimensions of the window.

   This is just boring when the user has a default view.  It is a nicety when using a custom view, It is very useful if the custom view is scaled or a different size than the window, It is absolutely necessary if the View where allowed to rotate.

-

Rotating sf::View
   Allow the sf::View to rotated.  It's very simple at the OpenGL layer, but a bit more complicated at the SFML API layer.  The View would be defined as a lookAt point, a view width and height, and a rotation.  This provides absolute flexibility with how the View is placed.

   The current way sf::View is defined (Right, Top, Left, Bottom) is incompatible with a rotating view.  So I would suggest a new class sf::ViewEx or whatever the name doesn't matter.  The old sf::View class would inherit from sf::ViewEx and constrain it to hide the new functionality.

-

Why do I care:

   In my game the players are playing on circular world, a planet.  Gravity is not +/-Y, it is to the center.  When a player is on the "south" side of the world I want to rotate the view so that all the controls work as he would imagine, left button moves his player left on the screen.

   I was performing translations in game.  Then I got to problem of mapping the screen coords back to world coords.  It's difficult once you through in rotations.  There is a function gluUnProject that does all this for you.  However, this information is abstracted away in the library (thank goodness).  Which means the library is in much better situation to perform the call than I am.

-Nick

7

Feature requests / sf::Input Copyable

« on: April 09, 2008, 04:16:00 pm »

Why is sf::Input Non-Copyable?

I understand that it is prohibitively large and that copying should be done lightly.  Is there another reason?

This came up as I was building an input manager for my game.  I found that I was doing a lot of checking to see if a key was down last frame, rising/falling edge.  My solution was to make the contents of the last sf::Input available.  However, this wont compile with the current sfml, because I cannot copy sf::Input.

-Nick

8

Feature requests / Primative with texturing

« on: March 07, 2008, 07:27:28 am »

I'm really impressed with the API to draw primitives. Well, done.

I know it's experimental but the primitives would be of much more useful to me if I could specify an image and image coordinates with each point instead of colors. I'm requesting a extension the current API doesn't need to change.

My particular problem is I need to draw several triangles from a tessellated polygon. With the current API I have supreme control over the color but I can't use images to color the triangles.

-caspin

PS: it posted a similar comment in the thread about the new primitives API.

9

Feature requests / Upside Down World

« on: October 05, 2007, 07:21:58 am »

I think that SFML should provide an option that will map the 0,0 to the bottom left hand corner of the screen instead of the top left.  The change is not that major.  It would essentially be a conditional around the few places where the world is specified upside down.

I understand there is a lot of history here with old dos games editing the frame buffer directly.  I however don't think that emulating this is good idea in a modern 2d engine.  We are not using a frame buffer so don't pretend we are.  OpenGL maps the 0,0 to the bottom left corner, and that is our rendering engine.

Ideally, a 2d engine should let the user specify their world and viewport into that world.  Most 2d engines don't do this (they're still hung up on the emulating a frame buffer).  I was very excited to see that someone finally realized a 2d engine would do well to use this concept.  I can pan the camera around instead of moving the world.  However, SFML requires the world to have the y axis upside down.  It's like it kinda stuck half way between the 3d vewport method and the 2d framebuffer method.

I would personally like to have the 0,0 mapped the bottom left always.  I mean OpenGL made the decision to map it there, and I generally view OpenGL as one of the best designed API's.  There are many reason to put it there.  That said it is very common for 2d programmer to expect the 0,0 to be in the top right that it wouldn't make sense to make it hard for them to use the library either.  So I propose a boolean value to tell the underlying system to not flip the y axis.

-caspin

10

Feature requests / Another option

« on: September 14, 2007, 09:05:43 am »

I agree that it is not in SFML's scope to build a logging mechanism.  However, it would be nice if the library was more flexible about how it reported messages.
SFML could store an ostream instance with the system core.  System would then provide a mechanism to set the ostream used, it could default to std::cerr.  In this way the behavior hasn't changed but SFML gains the ultimate flexibility in reporting messages.

  A flexible error reporting feature would allow application to use that message data anyway the choose.  Capture it and display it in a message box, log it to a file,  send it out over a socket, all of the above, or some other bizarre use that neither you nor I could dream up.  It could even be used to cause SFML to throw exception instead of report errors, though admittedly that is a real kludge.  But it does go to show how much flexibility extending the error reporting system would give.

If there is interest I could provide a patch.  Then all you'd have to do is review the changes.  Which should be minimal, except for changing all to references to std::cerr to sf::System::err().