Messages

1

General discussions / Re: SFML 3 - What is your vision?

« on: October 10, 2014, 07:09:57 am »

However one thing I wouldn't really want to see is Strata 0. Sure we won't be able to prevent it, but for the most time it's really just a lot of wasted effort when people try to use SFML without being able to program the most basic things. We've developed and maintain a library and aren't here to hold introduction to C++ or programming talks. There are dedicated communities which do this kind of thing to some form and they are usually way better equipped with information and teaching material.

This. SFML is written in C++. C++ is not Java/C#/Rust/Scala/Racket/Haskell/Python/JavaScript/etc. It doesn't hold your hand. It gives you a loaded gun, and lets you do whatever you want with it, especially shoot yourself. It's important to keep the target audience in mind: C++ developers. These developers might have a wide range of skill and experience levels, but if they're using SFML and C++, then 1) they aren't (or shouldn't be) total novices to programming, 2) they're in it for the pain, and 3) they're prepared to deal with the fact that they might (and eventually will) blow their leg off. While I think SFML should be as simple and user friendly as possible, it shouldn't coddle users who are woefully unprepared for the tools they're using.

I personally would like to see an SFML that changes the "Simple" from meaning the library is a bare-bones, minimal simple library, to a "simple to use, and simplifies your life" type of meaning. As FRex said, sometimes things move in the "simple to read, simple to write, hard as f**k to use because you need to write 5 helpers for everything" direction. I don't want SFML to be bloated and contain the whole kitchen sink. But I do think many SFML users reinvent the wheel just to use SFML, and I'd like to see more of those redundancies handled in the library.

So I guess I'd like SFML 3 to take the approach of: what to many users do with/to SFML to simplify their life in using it, and how can those common things be incorporated back into SFML?

2

SFML website / HTTPS support?

« on: October 08, 2014, 07:37:07 pm »

It would be awesome if this site had HTTPS support (especially for logging in). You can get one cert (for sfml-dev.org and one subdomain) for free with StartSSL. 2 more 5-year certs (for en. and fr.) can be bought for $46.40 from ssls.com.

There are other certificate authorities, but regardless of exactly which one is used, I would love to see some HTTPS support on this site. And they can be obtained for relatively cheap.

3

General discussions / Do you use radians or degrees?

« on: September 21, 2014, 10:07:24 pm »

SFML uses degrees. In my experience, it's the only thing that uses degrees (except for old, deprecated, and removed OpenGL stuff, which I ignore in this modern era).

I always use radians for things. Standard C and C++ trig functions take radians. OpenGL shader trig functions take radians. HLSL trig functions take radians. Whenever I do various geometric things I use radians. Honestly, the only time I ever "use" degrees is when I'm reporting them to the user; but even then I'm not really using radians; I'm just formatting the number as degrees for printing to screen. Whenever I actually use an angle, I use radians.

What about others? When do you use radians? When do you use degrees? How often do you need one or the other?

Side note: this isn't a "SFML should use radians" feature request, so I'm not looking to debate whether SFML should be radians/degrees. That kind of debate can happen in another thread. I'm trying to understand what users of SFML use, in real life.

4

Feature requests / Re: sf::Rect extension

« on: September 21, 2014, 09:56:36 pm »

I think "position" and "size" are good. No need for the ability to get all the corners.

I might be the only one who wants this, but I feel like the notion of top/left (or any other specific corner) should be banished. Allow rects with a negative width/height. Then, "position" is just the anchor point for the rect, which idiomatically is the top-left corner, but no longer forces the notion of top/left, and then the user is free to make the anchor point whatever makes sense for his/her program (want a bottom-left anchor point? great! just use a negative height).

I think it's simple to say the position is the anchor (heck, I'd even be okay if it was called "anchor" instead, though "position" is fine too). A rectangle is defined by points in the range [position, position + size].

I don't think it's inconsistent to provide a position/anchor point and a size (and nothing else).

edit: I just read Hapax's comment above. I like most of what he said, though I don't like the names (getStart/getSize/getEnd). I'd personally prefer something like "anchor" and "size". While a member dedicated to getting (anchor + size) would be useful, I can't think of a name that I like for it, and I'm the kind of person that would rather not have something if it's named something that feels... weird.

5

Feature requests / Re: sf::Rect extension

« on: September 20, 2014, 05:44:55 pm »

What is the "position" of a rectangle? Its top left corner, its center, its bottom right corner, ...? It's not clear and people might have different answer to that question. So if we really want a function to return a specific point of the rectangle, it should not be called «getPosition» IMO. Same apply for the «far position».

Presumably, "position" is exactly what it is in the constructor "Rect (const Vector2< T > &position, const Vector2< T > &size)". I get what you're saying, but reality is the Rect already has a sense of "position" (which, from the docs, is "Position of the top-left corner of the rectangle"). I think if you don't want to have a notion of "position" then that constructor ought to be removed. If that constructor stays, though, then Rects should have a proper sense of position.

Personally, I think it might be useful to have getPosition() and getSize() methods that return Vector2. I know you can just access the left/top/width/height members, but being able to concisely get a Vector2 that's consistent with an existing constructor would be useful. I don't really like getPositionFar().

6

SFML website / SFML 2.0 docs aren't up

« on: August 19, 2014, 05:32:03 pm »

Going to the 2.0 documentation results in just seeing the 2.1 documentation. Can this be fixed?

Thanks!

7

General discussions / Re: Conditional C++11 Support

« on: July 13, 2014, 03:07:22 am »

User-defined copy constructors (which isn't the case to my knowledge)? Because otherwise it's not a problem.

See en.cppreference.com/w/cpp/language/move_constructor#Implicitly-declared_move_constructor

Cool. Well I just learned something new! Thanks for that link.

Welp, carry on with the discussion here!

8

General discussions / Re: Conditional C++11 Support

« on: July 11, 2014, 07:33:06 am »

You can already add flags when configuring the CMake file. Compiling with C++11 should generate default move contructors wherever possible.

Although most of the classes in SFML have user-defined constructors, which means no other constructors are auto-generated (including move constructors).

9

General discussions / Re: SFML 3 - What is your vision?

« on: April 26, 2014, 10:21:32 pm »

IMO there are absolutely no reasons to add advanced maths stuff since there are other libraries doing that and being focussed on it. GLM for example is headers only and has heaps of functionality related to 3D graphics maths. Adding a maths module to SFML would only mean more maintenance and reinventing the wheel.

I'm not asking for the whole kitchen sink (I said "enhanced," not "advanced"). The thing is SFML already provides vectors and matrices. And these aren't things that can be stripped out of SFML, as coordinates and transforms need to be specified for SFML to do its work. But these things SFML provides have no support for basic linear operations (dot/cross products, projections, etc.). It would be nice if common operations and data types (i.e. quaternions, particularly if 3D support is added) were supported.

10

General discussions / Re: SFML 3 - What is your vision?

« on: April 25, 2014, 09:51:32 pm »

Things I really want:

• C++11 (non-optional) (C++14 is cool and all, but would have very little impact on SFML's API)
• Pure OpenGL ES 2.0 back-end
• Support for OpenGL ES 3.0 context creation (particularly on Android)
• Enhanced math library (more vector/matrix stuff, up to 4D, and including things like quaternions)
• Improved HiDPI support (across all OSes)
• The context stuff mentioned earlier
• Focused on multitouch rather than mouse
• Multiple windows
• More platform introspection (# of logical and physical cores, CPU/GPU type, etc.)
• Radians, not degrees
• (Not related to SFML 3, but would be nice to pair with it) Forums that support markdown

Things that would be awesome (but that I can live without):

• Web/emscripten back-end

Things that I think are cool ideas, but I haven't thought about enough to think if they're bad ideas:

• Basic 3D graphics support
• SSL/TSL/SSH support i.e. HTTPS, SFTP, etc.
• Bluetooth support
• File I/O stuff? Perhaps just until C++17

11

General discussions / Re: The new SFML team

« on: April 25, 2014, 09:29:16 pm »

This is fantastic. In fact, it's encouraging me to get more involved myself. The recent surge of commits indicates this is a very good thing.

12

Feature requests / Re: allow to change speed without changing the pitch

« on: February 28, 2014, 03:11:16 am »

A former coworker of mine wrote the atempo filter in FFmpeg, which allows audio to be sped up/slowed down without changing the pitch. The source can be found here for FFmpeg's atempo. If you look at that file, you'll see that it's LGPL, but he links to another (original) implementation that's licensed under the MIT license: Apprentice Video Player (specifically, the yaeAudioTempoFilter.h and yaeAudioFragment.h files).

You could strip out that code and turn it into a library, all based on the MIT license, if you felt so inclined.

But I'd have to agree this is beyond SFML's scope.

13

General discussions / Re: Unofficial Nightly Builds

« on: October 15, 2013, 05:03:30 am »

Nice! I'll probably steal a few ideas to update my packaging script when 2.2 is released. 

Ha cool; yeah I just hacked my build scripts together. If I had more time I'd go back and try to make them less hacky. But if you have any improvements/scripts you want to share I'd be happy to incorporate them

14

General discussions / Re: Unofficial Nightly Builds

« on: October 14, 2013, 07:19:18 pm »

Thanks Hiura for pointing out the missing FreeType framework.

I have updated my build system. The following changes were made:

• I no longer provide GCC builds; I only use Xcode 5 and Clang 3.3 (though I believe these builds should work fine with Xcode 4 and Clang 3.2)
• Minimum target is now 10.7; I will not be providing builds for anything less than 10.7.
• Base SDKs are now 10.8 and 10.9. I will not be providing builds with base SDKs < 10.8 (unless Apple changes Xcode to include the 10.7 base SDK by default)
• I now completely mimic the official SFML OS X distribution (that is, I have included the Examples, the install script, etc. so you can use/install my builds exactly like you would the official SFML distribution)
• I am also providing experimental builds that have the extra optimization flags -Ofast and -flto (link time optimization) turned on; note that I don't expect these flags to make any noticeable difference in your apps, but I did want to experiment with them

If there are any issues you encounter/find (or any other feedback), let me know!

15

General discussions / Re: Unofficial Nightly Builds

« on: October 14, 2013, 07:31:23 am »

I just want to leave a note that I've upgraded my system to OS X 10.9 and Xcode 5, so I'll be changing the OS X builds I provide. The notable changes are:

No GCC builds
Only 10.8 and 10.9 base SDKs supported
I'm still debating whether I should make the minimum target SDK 10.7 or still 10.5
If I do decide to make the minimum target SDK 10.7, then I'm not sure if I'll continue providing C++03 builds (and instead only provide C++11 builds)

Anyway, I'll try to update my build system soon-ish so I can resume regular builds, but I'm quite busy at the moment and can't promise anything.