Well, SFML is annoying.
| Therefore, I asked a question. If that isn't the point of a forum, then please enlighten me. |
| And also, it seems as if SFML is actually geared towards new programmers. The amount I work it does for you is almost annoying. |
Anyway, back to the original topic, where you able to run the example I posted or the SFML samples Laurent suggested?
Well well I downloaded the source and built them on my Linux VM and the same code works on there. No idea what the problem was on my Windows, but I'm done with this thread. It seems to have blown up into some philosophical debate over how to ask a question, and frankly I don't care.
I think it's interesting. They're about to dissect BHXSpecter for his "ugly API" comment.
@ResidentBiscuit
Theres obviously nothing wrong with the code so it must be your setup on windows. Maybe try recreating the project following sfmlcoders guide. http://sfmlcoder.wordpress.com/2011/05/18/creating-a-first-sfml-project/
Maybe you should care, a good question will get good answers.
Theres obviously nothing wrong with the code so it must be your setup on windows. Maybe try recreating the project following sfmlcoders guide. http://sfmlcoder.wordpress.com/2011/05/18/creating-a-first-sfml-project/
| It seems to have blown up into some philosophical debate over how to ask a question, and frankly I don't care. |
Last edited on
As far as I know, my question was fine. If I don't live up to your standards of question asking, don't bother commenting. Simple as that. I don't see where suddenly this became my fault.
I remember going to Sfml to ask a question related to the vector class , the only comment I got was "maybe you should learn c++ before you ask" .
| As far as I know, my question was fine. |
| Need4Sleep wrote: |
|---|
| the only comment I got was "maybe you should learn c++ before you ask" . |
Edit:
| ResidentBiscuit wrote: |
|---|
| If I don't live up to your standards of question asking, don't bother commenting. Simple as that. |
Last edited on
| Considering the original post had incorrect code not relating to the problem, I'd say the question post was not fine. |
My original post at SFML was exactly related to the problem. It was my code that was not working. I had an edit it in there saying I took something out not related, because it really wasn't related to the problem. The code itself, was exactly the problem. At least I thought so due to it not working for some reason on my computer.
So, I don't really get where you say my original post over there was not related to the problem.
| So, I don't really get where you say my original post over there was not related to the problem. |
| Catfish2 wrote: |
|---|
| I think it's interesting. They're about to dissect BHXSpecter for his "ugly API" comment. |
Well if you notice I'm avoiding getting into why it is ugly because I already know that no matter what you point out (as I've seen numerous threads point out the ugly parts of the API) they won't change it. Both developers are set in their ways and refuse to acknowledge anything is wrong with their API or code so when it is pointed out they do a half ass reply saying they know but it is how the intended it to be.
| Both developers are set in their ways and refuse to acknowledge anything is wrong with their API or code so when it is pointed out they do a half ass reply saying they know but it is how the intended it to be. |
You are grossly misinterpretting their intentions. You make it sound like they don't care about the API. That could not be further from the truth.
Laurent actually weighs heavily on pros and cons of API changes in order to make the API as simple and functional as possible. The problem is that you can never have a "perfect" API... they're always going to have warts. He's not above making recommended changes in the lib... and I've seen him do so several times in the past. When SFML2 was in alpha stages, he even opened the floor to user suggestions as to how to sculpt the new API.
Besides... just because you would design an API differently doesn't mean the existing API is broken. If Laurent changed the API over every user suggestion, it would change every other day and become wildly unstable. Realistically, he's going to have to say "no" to recommended API changes most of the time.
And talk about a double-standard. Tell me how successful you've been with getting the SDL developers to change their API. And look at the functionality of SFML's API vs. the functionality of SDL's API. SFML's is a dozen times more capable... yet it's considered more broken? Hogwash.
If you want to throw a temper-tantrum and refuse to use a good library because you don't get along with the userbase of its forum, that's your call. Personally I think it's foolish... and I don't think you're "sticking it" to anyone other than yourself.
Last edited on
All I've ever seen Laurent do is say no to API changes. I just personally think the API is ugly and while I've seen the userbase of its forums have an attitude toward noob programmers I still play with SFML. This comment blew me away:
How does a library being written in C make it cumbersome? I've coded Pong Clones in all 3 and the APIs look almost identical to each other(granted SFML abstracts more), but yet they say SDL/Allegro has ugly API while SFML has clean API. Also, don't know about SDL, but Allegro takes care of anything you forget to delete or remove after your program closes last I knew in the Allegro 5 releases. You can't say your API is clean then bash an identical API for being ugly, makes no sense to me.
| It is already more cumbersome to program with SDL/Allegro because they are written in C, with all the corresponding drawbacks. |
How does a library being written in C make it cumbersome? I've coded Pong Clones in all 3 and the APIs look almost identical to each other(granted SFML abstracts more), but yet they say SDL/Allegro has ugly API while SFML has clean API. Also, don't know about SDL, but Allegro takes care of anything you forget to delete or remove after your program closes last I knew in the Allegro 5 releases. You can't say your API is clean then bash an identical API for being ugly, makes no sense to me.
| All I've ever seen Laurent do is say no to API changes. |
Why does this upset you? In a way it's a good thing because changing the API breaks usability. Whenever you change the API, every program that uses the lib has to be updated. That's a huge reason to avoid doing it unless there's a very, very good reason.
One user's personal opinion of thinking the API is ugly is not a good reason. Laurent is right for not changing it on those grounds.
And again --- how many times have you seen SDL/Allegro change its API based on user suggestions? Has SDL even changed its API at all in the last 10 years?
| This comment blew me away: |
I agree that comment is pretty lame. I won't try to defend it.
The only thing about SDL I'd call cumbersome is its lack of RAII (which is due to it being a C lib). Though I wouldn't extend that to say the whole lib is cumbersome. And I don't know anything about Allegro so I won't comment.
Well BHXSpecter, you must have known from the start that the perception of ugliness is a subjective thing, so unless you can convert the idea of an "ugly API" to "hard-to-use API", "confusing API", with arguments and examples, then it's all just wasted effort.
@Disch
The Allegro API had subtle changes between A3, A4, and A5 and I'm amazed at how many people have had issues with it. The only change they did to the API in part was they added al_* in front of all the function calls and a few they combined. Though A5 is a new library and drops all backwards compatibility too. Last I knew they added iOS support to it. I believe Monster RPG 2 (http://www.nooskewl.com/content/monster-rpg-2-111-android-now-available ) is an Android Allegro game.
SDL 2 must have changed some of its API because my SDL apps return errors to some functions saying they aren't defined in SDL2.
Also, I never gave up on SFML, I still use it, just think the API is ugly, but I think all the libraries I use have ugly APIs and make wrappers for them.
@Catfish2
Yeah, I knew I was stirring up a hornets nest with my opinion. Though I love how they can't accept someone thinks it is ugly and want proof of why they think it is. Guess they don't understand how opinions work.
The Allegro API had subtle changes between A3, A4, and A5 and I'm amazed at how many people have had issues with it. The only change they did to the API in part was they added al_* in front of all the function calls and a few they combined. Though A5 is a new library and drops all backwards compatibility too. Last I knew they added iOS support to it. I believe Monster RPG 2 (http://www.nooskewl.com/content/monster-rpg-2-111-android-now-available ) is an Android Allegro game.
SDL 2 must have changed some of its API because my SDL apps return errors to some functions saying they aren't defined in SDL2.
Also, I never gave up on SFML, I still use it, just think the API is ugly, but I think all the libraries I use have ugly APIs and make wrappers for them.
@Catfish2
Yeah, I knew I was stirring up a hornets nest with my opinion. Though I love how they can't accept someone thinks it is ugly and want proof of why they think it is. Guess they don't understand how opinions work.
Last edited on by closed account z6A9GNh0
Laurent never asked for proof its ugly, but he does want to know why you think its ugly because he clearly takes users opinions seriously.
Huge rant ahead ;) I'd think it's unfair to call SFML an "ugly" API, as it's one of the few well structured C++-style API's I've seen. It makes very clean use of inheritence and polymorphism, etc, most notably in how easy it is to use sf::Shape, sf::Image, sf::Texture, etc interchangeably, as they all cleanly inherit from the sf::Drawable Abstract-Class.
However, one huge issue I've found with SFML is video card support. So far SFML applications will not run on ANY AMD (aka ATI) video cards unless you statically link to the SFML library. This bug is a throwback to SFML 1.6 where AMD video cards simply wouldn't work at all in many cases (interestingly, Laurent went around saying the problem would be fixed in SFML2, lo and behold, it wasn't). Sure, you can at least use the API on AMD cards if you use SFML2 (which was less of a good option 6 months or so ago), and statically link (which means any new library DLL releases require you to recompile and re-release your application, rather than simply issueing an small installer with the new DLLs).
This problem gets worse though. A few days ago, I realized my WIP SFML game was not rendering on my laptop with an Intel GMA965 integrated GPU (which does support OpenGL 2). The game started fine, and I could hear the music playing, and with a couple of debug statements, the backend was working (moving, collision, etc), just the window was blank (in fact, I could see the Explorer window underneath it). At first I thought it was a driver bug in the laptops driver, which was fairly old and hasn't seen updates in a while. Tried it on an entirely different Intel chipset (in a desktop, this time with a newer Intel integrated GPU), same thing. After some Googling around, surprise surprise, SFML's RenderTexture class (which is fairly important if you're blitting many small textures and applying shaders, which I am) does NOT work with ANY Intel GPUs. No work around this time. Now, I understand that Intel has a bad track record when it comes to proper OpenGL compliancy, but Minecraft, which uses JOGL (Java OpenGL binding), works fine on both computers, even with shaders.
What bothers me most about these problems is how cavalier Laurent is regarding them. When people make forum posts regarding the fact that his API only works completely on about 30% of video cards in use, he makes off-hand comments like:
"I am aware of the problem, I'm looking at fixing it in SFML2, though it is fairly difficult."
"The problem is fairly low-priority at the moment, just statically link."
Despite being "aware" of these things, he doesn't bother mentioning them anywhere on the main website or in the documentation (if you know that a class in your library flat out doesn't work with one vendor's hardware, you should probably mention that in the documention before someone spends a week implementing it, only to find out it won't work).
The other problem I've encountered is SFML's high memory usage. A game that ran with a memory footprint of under 3 megabytes with SDL runs at 40MBs under SFML (this is a 160x144 gameboy game clone mind you). I've tried everything to verify whether it's me or SFML, such as extending the Stack size and placing everything on the stack rather than using the heap for allocation (With new/delete), to make sure it's not a memory leak in my program, but the memory usage remains the same. The bizarre part is that SFML is supposed to make use of hardware acceleration automatically, which means apparent memory usage should be much less than SDL, since textures can be stored in video ram rather than system memory.
It's really saddening, since I loved the structure of SFML's API, but it has so many issues that the developer just shrugs at, I'm considering making the move to another API. Again.
However, one huge issue I've found with SFML is video card support. So far SFML applications will not run on ANY AMD (aka ATI) video cards unless you statically link to the SFML library. This bug is a throwback to SFML 1.6 where AMD video cards simply wouldn't work at all in many cases (interestingly, Laurent went around saying the problem would be fixed in SFML2, lo and behold, it wasn't). Sure, you can at least use the API on AMD cards if you use SFML2 (which was less of a good option 6 months or so ago), and statically link (which means any new library DLL releases require you to recompile and re-release your application, rather than simply issueing an small installer with the new DLLs).
This problem gets worse though. A few days ago, I realized my WIP SFML game was not rendering on my laptop with an Intel GMA965 integrated GPU (which does support OpenGL 2). The game started fine, and I could hear the music playing, and with a couple of debug statements, the backend was working (moving, collision, etc), just the window was blank (in fact, I could see the Explorer window underneath it). At first I thought it was a driver bug in the laptops driver, which was fairly old and hasn't seen updates in a while. Tried it on an entirely different Intel chipset (in a desktop, this time with a newer Intel integrated GPU), same thing. After some Googling around, surprise surprise, SFML's RenderTexture class (which is fairly important if you're blitting many small textures and applying shaders, which I am) does NOT work with ANY Intel GPUs. No work around this time. Now, I understand that Intel has a bad track record when it comes to proper OpenGL compliancy, but Minecraft, which uses JOGL (Java OpenGL binding), works fine on both computers, even with shaders.
What bothers me most about these problems is how cavalier Laurent is regarding them. When people make forum posts regarding the fact that his API only works completely on about 30% of video cards in use, he makes off-hand comments like:
"I am aware of the problem, I'm looking at fixing it in SFML2, though it is fairly difficult."
"The problem is fairly low-priority at the moment, just statically link."
Despite being "aware" of these things, he doesn't bother mentioning them anywhere on the main website or in the documentation (if you know that a class in your library flat out doesn't work with one vendor's hardware, you should probably mention that in the documention before someone spends a week implementing it, only to find out it won't work).
The other problem I've encountered is SFML's high memory usage. A game that ran with a memory footprint of under 3 megabytes with SDL runs at 40MBs under SFML (this is a 160x144 gameboy game clone mind you). I've tried everything to verify whether it's me or SFML, such as extending the Stack size and placing everything on the stack rather than using the heap for allocation (With new/delete), to make sure it's not a memory leak in my program, but the memory usage remains the same. The bizarre part is that SFML is supposed to make use of hardware acceleration automatically, which means apparent memory usage should be much less than SDL, since textures can be stored in video ram rather than system memory.
It's really saddening, since I loved the structure of SFML's API, but it has so many issues that the developer just shrugs at, I'm considering making the move to another API. Again.
| GetOutOfBox wrote: |
|---|
| I'd think it's unfair to call SFML an "ugly" API |
My opinion still stands, never said any body else had to agree with it. Though, I've looked at the APIs between SFML/SDL/Allegro and between the three the APIs have similarities, but it is interesting to me that they say the other two APIs are ugly even though they are similar (at least from the limited uses I have done with them all). For arguments sake though, fine, the API is beautiful, clean..so sexy I want to marry it but that doesn't mean jack shit because it is a sexy piece of crap on 70% of the cards, as you pointed out, that can't run SFML applications. It concerns me that they were more focused on aesthetics of the API and learning tricks rather than if I meant it was ugly in code structure. With the attitude of the important things being low-priority makes me think he is more interested in the look of the API rather than the actual use of the library. Allegro is my primary, SDL is my secondary, and SFML is my third choice when doing projects, but I do actually pick projects to solely in each (and I've done projects across all three before just for the hell of it).
| it is a sexy piece of crap on 70% of the cards, as you pointed out |
I think he actually said it doesn't work unless you statically link. Don't people do that for Windows binaries anyway? I know I sure do. In which case it's a nonissue.
No, most the programmers I know do dynamic linking so that you have to include DLLs/SOs with your game/applications.