Starting the SFML Journey with Fedora

I am a Fedora Fanboy. I love the distro. I will always recommend it to everyone. Despite that love, it seems like we have to cater our minds to how Fedora wants to do things. And believe me, it does things very differently when compared against Debian or any of its common derivatives. One major point of contention early on was getting used to how differently Apache works on Fedora opposed to Ubuntu. I actually prefer using Apache deployed on Ubuntu than I do Fedora. I fucking hate administering Apache on Fedora systems.

That being said, I wanted to take a few moments to discuss my adventure with SFML (Simple and Fast Multimedia Library) on Fedora from getting it installed, setting it up and actually compiling a simple source file with it.

First of all, I’m diving into SFML because there’s a project that I’ve been piecing together for a while and I think SFML fits the bill nicely based solely on research and reading the API. It also allows me to take a break from Java development and step back into C++ which is my favourite language. I feel all warm and fuzzy writing in it. I’ve always had 100% success getting SFML setup and configured on Windows computers with Visual Studio 2012. The obvious problems there are (A) I have to use a Windows computer (it’s bad enough that I’m surrounded by them at work and my laptop has Windows 7) and (B) while Visual Studio may be really pretty, I’ve never jived with how you have to use the GUI to configure all of the esoteric settings for the compiler and linker; it just feels clunky. I’d much rather type it out on the terminal or use a makefile.

Furthermore, as a bit of a primer, SFML is a multipurpose library for creating programs that need audio, graphics, networking or GUI resources in a cross-platform way using C++. The obvious use is video games but it can be applied to other types of programs as well.


Typically, when installing software libraries on Linux, you just hope and pray (if that’s your thing) that somewhere in your repositories that a pre-configured package exists for them. We shudder at the alternative method which is manually compiling and installing. I do anyway. So I was overwhelmingly pleased to see that the default repositories on Fedora did in fact have packages for SFML (SFML and SFML-devel). Cool!

First Attempt

For shits and giggles, I copied the source code that’s given on the SFML tutorial site and attempted to compile it (not link). I get my first ding.

#include <SFML/Graphics.hpp> not found

Fuck. Right off the bat, g++ can’t find a critical header that’s needed for the source to compile. So I did some digging. Knowing that library headers are typically under /usr/include, that’s where I started at. What a surprise! The headers got installed in a directory tree that went like this:


Well that’s not going to work at all. So I moved the SFML directory out to /usr/include and removed the SFML-2.0 directory. Compilation success!

What About Linking?

This is usually the step where things get hairy when they go wrong. After getting a successful compile with an object file, I tried to link based on the steps in the tutorial.

g++ <file>.o -o <file> -lsfml-system -lsfml-window -lsfml-graphics

Result? ld can’t find any of the sfml-* libraries! Fan-fucking-tastic!

So there were a few things going on here that could have been causing the particular problem. First of all, I’m using a 64-bit version of Fedora. All libraries that are automatically installed by Yum, unless specified otherwise, will install the 64-bit version of the library. These files go under /usr/lib64. Some people have said that they’ll find them under /usr/local/lib64 but on my Fedora system they were under the former. It’s best to find out before you go rooting around and changing shit.

Second of all, ld wasn’t looking in /usr/lib64 for libraries. You can find out where ld is looking for libraries by looking at the /etc/ file. Although not entirely proper, I simply tacked the path to the end of the file and wrote it out. Once you do that, you need to run ldconfig (as root) to enforce the changes. If this step weren’t done, you’d have to keep linking with -L<path-to-library>/lib every time.

Lastly, even after all of that, my linking attempts were still failing. The reason this time? Name mismatches! That’s right the damn names of the libraries were wrong. The tutorial tells you to link to -lsfml-window. By default, I should have linked to -lsfml-window-2.0. Fucking bullshit. That went for any of the SFML shared object files. So I renamed those symlinks and took out the “-2.0” at the end so that -lsfml-window would work.

The End

After all that, I finally got a successful build of a demo SFML program and got the green circle in a 200×200 window. Why I had to go through all that trouble to get the trivial tutorial program to compile is beyond me but now that it’s working, I can move forward with my deeply laid plans to make shit happen.

Initial Setup Reprise

Some interesting insight into the Setup Assistant. Hopefully this shows that future iterations are going to get better.

As far as I know

GNOME’s initial setup assistant was originally introduced in 3.8. It helps people set up GNOME 3 when they first log into a new session, and guides them through the essential steps to make their account usable. It enables you to set a language and the date and time, and it helps you to connect to a network and to online accounts.

Without something like initial setup, there’s a risk that a new user might be faced with a system that isn’t using their language or has the wrong time. Hunting through settings on a misconfigured system is not what we want people’s’ first experience of GNOME 3 to be.


From a design and development standpoint, one of the tricky things about initial setup is that it doesn’t get a huge amount of attention. Those of us who work on GNOME don’t see it on regular basis and our users only…

View original post 822 more words

Developer’s Notes 0001 – Revisiting Box2D (Start)

This is an excerpt taken from my OneNote page regarding Box2D. If anything, it shows that I took a lengthy hiatus from this library and I wanted to get back into using it. However I hit the same wall I hit before which was determining a sane pixel-to-meter scalar which is required for a proper implementation. Also, it clearly outlines that I’m not a physicist in any way and that I write in a very wordy manner.


Something that I’ve always had trouble with regarding the usage of this library is the scalar for pixels-to-meters. The official notes from the library developer state that it’s really dependent upon the game as to what value this scalar should be. However that response always struck me as odd; why should this value be so volatile as to not have some standard that works for a majority of cases so that you can at least get started using it? I always thought there would have to be some common expression of this scalar that could be applied to any rigid body in a simulation unit. As it turns out, there may be one although I’ve only been able to catch glimpses of it here and there on the internet.

One site in particular, run by an Italian ActionScript developer, makes a claim of an “unwritten rule” that 1m is equivalent to roughly 30px. ( I have seen this claim on a few other fringe sites that have appeared in the recesses of Google searches however there has been nothing that has substantiated this claim by any leading developers or physicists who use this library for simulation purposes.

The core of the issue stems from the units that Box2D uses to express rigid bodies. Relying on the MKS (meter-kilometer-second) system, a 1/1 ratio between meter and pixel doesn’t exist. Knowing that the conversion factor of a meter to a foot is 1/3.28, if a 1/1 ratio between pixels and meters existed, a 320px X 64px image would be 320m X 64m (1049.6ft X 209.92ft) which would most likely not translate to a real-world object that we would want to exist in the simulation.  Furthermore, the force that would need to be applied to that body to get it to move, assuming it were a non-static body, would be immense.

There is a small paragraph on the official wiki for Box2D which is effectively a FAQ. One of the questions is as follows:


There are a few things to take into consideration while reading this example:

  • The scalar chosen in the example (0.01) appears to be entirely arbitrary. There is no real rhyme or reason as to why it was used instead of another arbitrary scalar like 0.25.
  • The scalar is applied not only to the dimensions of the sprite (measured 100px X 100px thus making its rigid body representation 1m X 1m (100 * 0.01)), but also to the coordinate system as well in order to accurately reflect the body’s relative location. In the example, the sprite starts at Pixel Coordinates (345, 679). To Box2D, and based on the chosen scalar, it would actually be located at (3.45, 6.79) as a result of ((345 * 0.01), (679 * 0.01)). Upon moving, the sprite is then located at (2.31, 4.98) in Box2D Coordinates. The translation to Pixel Coordinates requires the inverse operation of the scalar applied ((2.31 / 0.01), (4.98 / 0.01)) which would place the sprite at (231, 498) in Pixel Coordinates.
  • The example clearly does not state or even remotely lean to an “unwritten rule” that would be indicative of the 1m/30px ratio. Instead it leaves it up to the reader’s interpretation as to what the scalar should be.

Clearly there will have to be some investigation as to what would work well. The information that I’ve been able to find here should be sufficient enough to get started with a simulation to play with.