Topics

1

Feature requests / Message Boxes / Alerts

« on: October 03, 2014, 06:56:31 am »

Saw this was suggested before, would like it to be reconsidered that it is "not in the scope of the project". I require a cross platform way to commute an error to the user when it occurs. There are numerous errors which can occur before the resources to draw text to a window are available, so using a sfml window with OpenGL to display this message simply won't do. I really would rather not have to include a library like Qt or wxWidgets simply for this purpose. The support can be minimal, no icons or configurable buttons, etc.

2

Window / Getting HDC of Window?

« on: August 29, 2014, 08:02:44 am »

Is there a way to construct a new window using the same context as another window?

3

Feature requests / Separate RenderWindow from Graphics?

« on: August 20, 2014, 11:21:24 pm »

I find i don't often need anything from the Graphics portion, except for the render window itself. Or possible create a derivative of RenderWindow that only creates the graphics context and such (no reliance on glew or opengl ; i don't think, just x11 on linux), it wouldn't need any other dependencies to put this type of window into the Window library.

4

Feature requests / Key Press Event Retain Native Code ?

« on: May 29, 2014, 04:01:33 am »

There are some libraries that can take native key presses, so having the native key code in the key event will make it easier rather than having a giant switch statement or some other system to map one to the other. Having a sfml -> native convert function would also be a solution.

5

Feature requests / Change Unit of Measure

« on: July 08, 2013, 09:12:41 am »

I know this is unlikely to happen, it would break too much in terms of compatibility (perhaps in SFML 3.0 someday). Angles are currently represented as degrees, it would be much easier for a lot of implementations for angles to be represented as radians instead. Yah sure degrees are easier to work with, but realistically when do you ever use degrees ? Perhaps when you are manually inputting a constant variable (in this case having a toRadian() function would cost nothing in terms of computation as it is a constant) but in every other case it costs cycles. The standard C math libraries all use radians so whenever you want to calculate sin or otherwise computations are wasted again.

As an example if I choose to store my angles are radians I would need to convert to degrees and than say I pass it to Transform::rotate(), well rotate() needs to convert them back to radians to use the sin/cos functions so I do a conversion that was never necessary.

Transform& Transform::rotate(float angle)
{
    float rad = angle * 3.141592654f / 180.f;
    float cos = std::cos(rad);
    float sin = std::sin(rad);

    Transform rotation(cos, -sin, 0,
                       sin,  cos, 0,
                       0,    0,   1);

    return combine(rotation);
}

I guess a question for the author, any reasoning for the use of degrees over radians ?