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 - SuperV1234

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


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! ❤️

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:

General discussions / Simple SpriteBatch desired interface/features
« on: June 03, 2015, 03:48:22 pm »
I'm working on a simple SpriteBatch class with the goal of automatically reducing the number of draw calls.

It currently supports layering and texture binding.
The interface looks like this, so far:

// ...load some textures and store them somewhere,
// then create some const references to them.
const auto& txApple(someAssetManager.get(...));
const auto& txBanana(someAssetManager.get(...));
const auto& txOrange(someAssetManager.get(...));
const auto& txSky(someAssetManager.get(...));

// Create a batch sprite manager.
// This would ideally go in your `Game` class or
// in your rendering system instance.
Batch::Manager bm;

// Bind the textures to the batch manager.
// Textures must be bound in advance for maximum
// performance. (No associative lookups!)
// Binding returns an handle-like object.
auto bthApple(bm.bind(txApple));
auto bthBanana(bm.bind(txBanana));
auto bthOrange(bm.bind(txOrange));
auto bthSky(bm.bind(txOrange));

// Create some layers to manage Z-ordering.
// Layer creation returns handle-like objects.
auto btlBackground(bm.createLayer(0));
auto btlForeground(bm.createLayer(1));

// To draw stuff, use `Batch::Sprite` instances.
// They have a similar interface to `sf::Sprite`,
// but require a layer handle and a texture handle.
std::vector<Batch::Sprite> sprites;

for(auto i(0u); i < 10000; ++i)
    // Make 10000 apple sprites.
    sprites.emplace_back(btlForeground, txApple);

    // Make 10000 banana sprites.
    sprites.emplace_back(btlForeground, txBanana);

    // Make 10000 orange sprites.
    sprites.emplace_back(btlForeground, txOrange);

// Make 1 sky sprite, in the background layer.
sprites.emplace_back(btlBackground, txSky);

// In the game loop, you need to clear, fill and
// render the batch manager.
    // ...stuff...

    for(const auto& s : sprites) bm.enqueue(s);

    // ...stuff...

// The `bm.drawOn(someRenderTarget);` call
// will result in 4 draw calls, implemented with
// 4 different vertices arrays.

  • Could the API/interface be improved?
  • Is layering sufficient for Z-ordering needs?
  • Is the ownership model of textures/layers fine?
  • What other features would you expect from a sprite batch?

Hello SFML community,
my name is Vittorio Romeo and I'm a Computer Science student.

This year I've attended CppCon2014 and gave a talk about game development (almost) from scratch using the newest C++ standards (C++11 and C++14) and SFML.

The goals of the talk are showing how easy it is to use modern C++ to create a game and encouraging everyone to try game development.

I hope you'll find it interesting!


I'm always open to feedback :)

Feature requests / sf::Text::setTracking(int)
« on: October 02, 2014, 03:43:44 pm »
It would be really helpful if we could specify a `tracking` int value in `sf::Text`.
All glyphs would be moved apart from each other by `tracking`.

Hello SFML community!

I've created a 40 minutes tutorial/screencast on the creation of a complete game using C++11 and SFML2.
The end result is a playable Arkanoid/Breakout clone with a paddle, a ball and destroyable bricks.

This is my first attempt at a complete C++11 game development tutorial.
I divided the code in 9 segments, that I analyze and execute individually.

The video is aimed at people with at least a basic knowledge of C++.
Having some knowledge about common game development concepts will also greatly help.

The point of the video is showing how easy it is to create something playable thanks to the new standard and thanks to SFML, and to show a possible train of thought that can be taken during game development.


I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Also, feel free to fork the game's source code at:
and expand upon it: I will feature the best forks in a future video :)

For other tutorials: http://vittorioromeo.info/tutorials.html - or just browse my YT channel.

Thanks for watching!

SFML projects / operation bloodshed - (WIP)
« on: September 26, 2013, 03:46:39 pm »

operation bloodshed

GitHub: https://github.com/SuperV1234/SSVBloodshed
Main devlog: http://forums.tigsource.com/index.php?topic=36131.0

This is my attempt at the creation of a spiritual successor to Operation Carnage, one of my favorite childhood games.
Operation Carnage is a 1996 abandonware arcade game with a very simple but addicting and fun gameplay. It has a very interesting shooting/strafing mechanic that is easy to learn but hard to master.
Unfortunately, it also has some design flaws that I'll try to solve in my game.

I'll attempt creating this game for various reasons:
1) I feel that Operation Carnage has never got the attention it deserved. Even if it's not a very innovative game, it's certainly a very fun 90's arcade experience, that has some interesting ideas which can be improved.
2) A `clone` of the game, Hyper Princess Pitch, was created by Daniel Remar. It is awesome and you should play it, but, in my opinion, it doesn't solve the design issues the original game had.
3) I haven't done much work since LD27 and I want a project to work on.

My language of choice is C++11.
I'll use QTCreator and Sublime Text as my coding tools.
PyxelEdit will be used for graphics.
I will use my own framework, the SSV Framework, and SFML2.1.
As my previous projects, the end result will be free, open-source and cross-platform.

Devlog (audio-commented) videos:
Code: [Select]
devlog #16 - http://www.youtube.com/watch?v=JG960pauKVs
(GUI, force fields, bullet boosters)

devlog #15 - http://www.youtube.com/watch?v=RHwQIXKO1n4
(on-off pressure plates, explosives, new elements/tweaks)

devlog #14 - http://www.youtube.com/watch?v=1iPkM9olna0
(new elements, multi-level sectors)

devlog #13 - http://www.youtube.com/watch?v=pIcEywsZ5eE
(many new elements)

devlog #12 - http://www.youtube.com/watch?v=hV5kkPBYfXI
(fully working level editor)

devlog #11 - http://www.youtube.com/watch?v=43gyuU-FdCY
(particle blendmodes, ai changes, wip editor)

devlog #10 - http://www.youtube.com/watch?v=blq33UhomBE
(wall autotiling, charge particles, raycasting, new gfx)

devlog #9 - http://www.youtube.com/watch?v=8GT8zbgt0ow
(turrets, new enemies, bar hp counter)

devlog #8 - http://www.youtube.com/watch?v=Za2w-nNwe0g
(all enemies can now have weapons)

devlog #7 - http://www.youtube.com/watch?v=5JmZmp_x5Uc
(major progress: ai, gfx, etc...)

devlog #6 - http://www.youtube.com/watch?v=_y_xcvS_aIk
(possible enemy types demonstration)

devlog #5 - http://www.youtube.com/watch?v=wkPzUk5oSMA
(testing enemies that shoot)

devlog #4 - http://www.youtube.com/watch?v=mcRPckkV1XM
(test particles redux)

devlog #3 - http://www.youtube.com/watch?v=KW-cqoaXmVk
(test particles)

devlog #2 - http://www.youtube.com/watch?v=DaIqr5thCQ0
(shooting test, enemy test)

devlog #1 - http://www.youtube.com/watch?v=0KVp2j5hbxI
(new possible project)

SFML projects / What are you working on?
« on: September 21, 2013, 01:38:14 pm »
Pretty much every community has a "What are you working on?" topic, so why not SFML?
Pictures, animated gifs, videos, information and code are greatly appreciated!

I'll start...

Devlog at: http://forums.tigsource.com/index.php?topic=36131.0

I think the gif link died, here's a video: http://www.youtube.com/watch?v=mcRPckkV1XM

SFML projects / [LD 27] 10corp
« on: August 26, 2013, 02:59:24 am »
a frustrating reflex-based puzzle platformer

This was made for my first Ludum Dare competition.

The game is written in C++11, using only SFML2.1 and JsonCpp as external dependencies.
It is written using my personal SSV framework, written from scratch, which is free, open-source and available on GitHub.

I couldn't manage to polish the game as much as I wanted to. There only are 7 playable levels, no gfx options, no key rebinding, et cetera.

Still, being my first Ludum Dare, it was a very interesting and learning experience and I'm glad (and surprised) I managed to create something (in my opinion) worth playing that could become a fun little game with additional polish.

Hope you enjoy my entry.

Ludum Dare entry page
Win32 download
Linux download

Gameplay video 1
Gameplay video 2



Linux users: native build is available, built on Ubuntu 12.04. Also, the Windows version works flawlessly on Wine.


`ARROW KEYS`: move around
`X`: jump
`Z`: hold/release to grab/drop blocks
'R': restart current level
`ESCAPE`: go back to menu
`W/S/A/D`: pan camera
`Q/E`: zoom camera in/out

How to play:
Bring all the crates to the receivers to enable the teleporter. Walk on the teleporter to finish the level.
Numbered crates can only be received by numbered receivers.
Non-numbered crates can only be received by non-numbered receivers.
Non-numbered receivers can receive any kind of crate.
Grab the crates by keeping 'Z' pressed. Quickly turn and release `Z` to throw the crate. Jump right before releasing `Z` to give altitude to your throw.
Stack crates to reach high places.
When the first crate is grabbed, you have 10 seconds to bring any crate to a receiver, or you will be terminated.
When a crate is received, the 10 seconds timer is reset.
After all crates have been received, the timer stops and you can safely walk to the teleporter.


Tools used:
`sfxr`, `Pinta`, `Gimp`, `LMMS`, `QT Creator`, `Sublime Text 3`





Level 6 is hard, but not impossible
Level 5, though, has a coding error (forgot a receiver at the bottom).
I assure you level 5 is possible though, even if INSANELY HARD.
I've come close to beating it a few times but failed. If you manage to beat it, big kudos to you!

Network / Correctly sending post requests to PHP
« on: March 09, 2013, 06:13:46 pm »
I'm using SFML Network to access my web server and send it high scores. The high scores are recieved by a PHP script that stores them on a JSON file:

    $name = $_POST["n"];
    $validator = $_POST["v"];
    $score = $_POST["s"];

I'm currently sending a POST request from C++ like this:

    Http http; http.setHost("http://mywebsite.com");
    Request request("script.php", Http::Request::Post);
    request.setBody("n=" + mName + "&v=" + mValidator + "&s=" + toStr(mScore));

This works, but has the same limitations as a GET request - especially character limit. Since I need to validate the high scores for custom levels made in LUA, I wanted to pass the whole LUA file (stripped of symbols and whitespace) as mValidator. But it doesn't work with 1000 characters. Small strings work properly.

I've been told that character limit is only present in GET requests, and that I'm calling the POST request in the wrong way.

How can I call the POST request correctly and avoid the character limit without compressing my parameters?

Audio / "SoundBuffer* s = new SoundBuffer;" freezes the application
« on: January 11, 2013, 09:53:42 pm »
class TestClass {
TestClass() {
SoundBuffer* s = new SoundBuffer;


namespace GlobalScope {
TestClass t;

Having a heap SoundBuffer creation in global scope freezes my application.
By debugging via GDB, the program freezes here:

audioDevice = alcOpenDevice(NULL);

in the file AudioDevice.cpp


Is this normal? Does OpenAL have to init or something to allow me to declare SoundBuffer* in global scope?

Pages: [1] 2 3