Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - eXpl0it3r

Pages: 1 [2] 3 4 ... 7
16
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?


17
General discussions / SFML featured in...
« on: December 10, 2018, 11:36:52 am »
As SFML has started to pop up here and there in different formats or places, I've decided to change the existing thread into a pinned thread, where we can post new things without having to create new threads every time. :)

Please post new-ish things SFML has been featured in!


Jonny just pointed out on Discord that Microsoft used SFML's Pong example in one of their Visual Studio 2019 Preview video to show off their cross-platform development features and more.

Thought some of you might find that interesting as well. :D


18
General discussions / SFML 2.5.1 released
« on: October 18, 2018, 11:44:09 pm »
SFML 2.5.1

A bit longer than expected, but here's the new SFML version! :)

This is a patch version release and thus only contains bugfixes.
  • After the big sf::RenderTexture refactor in 2.5.0 there were a few bugs which got fixed in this version
  • Linux saw some long await fullscreen/multi-monitor fixes
  • As well as a critical bug in the new clipboard API
And a few other fixes. The full changelog including detailed descriptions here:
https://www.sfml-dev.org/changelog.php#sfml-2.5.1

We're very grateful for everyone contributing, testing and discussing!

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!

19
SFML development / SFML Roadmap
« on: August 22, 2018, 04:52:22 pm »
Having just tagged the first release candidate for SFML 3, it's time to take a closer look at the rough roadmap for SFML.

SFML 2.6.x

Since the 2.6.1 release November 2023, we've fixed a few more issues and plan to release 2.6.2 within the next few weeks.

Since SFML 2.6 is the final SFML 2 version, we will continue to merge critical fixes, as to support anyone not planning to update to SFML 3 anytime soon, but do keep in mind that the priority for it will be lower and fade over time.

SFML 3.0

SFML 3.0.0-rc.1 has been tagged, which in the grand scheme of things means, that we're mostly feature complete (the new dependency management is still awaiting testing).

We believe to have achieved the goals that we originally defined:

  • Upgrading the SFML API for C++17
  • Cleaning up redundant and deprecated code
  • Adding features as we go along:
    • API breaking features only possible at a major version change
    • (low priority) Non-API breaking features

The plan moving forward is to do a lot of testing, hopefully with the help from all of you awesome people, to publish another release candidate within the next few weeks, and if all goes according to goes well, to release SFML 3.0.0 before the end of 2024. 🎉

Please report any issues, crashes, or general feedback, so we can make sure the SFML 3 release is as stable as possible.
Reach out: GitHub Issues / Discord / Forum / Twitter / Fediverse

SFML 3.1

Looking ahead, we have some pull requests open already that we put back into the "backlog", while focusing on getting SFML 3.0 finished up. We really hope to get those merged in SFML 3.1.
Additionally, we've made a few preparations in SFML 3.0, so we could add certain functionalities without breaking the API (e.g. the window state flag). Whether those will be added in 3.1 or later on, remains to be seen.


SFML 3.2

One thing we really want to change, is to have shorter release cycles.
We'll have to see how this plays out, since it still heavily correlates with how much free-time each of us can invest.

Having said that, the plan is to not let the scope of SFML 3.1 balloon too much, as such here are already some ideas that might make more sense to do in SFML 3.2 instead.


SFML 4

In the very first maintainer meeting, we decided to not change the underlying rendering API dramatically foro SFML 3 and focus on getting C++17 support out of the door.
But we also recognize that SFML's legacy OpenGL usage is a top priority, as it's preventing the use of the graphics module in quite a few scenarios, as well as not being able to use of OpenGL ES 2.0 or supporting Emscripten.

As such, the primary focus for SFML 4 will be to update the underlying rendering API. Whether this will bring support for multiple rendering backends or help with batching support, remains to be seen.

It's also very likely, that we'll be updating the C++ standard to require C++20, which should allow us to use std::expected and (C++23 feature) do more internal clean ups.

(click to show/hide)

20
SFML development / SFML Test Strategy
« on: August 15, 2018, 11:15:40 pm »
It's no secret that automated tests have many benefits and after many years of discussions and one stale git branch, it's time to finally dive in.

There are many different kinds of automated tests. We will limit ourselves to Unit Tests and Integration Tests for now. The following should give a brief overview of what kinds test we expect and how to approach testing.

Unit Tests

Unit tests should only test one specific unit independently from any other unit as much as possible. This means that we're not testing what effect one unit has on another unit, but simply check the functionality of that one unit.
For SFML a unit is most of the time simply a class. For example sf::Rect<T> is a unit, sf::Vector2<T> is a unit, but the unit tests for sf::Rect<T> shouldn't check that the properties of sf::Vector2<T> are set correctly, because the sf::Rect<T> unit tests, should only test the sf::Rect<T> interface.
The point is, if every class has its own unit tests, we can be certain that every class behaves exactly the way we expect them to, so they don't need to be retested.

The foundation for unit tests is setup in SFML 2.6.0, but massively expanded in SFML 3.


Integration Tests

Integration tests on the other hand do intentionally integrate multiple units to ensure that in combination they behave as expected.
For SFML this can often mean, that we let one unit pass through other units and finally transform the result into a format that can be asserted. For example the rendering of a shape would go through a render texture and then convert to an image, which can be compared pixel by pixel with a test data image.

The proper setup and intent of integration tests still needs to be determined, but some things will certainly build on top of the unit test setup.


What do we test?

Tests exist to assert that the promises we make by providing a public API, actually hold true.
As such unit as well as integration tests should only ever test the public interface and ensure that the API does what the documentation says.


When do we write tests?

For every new feature there should be multiple new unit tests, testing positive as well as negative test cases.
For every bugfix there should be at least one new integration test, that covers the bug and ensures that there's no regression.

21
DotNet / Drop .NET Framework in favor of .NET Core?
« on: August 14, 2018, 11:18:46 am »
SFML.NET has been slightly abandoned in the last few months and I'd like to change that with everyone's help. :)

One of the first things we need to do, is decide what direction SFML.NET should take.

  • Do we want to keep supporting .NET Framework?
  • What are the advantages of keeping support for the .NET Framework?
  • Are we going to support .NET Core only?
  • Are we supporting .NET Core 2 or also any other version?
  • What are the advantages of .NET Core 2?

I think, we did answer some questions already, but let's try to collect all the arguments here and then have one place to "document" the decision here.

22
General / SFML 2.5 CMake Migration
« on: May 23, 2018, 12:18:16 am »
With SFML 2.5.0 we have modernized our CMake build system largely thanks for Ceylo! :)
In the last weeks however we've noticed a considered amount of people not realizing the changes and thus wondering what to do with their "broken" build system. This thread should help clarify the required changes to utilize the new SFMLConfig.cmake file.

FindSFML.cmake has been removed
You can look for it as long as you want, it doesn't exist anymore, regardless of guide XYZ said, if you use SFML 2.5.0 there's no FindSFML.cmake anymore.

This also means, you no longer have to make sure that FindSFML.cmake can be found in CMAKE_MODULE_PATH. As such if you have some code like SET(CMAKE_MODULE_PATH ...) you can remove that from your CMake file.

SFML_ROOT is no more
Windows users (and maybe others) have gotten used to setting SFML_ROOT in order to tell the FindSFML.cmake where to look for SFML. This isn't true anymore and instead the error message with suggestion CMake throws at you, can finally be implemented.

Quote
Could not find a package configuration file provided by "SFML" (requested version 2.5) with any of the following names:

  SFMLConfig.cmake
  sfml-config.cmake

Add the installation prefix of "SFML" to CMAKE_PREFIX_PATH or set "SFML_DIR" to a directory containing one of the above files.  If "SFML" provides a separate development package or SDK, be sure it has been installed.

Meaning, if the SFMLConfig.cmake file can't be automatically located, you can provide the directory containing said file by setting SFML_DIR.

${SFML_LIBRARIES}, ${SFML_DEPENDENCIES} and ${SFML_INCLUDE_DIR} don't exist anymore
This is now mostly automated. The include directory no longer needs to be manually set, so this step can be completely removed. As for the libraries, all you need to specify is the dependencies on the highest level in a dependency tree. Meaning, if you want sfml-graphics, you only need to search for the graphics module and link the sfml-graphics library, CMake will take care of resolving the additionally dependencies like sfml-window or sfml-system. Even for static libraries, you don't need to specify the dependencies as CMake will do it for your.

Example CMake script

Update: Thrasher and I have put together a CMake-SFML project template, which also features quite a few useful links in the ReadMe: https://github.com/eXpl0it3r/cmake-sfml-project

Here's an example script that links sfml-graphics and sfml-audio and their dependencies.

cmake_minimum_required(VERSION 3.1)

project(SFMLTest)

## If you want to link SFML statically
# set(SFML_STATIC_LIBRARIES TRUE)

## In most cases better set in the CMake cache
# set(SFML_DIR "<sfml root prefix>/lib/cmake/SFML")

find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)
add_executable(SFMLTest main.cpp)
target_link_libraries(SFMLTest sfml-graphics sfml-audio)

Documentation
A more detailed usage documentation can be found directly inside the SFMLConfig.cmake file.

While you're here, you might as well try to get your project updated to modern CMake. This article might be useful for you. ;)

23
General discussions / SFML 2.5.0 released
« on: May 09, 2018, 11:59:11 pm »
SFML 2.5.0

We're finally here with a new SFML version! :)

Here are some highlights we're excited to share with an official release.
  • Modern CMake support with SFMLConfig.cmake
  • New system cursor API
  • New clipboard API
  • Introduction of sf::VertexBuffer
  • Added loop points for sf::Music
And many more features and bugfixes for which you can find the full changelog including detailed descriptions here:
https://www.sfml-dev.org/changelog.php#sfml-2.5.0

We're very grateful for everyone contributing, testing and discussing!

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!

24
General discussions / Discord server
« on: April 19, 2018, 10:33:45 pm »
While we all love and welcome people to IRC, times have changed and requests have been made to provide access to a more modern chat application. Discord has found a lot of popularity in recent years and offers a lot of options beyond just text chat.

With our Discord-IRC bridge we also try to not split the community, but to connect everyone. Come join us by clicking on the Discord logo below! :)


25
SFML website / Website downtimes in recent days
« on: March 08, 2018, 10:42:27 am »
Some of you have noticed that we had a long down time last night and had a few down times yesterday and last week. The root cause of it is unclear.

The long downtime last night was to replace the server hardware except the storage devices, as such we're hoping that the server will be running stable again.

Sorry for any inconveniences cause by this.

In case of any incidents I try to keep people up to date via @sfmldev on Twitter.

26
C / Shouldn't CSFML use CSFML as include directory?
« on: September 11, 2017, 08:10:45 pm »
Currently CSFML uses "SFML" as include directory. Which means, when you install SFML and CSFML the two include directories get mixed into each other.

Since they both use different header extensions it's not really an issue, but I feel it's not a very clean solution.

Wouldn't using "CSFML" make more sense?

27
SFML development / Current focus: SFML 2.5.1 Release
« on: September 07, 2017, 01:23:04 am »
In an effort to push development a bit more, we want to start focusing our efforts on one specific issue or feature at a time.
This thread serves as an announcement thread, so don't forget to add the thread to your watch list!

Current focus: SFML 2.5.1 Release

Progress tracking:

Needs testing:

Check the GitHub Project to see current progress!


Previous
(click to show/hide)
(click to show/hide)

28
SFML projects / SFML Projects - Platform to host, share and archive SFML projects
« on: August 21, 2017, 04:01:02 pm »

While the SFML forum provides a section for projects, it happens too often that nice projects get lost in the depth of that sub-forum or that the archive with the game executable or source code gets deleted overtime. With the SFML Projects website we want to provide a platform to host, share and archive projects that were made with or for SFML.

Contributions
  • SFML Projects is open source and hosted on GitHub. If people are eager to help out, I'll gladly add them as contributors!
  • In the very near future, I'll allow others to directly add and edit projects via the administration panel.

Contact

History

Seeing how really neat SFML games got forgotten and often their download links died as well, I had the idea to create a platform to share and archive SFML projects.
I made multiple attempts at creating a website that was simple to use, yet easy to manage. Switching from one CMS to the next framework, it never really clicked and development was slow and thus demotivating.
But recently I've been working with yet another CMS and noticed how easy it was to create a simple custom administration interface, plus utilizing some template to handle adding new projects easily.
Using the existing design, I was able to build a functioning and easily extensible site within just a few days!
It's not feature-complete yet as it currently is just a simple list of games and libraries, however with this base, it's relatively easy to create more detailed project pages.
A special thank goes to achpile and zsbzsb for having helped me out on previous versions in various ways!

29
SFML development / sf::NonCopyable and =delete
« on: April 04, 2017, 02:48:34 pm »
Info & Rules about this sub-forum

(Originally posted on the C++ standards thread.)

C++03 didn't offer a way to tell the compiler that a class wasn't meant to be copied, but in order to trick the compiler into preventing exactly that, one could make the copy-constructor and assignment-operator private.
sf::NonCopyable used that trick and by acting as an abstract base class (interface), all classes that should be non-copyable could simple derive from it.

The question would be:
  • Should we keep sf::NonCopyable and just change its implementation to use C++11 = delete?
  • Or should we remove the class and use the native C++11 language feature = delete?
In binary1248's latest C++11 refactoring, he's removed the class, in case you want to see how such a change would look like.


Personally, I find that sf::NonCopyable only existed to trick the compiler for a missing language feature. With C++ we got that feature through = delete, so I don't really see the reason to keep it.

Error messages will change, but people who are used to C++11, should understand the error message of C++11 better than a more cryptic error in combination with sf::NonCopyable.

30
SFML development / Clipboard Support
« on: March 21, 2017, 03:58:13 pm »
Info & Rules about this sub-forum

Note: Just to prevent potential confusion, this subforum is not just dedicated to SFML 3 discussions, but it's open to any SFML development topics like the this one right here.

Clipboard support has been a long requested feature (thread #1, thread #2) for many obvious reasons. In the past we had one attempt (forum post, pull request) at getting it implemented, but the discussion dragged on for a while and after the API discussion was mostly finished, nobody took it up and actually implemented the suggestion, until now...

In the past few weeks Ricardo (aka Ricky) has been working on a new implementation: https://github.com/SFML/SFML/pull/1204
His implementation seems to mostly resemble what had been discussed and is up to date with SFML's code base (switch back to Xlib).
While this thread can be considered a continuation of Aster's thread, I think starting fresh makes more time. I will try to summarize previous discussions.

I also like to mainly focus on the implementation bits and less about how the functions should be named, as this is a minor detail and will easily distract from the important discussion points.

Proposed API
// Get the content of the clipboard as string data
sf::String str = sf::Clipboard::getString();
// Set the content of the clipboard as string data
sf::Clipboard::setString(const sf::String& str);
 

Requirements
  • Linux (X11) requires access to a window's event processing and thus requires the use of a window.
  • Windows claims in MSDN to require a window handle to set the clipboard content, but in practice it seems to also work with a handle of NULL. For comparison, SDL and GLFW provide a window handle.
  • OS X and iOS don't require a window at all.
  • Android doesn't seem to require a window either.

Previous Decisions
  • The clipboard should not be part of the sf::Window API, but it's own class.
  • The use of a window is an implementation detail and should not be reflected in the public API.

Current implementation
  • For Linux, the implementation uses a dedicated, hidden and lazy-loaded window with its own busy-waiting thread to handle the events.
  • For Windows, there's no window handle used, instead NULL is passed to OpenClipboard.

Questions
  • Is the Linux implementation acceptable for us?
  • For Linux, should we instead try to use the global vector of windows that already exist in the window class? And how do we get access to the event processing of the given window?
  • For Windows, there's currently no window handle used, should the implementation be adapted to use a window handle? And how should the clipboard class get access to an active window handle?
  • For Linux and Windows, what should happen if there's no active window available?

Example code
(click to show/hide)

Pages: 1 [2] 3 4 ... 7