Topics

1

General discussions / SFML 2.6.1 Release

« on: November 04, 2023, 02:25:15 pm »

SFML 2.6.1

A small bugfix update to the massive SFML 2.6.0 release from earlier this year.
Largely addressing issues in the build process, but also fixing a few issues in specific, less tested scenarios, see the full changelog for more details: https://www.sfml-dev.org/changelog.php#sfml-2.6.1

Note again that SFML 2 will only see fixes for critical issues as patch releases (e.g. 2.6.2), but all the other development efforts are focused on SFML 3. For more details and future discussions, see the Roadmap.

Thank you to those reporting issues and helping them get fixed!

Visit https://www.sfml-dev.org/ for download instructions and extensive documentation. We hope you enjoy this release and would love to get some feedback!

2

General discussions / Mutual following on the Fediverse!

« on: July 04, 2023, 08:53:03 am »

Way back in 2014 we had a thread like this one for Twitter. Since Twitter is making itself less and less attractive, I thought it would be time to create a new thread for the Fediverse.

Post your Fediverse / Mastodon handles, so we can connect with each other

SFML
 SFML Team - @sfml@fosstodon.org

SFML Team
 eXpl0it3r - @darkcisum@swiss.social
 Thrasher - @ChrisThrasher@mastodon.social
 Nexus - @bromeon@mastodon.gamedev.place

SFML Users
 kojack - @kojack@mastodon.gamedev.place
 Hapax - @hapaxia@mastodon.world
 rubenwardy - @rubenwardy@fosstodon.org

3

General discussions / SFML 2.6.0 released

« on: June 21, 2023, 08:31:04 am »

SFML 2.6.0

After 5.5 years, we're proud to announce a new and massive SFML release. Over the past few years a lot has changed code-wise, in the team, in the community, and also with the roadmap of SFML. We would like to thank every single one of our contributors, who helped make this release. Thank You!

It's important to note, that this will be the final SFML 2.x release. We will provide fixes for critical issues as patch releases (e.g. 2.6.1), but all the other development efforts are focused on SFML 3. For more details and future discussions, see the Roadmap.

Highlights

• ⌨️ Support for Scancodes
• 🗔 Create windows without OpenGL context
• 🪟 Create windows with a Vulkan context
• 💻 SFML supports ARM64 on macOS, i.e. M1 and M2 chipsets
• 🧪 Unit testing foundation has been created

There are many, many, many fixes and lots of improvements. The full changelog including detailed descriptions can be found here:
https://www.sfml-dev.org/changelog.php#sfml-2.6.0

Visit https://www.sfml-dev.org/ for download instructions and extensive documentation. We hope you enjoy this release and would love to get some feedback!

4

General discussions / Taking On the Role As BDFL

« on: April 13, 2023, 09:55:12 pm »

Benevolent dictator for life (BDFL) is a title given to a small number of open-source software development leaders, typically project founders who retain the final say in disputes or arguments within the community

With Laurent not being noticeably active in the community and around development, we've been at times experiencing a lack of decision making in discussions, where opinions on technical details, benefits, and drawbacks diverge and we fail to come to a conclusion.
The SFML Team (excluding me) as such appointed me as new/additional BDFL to hopefully live up to Laurent's vision of SFML and to serve the community as a whole.

For most of the community this doesn't really change anything, as such decisions aren't a daily occurrence. We merely found it important to inform everyone about it.

I'd like to thank the rest of the SFML Team for the trust they put in me and am looking forward to moving SFML even faster forward!

5

SFML development / Allow for Limiting (Max & Min) Window Size

« on: March 05, 2023, 05:50:59 pm »

While the old trick of resizing the window to the min/max allowed size after the sf::Event::Resize event, there are at least two issues with it:

• The user can during the dragging go below or above the set limits (see also #2406), which might be undesired can cause a lot of unnecessary recalculations or having to support this edge case in your application code.
  
• Due to X11's nature of being async, this can cause some odd behavior with certain window managers (see #2124) and the conclusion out of #2378 is, that it's basically impossible to fix, unless there's a minimum (or maximum) size defined beforehand.

Beyond potential API bloat, I don't really see an argument against having something like sf::Window::setMinimumSize(sf::Vector2u) & sf::Window::setMaximumSize(sf::Vector2u). If the OS doesn't natively support such a functionality, it's also pretty easy to simulate it the "old-school" way with the resize event.

Thoughts from others?

6

Pull Requests & Testing / Scancodes Round 3 & Release Readiness

« on: February 23, 2023, 10:46:30 am »

Already some weeks ago, we've merge the scancode implementation to the 2.6.x branch and thus closing the final feature of SFML 2.6
You can use the pre-built binaries or the SFML CMake Template to get started quickly.

Now, we're looking for people to help us test the version further and especially also try and make use of scancodes.
If you have a game or other project using SFML, I recommend to update to the 2.6.x branch and see how you can add keyboard layout independent keyboard handling with scancodes.

There are essentially four additions or enhancements to the existing API:

• Introduction of a new enum for scancodes: sf::Keyboard::Scancode
• Enhancement of the KeyEvent event union to also return the scan code: event.key.scancode
• Real-time querying of the keyboard state: sf::Keyboard::isKeyPressed(sf::Keyboard::Scancode)
• Best effort translation from scancodes to the current keyboard layout: sf::Keyboard::Key localize(sf::Keyboard::Scancode code)
• Best effort translation from the current keyboard layout to scancodes: sf::Keyboard::Scancode delocalize(sf::Keyboard::Key key)
• Retrieving of a human readable key description (e.g. for in-game UIs): sf::String getDescription(sf::Keyboard::Scancode code)

If you want to test the inputs independently, there's also the existing SFML-Input example.

Let us know how things work out for you and report any issues encountered.
Happy testing!

7

General discussions / New SFML Team Member: Thrasher

« on: September 28, 2022, 12:47:27 am »

We're excited to announce that Chris Thrasher (also known as Thrasher) has joined the SFML Team!

Thrasher has entered the SFML playground only recently, but his work already had a huge impact on SFML and its development, especially with modernization of the code base, be it C++17, testing or CMake config wise.
I mean look at his commit count!

We're also really lucky to finally have a "native" macOS user back in the team, who can help with some not so often tested code paths.

Looking forward to all the additional changes and modernizations, lots of them already queued up, so I've heard.

Welcome to the SFML Team!

8

SFML development / sf::WindowBase vs sf::Window vs sf::RenderWindow

« on: April 22, 2022, 12:51:20 am »

Currently we have three different window classes.

Originally, sf::Window was a basic window that creates an OpenGL context, but without SFML specific draw functionality. And sf::RenderWindow which does add those SFML specific draw functionalities.

Then much later sf::WindowBase was introduced as a window that doesn't have an OpenGL context and to retain the API compatibility for SFML 2.

With SFML 3 being in development, we're no longer bound to API compatibility and with a glimpse into a future, where we might have multiple rendering backends...

What API would you propose for the window setup if you were to start completely fresh?

9

C / C API Limitations

« on: March 18, 2022, 03:55:34 pm »

Someone reported this on Discord and I believe, I've run into it sometime before, essentially the CSFML API is limited in regards to, that you can't cast an sfRenderWindow* to an sfWindow* which leaves APIs such as the sfMouse_getPosition(const sfWindow* relativeTo) unusable if you have an sfRenderWindow*.

Should we simply accept this limitation or are there alternatives that we could use?

The most natural one of just adding an additional "overload" doesn't work, because the sfMouse_* functions exist in the window module and the sfRenderWindow is part of the graphics module. It would only work if it was additionally implemented in the graphics module.

Another possibility, which I don't know if would even work, is to have an sfRenderWindow_toWindow or similar casting function, that down casts in C++ from sf::RenderWindow to sf::Window. What I'm unsure about, is whether we can use "safely" use the resulting sfWindow* structure, since we now have two references to the same window instance.

Any other ideas?

10

General discussions / New SFML Team Member: SuperV1234

« on: November 30, 2021, 05:23:39 pm »

We're excited to announce that Vittorio Romeo (also known as SuperV1234 or vee) has joined the SFML Team!

Vittorio has been an avid SFML user for many years and just recently published Open Hexagon on Steam, which as the name suggests is open source, and is also built on top of SFML.
Others might know his name, logo and voice from the excellent video tutorial series also making use of SFML.
And some might have seen one of his talks on C++ or ran into him at ISO C++ committee meeting.

As you can see we're very lucky to have Vittorio onboard and look forward, to how he can put some new wind in SFML's sails!
We're especially looking forward to all the help in shaping the transition into a modern C++17 code base for the just kicked-off next major version SFML 3.

Welcome to the SFML Team!

11

SFML website / We added a Content-Security-Policy header

« on: August 06, 2021, 03:19:54 am »

I just added a Content-Security-Policy header which these days is kind of an expected security feature.
This limits from where your browser will load, scripts, images, media, fonts, etc. and can thus prevent certain attacks.

On the flip side, this can lead to some previously working, but now broken images, postings, logins, sign-ups etc.
If you run into any issue that you think needs fixing, you can post it here or shoot me an PM or email (my nick at website domain).

12

General discussions / CSFML 2.5.1 Released

« on: July 12, 2021, 08:59:05 am »

CSFML 2.5.1

Note: Yes, this is about the C-binding and not the C++ library

• Download page
• GitHub git tag
• NuGet package

Bugfixes

• The sfRenderTexture_getMaximumAntialiasingLevel symbol wasn't properly exported
• sfRenderTexture_createWithSettings had a wrong signature, making it uncallable from SFML.Net
• sfTexture_updateFromTexture was not implemented, causing failures in SFML.Net

Features

• The community has provided some build scripts for generating a NuGet package which can be used in combination with SFML.Net
• While the macOS build script couldn't be fully utilized, it was also added

13

Pull Requests & Testing / Scancodes - Round 2

« on: May 27, 2021, 02:01:24 pm »

Scancodes is the last (major) feature which is required by the Roadmap planning to complete SFML 2.6

We have already done a Round 1 of reviewing and testing with different branches and still some misalignments.
After quite some additional work and great documentation efforts, I believe the code base is close to finalization and we'd like to invite everyone to help review and test our Scancodes implementation.

Code & PR: https://github.com/SFML/SFML/pull/1235
Snapshot Builds: https://artifacts.sfml-dev.org/by-branch/feature/scancode/

Purpose

Scancodes are a very important feature that's been asked to be implemented in SFML for a long time. It gives developers a layout independent way of reading keyboard input. Suppose you're using standard "WASD" walking input scheme in your game. If you just say "if pressed sf::Keyboard::Key::A then go left", it'll work as expected only on a QWERTY and a bunch of layouts where "WASD" is in the place gamers usually expect it to be. But, it'll work wrong on AZERTY layout, which has "A" where "Q" on QWERTY is.

Scancodes prevent this problem. If we say "if pressed sf::Keyboard::ScanA then go left", we're telling something like "if pressed the key which is in the place where A on QWERTY keyboards is then go left".

Testing

Either of the follow applications can be used to test:

• SFML-Input: https://github.com/eXpl0it3r/SFML-Input
• SFML-Test-Events (feature branch: scancode): https://github.com/mantognini/SFML-Test-Events/tree/scancode

The Scancode names and documentation description are generally in reference to the AT-101 layout, as for example seen on the following image:


Testing is especially important if you have non-QWERTY layout. The more non-traditional it is, the better. Another good thing to test for is weird keyboards with non-grid layouts.

Things to test

• Alphanumeric buttons. See that scancode corresponds to AT-101 reference layout. Key description should depend on your layout and produce the same thing that you see when you type into a text editor
• Toggle NumLock on and off and see if numpad keys are correct. In a lot of keyboards if NumLock is turned off then "2" on Numpad acts as "Down"
• Try pressing F1-F12, Space, Tab, Enter, Backspace, Delete, etc. and confirm that they are correctly displayed
• Try pressing Ctrl and Alt keys. They have "Left" and "Right" variants and this should be shown in the test program
• Try changing your keyboard layout in system settings. For example, switch to DVORAK and test that the keys are still identified correctly

New API

• Enum sf::Keyboard::Scancode
• On key events: sf::Keyboard::Scancode scancode
• static bool sf::Keyboard::isKeyPressed(sf::Keyboard::Scancode)
• static sf::Keyboard::Key localize(sf::Keyboard::Scancode code)
• static sf::Keyboard::Scancode unlocalize(sf::Keyboard::Key key)
• static sf::String getDescription(sf::Keyboard::Scancode code)

14

SFML development / Removing dependency binaries

« on: January 26, 2019, 06:56:57 pm »

Some years ago the SFML Team had decided to remove the binaries of SFML's dependencies from the git repository. Reasons for the removal range from bad practice to bloating the size of the repository, but there were also concerns raised about usability of SFML on Windows.
The decision back then was to move the binaries into a dedicated repository and add that as sub-module. Unfortunately as you all know, that decision was never implemented.

Now, when we look ahead a bit and see how SFML may evolve in the near future, there are chances that more dependencies will be introduced (harfbuzz, Opus, MP3, ...), more platforms will be supported in one way or the other and it becomes pretty clear, that the current setup doesn't really scale well.

Having to provide binaries for all the dependencies and all the platforms that need it and keeping them updated, is a time consuming task. We also end up making trade-offs for small file size, to not further bloat the repository size. As such, the idea came up to propose yet another approach.

Remove the binaries from the git repository, but instead include the source code of said dependencies and instrument our CMake build system to build the dependencies when building SFML itself.
This has the advantage that we cut down the size of the repo, remove the binary building maintenance cost on our side, can add more dependencies without mentioned concerns and if people want to, they can more easily modify or update the dependencies for their own needs.

Notice, the goal isn't necessarily to add sub-modules or let CMake dynamically fetch stuff, but instead provide everything that's needed to build SFML and its dependencies, but we'd like to hear your ideas on that topic as well. As an example take a look at Qt's setup.

What are your opinions on this topic and are there any takers for implementing the CMake scripts changes?

15

General discussions / What pain points do you experience using SFML?

« on: January 07, 2019, 10:23:42 am »

Some of you may have already seen or even replied to, a week ago, we asked people on Twitter and Reddit what their pain points are or were when using SFML.

https://twitter.com/sfmldev/status/1078414172747169792
https://www.reddit.com/r/cpp/comments/aavn0s/what_pain_points_do_you_experience_using_sfml/

We started on Twitter and Reddit in hopes of catching those developers who aren't regularly visiting the forum, but since we're interested in collecting as much feedback as possible, we also want to ask everyone here.

What are/were the pain points you experience(d) while using SFML?