Allegro or SFML?

[BHX]

Disch wrote:

How does being a C lib make SDL's (or Allegro's) interface any more simplistic than SFML's C++ interface?

@Disch
Now, I wanted to put my two cents in. I really don't care if one is simple to the other so long as they as easy enough to learn without feeling like you are learning a foreign language. My only point of view in regards to C libs is the fact that they are easier to use between C and C++ without much fighting while the same can't be said for C++ libs in C. I know this is a retarded point of view, but I just wanted to say I don't worry about simplicity of interfaces when I code so long as it is learn-able to some extent.

[Disch]

My only point of view in regards to C libs is the fact that they are easier to use between C and C++ without much fighting while the same can't be said for C++ libs in C.

Can you elaborate on what you mean by this? What "fighting" are you referring to?

I literally see very little difference between SDL's and SFML's API apart from SFML having RAII implementations and therefore you do not have to manually clean up. So these claims that C libs are "easier" or involve less "fighting" are very vague to me.

Examples would help.

[BHX]

I'm referring to linking. You can use any C lib in C++ and link without any fighting to link them. A library written in C++ can't be used with C, instead you either have to wait for the creator to make a C version or find a C equivalent. I don't worry about APIs look or simplicity because as a programmer you have to learn them and not all APIs are gifted with being simple.

[Disch]

Yes. You're right. I've already conceded to that point.

I'm not saying there's no reason to prefer a C lib... I'm saying I suspect the specific reason computerquip is claiming is fanboy garbage.


So to restate the specific question... again (since it's buried on the previous page):

How does being a C lib make SDL's (or Allegro's) interface any more straight-forward/simple than SFML's C++ interface?


This question is pivoted towards computerquip's comments on page 1 (a bit on page 2):

computerquip wrote:

If I had to choose.... Allegro, because it's in C.

computerquip wrote:

There's nothing wrong with a good C library and to be quite frank, they seem to be much more straight forward and simple.

computerquip wrote:

I believe a C interface is more simple, not so much the implementation.

I persist with this line of inquiry because Duoas called him out as a "C evangelist" to which computerquip got defensive and accused Duoas of "not reading the thread". But the more I read the thread the more I think Duoas was right.

To my knowledge, there is no supportive argument for the quoted claim other than personal preference towards C.

(which would be fine -- I just want computerquip to cop to it if that's really what it is)

[S6k9GNh0]

Fine...

How does SFML initialize itself? You never create an actual object that allocates resources and its core does use resources outside of it's other functionality. Do you know how it does this?

It does it by using the functionality of a global variable being initialized before main, in which case Laurent created a class and then instantiated that class for the sole purpose of initializing SFML. Problems with this? 1. Lack of memory model flexibility. 2. Implicit allocation sometimes leaving the user confused about use since it's not stated in the docs. 3. Complicates the environment for threads. All because it used a C++ feature simply because its available. A relatively simple 2 liner or perhaps 6 liner if you want some error checking without using assert, would fix the problem in C (or C++, whatever).

Did he do the wrong thing? No. Rather, I do sometimes work with SFML whenever people ask for advice concerning it. However, I do feel that the classes are less direct when dealing with things like state management, how it handles flexibility, or how each class/struct talks to each other, leading to a confused design. I also believe it is this way because of the nature of C++ and what is now common as C++ design.

For instance, SDL has a function to create a OGL context. It's called SDL_GL_CreateContext(). SFML actually does this out of the box but causes issues when concerning flags with the OGL context because of it's internal renderer. You wouldn't actually know this and you can't set them either if the context is of major version 3 or above. This is caused by automatic initialization of the window but ultimately, it's caused by the design of SFML. It can be fixed and improved.

I have no idea how you're getting that I'm a C evangelist. Rather, that wording slightly pisses me off simply because of how wrong you are. I've even stated that I don't use C internally and only interface my code in C linkage.

[Paoletti301]

3. Complicates the environment for threads

why do you say that? because they are deleted if they go out of scope?

[cire]

For instance, SDL has a function to create a OGL context. It's called SDL_GL_CreateContext().

SFML's equivalent is sf::Context.

SDL_GL_CreateContext() requires assocation with an SDL_Window. sf::Context requires no such association.

SFML actually does this out of the box but causes issues when concerning flags with the OGL context because of it's internal renderer. You wouldn't actually know this and you can't set them either if the context is of major version 3 or above.

There was a bug if you were on Linux for 2.0 where context settings for 3.x and 4.x were ignored, but a fix was included in SFML 2.1 (which was released about a month after 2.0)

http://www.sfml-dev.org/documentation/2.1/structsf_1_1ContextSettings.php

[S6k9GNh0]

Strange since the warning is actually still in the documentation. Towards the bottom if you will. http://www.sfml-dev.org/tutorials/2.1/window-opengl.php

Also, it does require a window (a dummy), it's just implicit. A context without a window doesn't make sense. Which is actually my point.

[S6k9GNh0]

Paoletti301, you just need to be sure the API that uses the resources allocated by this global is either safe to use in a threaded environment or you must make precautions yourself which isn't obvious.

[cire]

Strange since the warning is actually still in the documentation. Towards the bottom if you will. http://www.sfml-dev.org/tutorials/2.1/window-opengl.php

I don't see what's so strange about it. The settings so referenced are not publicly exposed (as indicated in the "warning") and don't stop you from setting the ones that are. I've been using glfw lately for the ability to select debug and forward compatibility modes. SDL still has a lot of cruft in it related to software rendering that I would just as soon avoid.

Also, it does require a window (a dummy), it's just implicit. A context without a window doesn't make sense. Which is actually my point.

That is a matter of opinion, and not one I share. Sometimes all you want to do is manipulate shared data, which is often the case for a thread dedicated to loading resources. The OpenGL Architecture Review Board has the following to say about the extension WGL_ARB_Create_Context:

Found @ http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt
4) Should there be a way to make a context current without binding
it to a window system drawable at the same time?

RESOLVED: Yes, but only in OpenGL 3.0 and later. This results in a
context with an invalid default framebuffer, the meaning of which is
defined in the OpenGL 3.0 specification.

Of course, the design decision by Laurent has nothing to do with the language SFML is coded in.

[Disch]

Thank you for the substantive reply, computerquip. I will read in more detail and follow up when I get home from work this afternoon.

[S6k9GNh0]

cire, it doesn't but the design of SFML is common in various C++ libraries. I do use boost all of the time because I believe their intuitive but I don't use SFML because I believe it is not. It does have to do with C++ because it's almost required to take on a design that uses C++ features, which is natural. It makes little sense to interface in C++ but then not take advantage of the features of C++. But it also differentiates between libraries, sometimes based on age, author, and so on. For instance, wxWidgets has a somewhat dated design because of the C++ standard available during its time of creation. Otherwise the design would have been different perhaps.

TLDR; SFML design has nothing to do with the language it's written in can be a correct statement but the reality is different.

[Disch]

Work sucks.

computerquip wrote:

It does it by using the functionality of a global variable being initialized before main, in which case Laurent created a class and then instantiated that class for the sole purpose of initializing SFML.

Is that really what it does? I haven't looked at the source that closely. If that is indeed the case, I would call that a terrible design decision as global anything (especially in C++, especially in a lib) is problematic. I can think of at least 2 other ways to solve this problem without a global.

Automatic initialization is not a bad thing... in fact you're right it's a C++ feature and a user would expect it. But it's all in how it's done.

Do you know specifically where this global is? This is worth filing a bug report, IMO.

I might look for it later today if I find the time.

However, I do feel that the classes are less direct when dealing with things like state management, how it handles flexibility, or how each class/struct talks to each other, leading to a confused design. I also believe it is this way because of the nature of C++ and what is now common as C++ design.

This is where you start to lose me. The interactions between classes are near identical to what I'd expect in a C lib (only classes instead of struct pointers).

Your example of the global context initialization was excellent. Do you have a similar example to illustrate confused class relationships?

EDIT: bah... sf::Context was your example. ...Long day...

You wouldn't actually know this and you can't set them either if the context is of major version 3 or above.

I haven't had any problem using OpenGL 3.3 with SFML creating the context... and I've been using SFML 2.0 for a while. Though as someone else mentioned this was a bug in the Linux port and has since been fixed in 2.1?

I'll write this point off as N/A.

I have no idea how you're getting that I'm a C evangelist.

It was the way you were phrasing your earlier posts. All of your qualms are design issues... not language issues... yet you present them as language issues.

I still think you're misguided in thinking that these problems are inherently C++ related. If there's any language where multiple designs are prevalent, it's C++. I'm not saying that like it's a good thing... I'm just saying. =P

That said... I would certainly agree that designing a good API in C++ is harder than designing a good API in C. Mainly because more is expected of you if you use C++. Example: std::string vs. cstring's strxxx functions. I'm sure std::string was certainly harder to design and write.

Also, [sf::Context] does require a window (a dummy), it's just implicit. A context without a window doesn't make sense. Which is actually my point.

I can certainly imagine uses for a context with no window... so it makes perfect sense to me.

A commandline tool to render scenes to .png files, for example. Could be useful for batch animations and/or movie creation.

Whether or not OpenGL requires a window to be created is irrelevent from an API design standpoint (for a lib like SFML) -- there's no reason to require it.

[S6k9GNh0]

Actually, SFML2 has fixed the issue of lack of thread-safety when allocating a context and also seems to no longer need resources except for an on-call basis.

https://github.com/LaurentGomila/SFML/blob/sfml1/src/SFML/Window/Context.cpp

Here, he uses a singleton to hold a context structure for global use.
Was what I was referring too. I'm also unsure of when it was fixed since it was in several 1.99 releases as well.

EDIT: I'm also pretty sure there were other instances of this, without even the use of a singleton... but I might be aging myself unfortunately. Either way, I shouldn't have claimed something as current when it was changed probably half a decade ago.

[S6k9GNh0]

As for what I meant by a window being required, I used horrible wording here apparently.

OpenGL is a graphics rendering library. It doesn't make sense if you don't give it anything to draw too. An image, pixmap, framebuffer, or whatever, it needs something to render to. A closer look at glXCreateContext helped my terminology.

This post explains it quite a bit better than I can.

http://tech.groups.yahoo.com/group/libsdl/message/59248

EDIT: Also, due to the nature of OpenGL: http://tech.groups.yahoo.com/group/libsdl/message/59388

In the case of creating a context without the purpose of using it in a window, SDL2 fails. It's simply not meant for this.

[cire]

Is that really what it does? I haven't looked at the source that closely. If that is indeed the case, I would call that a terrible design decision as global anything (especially in C++, especially in a lib) is problematic. I can think of at least 2 other ways to solve this problem without a global.

I would probably have gone a different way as well, but it isn't an issue unless you make your own global sfml variables that depend on the order of initialization and since you shouldn't be doing that anyway, it isn't considered a big deal (and it's a definite design decision on Laurent's part -- a bug report isn't the way to go.)

[BHX]

I apologize for derailing this, but I just wanted to say that I'm gaining a lot of insight from this discussion especially between Disch, computerquip, and cire. I've never written a library except the tutorials you can find on how to right one, but this discussion has made me take note of things to avoid and things to consider when it comes to the point where I need or want to write one.