Messages

1

General discussions / Re: SFML Blueprints - Another SFML book

« on: October 26, 2015, 09:32:37 am »

• Did you clone the project from here? https://github.com/Krozark/SFML-book . Some bug fix have been made since the book release (but don't related with your error).
• Concerning the alternative keywords, we already debate on it.
• If the problem persist, use another compiler such as mingw : http://freefr.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-posix/seh/x86_64-4.9.1-release-posix-seh-rt_v3-rev3.7z . I ensure that all work well on windows (7,8,8.1) with this one.

Edit :  PATH_MAX is define by windows headers.

2

General discussions / Re: SFML Blueprints - Another SFML book

« on: September 15, 2015, 06:08:29 pm »

No as it was already detail in another SFML book (the first one).

3

General discussions / Re: SFML Blueprints - Another SFML book

« on: September 14, 2015, 10:04:30 am »

I propose to stop the conversation about alternative tokens,as we totally derived from the topic of this thread.
It seems obvious that everyone has a different point of view, and this will not change.

4

General discussions / Re: SFML Blueprints - Another SFML book

« on: September 13, 2015, 06:24:24 pm »

I'm totally agree with you concerning the usage of digraphs and trigraphs.
Concerning the alternatives keywords, this is another story.
I've came to the point that this is maybe like the indentation (tabs / spaces) or comparison order (var == value / value == var)  : just different point of view.

By the way: Congratulations on actually finishing a book

Thanks !

5

General discussions / Re: SFML Blueprints - Another SFML book

« on: September 13, 2015, 04:06:18 pm »

If you don't believe that many C++ developers are confused by those keywords

I've admit this in a previous message :

I understand that it can be confusing at first

then at least accept that the probably most widely used C++ IDE does not support them

I only tried Code::Block and Visual Studio as IDE for C++, so I can only speak for them (I personally, used GVim). The first on support them completely (without any changes), and the second on with the flag /Za.
The reason that Visual studio don't support them by default is to be compatible with C (according to my research on the subject). But we make C++ not C, so ...

6

General discussions / Re: SFML Blueprints - Another SFML book

« on: September 13, 2015, 03:48:39 pm »

Since you compiled, could you just share binaries?

I've add them here : https://github.com/Krozark/SFML-book/tree/master/bin/win64 (build on windows 8 x64)

7

General discussions / Re: SFML Blueprints - Another SFML book

« on: September 13, 2015, 12:49:08 am »

They are a legacy from a time where many systems couldn't type characters like "!", "{" and "|". These days they should just be avoided. C++17 even removes (not just deprecate) a lot of that old cruft.
It's like "the 80's called; they want their trigraphs back"

You're wrong.
C++17  rewove Trigraph ( ??<, ??( ,...) that's true.
But here we are speaking of the alternative operators (and, or, not, xor, bit_or, ...) of standard ISO C++  created a while ago.

I understand that it can be confusing at first but, we are talking about a book. And the goal of it is to learn some new thing to the reader. Maybe it can be the first one.

Personally I think that it's more readable, and you avoid mistakes like "|" instead of "||".
I don't know any reason to avoid them, now if there is a real one (and don't say "Nobody is using it, so don't") please let me know.

I tried mingw, but I'm getting

I'm not able to reproduce your link error. Can you share your compiler version.
It look like a linker error on sfgui.
Did you take the code here : https://github.com/Krozark/SFML-book ?

8

General discussions / Re: SFML Blueprints - Another SFML book

« on: September 12, 2015, 04:47:40 pm »

Those operators are specified in the standard. I don't see why I should avoid them. All the good compiler support them.
And if you really want to use visual studio, you can activate them with a flag, but I don't remember which on.
EDIT : the flag is /Za according to https://msdn.microsoft.com/en-us/library/vstudio/2e6a4at9%28v=vs.110%29.aspx

9

General discussions / Re: SFML Blueprints - Another SFML book

« on: September 12, 2015, 04:29:57 pm »

99.9% of C++ projects avoid those keywords, it's well-known that they're not portable. Unfortunately it seems like not even Visual Studio, one of the most widely used IDEs, has been used for testing...

I've point this in the first chapter of the book. Visual studio doesn't sported full C++11 (VS 2013), and some feature not supported where required (don't remember which one).
You can use mingw our clang (as suggested in the same chapter), and all will  be fine (tested on linux/windows).

10

Feature requests / Re: Add sf::BlendMode::ReverseSubtract

« on: August 17, 2015, 04:19:59 pm »

Still, the example itself (red things not showing under blue light but showing under red light) seems to be the kind of thing you would do with multiplication.

I was trying to find an example of usage, and you're right, multiplication is a better solution.

My opinion (in case of ambiguity): Add ReverseSubtract only

11

Feature requests / Re: Add sf::BlendMode::ReverseSubtract

« on: August 17, 2015, 09:57:46 am »

In case it was not clear: I'm ok for adding reverse subtract, my objections are only about min and max.

Ok, I don't have any example for Min, here is for Max:

Let's take the case of a game were your hero have only light as weapons (in fact, this is the plot of the game that DaiMysha is working on).
Imagine some monster that can be see only by specifics light color (let's take the example of a pure Red).
Now put you hero in a dark dungeon plain of this kind of monster. He turn on his torch light in Blue, and nothing appear. Change it's light color to Red, and .... plenty of monster appear where nothing was visible with the blue light.

I hope you understand the example.

Concerning the implementation, I think there is a lot of solutions, but this is one using BlendMode.
Just make a Min between you light map (texture with only the light), and draw the monster texture (of Red color) with a Min on the top of it.
Now, I don't know if it's the best example to illustrate the Min functionalities.

I am really mixed about these features (Min/Max), and personally I think I would never use them.
I join point of view of Laurent.

12

Feature requests / Re: Add sf::BlendMode::ReverseSubtract

« on: August 15, 2015, 05:53:15 pm »

I'm glad this conversation is fruitful.

I'll open an issue on the SFML github, then make a  pull request with the appropriate modifications.

13

Feature requests / Re: Add sf::BlendMode::ReverseSubtract

« on: August 14, 2015, 02:12:17 pm »

More options means the functionality is less straight-forward to use. It is more complex for someone without knowledge on blending modes, to figure out what he needs if all possible options are exposed to him, rather than just the most useful ones.

Surely this is what tutorials and documentation are for? You can highlight which ones are the most commonly used ones and which ones are more advanced as well as what each one does. Surely you don't expect that people work out what to write purely by guessing what it will be called and then using the auto-complete/intellisense functions of an IDE.

+1 : totally agree.

Moreover, if a user start to use BlendMode, we can say that it's not a novice anymore. I'm sure that he will know how to search thought the documentation (which is very complete) to find the needed informations.

14

Feature requests / Re: Add sf::BlendMode::ReverseSubtract

« on: August 14, 2015, 01:36:13 pm »

Correct me if I'm wrong, but this just extending an enum (from the user's point of view) and that doesn't make SFML harder to use

Exactly, and a switch on this enum  values to complete (from a SFML developer point of view).

15

Feature requests / Re: Add sf::BlendMode::ReverseSubtract

« on: August 14, 2015, 11:17:14 am »

However I still don't understand what these "negative" lights mean; what effects do you achieve with them?

In reality negative light don't exist at all, but let take the case of a RPG. Imagine that your hero can throw spell of darkness, witch remove a color.
This is the idea of negative light.

Example :
Ambient color = (127,50,203)
Darkness spell  = (0,12,150)

final scene color = Ambient color  - Darkness spell
                = (127, 38, 53)

Could it be that this concept of "negative light" is a wrong solution to a more fundamental problem (lighting algorithm)?

I don't think so. It' more a new concept (which is be a bit confusing, I agree).

Regarding the other OpenGL blend modes, there is an obvious reason to not add them "just because they exist": SFML is a simple library, not a 1:1 wrapper on top of OpenGL.

I understand It. This is why, through this thread, we try to convince you (and other SFML team member) the need of it through concert example.