SFML News – Week 30-31 (2013)

Whenever I collect topics for forum post, you can be sure, that I’m missing one or the other by accident. If I notice it, I’ll make sure to include it in the next news.


Mega Man

Are you a fan of Mega Man? Then you should already know of this awesome project, otherwise what are you doing? Go check it out! ZackTheHuman is putting quite an effort into it and personally I think it totally pays off. Unfortunately I haven’t gotten around to build it, so I haven’t played it myself. It’s definitely worth keeping an eye on that project.

Continue Reading “SFML News – Week 30-31 (2013)”

SFML Game Development – A book on SFML

I should’ve posted about this long time ago, but better late than never.

A few month ago the publisher Packt Publishing contacted Laurent, the creator of SFML, and at the same time Groogy, a relatively active member of the community who also wrote the SFML Ruby binding. Packt seems to have noticed the potential of SFML and the lack of books and thus wanted to get a book out. Since Laurent is a very busy man, he asked the community if someone wanted to write a book. After a bit brainstorming and people checking their schedule a small team was formed and the work began.

Now after eight month the book, written by the SFML community members Nexus, Grimshaw and Groogy and supported by Laurent himself, has been finally released and is for sale on Packt’s website with a few different options. Grimshaw has also created a forum thread, so feel free to leave some nice comments regarding the book there. I’ve bought the book myself, but haven’t been able to completely read through it. Once I’ve finished it completely, I’ll certainly be writing a review.

There have been some negative comments on the forum and also in IRC, thus I want to quickly clarify a few things. This book was written by a team, that means you’ll be able to find different wirting styles and things might seem a bit inconsitant from time to time. The authors of the book are all three non-native English speakers, so you should not be expecting a high-toned English, but instead prepare yourself for some grammar mistakes. As the title of the book suggests, the book is about SFML and Game Development, thus the focus is not on pure Game Development nor SFML. If you expect to learn every bit and pieces of how SFML works etc., then you should rather read the documentation and the source code. If however you think you’ll be able to develop you’re dream 3D RPGMMO which is of course better than WoW and alike, then you’re clearly in the wrong, because the book only gives an introduction to game development in the 2D space with focus on highlighting parts of SFML. At the end of the book, you’ll have a game to play with, but since a lot of the stuff was handed to you, it may seem easier that it actually is developing a game from scratch. And one last comment regarding the publisher, although given that Packt gave a few members the opportunity to write a book about SFML, they seem to be lacking a bit on their editorial part. From a good publisher you’d expect them to proofread the book in details and be able to fix many of the English grammar issues, which they apparently Packt hasn’t spent too much time on.

Overall this book was never meant as the perfect book about SFML, but rather as just another book on game development and yet the first one using SFML. With that in mind you should get disappointed if your mind isn’t completely blown and you find some mistakes, but instead you should be happy that SFML has finally gotten an official book!

SFML News – Week …-29 (2013)

Although I’ve once wanted to make weekly updates on SFML News, the amount of content go more and more, while my time got less and less, thus I eventually stopped. Since there have been many new posts on various projects in the last few days, I decided to make another quick update and present some text and images and because there is so much nice stuff, I’m not going to limit myself on a fixed date in the past. Unfortunately I can’t write about every single project, otherwise this blog post would never end!


Academic project: Simulation of Scorpion & Mice

This project was presented on the forum for the first time on the 7th if July, it’s an academic project from the Swiss university EPFL and created by the Mac OS X guy behind SFML, namely Marco Antognini aka Hiura. Now the aim of the project was to simulate full life cycles of mice as the prey and scorpions as the predators. The hard part of the project seem to be lying with programming the neural network, rather than getting something displayed with SFML, but in any case it’s quite nice to see SFML being used in notable universities and projects. With this project the use SFML wasn’t just temporarily and won’t stop now, but Hiura says that they’ll be using their SFML based setup in the future, so the next class might be actually learning SFML!

Postmortem – One must die

Postmortem has been first shown over a month on the SFML forum, but it went into Closed Beta just recently and now even tries to get the green light on Greenlight – although I’m still wondering how they’re going to get a free game on Steam…
Here’s a quick description from their website:

Postmortem is a FREE Indie narrative-exploratory game that will stress your moral compass this August 15th! Think The Walking Dead meets Home and The Last Express, with a dash of To The Moon – a perfect mix of exploration, conversation, meaningful choices, discovering clues and some puzzles.
You are an agent of Death sent to take ONE life from a cast of influential and ambitious characters at a charity Gala, in a rich and complex setting of industrial-revolution, conflict-torn country.

They are of course running their own website and a nice dev blog. It’s nice to see, that they’ve already gotten an article on US Gamer. Personally I think it’s an intriguing idea and definitely worth checking out!

Colonies – A Retro Sandbox Survival MMO

Not a new game presentation either, but they’ve now gone into Closed Alpha phase and since it looks really well polish, I just had to include it here. As the title suggest this is going to be a sandbox game with RPG elements and it should be an MMO or at least O(nline) as well. You should be able to settle, create a village, and defend your friends from the horrible creatures who lurk in the forests. You can change the landscape, farm, or hunt in order to survive the conditions, etc. Whenever the word “MMO” drops people get suspicions, since it’s hard to get done right and needs a lot of skill and time, but feel free to follow Jungletoe’s dev blog and don’t forget to stop by their own community.

Basis: Bone and Sprite Integration System

Some of you might have noticed the Spine project from a few month back, which also has support for SFML and I’ve even helped on Kickstarter. While Spine costs you some money Basis doesn’t cost you anything. Both mentioned applications are for 2D animations of skeletal and sprite creation. Although the tool is free the development still needs to be financed, thus they’ve started a Kickstarter project as well and they could really use some help! A download can also be found on the Kickstarter page.

Council of Torment – 2D dungeon crawler with a rich storyline

Although Council of Torment is still in rather early development it still deserves its place here.

Council of Torment is a top-down 2D dungeon crawler inspired by Ultima IV, with a very rich storyline, gameplay elements that’s been under development for 10 months.

From the description on the forum it seems that a big portion of the development will also go into the story. There’s not much more to talk about for now, but it’s certainly a project to keep an eye on.

Rock, paper, scissor.

I think, I don’t have to explain how this game works or I at least hope everyone knows “Rock, Paper, Scissor”! Although there still seems to be some animation issue, it works fine and can be interesting to try and figure out, if it’s based on some pattern or simply randomly generated. Not only can you download the game itself, but if you want, you can also look at its source code.

Metanact – Filesystem spaceshooter

While nobody has ever heard of Schnommus aka Seb, he seems to have been reading the forum for quite a while now. Judging from his progress on Metanact so far, he also seems to know quite a bit on programming. Metanact’s goal is to explore and conquer your own computer’s file system in a 2D environment. So while playing, the game will go through your file system and pick out various file names and represent them as enemy. While this game reminds me of other “file system” games, which would actually delete the files you’re shooting (e.g. Lose/Lose), Metanact is not such a game. It does not do any harm to your file system. You can find out more about Metanact on their website or even help Seb getting a bit more money together for some more nice content on indiegogo.

2D Platformer using SFML and Box2D

It always amazes me how some is able to create such a rather nice game as their first project. I still haven’t managed to get my own little platformer running (most because I end up doing unnecessary stuff) and others just go ahead and get it done in their first project. Though it seems, he’s using the Public Domain tile-set, I’ve found yesterday as well – visuals are something that can blur the actual vision between good and bad.


One of my favorite game in the current list is GoPlanets. The idea is rather simple but much fun! You’re red and can send out a certain amount of ships to other planets to take them over. The numbers on the planets display how many ships you can send and based on this number a given percentage will be taken away when sending out ships. The number increase over time automatically, so the longer you wait, the more ships you get, but keep in mind that the computer will try to win everything in the meantime as well. Although the current AI isn’t really challenging it’s still very fun to play. I really hope to see some further development on this project!

Project Blastorium: a Bomberman-esque game

I don’t think anyone will really remember my attempts on a bomberman clone for one of the SCC. I got some result, but it was very messy and I think I’ve never got it really finished after I’ve missed the deadline. Project Blastorium on the other hand is very well polished and introduces some different weapons to the playground, which seems rather interesting. You can follow the progress on the game on the dev blog or just in the forum.

Black and White and Colors

Molyjam 2013 a game jam, where you have 48h to start from scratch to the finished product. They seem to have been three people involved in this project and their final product after only 48h is just mind blowing. It’s simple, but very well polished and the game idea is very good. It would be totally awesome, if they’d go and add some more content, i.e. new levels, since you’ll get to the last level in just a few minutes. You can get the Windows binary from the Molyjam site or read some more information on the forum.


SFML Game Jam

This discussion just popped up on the forum, thus it’s still very hot and it seems many people are tuning in on the idea – even Laurent would be excited to see something like this.
The goal would be to have a contest going for a specific amount of time (24/48/72h) to start and finish a game using SFML. How, when, where and why is what the discussion is all about, so don’t forget to give your own voice!

Clipboard and Open with Default Application feature for SFML

Originated form the GLFW 3 thread FRex went ahead and proposed the two features. The discussion is still open and if you really want this feature, you should definitely go and write there why you’d like to see this. Personally I think this could be nice, but since it should be relatively easy to implement on my own, it’s not something that should get on a high priority list.

Changes on SFML

There have been so many commits and issue discussions, that I’ve totally lost track. You can however always go and look at the commit history yourself!

New Nightly Builds

I finally got around to rewrite my build scripts again. But first let’s see what has happened in the past. As my notebook got stolen a few month back, I’ve lost the original scripts. Then I tried to write a “smarter” and more “modular” system, which ended up being just another mess after all and limiting me for the correct compilation of the Thor libraries. In between the last update and today, SFML has finally seen its long, very long, extremely long, awaited release, which also included an update to SFML’s website and the choice of the final logo. From now on I think many people will just stick to the official 2.0 release and wait for the next version, thus I didn’t feel obligated to keep the Nightly Builds update for every new commit and let it slide for a while. Till yesterday, when I decided to rewrite all the scripts and ended up doing so not only for SFML, but also for Thor, but since GCC 4.8 has been released in that timespan as well, I decided to switch out some compilers. In the past I’ve been quite happy with the rubenvb builds and I believe they are still very good, but I decided to switch to the MinGW Builds. On the search for GCC 4.8 MinGW versions, I’ve stumbled across nuwen.net, which is a project, where someone is keeping his development environment up-to-date with the public. Thus you get his own MinGW version, plus a few quite popular libraries pre-compiled. I believe this could be quite nice for people, that don’t feel like recompiling stuff every other week, which is why I’m supporting that project with my SFML builds. As a final note, I’m totally not a fan of the TDM builds, mainly because their default behavior regarding static linking goes against all the other GCC versions, but since it’s still the one compiler Code::Blocks ships with, I’ll keep it in the list for now.

Enjoy and as always, I’m very open for feedback!

SFML News – Week 12-13 (2013)


Updates on the Nightly Builds

My SFML Nightly Builds were quite a few commits behind last week, mainly because I wanted to keep the matching SFML version for Thor and thought I could get the automated building system to work with Thor. Unfortunately I didn’t manage to do so in time and thus I only update the latest version section and left the previous section with the older version. Now that GCC 4.8 got released this week, I’m thinking about providing binaries for yet another compiler, but I’m not sure which one I should use. What do you guys think?

Kroniax 5.2, Preview & Source Code

AlexAUT is not resting and keeps polishing his game Kronaix. We’re not at version 5.2, which brought a working Challenge Mode with online highscore and fixed different bugs. He also moved the updates to Indie DB and thus might get some more people to play Korniax.

I’ve posted the last weeks LP not only here, but also on the forum thread and AlexAUT asked me, if he could use my LP as a Preview. I gave him of course the permission, but also offered to create a ‘stand-alone’ preview, which he was even more excited about.

Besides the new official release and the preview, AlexAUT finally published the source to GitHub and with 5 pull requests, he already got some contributions from Haze, iostream and me. Haze made sure, that the source code will compile on Linux, iostream made a conforming Markdown ReadMe and I’ve mainly cleaned up the file naming and structure and added a CMake build system. Feel free to check it out and contribute to it.

Kroniax on GitHub

Open Hexagon’s Linux Port Released

Vee has been working hard on Open Hexagon last two week, but since he’s not that experienced with Linux, he has been deploying Open Hexagon for Windows only. Luckily he got flibitijibibo to continue his older ports. Thus releasing Open Hexagon 1.84 for Linux.

But with help from my side and even more from Aster’s side, Open Hexagon now uses CMake to build and thus is way easier to deploy on Windows and Linux and we might even see a Mac version, if anyone is willing to test it and compile it for Mac. With those new changes the time was right for version 1.9, which adds a new level pack and a few other changes and fixes, see the full ReadMe for more information.

Thor’s Particle System in Action

Tank has posted an example video on a small game he’s been working on, to get back at C++ again, after a longer time doing web development-only for the company he’s working for. It looks quite nice and demonstrates how easy it is to get a good effect with particles. If you’re looking for easy way to start with particle effects, you might want to checkout Thor, which of course offers many other handy things.

Mini Crown

kaB00M who has been or still is working on a Mana fan game called Seiken Densetsu, posted his newest creation Mini Crown. It seems to be based on Vanillaware’s Dragon’s Crown upcoming RPG/Beat’em up game and is available for Windows. The game is still work in progress, but it’s still nice to see that people are working on projects with SFML.

Platform – The simple platformer game

The author of yet another platformer called Platform is santiaboy. He has been on the forum only since the beginning of this year, but has now already released his first SFML game. The controls are quite fluid and from the technical part it seems well done, but one of course still notices that it’s a very rough version and needs some more polishing.

Personally I’m quite impressed how far he got his platformer, I always failed at the basic concepts or the collision detection, got frustrated and left my approaches to a simple platformer lying around on my hard disk.



Will SFML 2.0 ever see the daylight?

Believe it or not, but the people who’ve been with SFML for quite some time, are waiting on the release of SFML 2.0 already for around three years. I’ve started with a bit of SFML 1.6, but since the ATI bug wouldn’t let me properly execute my applications and since SFML 2.0 already came with a few more bug fixes I switched over rather quickly. The SFML 2.0 back then, wasn’t anything like the SFML 2.0 we have today. We were still using CamelCase for the functions and nobody had ever heard of sf::RenderTexture, sf::Vertex or a few other classes. The API was way more similar to SFML 1.6, what made the switch easier. The big graphics API change was introduce around 1.5 years ago, which was a good day and basically turned SFML into what it is today. The opinions of the community got split when changing the function names from CamelCase to camelCase. Some hated it, some loved it and others found it just ridiculous to even do such a change. Then nearly 1 year ago, we got a release candidate, which made everyone believe that a release would follow within the next few weeks, but as we all know, this hasn’t happened.
So getting back to the title question, will we ever see a SFML 2.0 release? The answer is yes and looking at the milestones on GitHub, we can only see a one open issue for 2.0, where Laurent stated that the tutorials are complete and only parts of the website need to get updated even gave, he even gave a rough ETA, “next month” – you better keep your word Laurent!

New SFML Logo

Unfortunately nobody has commented here on the blog about the last logos, but the discussion on the forum keeps constantly going. Haikarainen posted a new logo, implementing some suggestions by others. The font style looks really well, but personally I don’t see any reason to use an animal for a logo. The most interesting part is though, that Laurent has kind of pointed out the most fitting and we just might see a basic pentagon has SFML’s new logo. Obviously not everyone agrees and thus Nexus has introduce an idea with arrows and made an example. But one should also not forget the two contributions of jabza. Let me know in the comments what you think about the logos.

Changes on SFML

Unfortunately there have been no changes to SFML this week.

SFML News – Week 11 (2013)

Although I probably shouldn’t start again with something new and rather try to get more of those computer science articles ready, I still had this funny idea of releasing ‘news’ articles on what has been happening in the SFML community. I’ll try to release weekly articles, but I don’t promise anything and I don’t even know how much I’ll write for each article.



As promised by AlexAUT, Kroniax 0.4 got published last Sunday and it adds a complete redesign of the GUI and a few additional levels. Although he mentioned that it would take longer before the next version, he managed to get 0.51 (download page) out yesterday.

But who’s AlexAUT and what’s Kroniax? AlexAUT joined the SFML community in October last year and has been most likely busy ever since. Less than a month ago he released his probably first bigger game with SFML. It’s some kind of a side-scroller, where you have to maneuver a white triangle, representing a ship, through a maze of blocks. To make things more interesting the velocity of the triangle as well as the strength of gravity varies from level to level or can change within each level. Next to the described Arcade mode, the latest version 0.51 features now another mode called Speedchallenge, where you can change the velocity on your own, while you still have to beat the level. Since it is called ‘challenge’, AlexAUT added an online highscore, so you’ll get some aim to fight for.

Kroniax is extremely addictive and makes a lot of fun. Since I had so much fun with it, I’ve even made quick Let’s Play:

Open Hexagon

Legendary Vee has done it again and released not only one new version of Open Hexagon but five; starting with 1.8 and ending with 1.84 (download page). The most noticeable change are the online highscores. Everyone who’s playing with the official version in ‘official mode’, will automatically submit their scores to a server and get their current position and the top 8 places. But that’s not the only new thing; you now get a full menu for various options and a nice pseudo 3D effect. As always you can find the full changelog in Vee’s detailed ReadMe. The minor updates were mostly bug fixes, as well as security and performances updates.

I actually wanted to make another video on Open Hexagon, but my microphone on the headset died and I don’t have a replacement yet. The built-in mic of my notebook is not really useable for such things, but you can still checkout one of my older videos on Open Hexagon:

NEAT Visualizer

The NEAT Visualizer is a project, which visualizes an implementation of the Neuro-Evolution of Augmenting Topologies (short NEAT) algorithm. The NEAT algorithm evolves neuronal network structures and weights them simultaneously. Such a network is capable of learning some simple tasks, which the visualizer should make prettier for the eye. The used algorithm doesn’t have anything to do with SFML, since it’s a generic, but the visualization uses SFML underneath. Based on NEAT lolz123 has also written a small but fun game as Ludum Dare.

lolz123 released a new video and a new version of the NEAT visualizer this week. You can look at the video here:


New SFML Logo

Nearly two years ago Laurent opened the discussion on the forum for a new logo. Back then we already assumed SFML 2.0 would get released anytime now, but well we are still waiting, more on that in another post though. After the thread died out for a while it’s back again and every week we get a few new suggestions. The ones of this week were in my opinion quite strange and not very well suited as logo. On two of them it’s nearly impossible to see the letters ‘SFML’, especially if you don’t know already that they should be there. The other one is textured which is not useable at all for a logo. But maybe I’m not artsy enough to understand this, so I’ll let you make your own opinions:

Will SFML support OpenGL ES sooner than expected?

OpenGL ES is as specification for a platform and language independed 3D programming. It’s mainly aims embedded systems (thus the ES) such as Raspberry Pi or devices that run Android or iOS.
If SFML were to be ported over to OpenGL ES, it could potentially open the world to a whole new set of platforms and thus new games and applications with SMFL. In general Laurent wants to get SFML to OpenGL ES, but in the past this was not due for anytime soon. What could then change his mind? Well slotdev started a discussion on the forum about having a DirectX backend for SFML, which would involve even a bigger change to SFML, but luckily some guys have created ANGLE, which basically translate OpenGL to DirectX calls and thus enables one to write OpenGL applications for platforms which support only DirectX. The downside to this is though, that ANGLE implements an OpenGL ES specification. Since slotdev and a few more people are commercially working on games for casino machines, Laurent stated that he’d be looking into getting OpenGL ES support sooner than plant, if they require it anytime soon. The discussion was then moved to private chats and we’re kind of left in the dark what they decided on.

What do you guys think about elevating the priorities on OpenGL ES? Should Laurent tackle other more important issues first before rewriting huge junks of SFML’s code? Let me know what you think in the comments below.

Source code changes

Personally I feel like we got a much more involved community in the past few weeks, but I’m not sure whether this is just because I’m looking more closely at the commits and what’s going on, or if it’s really because more people are submitting pull requests and Laurent actually accepts them. It also kind of feels like, Laurent got a bit more open about contributions after the forum thread with the title: “More Commuity-driven Development”

  • We received a fix from one guy, who had problems with some events on Arch Linux with Awesome WM. – 560b741
  • As noticed by our great Nexus in a forum post, the explicit for the sf::Text constructor wasn’t needed anymore. – 5c46daa


I hope you’ve enjoyed reading my news post and actually got some news out of this. If you feel, that I’ve missed some parts or just got any kind of feedback, please leave a comment down below or contact me by means of PM, Mail, Twitter, IRC, etc. I’d really to hear some opinions.

Personal SFML Website Updated

A bit late, but better late than never: Happy New Year to everyone!

So the past few days I’ve been working on a new front- and back-end for my small personal website, targeted towards anything related to SFML. Active SFML developers and/or SFML forum readers might already know that I’ve been providing SFML Nightly Builds for a handful of compiler, up to now the downloads were provided through a small self written PHP file and linked in the static HTML download section. Now they’ve got a dedicated place and user-friendlier URLs.

Now let me talk a bit about the two frameworks, which currently power the new website. Both of them were fairly new to me and thus I had a lot to learn and read.

As for the front-end I used Twitter Bootstrap, the evermore popular collection of CSS and JavaScript assets, that give your site with a very simple HTML skeleton a somewhat standardized look and feel, which a many find quite intuitive and appealing to work with. The small SFML website wasn’t the first project with which I got myself introduced to Twitter Bootstrap, but it had recently refactored an older database-project, I had made for a friend of mine a few years back. The simplicity and powerfulness of the framework really surprised me and with the help of the online documentation working on a nice HTML site is a very easy task.

The decision for a proper back-end was a bit harder, since there are so many different ones and each of them provide again different features, which might sound genius, but can have a huge learning-curve, so you’d end up digging through tutorials and documentations for hours. The first framework I’ve had in mind was Symfony 2. It is a well-known and respected PHP framework and one can do any kind of web application with it. But because it’s so loosely coupled and generalized the learning curve is quite big. Although they provide some nice introduction tutorials, I’ve never gotten a good overview and never really understood how one would get to write a simple application with it.
In the search for something less clumsy and complex I went to Wikipedia’s web framework list and clicked me through one after the other, until I reached CodeIgniter. Looking at the short feature list on their website, I was immediately hooked and was pleasantly surprised as I switched to the documentation, which is structured cleanly and lets you choose on how deep you want to go, but builds up your knowledge about the basics step by step. Within a few minutes I had a running back-end with custom URL routing. The only problem I ran into was the correct mod_rewrite routing and I could only resolve it with some googling. So in case someone would by accident find my blog, here’s the correct routing I use to abstract the index.php away:

RewriteEngine on
RewriteBase /
RewriteCond $1 !^(index.php|img|css|js|robots.txt)
RewriteRule ^(.*)$ /index.php?/$1 [L,QSA]

That way one gets a nice URL like https://my-gate.net/about/ which will get redirected automatically to the index.php.

Anyways I’m quite happy with the combination of Twitter Bootstrap and CodeIgniter and will most certainly use them further for different projects. I’m here specially thinking about SFMLUploads, which has as back-end only a few very hackish PHP files and thus is constantly failing and very hard to maintain.

Do you have any experience with CodeIgniter, Boostrap or any other framework you want to drop a line in the comment section?

Using sf::View

I’ve been using SFML now for more than a year but I never really understood how sf::View really works, until now. So I feel like sharing this enlightenment and I’ll also create a tutorial in the wiki section on GitHub.

What can a sf::View do?

This question is not that complicated to answer and I would’ve already been able to do so a few weeks back but I never really understood how sf::View works. The answer would be a description, so here you go:

A sf::View is basically a 2D camera i.e. you can move freely in two dimensions, you can rotate the whole scene clockwise or counterclockwise and you can zoom in and out but there’s no tilting or panning. Furthermore zooming really means enlarging the existing picture rather than closing in on something. In short terms there’s no 3D interaction.



So if you now want to move a sprite around without altering its coordinates but instead moving the 2D camera, you could do this easily by calling:

view.move(360.f, 360.f);


Next you maybe want to get a closer look at something, so you can use:



Or you want to rotate everything:



Now you get the idea what the camera can do and you’d probably be even able to program something with it, but do you understand how it works? Do you know what the center of the sf::View is?

So let’s get a bit more technical.

How does sf::View work?

So lets see what the documentation of SFML says about this:

A view is composed of a source rectangle, which defines what part of the 2D scene is shown, and a target viewport, which defines where the contents of the source rectangle will be displayed on the render target (window or texture).

The viewport allows to map the scene to a custom part of the render target, and can be used for split-screen or for displaying a minimap, for example. If the source rectangle has not the same size as the viewport, its contents will be stretched to fit in.

If you’ve understood everything then congrats! I didn’t (at first) and although it’s a good, short and precise description it’s not very intuitive.

From the text above we can extract that there are two different rectangle defining the sf::View: a source and a viewport. What we also have, although not ‘physically’, is the render coordinate system, i.e. the coordinates you use to draw sprites etc.

At first I’ll explain how the source rectangle and the render coordinate system work together, then talk about the size and the constructor, furthermore show you how to use the viewport to create different layouts like a split-screen or a mini-map, as suggest in the description and at the end get a bit away from the direct manipulation of the sf::View and look at the convertCoords(…) function of a sf::RenderTarget.

At the bottom of the post you’ll find a ZIP file which holds a fully working example, demonstrating everything you’ll learn in this post.

The source rectangle

Since I don’t want to talk about the viewport yet but I’ll let it have its defaults value, which means that it will cover the whole window i.e. the whole scene will be rendered 1:1 onto the window.

In the example above I’ve already moved the view to the point, where I’m rendering the separate sprite of Link. Link’s position in pixel is (1056, 640) but to get him centered, respectively the top left corner of him, I can’t just use what might seem intuitively:

view.setCenter(1056, 640);

(Of course you can set the view center to (0, 0) and then move to to (1056, 640) but we’re trying to understand what the center of the view is.)

Since I’m assuming that you’ve already some knowledge with SFML, I’ll also assume that you know SFML is using a Cartesian coordinate system with a flipped Y axis. So the point (0, 0) can normally be found in the top left corner and then maximum x and y value can be found in the bottom right corner. If you’re working with images you’ll soon get comfortable with this system.

But now comes the center of view, which is in fact defined from the middle point of the display area. The view uses a Cartesian coordinate system too but this time the X axis gets flipped. In the end we have the point (0, 0) (also known as origin) in middle of the view, the maximum x and y values are in the top left corner and the minimal and negative x and y values are in the bottom right corner. What you’re now actually can set with setCenter is the where origin of the rendering coordinate system is put in the coordinate system of the view. I hope the following images will clarify the situation a bit.

The black square should represent the window and since we set the viewport to a fixed value the origin of the sf::View coordinate system will always be in the middle of the window. Here are the two separated coordinate systems:



If we combine them we get for example something like:


Then we have our two operations rotate() and zoom(). The last picture combines the two transformation:




I think it’s nearly impossible to explain this even better.

Note that in the images above, I’ve moved the rendering coordinate system around to get a few different variations. I guess most of the time it’s better to use the move() function since you won’t need to deal with where to place the origin point. On the other hand you really need to understand how sf::View works to use rotate() and zoom() because it’s not obvious that those transformation will happen around the sf::View origin i.e. the middle of the view.

You should keep in mind the introduced concept doesn’t just hold for a window it’ll work with any render target including sf::RenderTexture.

The size and the constructor

Before we take a closer look at the viewport we need to understand what the size of the view is and which parameters the constructor takes.

For now we’ve used the same size for the view as for the render target, this gives us a 1:1 projection. But what if we’d divide the size of both sides by two? From the observer perspective such a change would equal to using view.zoom(0.5f) but from the programmer perspective it’s something completely different. As we’ll learn in the next paragraph we can use the viewport to map the rendering stuff to a certain area on the window. Now if’ we’d apply the scene with the same size as before everything would get shrinked and eventually stretched if the ratio of the side isn’t the same anymore. This can create some wanted effects but mostly it would defeat the purpose. With setting a specific size, we’re telling the sf::View how big the view should get drawn while not making any visible transformations on the rendering part.

With that in mind it’s now easy to understand how to use the constructor.

sf::View view(origin.x, origin.y, size.width, size.height);

Where origin relates to a 2D vector of the origin in the rendering coordinate system and size relates to the sf::View size as discussed above.

The viewport rectangle

After we’ve seen most of the things sf::View can do, we want to generalize this even further. For now we’ve assumed we were using a window and rendered 1:1 onto it’s surface, but what if we wanted to display my stuff only on the lower right corner or use only the half left side? That’s where the viewport comes in.

The default values are sf::FloatRect(0, 0, 1, 1) which means the view covers 100% of the render target. So we got another rectangle which holds percentage values of the size of the render target. The first two values describe the position of the upper left corner and the last two values the lower right corner.

If you want to split the screen you’d need two different views for the left and the right side. Before you then draw to one side you’ll have to change the view on the render target first. To draw something to the other side, just set the second view and you’re good to go. This could look like this:

sf::View viewLeft(sf::FloatRect(0, 0, window.getSize().x/2, window.getSize().y));
viewLeft.setViewport(sf::FloatRect(0, 0, 0.5, 1));
sf::View viewRight(sf::FloatRect(0, 0, window.getSize().x/2, window.getSize().y));
viewRight.setViewport(sf::FloatRect(0.5, 0, 0.5, 1));
// ...

With all the knowledge provided above you should now have a good understanding of why we divide the window width by two or why viewRight is defined with 0.5 as first argument.


Another example I promised to show is how to create a mini-map i.e. a scaled down overview of the whole map. In practice it’s often better to construct it’s own mini-map rather than just scaling down the original one, since the quality can get fairly poor. But let us first test how it will really look like.

If you’re working with more dynamic data you’d probably need to render everything to a sf::RenderTexture and then extract the texture and render it twice. In this example we ignore those facts and just assume we’ve got a sprite with the Zelda map texture thus we can reduce the code to a few lines.

sf::View standard = window.getView();
unsigned int size = 100;
sf::View minimap(sf::FloatRect(standard.getCenter().x, standard.getCenter().y, size, window.getSize().y*size/window.getSize().x));
minimap.setViewport(sf::FloatRect(1.f-(1.f*minimap.getSize().x)/window.getSize().x-0.02f, 1.f-(1.f*minimap.getSize().y)/window.getSize().y-0.02f, (1.f*minimap.getSize().x)/window.getSize().x, (1.f*minimap.getSize().y)/window.getSize().y));
// ...


The convertCoords(…) function

As we’ve seen in the paragraph with the source rectangle it’s not very intuitive to work with those two coordinate system. It’s also pretty hard to determine by hand at which position for instance your mouse cursor is located relative to the view underneath. But why would you want to do this by hand, since SFML has already a build in function that will do the heavy lifting for you, namely convertCoords(…)?

There are two ways to use this function:

  1. Determine the relative position on the render target of the point P to the current view of the render target.
  2. Determine the relative position on the render target of the point P to a specified view.

This function can be very useful, e.g. you’ve moved around your view and now the user click on a point on the window. Just call convertCoords(…) and you’ll instantly know where on the moved view he clicked.

Complete demonstration

I’ve created a small application which packs up every introduced concept. The code isn’t the prettiest but contains a lot of more or less useful comments. I also provide a package that contains just the images presented in this blog post and since maybe some people want both, I’ve created one that contains everything.

If you have any questions/suggestions or found any mistakes/bugs/errors just let me know in the comment section!

Tutorial: How to change your cursor?


I’ve just published my first tutorial with SFML, okay it’s actually not fully my tutorial since I’ve partially rewritten one from the old section, but expanded it with in my opinion a better solution.
Although you can find the tutorial on the wiki site of SFML, I post it here again.

How to change your cursor?

The cursor is something every computer user is familiar with and in fact is constantly staring at, yet many people don’t even realize anymore that it’s there and changes its shape every so often. Next to the functionality like pointing and clicking the cursor can show many different states and indicate possible actions. For example you’ll get a selection cursor when hovering over a text or a hand shaped cursor could indicate a link etc.

Since SFML is not a framework nor a GUI system providing a native function for changing the mouse cursor doesn’t fit its purpose. Here’s where this tutorial comes in. If you’re making an application or game, you might want to be able to display a different cursor. There are two ways to change your cursor:

  1. You can hide the default cursor and draw a sprite where the cursor should be
  2. You can ask your OS to do it for you. (Windows & Linux)

This tutorial will cover both methods.

What do you need?

You’ll need SFML, an editor and a compiler (obviously these links are only suggestions).
Since I won’t go into details regarding C++ or SFML, the tutorial requires you to have some basic knowledge on both topics.

Hide and Draw

This task is fairly simple, it consists out of three required and one optional tasks:

  1. Use sf::RenderWindow::setMouseCursorVisible(bool) to hide the cursor.
  2. Set the position of the sprite to the position of the mouse.
  3. (optional) Adjust the view to get the correct render position.
  4. Draw the sprite to the screen.

Since it’s so simple there’s not more to talk about and an example shows a possible implementation:

#include <SFML/Graphics.hpp>

int main() {
     sf::RenderWindow window(sf::VideoMode(800, 600), "Hidden Cursor");
     window.setMouseCursorVisible(false); // Hide cursor
     sf::View fixed = window.getView(); // Create a fixed view
     // Load image and create sprite
     sf::Texture texture;
     sf::Sprite sprite(texture);

         sf::Event event;
             if(event.type == sf::Event::Closed)
         sprite.setPosition(static_cast<sf::Vector2f>(sf::Mouse::getPosition(window))); // Set position
     return EXIT_SUCCESS;

Ask your Operation System (OS)

Update: SFML 2.5 introduced support for system cursor, as such it’s recommended to use that instead of the following code.

What are the advantages of using this method over the other?

  • The OS will not duplicate the cursor in memory, because it is a shared resource.
  • The OS will use a cursor that the user is used to. For example on windows 7 the user is not used to having an hour glass, but is familiar with some sort of an animated circle.

Class Prototype

Since we have to store the cursor differently for the Linux as for the Windows platform, we’ve introduced an preprocessor switch for the include files and the private class members.

#include <SFML/System.hpp>
#include <SFML/Window.hpp>
    #include <windows.h>
#elif defined(SFML_SYSTEM_LINUX)
    #include <X11/cursorfont.h>
    #include <X11/Xlib.h>
    #error This OS is not yet supported by the cursor library.

namespace sf {
    class StandardCursor
        HCURSOR Cursor; /*Type of the Cursor with Windows*/
        XID Cursor;
        Display* display;
        enum TYPE{ WAIT, TEXT, NORMAL, HAND /*,...*/ };

        StandardCursor(const TYPE t);
        void set(const sf::WindowHandle&amp; aWindowHandle) const;


Class Implementation

Instead of ‘breaking’ the scope with preprocessor statements we’ll define every function twice with a switch for each platform.

#include "StandardCursor.hpp"


sf::StandardCursor::StandardCursor(const sf::StandardCursor::TYPE t)
        case sf::StandardCursor::WAIT :
            Cursor = LoadCursor(NULL, IDC_WAIT);
        case sf::StandardCursor::HAND :
            Cursor = LoadCursor(NULL, IDC_HAND);
        case sf::StandardCursor::NORMAL :
            Cursor = LoadCursor(NULL, IDC_ARROW);
        case sf::StandardCursor::TEXT :
            Cursor = LoadCursor(NULL, IDC_IBEAM);
        //For more cursor options on Windows go here: http://msdn.microsoft.com/en-us/library/ms648391%28v=vs.85%29.aspx

void sf::StandardCursor::set(const sf::WindowHandle&amp; aWindowHandle) const
	SetClassLongPtr(aWindowHandle, GCLP_HCURSOR, reinterpret_cast<LONG_PTR>(Cursor));

	// Nothing to do for destructor : no memory has been allocated (shared ressource principle)

#elif defined(SFML_SYSTEM_LINUX)

sf::StandardCursor::StandardCursor(const sf::StandardCursor::TYPE t)
    display = XOpenDisplay(NULL);

        case sf::StandardCursor::WAIT:
            Cursor = XCreateFontCursor(display, XC_watch);
        case sf::StandardCursor::HAND:
            Cursor = XCreateFontCursor(display, XC_hand1);
        case sf::StandardCursor::NORMAL:
            Cursor = XCreateFontCursor(display, XC_left_ptr);
        case sf::StandardCursor::TEXT:
            Cursor = XCreateFontCursor(display, XC_xterm);
        // For more cursor options on Linux go here: http://www.tronche.com/gui/x/xlib/appendix/b/

void sf::StandardCursor::set(const sf::WindowHandle&amp; aWindowHandle) const
    XDefineCursor(display, aWindowHandle, Cursor);

    XFreeCursor(display, Cursor);
    delete display;
    display = NULL;

    #error This OS is not yet supported by the cursor library.

Cursor Demonstration

This section presents a fully functional demonstration of both cursor changing possibilities.

To get an handle to the window we will use SFML’s sf::Window::getSystemHandle() function and then we will load the cursor with the OS specific implementation.

#include <iostream>
#include <SFML/Graphics.hpp>
#include "StandardCursor.hpp"

int main()
	int choice = 0;
	while(choice != 1 &amp;&amp; choice != 2)
		std::cout << "t1. Hide the cursor and draw your own." << std::endl;
		std::cout << "t2. Let the OS handle the cursor." << std::endl;
		std::cout << "Choose your cursor behaviour: ";
		std::cin >> choice;

    sf::RenderWindow window(sf::VideoMode(800, 600), "Cursor Demonstration");

	if(choice == 2)
		sf::StandardCursor Cursor(sf::StandardCursor::HAND);

	sf::View fixed = window.getView();
	sf::Texture texture;
		return EXIT_FAILURE;
	sf::Sprite sprite(texture);

		sf::Event event;
			if(event.type == sf::Event::Closed)


		if(choice == 1)

    return EXIT_SUCCESS;

A *.zip file containing both, the code for StandardCursor class and the demonstration and an cursor image, can be obtained through this link: cursor.zip (2.9 KB)

TileMapCreator – Update 01

As promised here comes a small update on the TileMapCreator; screenshot first:


So this must seem disappointing, nothing really changed, except maybe the gray square on the grid. But then again I’ll have to remind you that TMC is far from being useable and the biggest changes will happen in the codebase which then again don’t necessarily need to be visually present in the application. What did then change?

In the old version I just had one class Grid which handled all the selecting and highlighting decisions next to the rendering part. This ‘method’ got quickly out of hand and there was no useable way to keep track of every cell and its states. But if one ‘object’ has different states why would I want to try really hard to synchronize different vectors? Why not just use another class? So I introduced the new class Cell for which exist just one header file. One cell keeps track of the states highlighted, selected, changed and filled. Additionally if also hold a shared_ptr to the texture or nullptr if the cell doesn’t hold a tile.

For the grid rendering I also thought about for quite a bit, actually it was the first part I changed, and I’ve chosen the following render steps.

for each cell
  if the cell has changed
   draw the blank sprite to clear the cell
   if the cell is filled
    draw tile
   if the cell is selected
    draw selector
   if the cell is highlighted
    draw highlighter
   draw the grid overlay
 if one cell has changed
  update the grid texture

This assumes an iteration over all cells doesn’t cost much time. Also I always clear the cell because it’s possible that the tile as some transparent pixels, rendering it on old content would produce a wrong image. This seems to work quite well.

Another approach I could think of would be using multiple render textures for different layers and then combine them at the end. But I don’t really see how it would make a difference in performance and it would probably only increase the GPU memory usage.

As you can see in the screenshot the highlighting already works (again). When ever your mouse cursor hovers over a cell it will get highlighted once and when you leave it, it will get ‘unhighlighted’ and the next cell will get highlighted.

Next up will be selection. For that I’ll have to store the selected cells in a vector or a similar data structure, to tell the grid which should be shown as selected and later to tell the events like delete or place where to work their magic.