Topics

1

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

2

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

3

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.

4

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