Archives

All posts for the month May, 2012

The Curse of the Build Processes

Posted by Shai Shapira on May 31, 2012
Posted in: Free Software, Software Developement. Tagged: , , , . 1 comment

I installed MinGW today, making me finally able to build C++ projects on my Windows machine. I’m always quite surprised by the lack of support for C++ development on Windows – you have MinGW, and you have Visual Studio. If you don’t like the GNU design philosophies and don’t want to pay ridiculous amounts of money for Visual Studio – well, that’s too bad.
So I went with the GNU approach. But first, a little background.

There are some things in my life that come back to my mind every few years. I come up with something, try to do it, maybe advance a little, and then for some reason decide it’s not feasible at the moment and forget about it for another few years.
If you’ve been following this blog for a while, you might be thinking: “Hey Shai, you’re a programmer. You like open-source games. You even started contributing translations to an open-source project. Why don’t you ever contribute code to any project?”

That a good question, hypothetical reader. And here is the answer:

What you’re seeing here is about one half of the makefile of SuperTux, but it could just as well be from pretty much any big open source project. A makefile, in case you’ve never had the (debatable) pleasure of developing on Unix-like systems, is a file that describes an automated build process so that the build can happen with one simple command.

The problem? It doesn’t work.

Well, to be fair – I’m sure it works for some people. Software does get made on Linux, so I’m sure someone is able to make those things work. But in my 5 years or so of using Linux, I can safely say that of all the open source projects I tried to build from source (and I tried many), maybe 30% worked with a single command [1]. And now, having made the ultimate sin and gone back to using Windows? Good luck. Most projects I’ve seen either don’t consider Windows at all, or assume you’re using Visual Studio. And when someone does give a non-Visual Studio build process – well, try to read the SuperTux Windows build instructions[2] and see if after the first 200 paragraphs you still have the motivation to fix that little bug you saw.

And the strange thing is, I don’t understand why it has to be like that. I’ve programmed in C, Java, and even a little C++ before – I had source files in one place, destination files in another place, libraries in a third place and that’s it – compile, link and run. Maybe it’s a matter of the compatibility? Make things work on as many machines as possible? I doubt if that explains it.

Until about a year ago I worked (professionally) on a huge project – over 50 coders, several sub-projects that had to be connected to a final one, it was web-based so it came with a huge mess of Java files, web pages, JSP and whatever. To build the project, we had an Ant file smaller than what they have in the most basic C++ projects, and it was all in human-readable XML full of comments about what each part does. Not that it wasn’t a huge mess, but every piece of the mess was added for a specific, documented reason. It also failed quite often – when something important in the project changed, when someone new tried to run it, when Jupiter aligned improperly with Mars. But even without being an Ant expert, you could open the file and see what was going on there, and search for the problem.

Just to be clear – I’m not saying those projects are doing something bad, and some other way is necessarily better. What I’m saying is that for me, and I’m guessing it’s also for many other people who are not crazy about Unix design philosophies, this is a significant barrier from getting into projects like these.

So, in conclusion – I now have a C++ compiler, but I don’t know if I’m going to do anything with it. Maybe I’ll study the inner workings of makefiles and build processes until things will actually work, or maybe I’ll just keep working in Java and live in a parallel universe to most of the open source world. Either way, one thing is certain – I used Linux before and I might use it again, but I’m definitely not a subscriber to the Linux philosophy.

 

[1] Or two, or three – makefile also has a little brother called autoconf, and I think there was something additional sometimes.

[2] Which, by the way, starts with a “warnings” section, including the fact that it might destroy your computer and you should do it on a virtual machine.

And now, I’m also a translator

Posted by Shai Shapira on May 27, 2012
Posted in: Free Software, Games, Languages. Tagged: , , , . Leave a Comment

Another example of how the open source world works – a few days ago I complained about the bad Hebrew translation of SuperTuxKart, and now I’m officially working on translating it myself.

It’s kind of an odd feeling to translate a game to Hebrew. I guess it’s probably how it felt for the people who translated Google to Yiddish and Klingon – more like a curious exercise in linguistics than actual practical work. Although I guess maybe since STK is kind of a family-friendly game, maybe there’s a chance of someday people outside the heavily-Anglophone gamer demographic might play it, so maybe someone will actually want a proper Hebrew translation.

Anyway, it’s nice to contribute something to a serious game. Maybe next I should do something about this little gem from GIMP:

Anyone can translate “Save”, but for “Don’t Save” you really need the experts.

Yes, that’s the kind of things Hebrew speakers have to work with.

Review – SuperTuxKart

Posted by Shai Shapira on May 24, 2012
Posted in: Games. Tagged: , , , , . Leave a Comment

With some annoying delays on all of my own projects (some are my fault, some only kind of my fault), I thought I’d do a little reviewing instead, for now. A few days ago I finally filled a gap in my FOSS gaming education, and downloaded one of the most famous of those games – SuperTuxKart. Despite my initial skepticism, I ended up loving it.

Initial impression: Language trouble

The beginning wasn’t very promising. The game automatically chose to use the system’s default language – a reasonable choice. The problem is, my system language is Hebrew (I don’t even know why, my OS is in English), and unlike most software, SuperTuxKart has a Hebrew translation. And like most (if not all) software with a Hebrew translation[1], it mostly resides in the area between “goofy”, going through “horrible”, all the way to “completely broken”.
Some pieces of text are possible, but sound bad (“eat one’s dust” is a proper English phrase, but it doesn’t work in Hebrew), some are obvious machine translations (my favourite: of two instances of the word “squash”, both get comically mangled in different ways – the rubber ball is apparently made of pumpkin, and the swatter is… something ungrammatical involving racquetball), and some break because of the right-to-left writing (notably, it makes sense to leave names untranslated if you translate from English to French; To Hebrew, it brings single lines with both Hebrew and Latin letters, and that’s a guaranteed bi-directional fail).

Also, just to add insult to injury: They’re actually inconsistent about the Hebrew spelling of their own game’s name.

Is a “U” like Kamatz or Kubutz? You decide

Moral of the story – don’t publish a translation if no one on your dev team actually plays the game in that language.

The actual game

However, after having that little laugh, I could start experiencing the actual game, and it’s very good. First, a little about where I come from – I have virtually no experience with kart racing games, maybe one or two attempts at Mario Kart on a friend’s Wii. Most of my racing experience is on Stunts, Micro Machines, and Redline Racer. So some of what I say about this game might be just generally about the kart genre.

- The driving physics: At first I was a little unimpressed, the driving felt a little boring and uneventful. Then I discovered the “fast turn” button – that made all the difference. For me, that option is what really brings some excitement to the game, allowing some fast driving through twisty areas, which requires some skill.

- Tracks: Quite well made. Most initial tracks are pretty simple driving, but later, especially with the unlockable ones, it gets much more interesting. I think not many tracks provide a unique driving experience (mostly the lighthouse track, the mini-golf track, math class track, and the stars track. But I think I still haven’t unlocked everything) (Update (28.5.2012): Having unlocked everything, I can now say that it’s only true for the initial tracks. Almost all of the unlockable tracks are much more unique and interesting to drive) .

- In-game appearance: Not the strongest point. The tracks mostly look like they’re a bit short on polygons. On the other hand, I don’t really like what Mario Kart looks like, so maybe it’s just the style. I do like the themes, though – almost every track does have a unique visual feeling to it. If they were also prettier, it would really be great.

- UI appearance: The menus look very good, kind of unusual for FOSS games. The UI is both polished, and has a consistent style. I could certainly believe it’s the UI of a professional game. However, some parts outside the menus (like the result panel, and the unlocking screen) feel much less polished.

- Music: Excellent. I don’t know if it was written especially for the game or those are public domain tracks they borrowed, but they sound very good and some of the songs are very fitting for the tracks they play on. One thing I would consider changing – maybe try to make smoother loops in the music. The music is often much shorter than the driving, and then the music noticeably stops and restarts. If the music would be written or edited to have continuously loopable parts, it would sound much better.

- Replayability: The challenge system is very good, giving some good reason to keep playing the game. Too bad there’s no achievements though (I love achievements[2]).

- Multiplayer: Unfortunately, no net-based multiplayer. And I don’t have a big screen to play it on. I hope it will come in the future.

Conclusion: Excellent game. Very recommended if you like the type. Even though they’re not in version 1.0 yet, it’s one of the few FOSS games I feel really looks polished like an actually completed game.

[1] A little note about Hebrew translation, for you major language speakers – with so few speakers who almost always speak English as well, no one really sees a point in translating stuff to Hebrew. Thus, Hebrew speakers are used to having no translations, and always use software in English. Then, when people do translate stuff to Hebrew, Hebrew speakers by habit don’t use it so no one notices any horrible mistakes. So translations stay bad, users keep not using them, and the cycle of poor quality is complete.

[2] Of course, some modern games have a very liberal interpretation of the word “achievement” that could count the challenges as such, but I don’t like it. For me, achievements are supposed to note unusual behaviour in the game, not ordinary successes.

Blocky Gaming

Posted by Shai Shapira on May 16, 2012
Posted in: Modding. Tagged: , . 1 comment

Finally, like many people out there (although maybe a little later), I was struck with Minecraft fever. Not with the actual Minecraft, actually, but with the open-source alternative Minetest[1].

As might be expected of me, I got over the initial “let’s build pretty things” phase quite quickly, and started thinking about modding some special gaming maps into it. I think it has a lot of potential, and the modding API is very well made and relatively well documented. I have some wild ideas for maps, many of which will certainly turn out impractical, but let’s hope that at least some fun things come out of it.

So for now, exclusively for this blog, here is a sneak peek to the construction site of my first map:

Hopefully it will start being playable in a few days.

[1] I really wish it will get a better name in future versions.

Blender Scripting Tips For Programmers

Posted by Shai Shapira on May 10, 2012
Posted in: 3D Graphics. Tagged: , , . Leave a Comment

I’m not really a Blender expert, but I did work a little on scripting once in a while over the past month or two. I thought I’d share some of the problems that confused me, so others might get it started faster.
I write “for programmers” because I think many of the mistakes I made ultimately stemmed from my attempts to use programming ideas on a scripting environment (more on that later), so non-programmers might not have a problem with them. But of course anyone who wants to script in Blender might find something here useful.

1. Most, if not all, of the Blender scripting documentation and discussion is geared towards scripting as a way to assist modeling, not to replace it (which is what I’m doing). If you’re trying to make a script that does any serious kind of modeling on it’s own, you probably won’t find any documentation (of course, if anyone knows anything I missed, I’d love to hear about it). Your main source of information is the reference - keep it in your browser favourites. But even that is kind of lacking (it contains all the fields and functions, but many of them have little or no description).

2. Most importantly, if you’re a programmer – the Blender scripting API is made for scripting, not programming. This means that many things work in a kind of counter-intuitive way for a programming API – because as a scripting API, it does not expect much logic and automatic flow – it’s meant to be simply a series of tasks that could have been done by a human Blender user. This mostly means two things:

2a. None of the functions work directly on objects. This is very confusing, because as a programmer you’d expect that, for example, to add a vertex to a Mesh, you’ll need to work with the mesh object. But the scripting world doesn’t work with behind-the-scenes objects – instead, it works on selected objects and active objects just like the Blender UI. If you want to do something to a mesh, you need to select it first, and then the mesh operations will know to work on it. The bpy.ops.object module has some functions for selecting objects, and bpy.context can give you information on currently selected objects.

2b. None of the functions have return values. This can be quite confusing for a programmer, as you might expect that, for example, after creating an object you’ll get a reference to it as a return value. But no – after you create an object, the only way to reference it is to use the fact that it automatically becomes active, and thus getting the active object from bpy.context.

3. Make sure you understand the difference between an object and a datablock. Okay, I don’t think I fully understand it myself, but I know it’s important – basically, all the details of your object (mesh, lamp, curve etc.) are saved in the datablock. The object is a simple, general purpose entity, which has a property called “data” that links to it’s datablock. So for example, if you select a mesh object and want to work on the mesh, you need to get the selected object’s name (from bpy.context), then get the actual object from bpy.data.objects[name], and then getting obj.data. The object is an instance of class Object, while the datablock will be an instance of class Mesh – so the vertices and other properties are in the Mesh, not the Object.

4. Generally, when you’re trying to make something happen automatically, it’s always good to do it step-by-step in the Python console first, and only then write the script. This is because debugging is very problematic in Blender, usually when you crash a script from the text editor, you have no idea which line crashed and why.

5. Some text editor tips:

5a. The Blender text editor is not exactly a professional IDE. Most importantly, save your work often – if you accidentally make an endless loop or an impossibly complex operation, Blender will crash and you’ll lose your current work.

5b. In case you’re not used to working with the keyboard in Blender – note that the keyboard focus, unlike in most applications, always changes to where the mouse cursor is. That means if you want to write something in the text editor, make sure the cursor is in the text editor (I can’t count how many times I started writing, only to find I’m activating all sorts of weird keyboard shortcuts in the 3D view).

5c. There’s a button in the text editor menu that activates context highlighting. I missed it at first, and it made my work much less pleasant.

Have fun!

Bunch of Things #3

Posted by Shai Shapira on May 6, 2012
Posted in: Bunch of Things. Leave a Comment

1. I did a little redesign of the site, mainly because I wanted a top navigation menu. There aren’t many entries there for now, but I have big plans for the future.
2. Guess which game went open-source? More than 20 years after its original release, none other than Prince of Persia. As code doesn’t age very well, I doubt if it would actually be of much use to anyone but historians. But symbolically, it’s a nice move.
3. Lately I’ve been quite fed up with Google’s habit of guessing what I want to search instead of doing what I ask it to. A while ago I heard about DuckDuckGo, which works more like old-school Google, giving the same result no matter who’s doing the search. Also, they claim to better keep your privacy. So if you’re like me, you might want to check it out.
4. Any francophones out there? I wonder if someone can shed some light on this:

From Wiktionary

How can a phrase mean either “earlier” or “later”? If I hear the someone say “tout à l’heure”, what information am I supposed to deduce from it?