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.

Messages - SuperV1234

Pages: [1] 2 3 ... 13
My comment wasn't directed at you or related to having a BDFL. I was trying to achieve calling out a self serving proposal by Vee, one which would give him much more influence over the direction of the library at the expense of other stakeholders.

Could you please point out where I said that my vote would weigh twice as much as the other stakeholders' vote?

Or could you please point out where my proposal mentioned that if one of Vittorio's proposals gets below 75% approval he gets a pass anyway?

Oh, I guess I never said neither of those things. Just complete insanity.

As there recently were some disagreements on whether certain PRs should be merged or not, or on whether SFML should move in a specific direction compared to another, I believe it would be in the best interest of the SFML project and of the maintainers' time to decide on a simple process that defines "consensus" for us, to minimize time spent arguing and working on changes that will not end up being part of SFML.

I propose a simple system loosely based on WG21 straw polling -- basically, in case of a disagreement, all active SFML team members will vote with a Y/N. 75% of voting in favour of changing the status quo is required to proceed.

Despite many SFML team members being listed on GitHub, I believe the currently most active ones are:
- Vittorio Romeo
- Chris Thrasher
- Lukas Dürrenberger
- binary1248

I suggest that those four should be the ones taking the vote when required. If anyone else from the SFML team would like to be included in the polls, please let me know.

Note that there won't be a formal process for polling, but let's say that if 75% of voting members express concerns/disagreements with a proposed change either on GitHub or on Discord then there's no point in trying to argue or continue work on that proposed change.

General discussions / Re: Anyone targeting 32-bit platforms?
« on: December 24, 2021, 04:35:59 pm »
My case is not statistically significant at all, but still I'm using SFML with TGUI for my own applications and sometimes on freelance. And after the third complaint that application doesn't work my default choice is Win32 for all applications. To be clear - those complaints weren't SFML-related. 
But I'm not active user of SFML and can live even without x32 out-of-the-box support.

To be honest I not understand how architecture could be related to C++ standard? Architecture about users and standard is about developers.

Thanks for sharing your use cases, that is good to know. I wasn't really clear in my OP, I was mostly thinking about people developing on 32-bit architectures rather than targeting them via cross-compilation -- in my experience those kind of people are not really interested in having updated toolchains or development environments.

Regardless, there is no consensus on the proposal of dropping 32-bit support for 3.x, so this will not happen anytime soon.

General discussions / Anyone targeting 32-bit platforms?
« on: December 23, 2021, 07:43:54 pm »
Hello -- we are considering removing 32-bit support from SFML 3.x.

I'm curious if anyone has actively been using SFML targeting 32-bit platforms.
If so, what's your use case?

Also, do those platforms support C++17?


General discussions / Re: New SFML Team Member: SuperV1234
« on: November 30, 2021, 06:16:47 pm »
Thank you for the warm welcome! Eager to bring SFML into the modern C++ era ;)

SFML development / Re: Getting the ball rolling
« on: November 23, 2021, 12:46:43 am »
I see, but since you opened a PR in the SFML repo, the idea is probably also that other users can benefit from the changes and at some point it becomes part of the "official" version, no?

It's totally fine to have things messy as a PoC, but I'd still say we should clean a bit up before merging to the main repo (on any branch). And by that, I definitely don't mean the code needs to be perfect, but things like passing CI, readable commit history, and an easy way to comprehend changes (this is where commit messages help, I don't insist on changelog for now). Not for me personally, but to give other users the option to comprehend the changes and to contribute themselves with feedback, comments, improvements.

It's part of continuous integration: make sure things are more or less "green" right away -- otherwise we accumulate tech debt that we have to sort out later, in a giant PR when merging to master. In my opinion, if we take SFML 3 serious, we should make the branch usable from the start, and motivate users to try things out.

This is also what we would communicate by staying on master. It doesn't mean there won't be many changes, or even breaking ones, but that it's in an internally consistent state and ready-to-use, and it makes us accountable :)

Would be great to hear other team members' input here.

I totally agree with you, and that's why I don't want my big PR to be merged. If someone wants to use it, they can checkout the branch and play around with it.

For merging stuff into SFML, I want to create smaller and easily-reviewable PRs. I already have a plan of how to split the work, I just need a target branch and someone that reviews the stuff.

My current plan of attack would be the following:
  • Get the warnings changes merged, as this would cause lots of conflicts against larger changes
  • Create a sort of release branch 2.6.x, for any remaining features/fixes for SFML 2.6 (e.g. Scancodes)
  • Start with step-by-step PRs for C++17 on the master branch
  • Back merge changes on the 2.6.x branch to master (limited set of changes)
  • Back port critical fixes to 2.6.x and consider patch releases after the 2.6.0 release

The plan sounds good, but if we had a separate `sfml3` branch we could already start sending PRs towards it in parallel, we don't need to wait for scancodes or #1846. Merging either into the `sfml3` would be relatively easy.

As originally defined in the Roadmap, I'd like to keep the SFML 3 release relatively slim and just mostly get C++17 changes in and much rather do a bigger API jump for SFML 4. There's some advantages to long living API stability (e.g. see all the SFML learning material that applies for basically all SFML 2 versions), but ultimately trying to bring a whole API evolution next to a C++17 refactoring in one release, will extend the release horizon already to multiple years, but one step at a time. ;D

I disagree with this point, I think that this is a great opportunity to clean up the API. It's been years and we don't have SFML 3 yet. Are we seriously going to ask people to wait a decade before we can do some API breaks?

If users are not able to make small reasonable changes to their code to keep up with an evolving library, they can always use the older versions. We don't want to end up in a situation where we have to sacrifice the quality and speed of our work. SFML 3 offers an opportunity to improve SFML as a whole, and a new major version does imply API-breaking changes.

SFML development / Re: Getting the ball rolling
« on: November 22, 2021, 04:26:37 pm »
I wonder though if we should not use the master branch directly for SFML 3, and maintain a separate sfml2 branch for a while. [...]

I think that creating a `sfml3` branch is a good starting point. It doesn't mess with `master`, and we don't need a lot of feedback/exposure while we're just starting out. As soon as we have something more significant, we can start asking for feedback and potentially change our approach.

What I would appreciate regarding contributions, is that pull requests are reasonably sized. We can make an exception for the initial one, but if possible let's not add even more to this one. The risk of big PRs is that it becomes a daunting task to review, and people are scared off if they have to invest multiple hours just to go through the code -- which is exactly what we don't want ;)

Also, would it be possible to merge dozens of commits to one, or a few, with meaningful commit messages? That would also help understanding a lot :)

The large PR is, as previously mentioned, a "proof of concept". More of a statement than anything, saying: "Hey, I did this in two days and it works on a real game. Let's get to work!".

I don't want that PR to be merged, I want to use it as a testbed and maybe maintain my own fork of SFML as I don't care about stability and want to experiment with stuff.

These are the things I request:
1. Please give me a target branch I can send PRs to, in order to initiate the SFML3 project.
2. Please tell me that my (small) PRs will be reviewed and merged in a timely manner, within reason.

If I can have both (1) and (2), I'll start creating small PRs that can be individually reviewed. The first one will only change CMakeLists to build in C++17 mode. The second one will have some small C++17 usage. And so on.

Looking forward to know how to proceed.

SFML development / Re: Getting the ball rolling
« on: November 19, 2021, 09:44:05 pm »
Here's a proof of concept PR that converts SFML to C++17 and removes some classes made obsolete by the C++ Standard Library: https://github.com/SFML/SFML/pull/1847

SFML development / Getting the ball rolling
« on: November 19, 2021, 07:15:16 pm »
This is a post from the perspective of a SFML user who has contributed small PRs in the past. To me, it feels like the development of SFML is stagnant. It's 2021, and SFML is still stuck on C++03 for no good reason whatsoever.

I open the roadmap on GitHub and I see a PR for a small reasonable improvement that was created back on the 12th of October 2014, and that is still open and unmerged.

- Why is the development of SFML stagnant?
- Why does it feel like there have been no major improvements for almost a decade?
- Who decides what should be worked on?
- How does someone apply to be part of the team that decides the fate of SFML?

I want to see SFML transition to C++17 and become a modern, useful and popular library.
Yes, I am volunteering to do the work. But I don't want to send a PR that's going to be left untouched for 7 years.

How do we get the ball rolling?

This is my proposal:
1. I'll create a branch for SFML 3.x, which is going to be C++17-only.
2. I'll start making some basic changes (e.g. adding move operations for `sf::Shader` and similar classes), and create PRs towards that branch.
3. Have the SFML team review the changes and get consensus as we go along. Don't aim for perfection. Don't aim to have a perfect plan right from the beginning. Move fast and break things.
4. Get a few major changes done (e.g. the entire codebase uses move semantics), and ask for community guidance and feedback.
5. Rinse and repeat.

Shall we?

SFML projects / Open Hexagon - now released on Steam!
« on: November 12, 2021, 12:16:56 am »

Hey folks! I remember posting about one of my first SFML projects, Open Hexagon, about 6-7 years ago. I kept working on it (with the occasional year-long pause), until it finally reached a state where I felt proud to release it on Steam.

Open Hexagon is a "spiritual successor" to Super Hexagon, a popular indie game that was created by Terry Cavanagh back in 2012. The basic concept is quite simple: you are a small triangle, and you need to avoid the incoming obstacles by spinning around the center of the screen. Note that Terry Cavanagh fully endorses the project!

Open Hexagon expands upon this simple mechanic by adding features such as a 180° swap move, curving walls, and more. However, the most important thing is that Open Hexagon features a powerful Lua scripting system, allowing creative people to create their own levels. I've seen incredible creations, ranging from brand new games implemented as a Open Hexagon level, to "Bad Apple!!" being embedded in the game via a matrix of moving walls.

The game is written in C++17, and it's completely open-source. The source code is available on GitHub. If you have any question about the game itself or any implementation detail, feel free to ask here on or the official Discord server -- we have a channel dedicated to level development via Lua scripting and a channel dedicated to the development of the C++17 engine.

I also wrote some articles on the game's internals. As an example, check out "vittorioromeo.info: implementing secure leaderboards for my game", explaining the cheat prevention mechanisms I used to implement a fair and competitive online environment.

I sincerely hope you check out the game and enjoy it.


SFML projects / [Steam Release] Open Hexagon
« on: July 18, 2020, 02:11:30 am »
Hello folks!

I've recently released my first complete game (powered by SFML) on Steam, Open Hexagon:

Open Hexagon is a fast-paced and adrenaline-inducing paced arcade experience by Vittorio Romeo. Designed for moddability and custom level creation.


While it might look like just a clone of Super Hexagon on the surface, it is far from that. Other than brand new gameplay features such as a 180° swap and curving walls, Open Hexagon was completely designed with modding and customization in mind.

Users can create custom levels using Lua scripts, and I have seen some fans creating some absolutely mind-blowing levels that push the engine to its boundaries. I've also had fans thank me for getting them into programming, and that has been an amazing feeling.

The history of this game is quite interesting. It started as a clone of Super Hexagon about 7 years ago, and it was one of my first C++ projects. Over time it developed a community of fans who started creating amazing custom levels, and enjoyed competing with each other for the highest scores. I've worked on the game for a few years in the past, adding features that distinguish it from the original, and making it more and more unique.

After a long hiatus, I've returned to the community and I have started working on Open Hexagon again. The last few months' efforts resulted in a Steam release, with many improvements and new features.

Despite the Steam release, Open Hexagon is still available for free as open-source (and always will be): https://github.com/SuperV1234/SSVOpenHexagon/

Hope you enjoy the game, and let me know if you have any question! ❤️

Great talk. Thank you.

Interestingly I have an ECS implementation which is very close to yours and was developed completely independently [1]. Same emphasis on compile time configuration (C++1y FTW). The bitset with tags at the end, the components meta list and the concept of signature, everything is here. For that latter I don't request the user to declare his signatures prior using them (I use Eric Niebler's tiny meta library). Yet we both pass lambda with expanding auto& arguments matching the components. Awesome.

My tuple of vectors of components data are "compressed". Random access requires an extra level of indirection through a lookup table (handle ID+counter). Initially I thought it was a good idea which allowed me to loop through valid components data without encountering "holes" but it prevents me from looping over more than one vector at the same time because indexes don't necessarily belong to the same entity (compression might reorder slots in one vector but not the others).

Also I should definitely use std::get<T> rather than std::get<size_t> for tuple element access. It simplify things greatly ;)

[1] I'm by no mean a game developer but got interested in ECS after reading stuff about DOD. I don't remember having watched your video but I for sure read lots of articles on the net. The compile-time approach (meta list of components) without some kind of static counters or typeid doesn't seem common at all.

Thanks for the feedback, glad you enjoyed the talk!

It's really cool to see that someone else had a similar idea - I think heavily using compile-time computation to define ECS architectures is valuable and I'll continue to explore it further in the future.

There is another C++14 developer who built something interesting as well:

Is your implementation available online? If not, consider putting it on GitHub - I would be happy to see it and learn from it.

Sounds very interesting and I will definitely watch full video later, but the first thing I've noticed while looking at the source code on github is that it is barely readable. 1k+ line of source code in file p7.cpp, not to mention a lot of files in Other folder with nonintuitive structure and contents. It would be much better to have separate file (possibly with header/source separation) for each class and without any other files that just include other files without having any additional code in them.

All the code segments were written for the talk - they're supposed to be shown one after another, explaining the additions/removals/changes from the previous code segment. They were made with the idea of a "step-by-step" live talk in mind, so I understand that they might not be well suited to reading. Sorry about that!

Regarding the code in the "Other/" folder - that's code that has been included mostly to get utility functions out of it. There's also an outdated ECS library prototypical implementation - my intention was to show some of the ideas present in the library but not in the live code segments if I had enough time during my session... but I actually ran out of time  :-\

So, yeah, the material was created with the live talk in mind.
However, if you'd appreciate me to explain anything regarding the code or the talk, don't hesitate to ask :)

Hello SFML community.

Like last year, I attended the truly excellent CppCon 2015 conference (Bellevue, WA) and presented two talks.

The video of my first talk, which is heavily oriented towards game development, is now available on the conference’s official YouTube channel:


The talk shows the audience how to write a simple yet powerful C++14 component-based entity system, from scratch.

I use SFML for window/input management and to render simple 2D graphics.

Modern C++ features and idioms are used.
I’ve tried to make the implementation as cache-friendly and data-oriented as possible while maintaining a reasonable level of simplicity.

It is not an AAA framework, but I think I’ve managed to write a small powerful system that shows the benefits and ideas behind a data-oriented ECS.

Choices I’ve made:

  • Components are logic-less. (They are simple structs.)
  • Entities are implicit. (The Entity class is just an ID with some metadata.)
  • Components are stored in separate, contiguous arrays. (Every component type has its own array.)
  • Systems are implicit. (Entities are matched using “signatures”.)
  • Entity metadata is sorted in memory for efficient iteration. Component data is not sorted or “compressed”. (Think about the storage as a relational table, where the columns are the entities and the rows are the component types.)

There are many open-ended questions and possible improvements of this implementation - my goal was showing people how beneficial and convenient a more data-oriented and component-based approach is, and how C++14 makes coding such a system extremely satisfying (thanks to its modern features and cost-free abstractions.)

I’m very open to feedback and would love to hear what you think.
Hope you find the video interesting!

You can find all the material (slides and code) on my GitHub repository:

I don't really understand what the purpose of those texture and layer handles is.

According to the comments "Textures must be bound in advance for maximum performance. (No associative lookups!)". Why is this necessary? You end up passing the texture reference to .draw() as a sf::RenderState anyway, so you might as well let the user simply construct the texture themselves and just pass it on to SFML when the time comes. This also doesn't require any associative lookups.

Also, why do we need handles for layers? All layers are meant to do is specify an order in which the buckets of draw calls are actually dispatched. Simply storing a numerical value would suffice if you ask me.

The design of this sprite batch allows it to be quickly integrated in projects using `sf::Sprite` without any batching.

Whenever you bind a texture to the batch manager, you get an unique integer (starting from 0) identifying that texture.

Whenever you create a layer in the batch manager, the layer automatically creates contiguous data structures (`std::vector` instances, for now) for every bound texture.

When you want to draw a Batch::Sprite on a specific layer, having the sprite know the ID of the texture it has and the ID of the layer it needs to be drawn onto results in some contiguous memory direct access lookups and 4 `sf::Vertex` emplacements.

The user can simply store a Batch::Sprite instance in its game entity class (or replace `sf::Sprite` instances), and can fire-and-forget multiple Batch::Sprite draw calls - the batch manager, thanks to the unique IDs of textures and layers, will deal with minimizing draw calls.

The code for the sprite batch is here (still very primitive), but I hope it clarifies the idea:

When you call `Batch::Sprite::draw()` you're just asking the manager to "enqueue" the sprite in the right layer, in the right vertices container for its texture.

As stated above, I don't think they are even necessary. Just let the user use their own sf::Textures as usual and specify numerical values instead of layer handles.

The user manages the lifetime of their own `sf::Textures`. Binding them to the Batch::Manager is pure convenience - having an handle object that refers to that texture that can be used in Batch::Sprites allows the user to not having to specify the wanted texture during the draw call.

I'm trying to make the system as easy as possible to substitute to existing `sf::Sprite`-based code.

The idea behind layers is that the user does not care about the drawing order of sprites in the same layer - but that may not be realistic.
One thing I'm considering to add, is another layer type, where instead of having separate buffers for every texture, there is an unique buffer where vertices are sorted inside the same buffer by an user-specified Z-order.

If the user requires more fine-tuning with it's Z-order, that type of layer can be used, but it will definitely result in more draw calls.

Better batching.

In terms of OpenGL draw calls, yes, they do get reduced, but only in optimal scenarios. Since you don't re-order the sprites in order to minimize state changes, a user specifying their sprites in a really disadvantageous way will not benefit at all from your batching. In fact, it will even add additional overhead in that case.

Where your batcher does save time is within the sf::RenderTarget methods. When batching does work, less time is spent in there and potentially on the GPU since you pre-transform vertices (this leads to more optimistic paths being taken when the GPU realizes it doesn't have to do anything). However, in exchange for reducing the time spent in those locations, we need to consider the extra time that will be spent in your batcher. From your example, it seems like it will scale linearly with the number of sprites that you actually intend to draw with it since you seem to have to reconstruct the draw queue again every frame. I just don't see the advantage your class is supposed to provide over "manual batching" via sf::VertexArray.

Have you run any performance tests using your batcher? Where does it save time? On the GPU, in the driver or in the application?

The current state of the batcher is a start, but there is still much more to do in order to be useful in real world scenarios if you ask me. When writing my own batchers (similar to how I designed the SFGUI renderers) I like to measure the amount of draw calls that are actually issued to OpenGL in total every frame. I estimate that for a typical 2D SFML application that doesn't make too much use of shaders, it can easily be dropped below 10 in total per frame. This of course requires more advanced techniques such as texture atlasing, but that is what a batcher is there for...

Having only minimally used OpenGL without SFML, I do not really have a lot of experience/knowledge on the subject. Maybe I'm approaching this in the wrong way...

You're correct when you say that "it will scale linearly with the number of sprites". I am re-creating the draw queue every frame.

But I was under the impression that calling `sf::Sprite::draw()` does actually execute an OpenGL draw call.

Drawing 10000 `sf::Sprite` instances with the same texture would result in 10000 OpenGL draw calls.
Drawing 10000 `Batch::Sprite` instances with the same texture would result in a single OpenGL draw call.

The advantage of my system, over `sf::VertexArray`, is pure convenience - binding textures and layers to the manager, and having `Batch::Sprite` instances store their texture ID and layer ID, allows the user to "think in terms of `sf::Sprite`" and still get some performance benefits from automatic batching.

Pages: [1] 2 3 ... 13