SFML community forums
Help => Graphics => Topic started by: NPS on January 16, 2013, 09:39:44 pm
-
I'm loading a font with Font::LoadFromFile() and it returns true but when i Draw it on the screen, the font is always the same (the default one, I guess). What's wrong?
-
If you don't use sf::Text::setFont (http://www.sfml-dev.org/documentation/2.0/classsf_1_1Text.php#a2927805d1ae92d57f15034ea34756b81) (or provide your font in sf::Text constructor), the text is drawn with the default font indeed.
Note that in recent versions (on github) of SFML , there isn't a default font anymore.
-
Read this: http://en.sfml-dev.org/forums/index.php?topic=5559.0 (http://en.sfml-dev.org/forums/index.php?topic=5559.0)
There is almost no information in there, so we can't help you unless you show us some code.
Correct me if I am wrong on this.
It's my guess that you are using SFML 1.6 due to the capital letter in the function. SFML 1.6 hasn't been touched in two years and it won't be worked with any further, while SFML 2.0 has bug fixes and overall nice features in the Graphics module. The switch is the best option.
-
Eh... my inadvertence. You're right, G., I didn't actually set the font to sf::String.
As for the version - I notices a couple of topics tagged with "[2.0]" so I asumed every other topic was concerning 1.6.
One more question about fonts - is there a way to load system fonts (without having to copy font files into the application directory)? Is the only way of doing that providing the full path (e.g. "C:/Windows/Fonts")?
And a little offtopic - the SFML page states that 1.6 is the "current" version. Somewhere I read that 2.0 is a little bugged or something, anyway - it's not fully stable/done. Are you saying it's not true (and everyone should use 2.0)? If so, imo the web page should state that explicitly.
-
Yeah, I didn't notice it was 1.6. ^^
Using 2.0 is perfectly fine, it's actually the recommended version and yes you should use it.
There are a few threads about this. The website will be updated when 2.0 is officially released.
-
I've changed the version of SFML to 2.0 and I regret that already. The tutorials section is only like stated and misses most of the functionality so I have to read through whole documentation and compare both versions to discover by myself what changed (class names/functions/whole functionalities). In what universe is it "recommended" to use undocumented version of a library?
-
It's not undocumented as you've already said yourself... ;)
The documentation is fully complete, the tutorials aren't yet. But most of the parts are every similar and if you understand the SFML 1.6 tutorials you should also understand how to use SFML 2, while keeping an eye on the documentation.
Tutorials are anyway only interesting in the beginning, once you understand the concept you'll always deal with the documentation directly.
You can also take a look at the also incomplete FAQ (https://github.com/SFML/SFML/wiki/FAQ), which is maintained by the community.
Thus just because some tutorials are lacking for a newer and better version, doesn't mean that the old version is still recommended. It's 3 years old and has some serious bugs. On top of that most of the community members can't help much with directly related SFML 1.6 problems, since they haven't touched it in years... ;)
-
Still - reading tutorials to the previous version and then looking (by oneself) for all the differences between the versions is not the way to go.
-
Nobody forces you to do anything, if you feel better with SFML 1.6 go for it, but don't get angry when people point you towards SFML 2 (which happens nearly every time someone posts some SFML 1.6 code). ;)
The tutorials are in the work - you should remember that SFML is written by one guy in his freetime, side by side to his real life, which involves family + work and everything is done for free and even with a zlib license on it. :)
-
I do realize the latter and I'm not complaining whatsoever. I just wanted to point out that the recommended version of a library should not only have full API documentation but also its usage fully described (tutorials/samples). Which I did.
-
I just wanted to point out that the recommended version of a library should not only have full API documentation but also its usage fully described (tutorials/samples).
Seeing that the documentation is complete and that all the examples exist and that 2/3 of the tutorials are already written, I just can't value an outdated, buggy and feature-lacking version more than a few missing tutorials next to a shiny new library, which has a nicer overall code design, runs more stable and brings an evolving community mostly surrounded around this version. ;)
Good luck then on your SFML 1.6 journey and have fun rewriting/relearning everything anyways once SFML 2 gets officially released. :)
-
Gee, why are you such a hater?
And I think you're exaggerating with all that, I can't say I have much experience with SFML 1.6 but I've never had any problem with that library.
Btw where exactly do all these examples exist?
-
https://github.com/SFML/SFML/tree/master/examples
-
Gee, why are you such a hater?
Why am I a hater? I don't hate you. I don't hate SFML 1.6. I also don't hate you for using SFML 1.6. Not sure what you're getting at here. :)
And I think you're exaggerating with all that
If I may ask: How? Or what seems to be exaggerated?
As an example: If you don't link SFML 1.6 statically into your application, around 50% of the users won't be able to run your application due to the ATI bug. I wouldn't call that stable at all... ;)
I can't say I have much experience with SFML 1.6 but I've never had any problem with that library.
Well many here, who say SFML 2 is better, have been around when SFML 1.6 was the only version to go at, thus they have more experience and can often tell better where the up and down sides are. I've only slightly touched SFML 1.6, then ran into the ATI bug on my system and moved on to an early version of SFML 2, so yes maybe my judgement isn't the best, so don't listen to me. ;D
-
Oh, you're a hater all right. This sentence alone proves it: "Good luck then on your SFML 1.6 journey and have fun rewriting/relearning everything anyways once SFML 2 gets officially released."
Hmm... ok, I guess I'm done with the offtopic. :P
-
Oh, you're a hater all right. This sentence alone proves it: "Good luck then on your SFML 1.6 journey and have fun rewriting/relearning everything anyways once SFML 2 gets officially released."
Hate is an emotion of intense revulsion.
I didn't really feel emotionally when writing that sentence and certainty not an intense revulsion. ;)
It of course was irony, which unfortunately is sometimes hard to interpret, especially from written words. With that I just wanted to point out, that you'll only shoot yourself in the foot when sticking to SFML 1.6, because sooner or later you'll probably anyways move to SFML 2 and have to rewrite and relearn everything then. The sooner you start the less rewrite is needed.
So the punctuation was on the 'fun' not being funny at all in the future and not really on the 'good luck' part, that was meant and still is meant serious. ;D
-
Well many here, who say SFML 2 is better, have been around when SFML 1.6 was the only version to go at, thus they have more experience and can often tell better where the up and down sides are.
I can totally confirm that. Five years ago, I started using SFML, at that time it was at version 1.2. Since then, I have followed the development quite actively, and I can say that the library has improved vastly in that time. NPS, this is difficult to judge if you have just begun to work with the library. You don't know what advantages SFML 2 brings you before you see the limitations of 1.6.
Just to come up with another example: In SFML 1.6, it was not possible to load images that are bigger than the texture limit of your graphics card (now it can be split). Therefore, drawing a background image of 1000 pixels width might already be an issue on computers that are a few years old. Also, you had no possibility to detect when the window loses focus, to pause a game. You could not load images directly from a stream (like a file archive). There are tons of examples like this, when using SFML 1.6 you will be left completely alone. Not only because most forum users work with version 2, but also because you have no chance of a bug ever being fixed, or a feature ever being introduced -- unless you switch to SFML 2.
So no, eXpl0it3r is not exaggerating at all. And you shouldn't feel offended so fast on the internet ;)
-
Eh... You're a hater because you treat SFML 1.6 like pure evil. You don't need to actually feel hatred for that term to apply. And I don't understand why we're even arguing about the words and semantics...
Nexus, by saying exploiter was exaggerating I meant the SFML 1.6 being that bad, not SFML 2.0 being that much better.
-
I meant the SFML 1.6 being that bad, not SFML 2.0 being that much better.
While I understand your point I can tell that both Nexus and eXpl0it3r are right. If you haven't heard of it then look for the ATI bug that 1.6 had. Not working well for a large portion of hardware is a grand sin for a multimedia library, that has (and mostly could have only) been overcome with time and experience. The whole graphics API was rewritten for a reason.
For your project 1.6 may be fine, but for anything else is non-sense unless you have a real reason for not changing, honestly I can't think of one other than your case.