Topics

1

General discussions / French school looking for speaker

« on: July 23, 2021, 09:28:58 am »

Hi

I got a request from a french school, Gaming Campus (https://gaming.tech/), located in Paris and Lyon. They are looking for a speaker to give a 2 or 3 week course on SFML in november. It would be in french, but if the person speaks a very good english they could be interested too.

If someone is interested, please contact me.

2

SFML website / Forum database errors

« on: May 04, 2020, 09:09:25 am »

Hi

It seems that nobody was able to post a new topic nor perform a forum search the last few days.

The SFML server was moved to a new host, and apparently this caused an error in the forum database.

This should now be fixed.

Apoligies for the inconvenience!

3

General discussions / Mario is now a member of the SFML Team

« on: January 06, 2015, 08:17:02 pm »

The SFML Team is growing again!

Mario is really involved in the development of SFML, especially on the Android side, so we officially integrated him to the team today.

Congratulations, and welcome

4

General discussions / Different implementation for setFramerateLimit

« on: September 28, 2014, 07:41:43 pm »

Edit: Original thread start:

I tried some SDL. I find SFML better for OOP, Documentation and Guides/Tutorials.

2 cents:
- GL core spec should be used by default. Yes I can recompile SFML, but defaults matter. 
- http://www.sfml-dev.org/tutorials/2.0/window-window.php says it uses sf:sleep for managing framerate limit, and that sf:sleep's "resolution depends on the underlying OS, and can be as high as 10 or 15 milliseconds". I find it very important to use the best (most accurate) solution on every OS. i.e. Windows has Multimedia Timers. Using an inaccurate thread-sleep in non-v-synced mode kind of defeats the purpose of a non-v-synced mode (reduced input lag).

Cheers.

Edit: Laurent's response:

http://www.sfml-dev.org/tutorials/2.0/window-window.php says it uses sf:sleep for managing framerate limit, and that sf:sleep's "resolution depends on the underlying OS, and can be as high as 10 or 15 milliseconds". I find it very important to use the best (most accurate) solution on every OS. i.e. Windows has Multimedia Timers.

Please have a look at the source code before making (wrong) comments about it

5

General discussions / The new SFML team

« on: April 21, 2014, 07:50:41 pm »

Hi

After this discussion, I've decided to open the development of SFML to a team composed of the most talented and involved developers in this community (sorry for those I forgot -- the team may grow in the future).

What this means is that I'll no longer be the only one to decide and write code; this was already the case with Nexus, Marco and Jonathan being part of the team, but this was just enough to make SFML survive. These new members (yes, the list is coming) will bring their motivation, ideas and technical skills, and there will be nobody to say "no" to what they propose. Instead, the team will discuss every suggestion and implement it if it meets an agreement.

Development of bug fixes and new features will also be a lot more open to the community, we don't want motivated members to see their contribution rejected most of the time. We need everyone's energy to make SFML the best multimedia library out there.

The team is composed of:
- Nexus
- binary1248
- Tank
- Grimshaw
- eXpl0it3r
- Hiura
- Sonkun
- and myself

In this team I'll be nothing more than a regular member: everyone will get an equal weight on decisions.

I hope you like this major change; in any case you should soon see a difference

6

General discussions / Future release of SFML 2.2 (feedback needed)

« on: April 01, 2014, 12:40:32 pm »

Hi

I'd like to announce the future release of SFML 2.2. I don't have a precise schedule, so don't ask "when"; all I can say is that it will be soon.

My plans are to integrate the ios/android branch, even if not 100% stable. As long as the public API is stable, it doesn't hurt to include these ports as a "technology preview" in SFML 2.2.

I'll also include the additional blending modes branch after more testing.

So basically I open this thread to get more feedback from you, users. What do you think should be integrated into SFML 2.2? What critical bugs should be fixed? Keep in mind that "soon" means that we'll work on important / critical tasks only, don't start to suggest tons of new features here

7

General discussions / Current situation of SFML

« on: January 27, 2014, 04:25:21 pm »

Hi

Many of you have probably noticed that very few commits were made in the last 2 months. I'm currently very busy doing something totally different (working in my house), and this situation will probably last a few weeks or months more. Since SFML can't wait this long, I've asked Nexus to be "me" until I can be available again, and he agreed to help

What this means, is that in the next months he will be the one who makes new commits, decides which features are implemented, etc. Of course the rest of the team (Marco and Jonathan) is still here, and I will continue to check the forum, the task tracker, and if needed, help with design decisions or very specific technical questions. And you, community members, can still contribute with pull requests or patches -- or more if Nexus decides that he needs more specific help.

I hope this will be enough to get SFML 2.2 released in a decent amount of time, and to start working on important things for SFML 2.3.

8

General discussions / Android and iOS ports available for testing

« on: November 29, 2013, 03:56:03 pm »

Hi

The iOS/Android ports are finally ready for beta-testing. This happens one month after the expected date, sorry for the delay (everyone is very busy -- more than usual). Until Jonathan pushes the code to the public repository, here is what you need to know if you want to play with them.

Where?

The ports will be available in the ios_and_android branch of the repository. This way it won't bother people who are not interested, and the amount of testers (and reports) is kept under control.

How to compile the iOS port?

To compile the iOS port, you must use the Xcode generator of CMake, and define the "IOS" boolean variable (set to TRUE) before configuring for the first time. The generated projects can then be compiled for x86 (simulator) or armv6/v7 (device) by selecting the target in Xcode; no need to generate multiple builds for that. SFML is built as static libraries on iOS (this is the only option for this OS).

To use SFML in your iOS app project, do as usual: add the include path to your project settings, and drag'n'drop the libraries into your project. Since SFML is linked statically, you'll have to link all its non-default dependencies as well (extlibs/libs-ios).
Note that you'll need a registered Apple developer account in order to copy and run your app on a device; otherwise the simulator will be your only choice.

How to compile the Android port?
How to compile the OpenGL ES port for Linux?
Things to know for Android

Jonathan will explain that as soon as he is available

New API

Only a few things have been added to the public API:

• The sf::Keyboard::setVirtualKeyboardVisible function
• The Touch API:
  
  • A sf::Touch class (similar to sf::Mouse)
  • sf::TouchBegan / sf::TouchMoved / sf::TouchEnded events (similar to mouse events)

General things to know

The sensors (accelerometer, gyroscope, compass, ...) are currently using the Joystick API (see the sources for more detail about the mapping). We'll soon add a sf::Sensor API that better matches the requirements.

The foreground / background events are mapped to the GainedFocus and LostFocus events.

Orientation changes are mapped to the Resize event.

sf::Shader is not available, because the implementation is based on OpenGL ES 1. Shaders are only available in OpenGL ES 2, which would require a major rewriting of the graphics part. So that won't be done in a near future.

Things to know for iOS

On iOS, the working directory is automatically set to the resources directory.

There's no audio module on iOS, I'm still waiting for libsndfile to add a license exception for iOS so that I can use it statically without breaking the terms of the license. The author said it was one of its priorities, but it was months ago and I've got no news...

The implementation should be compatible with iOS 4.0 and more.

The size of the window is ignored, the screen size is always used.

Examples are not available. It seems that CMake is not ready for that, it still requires too many hacks, and even with them, it was still pretty bad.

The ugly hack: you need to include <SFML/Main.hpp> in the file where your main function is defined. This is because SFML has to hijack it, and rename your own main to call it later.

There's no specific support for high-resolution (retina) screens, they currently produce the same output as low-res screens (this will be done later).

Important

Until everything is merged into master, please use the forum for your feedback. You can post here or open new threads. There are still many things to do, I don't want to pollute the task tracker

9

General discussions / Better keyboard handling

« on: November 25, 2013, 11:06:53 pm »

Hi

I'm currently working on improving the keyboard support, and after having a look at how other libraries handle it, I think I have what I need to finally provide good support.

However a few design choices have to be made, so I'd like to collect as many ideas/feedback/use cases as possible to make the right decisions.

There are three problems so far:

1) Many keys have 2 or 3 symbols on them. Which one should be reported when the key is pressed? The obvious answer would be "the main one", i.e. the one that is produced when no modifier key is pressed. However the default symbol for a key may not be the most "standard" one; for example, on my french keyboard, pressing '1' yields a '&', and to get a '1' I have to press shift. SDL has a special handling for these keys, so that the numbers are always reported, even if they are not the default symbol. Same for 'ù' and '%', etc.

2) Should modifier keys (shift, alt, control) be interpreted or not? In other words, does the reported symbol changes when we press a modifier key, or should there be only one symbol reported for each key?

3) Should the scancode be reported too? Reminder: the scancode is a hardware-dependent code that represents the physical location of the key on the keyboard. According to SDL sources, although scancodes are hardware dependent, there seems to be standards. The scancode is typically useful when a program provides the ability to choose key bindings; in this case you don't care which key is pressed, you just want to save its code and be able to test it later. Scancodes are better than key codes here because there is always a unique code for each key (within a keyboard), whereas all key that are not part of the sf::Keyboard::Key enum will all have the same code, sf::Keyboard::Unknown.

What other libraries do:

- SDL is pretty accurate, only 2 or 3 keys are not reported correctly on my keyboard. Modifier keys are not interpreted. It provides scancodes.

- GLFW is bad, on Windows it simply returns what the OS gives, which is wrong for almost every non-trivial key on my keyboard. Modifier keys are not interpreted as far as I remember. It provides scancodes.

- Qt is the best, it always reports the right symbol (even ù, é, ç, £, §, ...), its key codes enum is impressive. Modifier keys are interpreted. It provides both scancodes and the native OS key code.

I haven't tested Allegro, which is usually in my reference libraries too.

10

SFML website / Language of donation (Paypal) page

« on: November 15, 2013, 12:19:37 pm »

Hi

Yesterday someone reported that the donation page on paypal was always in french. Since paypal seems to automatically select the user language, and mine is french, I can't verify this.

Can someone check this for me?

11

General discussions / Moderation reports

« on: October 26, 2013, 09:32:00 am »

Hi

Today I got many reports in my e-mail box from you guys, reporting spam on this forum. I'm glad you care about keeping the forum clean, and I thank you for that

However there was really a huge number of reports, my mail box was full of them. So, maybe you could send reports for less obvious moderation issues, and don't care about robots? Don't forget that I'm on this forum everyday, sometimes every hour, and that I always read every single post. If there's obvious spam, be sure that I will see it and eradicate it quickly

12

General discussions / Exceptions in SFML 3 ?

« on: October 11, 2013, 08:11:04 pm »

This topic was originally following this discussion.

It's not bool or err(), it's usually both

And yes, SFML 3 will most likely use exceptions everywhere.

13

General discussions / SFML team is growing

« on: August 05, 2013, 08:35:40 am »

Hi

I'm proud to announce that the SFML team counts a new member

Jonathan (a.k.a Sonkun) will maintain the Android port, the Linux packages for SFML (and for as much bindings & add-on libraries as possible), and continue to work on his Python binding.

And yes, he's a french speaking guy too

14

General discussions / SFML 2.1

« on: July 27, 2013, 01:51:11 pm »

I'm happy to announce the release of SFML 2.1

It's a bug fix release, so don't expect anything new.

I'll focus on implementing new stuff in the next release, SFML 2.2.

15

DotNet / SFML add-on for Visual Studio

« on: July 17, 2013, 03:01:45 pm »

RadicalEd (from the french forum) has created and put online a template for SFML.Net, directly installable from the gallery.

Follow the link for more information

http://visualstudiogallery.msdn.microsoft.com/856f52bc-b4a7-4a9d-a235-620565ccac32