Topics

1

SFML development / Allow changing processing interval in SoundStream

« on: May 27, 2020, 01:51:41 am »

Hi guys,

https://github.com/SFML/SFML/pull/1517

I can see this pull reques is currently closed, but also on the discussion board for SFML 2.6 (and a very worthwhile feature). Lets discuss.

Is this a feature we want for 2.6 given the recently reduced scope, and what exactly is the current state of the PR (testing or review)?

2

General discussions / Concerned and Eager

« on: May 26, 2020, 04:52:27 pm »

Hi guys,

I would like to share some thoughts that have been plaguing me a bit recently.

I am a huge fan of SFML and I feel quite heavily invested in the project, but I am a bit concerned about how the library will continue to keep up with changes in the industry. I have been lurking around here for long enough to have seen discussions on all of the things that concern me. Two of my main concerns are:

Rendering Backend - OpenGL deprecation is going to be an issue at some stage, support for multiple rendering backends has been discussed/prototyped which is great!

C++ Standard Integration - There are classes in SFML that have been made obsolete by features added in newer C++ standards (mostly thread related). There are also some concepts, such as move semantics, that really should be implemented.

While neither of these are actually a real issue at this very moment, I am concerned about how long it will take to adapt the library when they do become immediate issues. I know that the library is maintained by the devs in their spare time, and the dedication you all have is incredible. However, I know SFML 3.0 is far beyond the horizon and I am not sure that the official plans even encompass the pending rendering backend issue?

I guess that what I am trying to articulate is that I am concerned about SFML being left behind by the industry. These concerns may be completely unreasonable, but I know some others share the same (see Elias blog post about moving away from SFML in favour of SDL for similar concerns), but I have them none-the-less.

Instead of worrying about this, the better thing to do would be to help contribute. I have already said that I was going to work on implementing move semantics for the library, but I am having second thoughts because I don’t think move semantics are on your critical path (making it a low-priority pull-request).

With that said, what can I do to help SFML with something more immediate that would help push towards 2.6 or 3.0? I am keen af.

Any thoughts or suggestions?

3

SFML development / SFML Move Semantics

« on: April 14, 2020, 01:40:18 am »

Hi guys,

I was hoping to find some information about the status of move-semantic implementation in SFML. I have seen a bit of discussion regarding C++ standard support and plans on the SFML roadmap, but I am not sure if any concrete decisions have been made, or if anyone is already working on it?

My motivation for asking is because I would be more than happy to work on implementing move semantics for SFML, but only if it fits with SFML's current plans and would be taken seriously / reviewed for merging.

Much love!

4

General / CMake SFML Private Linkage

« on: January 19, 2020, 03:02:37 am »

Howdy pardners

Throughout my time using SFML I have built up a library of common utility classes that I like to include in all of my projects (as I am sure most of us have). I am using CMake to generate build files for my projects (Linux), which works great, but something bugs me that I dont understand and I am hoping someone here may be able to explain.

Consider the following minimised CMakeLists.txt example

cmake_minimum_required(VERSION 3.12)
project(my_lib)

# Set project paths.
set(EXE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/example)
set(INC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include)
set(SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src)

# Find SFML.
find_package(SFML 2.5 COMPONENTS graphics system window REQUIRED)

# Build library.
file(GLOB_RECURSE LIB_SRC ${SRC_DIR}/*.cpp)
add_library(${PROJECT_NAME} STATIC ${LIB_SRC})

# Set include directories publicly.
target_include_directories(${PROJECT_NAME} PUBLIC ${INC_DIR})

# Link library to SFML privately.
target_link_libraries(${PROJECT_NAME} PRIVATE sfml-graphics sfml-system sfml-window)

# Build test
add_executable(my_exe ${EXE_DIR}/Test.cpp)

# Link test to library
target_link_libraries(my_exe ${PROJECT_NAME})

This script does the following:

• Finds SFML
• Builds my llibrary
• Links my llibrary to SFML
• Builds my executable
• Links my executable to my library

What bugs me here is that I link my library to SFML manually, but my executable also gets linked SFML automatically, despite the fact that I am using the PRIVATE keyword while linking my library to SFML. This happens regardless of whether my library and executable are defined in the same CMake script, or seperate scripts with the executable adding the library via the add_subdirectory command.

This logic doesn't hold in other similar situations, which leads me to believe it might have something to do with the SFML cmake config? Can anyone explain the logic to me?

5

General discussions / Movement Scripting

« on: September 12, 2019, 05:51:17 am »

Hi guys,

Just wanted to start a general conversation about how you have implemented movement scripting in your games, i.e. how do you define a path for an entity to follow. Has anyone implemented this in a generic way?

I recently created a class called Trajectory, which allows you to add time-stamped position/rotation points, then a getter function that returns interpolated position/rotations based on an input time value.

This works well enough for my use case, but I can imagine better solutions exist for motion that ought to be smoothed using splines or something like that.

6

SFML projects / Procedural Pacman

« on: March 01, 2019, 12:56:50 pm »

Hi guys,

I have recently started developing my first proper game using SFML, it is going to be a Pacman clone that uses procedural generation to produce randomised maps. At this stage I have just finished working on the map generation algorithm which consists of three stages:

The Obstacle Map - uses recursive backtracker to produce a grid of number-clusters.
The Collision Map - treats number clusters as obstacles, adds traversable paths between them.
The Game Map - Assigns type to path cells (i.e. dot/intersection/player/etc).

I created a generic tile set image that contained all of the possible obstacle shape segments and wrote a nearest-neighbour algorithm to dynamically build a tile map to match the collision map data. The results of the algorithm can be seen in the attached image.

I am now moving into the game logic itself, which I will post updates on. Part of my motivation for this project is to gain experience with some programming patterns that i will need to know for another project in the future, so I expect this game to be very over-engineered by the end.

7

Graphics / Superfluous Transformations in Sprite Batch

« on: February 19, 2019, 11:23:12 pm »

Hi guys,

I am currently looking to write a Sprite Batch class to assist in rendering a large number of sprites and would like some advice so that I don't needlessly double up on transform calculations.

My approach is to write a custom Sprite class that inherits only from Transformable (not Drawable) and provides a function to get it's (untransformed) vertices. I would also write a Sprite Batch class with an "addToBatch" function that takes a custom Sprite object. The Sprite Batch would get the Sprites vertices and its Transform, apply the transform and store the resulting vertices in a Vertex Array (or Vertex Buffer).

The Sprite Batch itself would inherit from Transformable and Drawable so that it can be rendered as though it were a native SFML entity. Within the inherited draw function, it would send set the Render State's Texture and draw a bunch of Sprites in a single draw call. This seems straight forward, but I noticed in the source code for Render Target, that the Render State's Transform is applied to all of the vertices before drawing. This would mean that all vertices have had two transformations applied in total. Is this something that would be detrimental to performance?  Or am I being overly paranoid?

8

System / Issues with SFML/OpenGL.hpp on Mac OS

« on: January 14, 2017, 01:20:52 am »

Hi guys,

I am new to SFML and have come across an issue and would like some advice on how to report it, or find out if it is already a known issue.

I have been trying to use the SFML/OpenGL.hpp header to access openGL function calls on a MacBook. However, this header file does not give me access to the standard OpenGL functions for generating or binding/unbinding vertex arrays, instead I am provided with Apple-specific versions of those functions as shown below:

glGenVertexArrays(GLsizei n, GLuint *arrays)  --->  glGenVertexArraysAPPLE(GLsizei n, GLuint *ids)
glBindVertexArray(GLuint array)  --->  glBindVertexArrayAPPLE(GLuint id)

After some research and experimentation on the subject, I found the cause of this to be the inclusion of a header file within the SFML/OpenGL.hpp header:

.....
#elif defined(SFML_SYSTEM_MACOS)
    #include <OpenGL/gl.h>
.....

This header file I believe should actually be replaced with:

#include <OpenGL/gl3.h>

As I mentioned before, I am new to SFML and OpenGL so I may very well be wrong here, all I know is that if I include the above header file, I get access to the standard OpenGL functions to generate and bind vertex arrays. Using the Apple specific ones mentioned earlier result in my calls to glDrawArrays failing to render (no error messages), but using the above header and the standard vertex array functions fixes this problem.

If anyone has any advice on how I could further this issue, or if I am wrong in some way, I would appreciate your time.