Messages

1

Feature requests / Re: Message Boxes / Alerts

« on: October 04, 2014, 12:57:57 am »

Well, I don't know about your own implementation, but with SFML the only thing that can report an error (!= can fail) is the font loading, and this can easily be prevented. So even if your code can fail at several places before being able to draw text in the window, you still have the solution to open a popup SFML window and display your error with sf::Font and sf::Text. Unless you really don't want to depend on sfml-graphics at all, of course.

Not just my code, SFML as well. I've run on a system that had bad drivers, in which an OpenGL context couldn't be created. So unless you can draw your sf::Font and sf::Text without a window, then there is more than just the font loading, which tbh your solution of embedding a font into your source or program is a really really bad solution. To be portable that essentially means having a file somewhere that has an array containing the binary information of the font.

And by the way, if I remember correctly (too lazy to check again), Xlib doesn't even provide standard messages boxes. So the implementation of such a feature could be far more complicated than it seems.

Which is why having it in a cross platform library, such as sfml, would make it useful. Oh well, off to C naming conventions with SDL.

2

Feature requests / Re: Message Boxes / Alerts

« on: October 03, 2014, 09:06:38 pm »

I don't use sfml-graphics, i use my own font system which has the font embedded into a larger resource. There could also be issues with creating an OpenGL context, or one of the required functions needed to draw the font aren't supported. They could have not properly copied the files over, so the font doesn't load (permissions, simplify missing a folder, etc...). The bottom line, using OpenGL (sfml) as a window to report an error simply doesn't encompass all possible cases, when there is a solution that does, why not support it?

Embedding it into the source code isn't possible with my implementation. At the very least it would require a bunch of new code to be written to support that kind of loading. This solution also doesn't cover the case in which the window fails to create or required features to draw the font aren't supported.

3

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.

4

Window / Re: Getting HDC of Window?

« on: August 29, 2014, 08:54:07 am »

Well i am trying to use a single context (with all my loaded resources and such) to render to two different SFML, i'd just have to call the glMakeCurrent and SwapBuffers myself, and there'd just be an extra context created in the other sfml window?

5

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?

6

Feature requests / Re: Separate RenderWindow from Graphics?

« on: August 25, 2014, 03:21:38 am »

You have that dependency incorrect, you don't need opengl to create an OpenGL context, you need an opengl context to render using opengl though. So no, since it is such an OS specific operation, i would not say it to be part of opengl.

You are telling me there is a wglCreateContext function in GL on linux? Cause uh i don't see it . It's by chance (eg not a requirement) windoz decided to put that function in the opengl32 library and not gdi or some such where the pixel format is created and what not.

7

Feature requests / Re: Separate RenderWindow from Graphics?

« on: August 21, 2014, 12:20:49 am »

Indubitably, didn't think you needed to link to opengl to create a context, as it is very Operating System specific in terms of parameters and naming used.

8

Feature requests / Re: Separate RenderWindow from Graphics?

« on: August 20, 2014, 11:45:18 pm »

OpenGL is crossplatform, i just don't like the dependencies the Graphics library uses, all i need is the window with a context to be created, which is not part of OpenGL and is not crossplatform. I didn't think sf::Window did that.

9

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.

10

Feature requests / Re: Key Press Event Retain Native Code ?

« on: May 30, 2014, 01:15:20 am »

opened this issue on Mar 27, 2011

):

11

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.

12

Feature requests / Re: Change Unit of Measure

« on: July 08, 2013, 04:53:59 pm »

Compare that to the 100 000 000 cycles you would need to do other meaningful things with those entities and you have a whole new picture.

What other meaningful stuff takes 100 000 000 do tell.

In any case not being wasteful is only an added benefit. Having to do conversions to have access to function calls is tedious and a design flaw imo.

13

Feature requests / Re: Change Unit of Measure

« on: July 08, 2013, 03:57:38 pm »

@Laurent
Believe that is partially at least because C took some roots from Fortran which was targeted for scientific computing which doesn't use degrees. Now though there is hardware support for said functions and last I've they take radians with no support for degrees. I guess it can be argued whether degrees are natural or not, from my viewpoint at least I haven't seen degrees on a mathematical equation for years all while using triple integrals to calculate volumes using degrees becomes irrelevant.

Also a bit curious why you didn't simply define a PI constant somewhere, do you have those several digits of PI memorized ?

You really shouldn't worry about angle conversions. It is a pure mult/div in hardware. It can be done in very few clock cycles if indeed more than a single one. This is not even nearly comparable to other things in your code.

Can be said otherwise when I have an entity with 5-10 angles all of which are used in multiple calculations, when I have on a scale of 1000 objects those few cycles now become a few 100 000 cycles of meaningless and avoidable operations.

Just like almost every other function Laurent uses in SFML... Laurent has other things to worry about than self-imposed deprecation restrictions. He already said OpenGL ES support was a goal, but until then, you just have to live with the fact that SFML runs on deprecated OpenGL code.

Wasn't really the intention of that comment, I could careless what he uses underneath, the API I am interacting with is what I am worried about. For 2D purposes there is no need for any of the new OpenGL features. The fixed pipeline was also great for debug purposes, bit bummed they completely removed it instead of just removing support in shader objects.

14

Feature requests / Re: Change Unit of Measure

« on: July 08, 2013, 02:55:16 pm »

Yah the only function that takes degrees in OpenGL is glRotatef and that's been deprecated since OpenGL 3.0+ and removed since 3.1+. I think that's a bad call if the only reason is degrees are easier to work with, at least from my standpoint if you want to be compatible with SFML that means you have to have a function to convert from degrees to radians whenever you want to use any trig. If I were to use radians than I'd need to convert from radians to degrees for SFML. If SFML used radians and I used radians though, there would be no need for conversion except for the odd case of a constant angle in code or printing some sort of debug message. In either case there is conversions but I find it is obvious which case would require less conversions and is more efficient than the other cases.

15

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 ?