Topics

1

SFML website / Pre-post questionnaire

« on: August 26, 2015, 10:13:23 pm »

IMHO it would be great if we could get all new posts to (at least) the help forums to include filling out a questionnaire with basic stuff (that people always need and ask for) like:
What is your OS (Linux, OS X, Windows, Android, iOS, other (please tell us)?
What version of SFML do you use?
Did you compile SFML yourself or use pre-compiled binaries?
What compiler do you use (msvc, icc, gcc, clang, other)?
Are you linking SFML statically or dynamically?
Does your problem reproduce in debug builds, release builds, or both?

There may be other questions that are relevant to add to the list. But having the above answered by default on every help post (possibly hidden behind a spoiler so you only have to see them if you care) could cut down enormously on a lot of duplicate posts that just ask for more details (usually the ones mentioned above).

2

SFML website / HTTPS support for the forum and main SFML website

« on: July 21, 2015, 05:28:21 pm »

Could we, please, get HTTPS support for the SFML websites?

First of all I like knowing that the site I'm communicating with is the one I intended.
Secondly I like to know that my communication cannot be snooped upon by third parties while in transit.
Thirdly I'd like that third parties cannot inject content into the pages I'm viewing.

While it's been bugging me for a while that the SFML website(s) don't use TLS it became really annoying a few days ago when I was pair-programming with a friend at a pub and using their public wifi to look up details in the SFML docs. It was annoying since their access point injected ads and tracking cookies into the pages retrieved - which would not have been possible over a HTTPS connection.

If cost of a certificate is an issue, then contact me via PM and I'd be happy to cover that cost.

3

Feature requests / Detect if vsync is active

« on: July 20, 2014, 03:02:28 am »

It's fairly annoying that setVerticalSyncEnabled(true) can fail to enable vsync - although that's not really any fault of SFML's. But it would be really nice to be able to detect if it is in effect or not.

Basically I find myself forced to enable user configurable options to enable/disable vsync (and then use setFramerateLimit() when users set it to 'Off') so that users at least have some way to avoid my game loops burning up 100% CPU.
I could of course just always use setFramerateLimit() and avoid having to add a config setting, but although that fixes the "burn 100% CPU" problem it doesn't fix tearing issues, which setVerticalSyncEnabled(true) does.

So basically what I would like would be either of these two:

1) Let setVerticalSyncEnabled() return a bool that indicates if the requested operation was a success or not. So basically setVerticalSyncEnabled(true) would return true if it successfully enabled vsync, false otherwise and setVerticalSyncEnabled(false) would return true if vsync was definitely disabled when it returned and false otherwise.

or

2) Add a "bool verticalSyncEnabled() const" function that tells you if vsync is currently active or not, so you can try and enable it and if it didn't take (since drivers forced it off or whatever other reason) you can at least find out and then just fall back on calling setFramerateLimit() without ever having to bother your users with switches they manually have to toggle.

4

SFML wiki / Simple 'bouncing ball' example posted on the wiki

« on: July 10, 2014, 11:19:26 pm »

Hi people

This is just a quick message to let you know that I've posted a simple example program on the wiki. It just bounces a ball randomly around in a window. I wrote it in response to a forum post and would have left it at that, but then it became relevant in another forum thread and I thought I might as well make a wiki entry out of it.

You can find it here: https://github.com/SFML/SFML/wiki/Source%3A-Bouncing-ball

I hope you find it useful.
Comments and criticism is of course welcome.

5

SFML wiki / a simple Jukebox class posted on the wiki - feedback request

« on: May 23, 2014, 06:10:57 pm »

Hi everyone

I recently posted a small Jukebox class to the wiki ( https://github.com/SFML/SFML/wiki/Source%3A-Jukebox ).
It works fine for my own purposes and I hope it can be a good example for others. But I'm curious as to what other people think about it and would apreciate some feedback.
So, what do you think? Do you like it? Do you hate it? Are there bugs I've missed?  Any and all criticism, comment, feedback welcome 

6

SFML website / maybe tone down the white background a bit

« on: February 15, 2014, 10:06:12 pm »

It would be really nice if the background in the tutorial and documentation pages were not pure white, but instead a bit grey.
Reading the documentation in a dark room with a bright monitor really hurts my eyes on the sfml site.

Usually I use "redshift" (http://lifehacker.com/5567172/redshift-makes-your-screen-easier-on-the-eyes-at-night) to ease the pain, but the sfml site still stands out as painful late at night.

7

Feature requests / set functions should return reference to self

« on: February 11, 2014, 12:14:59 am »

It would be nice if "setters" like for example sf::sprite::setPosition() returned a reference to themselves rather than void.

sf::sprite& sf::sprite::setPosition(...) {
  ...
  return *this;
}

This would allow easy chaining of multiple setFoo calls on the same object like:
  Foo f;
  f.setBar().setBaz();
Etc..

Since setters currently return void we know that no one is storing, or otherwise relying on, their return value, so changing the return value shouldn't cause any problems for legacy code. It would just provide new functionality that old code could blissfully keep ignoring but that new code could exploit.

I'd be happy to make the code change and submit a pull request if this would be liked/wanted/acceptable.