Last night I spend multiple hours trying to get a non-broken CSFML build ready, which requires to have import libraries for MSVC and GCC that both depend on the same DLL. This works because the import library only points to the symbols that are in the DLL, thus acts as sort of instruction how to use the DLL.
Those newer to programming in C++ often fail to understand that compilers like GCC or Clang require a specific link order for the libraries in use or they don’t know what order to pick. Working on SFML and helping out in its community, I’ve had the pleasure to help people fix their linker errors many times and every now and then I’d explain a short rule of thumb one can keep in mind when specifying libraries to be linked. As such I wanted to share it here with you too.
Most of us probably ran into a bug in some application at one point. Sometimes it’s not very obvious, e.g. a random crash, while other times you may know that, if you for example perform certain five steps it will crash. But what do you do when you find an issue? Do you just avoid the crashing steps? Do you restart the app and keep working? Or do you put in some time and try and report the issue to the developer?
As a developer myself, detailed bug reports and active involvement in the bug report have been among the most valuable things in fixing bugs. As such, I can only highly recommend to send in bug reports whenever possible! Here is just some bug hunting story from last weeks.
Last week I opened the great video player VLC to playback some Opus audio file. Shortly after opening the application, it reported that there was a software update. I vaguely remembered that it already previously mentioned that, so I was a bit confused why I didn’t update then. Of course I accepted to download the new version and after 22% through the download process, VLC simply crashed. Aha! That’s why I didn’t update VLC last time. And indeed whenever you try to update VLC it would simply crash.
I remembered back when ShareX didn’t update when you clicked on the auto-update message and also remembered that they put up a notice on their website to manually update it. Certainly a broken update function in a quite popular media player would have been reported by now and thus I checked the website. To my surprise however there was no notice and searching a bit further I couldn’t find a report either. So I took things to the VideoLAN IRC channel and quickly found some active user.
After some digging we found the debug nightly builds. With that in hand, I thought it would be very easy to get a stack trace of the crash, but because this was a nightly build, the update feature points to a test server and while it actually triggered an update to be run, the build to update to wasn’t available anymore and thus nothing happened.
My next idea was to simply spoof the update server and change the update information. Having Python installed on my system I could just run python -m http.server 80 and it would launch a web server that served the files in the working directory. Then I added the update server to my hosts file, placed the update text file in the web server’s directory and … VLC’s update feature now simply threw an error. Luckily the debug build also output a lot of useful information in the console, so I saw that the update tests a signature file. This security feature prevents exactly this kind of “attack” where the DNS is spoofed and the fake server serves a malicious update. Having a file with a PGP signature ensures that only the ones with the private key can provide binaries with matching signatures.
So the new plan was to simply take the update file for the latest release version and its signature file. Finally, VLC crashed and I could get the stack trace. With an impressive list of 1637 entries, it became clear that the crash must be some sort of infinite recursion, which fills up the stack and finally leads to the crash. Since the problem seems to occur around lots of Qt functions, it may end up being less of an VLC issue and more one of Qt. A report was filed and now the waiting game beings.
In my books having a broken update function seems quite critical, as your users won’t get any security updates anymore, but need to go to the website and manually update VLC and many will probably just disable auto-update to not receive that message anymore. As such the reaction so far have been too low for my liking and I’m surprised that nobody else has experienced this issue. Then again VLC is an open source software maintained by developers in their free time, so it’s not a surprise that things take a bit longer.
The fact that the update feature doesn’t work due to outdated files in the nightly/development builds is a bit concerning. If it can’t be tested easily, then it simply won’t be tested at all and bugs like the one mentioned won’t be found during development.
VLC’s automatic reporting system doesn’t work (anymore). The FTP server the reports gets send to, doesn’t seem to exist anymore. In the consumer market direct reports to the team like mine are quite rare, so an automatic crash report system should work, so you actually see in case VLC suddenly keeps crashing all around the world.
As a software user, report bugs whenever you can and include as much information as possible!
As a software developer, make sure your features can be tested and that debug builds/symbols are available to get more detailed information.
I wanted to write some more on how to report bugs, but this post has already turned into a longer one, so I’ll reserve that for a dedicated entry.
Looking at the last news entry on the NightlyBuilds website, it seems like it has nearly been two years since I last update the Nightly Builds.
One of the reasons I didn’t bother as much to keep them updated was, because we at SFML now have setup a Continues Integration system which allows anyone to download the latest builds for various compilers. Additionally my system still isn’t very automated, so I always have to spend quite a bit of time to get everything ready, especially having to update all the compilers. But I’ve made things a bit easier by rewriting my build scripts, so an update to a new compiler version is a lot easier.
I’ve removed all the older compiler versions (VS 2010, 2012, 2014, 2015 RC, MinGW < 6) and now have just four compilers listed:
- MinGW Builds Posix Dwarf 710r0 32-bit
- MinGW Builds Posix SEH 710r0 64-bit
- Visual Studio 2017 32-bit
- Visual Studio 2017 64-bit
Currently I haven’t rewritten the build script for CSFML, so I’m only supporting the following libraries at the moment:
Still not sure where I want to really go with this project, but for now I’m going to use to provide library versions with the runtime lib statically linked, since we aren’t providing those in the SFML downloads on the official website.
And I hope it’s of use to some people out there!
I wasted like one or two hours on this and thought, I’d make a quick post, so others don’t have to waste their time in the future.
Convert EPS to SVG
If you just want to convert some EPS files to an SVG file, all you need is Inkscape and then use the following command to do the magic:
inkscape input-file.eps --export-plain-svg=output-file.svg
If you have a bunch of these files you can use the following command on Windows to convert them in one batch:
for %%f in (*.eps) do inkscape "%%f" --export-plain-svg="%%f.svg"
Of course Inkscape supports a lot more formats with a lot more options, just use the help flag to get the full list.
Cisco Icons for yEd
I originally ran into the problem, because I wanted to use the “standard” Cisco icons for a network diagram in yEd, an awesome and free graph editor. While googling I ran into this post which provides a set of Cisco icons for yEd, but the huge color difference between the icons just wasn’t acceptable (light blue vs “Cisco” blue). So I thought to create my own set and found myself converting the EPS from Cisco’s official Network Topology Icons page. I then converted them as described above, imported them into yEd and exported the full set for you to enjoy. There’s still some color difference, but less extreme. Since a lot of the icons are rather useless – or do you use some space router at home? – I’ve selected a few of the icons which seemed most useful to me and created a separate package. Note: The converted SVG files ares included.
See this article on how to import the icons into yEd.
For the development of Synth Guitar my Ludum Dare Compo entry I decided to use JetBrains’ CLion as my IDE. Ever since writing my most popular post about MinGW-w64 and an older EAP version I played around with the thought of trying it out, but never found the right project for it. For a year or two I’ve been using Code::Blocks, but was never fully satisfied (among others also because of this), however whether CLion will replace Code::Block for me is still open.
Before I had the EAP (Early Access Program) version installed on my notebook, but for my desktop PC I got to newly install the full version of CLion. As a student I get a non-commercial license for free, not only for CLion but for most of JetBrains’ products. If you however want buy CLion you’ll be paying €99 for a personal and €199 for a commercial license.
The download was very fast and with 138 MiB acceptably small. In comparison the offline installer for Code::Blocks with a compiler is 98 MiB and for Visual Studio you’ll be spending 6.9 GiB of your bandwidth, because Microsoft unfortunately doesn’t manage to provide a version just for C++.
The setup is very simple and I quite like the settings part when starting CLion for the first time. It allows you to directly change the options for design, version control integration and proper compiler detection. The later is one of the strong points compared to Qt Creator or Code::Blocks, because CLion supports and properly detected my MinGW-w64 installation, while it always seemed a bit of a hassle with Code::Blocks or you first needed to learn how Qt Creator actually handles toolchains and compilers. I wonder though why JetBrains couldn’t fully “support” the latest builds of MinGW-w64, not even with their 1.0.1 update. Then again I ignored the warning you get for it and have yet to run into any problems because of that. However CLion has stated that it can lead to freezes in certain situations.
The Build System
As someone who quite likes CMake, CLion’s native support is amazing and something I’ve been looking for quite some time. Of course Qt Creator comes with CMake support as well, but last I tried it, it did not integrate very well. With CLion you write your CMake code, link your favorite libraries through it and it will build and run just fine. One thing that seems a bit strange compared to most other IDE is, that CLion keeps by default all the build files in a temporary directory somewhere in your user directory. I mean it makes sense to not spam the source directory with all the CMake temporary files, however every now and then one might want to do something specific with the binary and has to go search it in there. My assumption is that CLion expects you to install the binaries instead. Luckily the directory can be changed with a few simple clicks if you know where to look.
One of the strange default options CLion ships with is that it allows multiple instances of the application to be run. So when you for example are debugging, you can also click on run again and the interface will switch to a different layout but still keep running in the background and a new instance will be loaded. During the Ludum Dare Compo I didn’t figure out that there’s a stop button if you switch to the correct tab, thus I ended up killing off GDB manually. I’m however really glad that pressing the stop button works, because pressing the stop button with Code::Blocks most of the time simply doesn’t work and you end up having to kill the process in the task manager. After the Compo I got a response from CLion that there’s an option to only allow one instance. This should in my opinion be the default setting given that single-instance applications are a lot more common.
I had been using Vim for some web development during a year or so and gotten quite used to some commands, however I’m still not a Vim guru, but can’t argue with the fact that it can accelerate the code-writing quite a bit. As such I tried out CLion’s Vim-Emulator and I’ve to say it’s very good. My main critique would be, that it’s not obvious in what mode you’re currently in, as such it’s really annoying when you start typing commands or text and only then notice that you’re in the visual mode. I honestly never had that issue with Vim, so all I can assume is that the indicators aren’t well placed. Something else that got me quite annoyed is that in almost all cases when you click on the editor to get the focus back, it will (accidentally) switch to visual mode. This usually lead me to keep hitting the ESC key multiple times just in case, to ensure that I ended up in command mode. Since the Vim-Emulator is a general JetBrains’ feature and not strictly related to CLion it might also just be me, who isn’t used to it.
I’m not a big fan of getting my code automatically formatted, since my style usually doesn’t match with the coding style of a lot of other C++ developers. Until I realized that CLion allows you to customized the formatting rules to about every detail, it was quite annoying to work with at times. But the customization settings are in fact so detailed that you have to be careful to not overlook the option you actually want to change. What was a bit counter intuitive however is that in order to make any changes to the formatting, you first have to create a new style setting. The ones that are installed by default are read-only. Some indication for that would be helpful and would’ve saved me a trip to the all-knowing Google.
Performance is one of my main concerns with JetBrains’ IDEs. CLion is written in Java and even though they do a great job at hiding that fact, meaning the application doesn’t feel nor look like your standard cheap Java application, the resource allocation regarding RAM and CPU time is something you might not want to overlook. To be fair though, it’s impossible to tell whether Java itself has much to do with it or if there is more improvement possible in CLion’s codebase alone.
When opening my Ludum Dare project and just letting CLion sit there, the memory allocation idles at around 1000-1200 MiB. I assume most of it is used for source code meta information to make auto-completion or similar things faster. However Synth Guitar only uses SFML as library, which makes me wonder how the memory allocation scales for larger projects with a lot of different libraries. Personally it doesn’t seem like a big issue, after all there’s plenty of free RAM and it certainly is a better alternative to keep that data in memory compared to Visual Studio’s huge IntelliSense database files.
Something that got a bit of an issue during my Ludum Dare live stream, was the CPU usage of CLion. It’s nice to see CLion using no CPU time at all, when doing nothing, but it gets quite scary when you look at it while writing code. It will jump all over the place starting off at around 30% total CPU allocation and when you start compiling something it actually maxed out my CPU. If you do CPU-heavy things like encoding live stream video and audio data at the same time, such a high CPU load can become a bit of a problem. Again it’s just a speculation, but I’d claim that optimized C++ code instead of Java code, would reduce the CPU usage for the general editing part quite a bit.
Having worked with CLion for only a short period of time, it’s kind of hard to talk about features, since I have yet to discover most of them and put them to use. But since we’re talking about JetBrains here, I think the most talked about feature is their refactoring tool. I’m very used to manually refactoring everything and as such will first need to get used to the option of having code changed automatically, as well as learn what the tool can actually do. Something that I tried to do was rename my copy of a class, but apparently that’s still a missing feature. It might have been just my lack of knowledge, but using the refactoring tool with the Vim-Emulator seemed to cause some trouble.
CLion is a solid IDE for C++ development. You really notice the long experience JetBrains had with building code editors and yet they still managed to keep up to date with the “latest tech” (Git, CMake, MinGW-w64, etc.). I really hope that performance will improve a bit and am sure that some of these early bugs and missing features will get fixed over the next few months. I wish the developers of Code::Blocks and similar IDE would take a look at the look and feel of CLion and try to aim for that as well. Especially Code::Blocks seems to not have improved noticeable over the past years, which is quite a shame.
Everyone who works a lot with CMake should really give CLion a shot. I already started another project with CLion, so who knows maybe Code::Blocks will slowly drift into the “unused” section of my PC?
As a final note: JetBrains has in the meantime released version 1.0.1.
Update 29.09.2014: As pointed out by Anastasia Kazakova in the comments, CLion’s EAP has received an update which added native support for MinGW-w64!
In the past few days, I’ve seen CLion mentioned on multiple locations including the SFML forum. CLion is a new IDE developed by JetBrains for CMake based projects, it supports multiple languages and can be further extended with plugins. Some might recognize the interface since it’s very similar to JetBrains’ popular Java editor IntelliJ IDEA.
Personally I haven’t really looked at the IDE in-depth, since JetBrains is the creator of the allegedly awesome ReSharper tool for Visual Studio – which I’ve never used – the IDE itself should provide some pretty decent refactoring capabilities. Last I checked out Qt Creator, I was a bit disappointed at the sluggish CMake integration; this at least seems to work a lot better with CLion. However maybe Qt Creator upped their game since then as well.
This post however shouldn’t really be about introducing/promoting CLion and maybe some or many of you who somehow find this post already know what CLion is, instead this should actually be a short tutorial on how to use a compiler of the MinGW-w64 family with CLion.
For whatever reasons the developers at CLion apparently didn’t get the memo, that the original MinGW has been relatively abandoned and most of the user base has moved on to the MinGW-w64 project, which originally was created to develop a 64-bit compiler, but now supports both architectures. As such CLion currently only officially supports the vanilla MinGW. As a MinGW user for many years, the fact that CLion only wanted to recognize the original MinGW as compiler seemed rather odd, since the differences in using either a MinGW or a MinGW-w64 version nearly doesn’t exist. When I ran ProcMon and tracked what in the filesystem CLion accessed, I noticed that it checks for the existence of include/_mingw.h. By providing such a file in your MinGW-w64 directory structure you can trick the compiler into accepting it as MinGW compiler.
Here are the few steps to make it work:
- Get your MinGW-w64 compiler installed somewhere.
- Create a file with the path [MinGW-w64 dir]/include/_mingw.h and the content shown below.
- Point CLion to your [MinGW-w64 dir] and watch how CLion recognizes your MinGW setup.
#ifndef __MINGW_H #define __MINGW_H #define __MINGW32_VERSION 3.20 #define __MINGW32_MAJOR_VERSION 3 #define __MINGW32_MINOR_VERSION 20 #define __MINGW32_PATCHLEVEL 0 #endif /* __MINGW_H */
Disclaimer: CLion is still in an Early Access Program and may change any day. This trick worked for me, but there’s still a chance that it might not work for you.
To end this write up, here’s the introduction video from JetBrains on CLion – it was posted on their blog.
Believe it or not, but here’s a new SFML News post. About half a year is it since the last news post, to all the regular followers of the SFML News I apologize. Writing the SFML News is a time consuming thing and with my internship my focus has been heavily shifted toward web development, but as you may read further down, SFML hasn’t been forgotten.
Given the huge gap, I’m sure you’ll understand that I won’t be presenting all new projects, but well see for yourself, the list is still huge. And because of that I decided to put the other news bits first.
After answering the same questions over and over and over and over again especially about compiling and linking, I thought it might be time to write down a few things, that I and maybe others could point to instead of keep repeating ourselves in the future. Given the wideness topic I’ll be writing things down in multiple parts. In this first post I’ll be explaining a few basic terms and their practical applications, the next one will go more into details on how linking against external libraries work and in the third and last part I’ll be writing down answers to some common issues. I hope this will turn out as a timesaver for all parties. – As a disclaimer I should add, that I’m a human being that makes mistakes and can have wrong models in their mind, thus if I make a mistake feel free to point them out.
Part I – Terms and Explanations
Although this should essentially be covered in any basic programming book, even the bad ones, here we go with a few “definitions”:
Looking at it in a very abstract way, an application is no different than anything else on your hard disk, because it’s just ones and zeroes, the important part however is how these numbers get interpreted. Your CPU (the heart & brain of your PC) doesn’t understand the ones and zeroes from a music file, but if you give it the data of an application it can translate them into actions that will do what the programmer intended to (hopefully).
To get such an application, your C++ code has to be turned into ones and zeroes, also known as machine code. The full processes of doing so is called building and is as such more an abstract term, because the process is essentially a composition of mainly three sub-processes: Preprocessing, compiling and linking.
Header File (*.hpp / *.h)
If you’ve done your job right, i.e. followed the correct way of writing code, then you should have all the declarations of functions, classes, structs, enumerates, templates, etc. in header files. With the help of a header file, the compiler will know how much stack and memory space is needed for the machine code that is about to be generated.
Source File (*.cpp)
The source file holds most of the implementation details, also known as code definitions. It’s where the behavior of the application itself is crated, meaning how the declared classes and functions interact with each other.
Inline File (*.inl)
This is not always needed and essentially optional, but it’s a common and good practice to put code definitions, that are required to be in the header file, into an external file and include it at the needed position in the header file. The most common use of inline files is for template definitions, which need to be in the header given that they get executed at compile time and can influence the memory layout and footprint.
Before your code gets translated into anything the preprocessor will kick-in. All the statements that start with a number sign are actually preprocessor directives and get resolved in the first step of building an application, for example all the #include will get replaced with the actual content of the included header file or for any #define X Z all X will get replaced with Z or any kind of macro will get executed.
Now that one source file will hold all required declarations the compilation can begin. Compiling is one of the terms that confuses a lot of people since it’s often used synonymously to building, which in turn isn’t too surprising given that compiling is the most crucial part, since it actually translates all the source into machine code. But you don’t end up with an application itself, but instead you end up with an object file for each source file.
Object File (*.o / *.obj)
Object files contain the translated source code in machine code. While the CPU essentially would understand the commands of the binary data, it would not know where to start exactly and miss other referenced code pieces. Thus these object files are only the building blocks used by the linker to generate the final executable.
As pointed out above the linker will be combining the object files generate by the compiler. It’s called linking because it obviously doesn’t just append or prepend the files, but actually makes “smart” links between parts of the object files – for details you might want to refer to a linker manual or other sources. But the linker doesn’t just link object files, it also links in libraries and it’s here where the difference between static and dynamic libraries are important, but I’ll go into more details in the next part, for now I’ll just say that static libraries are actually just archives of object files and thus can be linked in directly, while for dynamic libraries one just specify the interface and the “connection” between the application and the external code will be made at runtime.
Integrated Development Environments
This essentially doesn’t have anything to do with building applications, but it’s exactly that point that gets confused often. Integrated Development Environments short IDE are simply a set of tools created to work nicely (integrated) together and assist the programmer in creating code. A compiler and a linker can be considered part of this tool set, but it’s not the IDE that builds anything. Some of the most common IDEs would be Visual Studio, Code::Blocks, Qt Creator and Xcode. However one exception remains and that is, the Visual Studio compiler doesn’t really have a name of its own. Sometimes one refers to it as MSVC (Microsoft Visual C++), which in turn could also mean the IDE itself. What’s certain is, that one should not use “I built this game with Code::Blocks”, but instead “I built this game with MinGW” or “GCC”.
Having reached the end of the first part, I hope this basic information will be of some help to new beginners and depending on the response or future experience, I might add one or two paragraphs. The second part already has some words written for, so stay tuned!
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!