Messages

31

General discussions / Re: C++ ISO Standard Committee 2D Graphics Library Discussions

« on: September 26, 2013, 06:05:55 pm »

Sorry, I didn't have time to get into details. Sot summup, what you think about Mr. Sutter is besides the point because the C++ standard is an ISO standard which means it's voted by countries, not companies. Companies can push for features but if not a majority agree, it don't get into the standard. That Mr Sutter is from Microsoft doesn't mean the proposed library (which have no proposal at the moment so it's not even a proposed library) will or will not get voted in. However, if an implementation is provided, it have great chances of be evaluated as fast as possible.
The rant about Mr Sutters presentation is besides the point of the thread which is about participating into designing a library to do, basically, what SFML, Cinder, OpenFrameworks and other libraries I forget do. It's not about Microsoft, it's not about Sutter, it's about the standard.
For the first time in C++'s history, people who didn't pay to get "official" can contribute to the standard. We have an opportunity to provide input so I'm saying let's focus on that input instead of discussing who sells what, other than language and library features.

That hopefully clarified, I didn't meant to be offensive but I'm getting tired of rants about an aspect of the issue at hand (designing a library) that can easily drive disucssions unhelpful, like both mine and your posts.

The first part about the code is the interesting part in your post. I am officially giving you my most sincere excuses and hope you will contribute again.

Just to get back to one of your questions:

When all those workgroups are done with their work and C++'s library is expanded to what Mr. Sutter said they envisioned, and the platform independence problem is practically solved and the undefined behaviour (which I found surprising they even considered making a workgroup for) is... defined? () What advantages will a language such as Java have over C++ any more? Beginners and experienced programmers always argued in favour of Java because of all those things that C++ currently lacks but is being worked on, so once all those things are in C++ as well, why would anybody even consider Java any more?

Java and other languages still have benefits in specific domains. For example, setting up Java server nodes automatically is incredibly easy. Not having to "think" about the end of life of objects can help quickly getting to the point (before maybe an optimization by converting to C++). C++ will not have a big library as Java does, not before at least 10 years at the speed we're adding libraries. C++ lacks a lot of reflection features (and apparently work in reflection group can't go fast because they need to have C++14 out first to know what they can or cannot consider) which means it's still problematic to use in a lot of cases like server applications.

Basically, there is room for other languages. Also C++ stumped under Rust or D invasion, if they manage to fix some major problems compared to C++.
Also, C++ isn't "pure", which is both an advantage and a problem depending on the specific context.

So basically, it's not important. What's important is that at the moment, using C++ for prototyping is not efficient enough because it takes too much time. In the same time, it's still certainly the best language for infrastructure.

Does someone around read a bit the first example of potential proposal that have been posted? https://bitbucket.org/brechtkets/graphicscpp So far I'm not satisfied at all but I think it just need some clearer design guidelines.

32

General discussions / Re: C++ ISO Standard Committee 2D Graphics Library Discussions

« on: September 18, 2013, 03:19:30 pm »

binary1248, you're both missing all points and being totally unhelpful here.

To get back on the topic, on the forum open to people interested to help on the graphics library, I already posted a SFML version of the Cinder example, liike two weeks ago.
I think maybe some here didn't understand that if you want to help, you can. It's not a closed system anymore (even if some parts are closed).

33

General discussions / Re: C++ ISO Standard Committee 2D Graphics Library Discussions

« on: September 05, 2013, 10:14:45 pm »

Indeed, I hope SFML inspire the interface of the graphics/io library to be composable instead of a being a framework in which you inject user code. With a composable library, such a framework is easily constructible.

34

General discussions / Re: C++ ISO Standard Committee 2D Graphics Library Discussions

« on: August 28, 2013, 05:46:08 pm »

sounds like an hell to come true with all the possible platforms supporting c++

Not if it's only a library interface specification and the focus is on high level requirements (and taking into account experience with implementations).

That's the point of having a library in the standard: the implementor can do whatever he wants as long as it exposes the same interface as the standard.
So, it's not a problem of platform, really, it's a problem of having a majority of people agree on an common interface to rely on in the long-term future.

Which is certainly the hardest thing ever.

35

General discussions / Re: C++ ISO Standard Committee 2D Graphics Library Discussions

« on: August 27, 2013, 06:09:38 pm »

Yes but Microsoft will take years to implement it and it'll be buggy meanwhile and you'll have fun buying two or three visuals in a row till you get what you want 2 years after ratification, like they are doing/did with c++11.

Well, Microsoft is the one pushing for graphics here, so I expect them to be the first to implement and publish such a library, as they did with all the technologies they were interested in.

Something cross platform and possibly based on OpenGL is very weird coming from ms, since they are so dismissive of crossplatformness and GL.

First, this is not about MS, it's about the C++ standard. Second, the standard will not provide nor specify an implementation. It specify only interfaces, and sometime performance scale expectations. So whatever the technology inside such a library, that might not be OGL. You don't even care, frankly, as long as your same code works for all platform, which is the point of having a standard library.

Maybe they're looking for graphics API to drop and since they dropped GL on phones and dropped XNA they ran out of things to safely drop(and D3D is no-no to drop).

You're again mixing things, this is not about replacing OGL, read the linked message, this is about 2D graphics only and the point is to have something to rely on both for games and GUI implementations. Also, they open the possibility of 3D but don't want to talk about it until a 2D library is ready.

Can I join rant and say that the next VS already includes some C++14 features, even though we're lacking important C++11?

That's what I'm saying: Microsoft is pushing for this library so it might appear sooner than having the full C++14 implementation from them.

Now, it's really a big problem that Microsoft tools, the most used in the C++ world, is the most lacking, but at this point and time I think they are making as much effort as they can to fix the game. From the point they started with, frankly, it's almost a miracle they managed to get as much features as the VS2013 version is supposed to provide.

That being said, this is not about Microsoft, focusing on the point of the library/disussion would be saner than bashing one implementor.

36

General discussions / Re: C++ ISO Standard Committee 2D Graphics Library Discussions

« on: August 27, 2013, 04:57:57 pm »

The sooner would be C++17

So with speed Microsoft does things from standards by 2030 we will have it implemented fully in visual, can't wait!

Errr no Microsoft is not the standard commitee (it's one member), and the commitee changed speed after C++11 which is why there will be a new C++ standard next year already (c++14).

37

General discussions / Re: C++ ISO Standard Committee 2D Graphics Library Discussions

« on: August 27, 2013, 04:34:16 pm »

Imagine SFML having an impact on C++14!

Nope, not C++14, no new feature will get in for that version.

The sooner would be C++17 (assuming release time is right) OR through a TS, but as work really started only recently, I expect that this might not be ready for C++17.
Except if a lot of people gets their hands dirty.

38

General discussions / C++ ISO Standard Committee 2D Graphics Library Discussions

« on: August 27, 2013, 02:58:53 pm »

See: https://groups.google.com/a/isocpp.org/forum/#!forum/graphics

Apparently, from this message, Laurent should be contacted by Herb Sutter to discuss about the topic.

39

General discussions / Re: SFML Game Jam

« on: July 21, 2013, 05:47:54 pm »

Advantages are not to be taken into account for a Jam because it's not a competition with prize (or more exactly, it shouldn't be if you want to keep the fun).

I would suggest this formula:

 - to be listed in the official list of jammers, use SFML and jam alone;
 - have a separate list of jammers who worked in team or with SFML-based higher lilbraries;
 - no other restriction at all;
 - maybe a random theme which is optional, just to help people who don't have tons of ideas;

40

General discussions / Re: SFML Game Jam

« on: July 21, 2013, 12:08:00 am »

In my opinion, a Jam isn't a Jam if:

 1. the theme is not optional and open to interpretation;
 2. there is prizes;
 3. only a select group of people can judge.

See for example how Ludum Dare works.

The first point is about the liberty of just doing something in the time, risking to be under evaluated if you go too far from the theme. The evaluation should take into account how the theme have been used, but not ban games that don't use it, just give them less "points".

The second point is well known to immediately kill the fun. Search for reports from organizers of game jams, this one is an instant killer. Global Game Jam began like that but abandonned quickly.

The third point is first because not everybody have the time to test tons of games in a limited time, even if it's onlyu 30seconds per game. Second because the point is to make games in the time limit, good if possible, and just let people play it. A jam is never about  being better at convincing judge, it's being better at convincing a maximum of players. So anyone should be able to give a vote (or several). Maybe only people registered or something like that, to filter a bit, but don't make a group of judges.

41

General discussions / Re: SFML Game Jam 1 Theme Submission Thread

« on: July 20, 2013, 11:57:44 pm »

Multiplayer
Persistent
Fractale
Kandinsky

42

Feature requests / Re: Change Unit of Measure

« on: July 14, 2013, 03:31:46 pm »

Indeed it requires a lot of overloads. Ogre manage this by having it's own math library (which is a modified version of an old math library called Magic Box if I remember correctly).
If this is a problem then sf::Angle is certainly a good enough solution.

43

Feature requests / Re: Change Unit of Measure

« on: July 13, 2013, 02:17:25 am »

Do you need to know the angle type? Not really...

I disagree.

if you want to pass an angle in degrees, mark it with _deg, if you want radians then _rad.

Which, in a typed context, is exactly a shortcut for Degree(value) and Radian(value). Please check what UDL is really, because I think you don't understand it nor do you understand strong typing.

You don't need to rely on the implicit type if you don't want to.

If you don't want to use a degree value into an object which is interpret on read as a radian value, you want it typed.

As an example, you could pass shorts around as 10_s if that makes it more clear you intend on it being interpreted as a short as opposed to an int or what not (this is really useful when trying to pack short literals into an sf::Packet without explicit casting).

I agree, as I was saying, UDL is nothing else than shortcut conversion from source code litteral to a typed value. If you use double or float or any basic type, your conversion is just meaningless in specific context, but useful if it's exactly what you meant, which is why there is already the default litterals L, l,  f etc.

User-defined literals are not meant as a way to prevent errors by passing PODs around.

Exactly, you need strong typing to prevent these errors. Whatever the way you can't avoid defining one (sf::Angle) or N types (Ogre::Degree/Radian). You can't use int or float and assume everybody will know it's degree and will never make mistakes.

If you wanted that, all functions would take some kind of an Angle type but since this topic was about being able to pass different units to functions without worrying about conversions, user-defined literals solves that problem completely.

Not if the compiler can't know the difference. You see, if your function takes a radian as float, and you provide say "90deg" and  you have UDL converting it to a float, then you used UDL to give your intent but the code will compile and not do what you intended.
Which is why you need strong typing.

User-defined literal is quite literally what the name implies, a mechanism for you do define your own kinds of literals.

We strongly agree.

Literals aren't bound to a type until they are put into a certain context.

No, litteral are strictly always bound to a type, which is what makes auto works in the first place:

Code: [Select]

auto a = 42; // int
auto b = 42.0; // double
auto c = 42.0f; // float
auto d = 42L; // long (or long)  etc.


That is why your literal handling function gets nothing but the string of characters straight out of your source code and it is up to you to interpret them in any way you want.

And return a type. So, basically UDL solve the ease of writing but types solve the identification of intent and basically allow you to see the points of conversion. If you use UDL to always return a sf::Angle, why not, but don't return a double or float, it's hiding the intent of the library developer side of the contract in the interface of the function.

You can make both _deg and _rad return some double value, be it in degrees, radians, gradian or whatever crazy unit you can think of. It just has to fit with the rest of the interface.

double, I disagree. A specific type, I agree.


By the way, UDL is a minor improvement here because most games are data-driven so the data were not in the code anyway. When you get the data to inject in SFML, I hope you know what type it is. I wouldn't trust mysefl with it, which is why I let the compiler make sure it's the right type.

sf::Time is nice, but it does force you to convert the value to something at the point of use.

The same applies to Degree and Radian classes, you have to call something like an asFloat() function as soon as you need to perform a computation with it.

Not at all, it provides all the necessary operators, even implicitely converting degree values to radians if you are mixing them in calculus (in which case you pay for mixing the types but it don't make the code uglier by forcing you to explicitely convert). Take a look at the header: https://bitbucket.org/sinbad/ogre/src/0bba4f7cdb953c083aa9e3e15a13857e0988d48a/OgreMain/include/OgreMath.h?at=default
Actually the conversion is implicit between Radian and Degree (I was wrong on this detail), but explicit when you provide a float value (which is where having UDL makes code shorter to read)

Ogre uses Radian by default internally and in all it's interface (which is configurable), which means if you use Radian in your user code then there is strictly no conversion hapening. If you use Degree in all your user code then at least one conversion happen when you push Degrees into Ogre. You can avoid it when you configure Ogre to use Degree but then it will have to convert to Radian before pushing it in the graphic card anyway.

Basically, no conversion until you use Degree. There are also operations on Vector and Matrix types in Ogre which rely on Radian which mean there again there is no conversion until you use Degree.

Which was my initial point with this design. I believe sf::Time/Angle don't have the same properties. I consider it's ok with Time because it's more about time scale and SFML don't work under microseconds and over seconds, so it's good. ( std::chrono necesarily needs to be more flexible and precise because far more generic )
However angles have two defined types which are not just scales so to me it's more obvious to have a different type for each, it fit the semantic and allows the no-conversion-if-same-type semantic.

That is currently the biggest drawback of such wrappers, every trigonometric function call requires an explicit conversion. The only way to cope with this consists of overloading a large number of functions.

I'm not sure I understand by overloading a large number of functions. If a specific type is used into SFML (or Ogre) for angles, then there is no need for overload, isn't it?

44

Feature requests / Re: Change Unit of Measure

« on: July 12, 2013, 09:23:04 pm »

@binary1248 I think you totally don't understand why you need types in this specific case. As other pointed, it's the same problem than with sf::Time values or std::chrono time values. You don't want implicit conversions. Using user defined literals without types (or by returning a basic type like float for example) is like asking for obscure ninja conversion errors to happen. If you don't understand this, maybe you didn't hit them enough yet. It's typically the kind of error that make space projects fails.

To me this could actually be something for a very simple class/struct like sf::Time. In the end you've got the same issue here: Several different units essentially measuring the same thing (and different functions obviously expecting different dimensions).

Exactly.
The point is that the same values with different referential MUST NOT be mixed without being converted to the same referential, whatever the way.

This would work on any platform. Using C++11 as an additional feature sounds neat, but at the same time you've still got the same issue in older standards.

You don't need C++11 to do it. User defined literals are basically allowing you to associate a litteral value to a type (with a potential conversion). It is not intended nor should be used as binary1248 described (which is actually a dangerous practice).

I have to agree. Unnessesary converting back and forth between degree and radians is a waste of time and performance. I have worked with ogre before and the way they implemented it is very nice and handy.
But something similar to sf::Time would be great too.

I prefer the typed way of Ogre::Radian/Degree personally as the compiler helps pointing potential errors instead of allowing you to mix with floats like in SFML. It also don't add any conversion until you use only a type different than SFML.
The approach used by Ogre::Radian/Degree is actually similar to std::chrono time values.
sf::Time is nice, but it does force you to convert the value to something at the point of use.

45

Feature requests / Re: Change Unit of Measure

« on: July 12, 2013, 12:29:40 am »

What type definitions? The user-defined literal is converted to the appropriate angle type when being passed to any function that would take an angle. No type definitions there...

How do you know the angle type? No, better: how does the compiler knows the angle types so that it can stop you when you're implicitely trying to convert?
The user-defined litterals just let you associate litteral shortcut syntaxes to types. So you first need these types.