Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Foaly

Pages: 1 ... 3 4 [5] 6 7 ... 31
61
Feature requests / sf::Text horizontal character spacing
« on: July 21, 2015, 11:36:44 am »
Hi there,
I want to propose a feature that I think sf::Text is missing. Vertical spacing between characters (letter-spacing).
It kept reappearing in a couple of my projects now, so I thought I suggest it. For example there are some fonts that I used of the web. They looks fine on a regular size, but if I scale them up to a very big or down to a very small size, the spacing between characters just doesn't look right anymore. The whole text looks streched/squeezed and it affects the readability (could also be used as an effect thought). It would be nice if you could counter that.
Besides that it would enable people to do bounchy/streching effects with text.
This is nothing excotic and users know this feature from software like GIMP/Photoshop, Word/LibreOffice or from CSS. It's just something you would expect from a multimedia library handeling text.
I have helped myself with a modified version of sf::Text in the past, so there is a tested code ready to go.
What do you guys think?

62
SFML projects / Re: Thor 2.0
« on: July 10, 2015, 02:01:39 pm »
Hello there!

I don't know if this is the right thread for this, but I have a problem compiling Thor.
I have pulled the lasted github version, configured cmake to point to SFML (2.3.0) and then generated two seperate debug and release projects (codeblocks).
When I open the debug project, compile and install it everything works as intended. But when I try to compile the release project, I get the following compile error:

Code: [Select]
cd /d F:\Librarys\Thor\Build\Release\src && C:\MinGW\bin\g++.exe   -DTHOR_EXPORTS -Dthor_EXPORTS -std=c++0x -O3 -DNDEBUG @CMakeFiles/thor.dir/includes_CXX.rsp   -o CMakeFiles\thor.dir\Action.cpp.obj -c F:\Librarys\Thor\Thor\src\Action.cpp
In file included from c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\cmath:44:0,
                 from c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\random:38,
                 from c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\bits\stl_algo.h:65,
                 from c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\algorithm:62,
                 from F:/Librarys/official_SFML/install/include/SFML/System/Utf.hpp:32,
                 from F:/Librarys/official_SFML/install/include/SFML/System/String.hpp:32,
                 from F:/Librarys/official_SFML/install/include/SFML/Window/Joystick.hpp:32,
                 from F:/Librarys/Thor/Thor/include/Thor/Input/Joystick.hpp:34,
                 from F:/Librarys/Thor/Thor/include/Thor/Input/Detail/ActionOperations.hpp:29,
                 from F:/Librarys/Thor/Thor/include/Thor/Input/Action.hpp:32,
                 from F:\Librarys\Thor\Thor\src\Action.cpp:26:
c:\mingw\include\math.h: In function 'float hypotf(float, float)':
c:\mingw\include\math.h:635:30: error: '_hypot' was not declared in this scope
 { return (float)(_hypot (x, y)); }
                              ^

According to this SO its a MinGW compiler bug (I am using gcc 4.8.1 on windows). I fixed it like the first answer sugessted, but I was wondering, why is Thor using the flag -std=c++0x and not -std=c++11 ? It doesn't make a difference in this case, but I just noticed that. (also I wanted to show other people a solution, who might run into the same problem)

63
SFML wiki / Re: Animated Sprite class
« on: March 08, 2015, 01:52:12 pm »
Please go ahead and tell us what you would change/improve. New stuff is always welcome!

64
SFML wiki / Re: Settings parser
« on: December 06, 2014, 11:26:42 pm »
Hi there!
The settings parser class has gone through some changes recently. I finally had some time to wrap it all up nicely and update the wiki page.
The class uses templates now and features things like reading/writing values from/to a vector. Parsing has been moved to a seperate function and is now more robust. Lots of small things (like using auto) have changed. For a full changelog just refer to the commit history of the repo.
All the things mentioned in this thread should be fixed. So check it out and let me know what you think! :)

65
SFML wiki / Re: Settings parser
« on: October 05, 2014, 02:35:18 pm »
There is nothing wrong with std::getline(), that's what I am using right now.
But Nexus suggested that he did something a little more elegant with >>. That's why I asked if it's possible to extract multiple words containing whitespace into one string.
But I guess that's not possible, so I'll stick with getline()

66
SFML wiki / Re: Settings parser
« on: October 05, 2014, 02:44:12 am »
I investigated a little bit and unless I am missing something, I don't think this can help me. From what I understand std::noskipws only effects leading whitespace. But what I would need is to change the seperator for the >> operator. So I can parse something like that
Code: [Select]
key = some value containing spaceBut I don't think that's possible, is it?

67
SFML wiki / Re: Settings parser
« on: September 29, 2014, 12:30:30 am »
Wow that is indeed very few lines for a simple key value parser. Thanks for sharing the code.
I don't think it will work for my case though, because I want to support strings containing whitespace as a value type. And according to the doc the >> operator separates at whitespace, meaning I would only get the first word. I don't see a way to change that, so there seems to be no other way but std::getline().

68
Feature requests / Re: small & stupid api changes: radians, vectors, colors
« on: September 22, 2014, 03:06:40 pm »
Just wanted to say that I also think that 3 is a good idea!

69
SFML wiki / Re: Settings parser
« on: September 21, 2014, 03:26:38 pm »
Alrighty I gave the class another overhaul. Now only the data nessessary is kept in memory. Keys are now unique and will be overwritten if used more than once. A std::map is used to ensure that and also because it is the easiest to find the keys. Writing modified data back to the file is still supported.
Also strings containing whitespace are now supported and there were quiet a few bug fixes :)
I created a git repo with the code here and I update the code on the wiki page.

edit: @Nexus: what kind of link do you want me to add in the first post? A link to the wiki page is already there.

70
SFML wiki / Re: Settings parser
« on: September 18, 2014, 11:39:21 am »
Hello everybody!
Like I said I was away for a bit, but I found some time to look at the code again.
I thought about the suggestion that Jesper Juhl made (using a std::map instead of a std::vector, to ensure unique keys), but since this class also supports changing the values and writing them back to the file, the order of insertion is important and needs to be preserved. That's why I will stick with the std::vector. I updated the documentation to clarify that keys have to be unique.
I also refactored the read() method to be more robust handling whitespace and I rearranged some includes.

71
SFML wiki / Re: Settings parser
« on: August 05, 2014, 11:16:40 am »
Thanks! Those are really good point. But since I am on vacation, I can't investigate your suggestions… I will look into it when I get back  :)

72
General discussions / Re: Multi Monitor Setup
« on: July 31, 2014, 05:41:36 pm »
Hmm those are actually good points.
It seems as if you are right about the first point. I don't think that many parts need to be refactored, but it might be more than this one method. For example the getFullscreenModes() method also only querys the first monitor for valid modes. I noticed this, because the code I posted doesn't work 100% as you'd expect it. It only makes the window fill the whole screen of the second monitor, but it keeps the video mode from the first monitor (meaning the output is askewed, because my second monitor has a different aspect ratio)
About the second point. I'm not an expert on this, but what I understood from my reseach is, that windows spanning over mutiple monitor and resources shared between graphic cards are handled by the operating system (on windows at least).

73
General discussions / Re: Multi Monitor Setup
« on: July 31, 2014, 01:13:56 am »
Haha good! Then we are on the same page :D Because that is exactly what I said in my first post.
I know it's planned to be implemented, but if you take a look at the ticket it hasn't been touched in the last 2 years. Also this issue does not have a very high priority, since right now there are things more important (like finishing the moblie ports etc.)
Thats why I suggested to let the window go into fullscreen on the current monitor instead of statically picking the first one. That would offer a clean workaround untill a proper API has been developed.

74
SFML wiki / Re: Settings parser
« on: July 30, 2014, 11:59:07 am »
Aah damn! I knew something felt odd, while I was doing this... But it was early in the morning and I thought I simply forgot the const. Didn't think there for a minute :D
Thanks for pointing this out. And also thanks for the links! I didn't know you could make the parameters in the implementation const but not in the interface. Very interessting.
Anyway I removed the const from the interface.

75
General discussions / Re: Multi Monitor Setup
« on: July 30, 2014, 10:36:49 am »
Well... that's exactly my point :D
The topic seems to be rather complicated and it doesn't have a high priority since not a lot of people have requested it. (altough I remember a couple forum threads and there is even a issue on the tracker)
Thats why I suggested to let the window go into fullscreen on the monitor its currently in. This offers a simple way to select the monitor for fullscreen, by simply moving the window to the correct monitor and then let it go fullscreen.

Pages: 1 ... 3 4 [5] 6 7 ... 31