A Public Domain C++11 1D/2D/3D Perlin Noise Generator

Recently I needed to generate some simple procedural textures for a game I'm working on - after a quick search I found that the top result was licensed under the GPL which is no good to me. After a while I did find an MIT licensed one, but as all these code snippets are just C++ ports of Ken Perlin's improved noise function written in Java, I figured I might as well write my own from scratch and license it under the public domain. So, here it is, in all its glory:

Writing a C++ Completion Provider for GtkSourceView

Over the last few weeks I've been implementing Python code completion in my homebrew text editor. After a lot of work I have most of the backend code worked out, the file parsing and indexing generally works.

The next step was to create a CompletionProvider to tell the Gtk+ text view about any suggestions that my code completion engine had. In my mind, I just had to do the following:

1. Subclass CompletionProvider, implement the populate() function
2. Call view().get_completion()->add_provider(my_provider);
3. Wallow in the joy of having working code completion

However, it's not as simple as that, because the C++ GtkSourceView bindings suck, although they'd suck even less if they had some sensible documentation, or examples...

Bug Trackers Suck!

Recently, I've been thinking a lot about bug trackers. For those who aren't in the know, bug trackers are websites that allow software developers to, well, track bugs in their software.

More specifically they allow management of the entire life cycle of a bug report. Starting with the report itself which probably comes from a user of the software, all the way through to the final deployment of the fixed code in the application.

There are numerous free and paid for bug trackers out there - all of them suck.

Well, I guess that's a bit unfair, let me rephrase that, all of them suck if you aren't a developer.

A Quick Introduction to KGLT

Those of you that follow me on Twitter, or have the pleasure to listen to my waffling in person, will know that I'm working on a game engine - although I'm still not convinced that's the right terminology. Let's call it a "game framework".

There's a well known saying in the game development world, it goes like this: "Write games, not engines". And, it's actually really good advice, there are plenty of game engines out there, many of them open source and free to use commercially. On top of that, writing a game engine is hard, really hard. It probably is the most difficult user-space application that you can write, and only the insane or brilliant even attempt it.

I must be insane.

Now that I've painted a clear picture of why writing a game engine is an extraordinarily bad idea, let me explain why that's pretty much exactly what I'm doing.

Every so often I grab an old PC game from my shelf, shove it in the DVD drive and prod around the folder tree. If I find something that looks like it could be a new texture format, or model format, I can't resist firing up a Hex editor and trying to decipher it. I've had some moderate success too. I successfully reverse engineered the Ignition texture format for example. And it was during one of these reverse engineering stints that I realized I needed a game engine.

The reason was that, reverse engineering something like a 3D model format is a bit of trial and error, for example "Is that set of floating point data the vertex positions or the vertex normals?" might be the kind of thing you can't decipher just by looking at it in hexidecimal. This is why I needed a game engine, I needed a way to construct a mesh from what I thought was mesh data, and I needed to be able to iterate quickly if a certain block of data wasn't what I thought it was.

After trying a few game engines, I couldn't find anything that did exactly what I wanted. I found loads that did far more than I wanted, but I just needed something simple. And then KGLT was born.

I started by creating an OpenGL window with SDL, then I needed a way to create meshes, then a way to manage those meshes, then a way to skin those meshes, then I needed to render them faster... before I knew it I had been coding this thing for a year and it had grown beyond what I set out to do, hell, I never did get around to reverse engineering that format!

So, now KGLT exists. It's on my GitHub and it provides a really simple API for building up a 2D or 3D scene. It's written in C++ (although you don't need to worry about memory management or any of that nonsense, it's all taken care of). The whole thing is based around a few core concepts:

• When you create a Window, it owns a Scene.
• Each Scene can have multiple SubScenes, although a Scene starts out with one.
• You can add each SubScene to the Pipeline for rendering by specifying a viewport, camera, target and priority.
• To render things, you create Entities from Meshes. A Mesh can be shared across Entities.

KGLT is different to other game engines, it doesn't try to be ultra-flexible, or ultra-powerful, or all encompassing. It just provides a common framework for building on top of, a bit like Django in the web world.

KGLT is still in heavy development, but it would be good to get feedback/other contributors. So if you are into game development and you fancy playing around with it, give it a go! Let me know how you get on!

So, You want to Write your own Linux Display Server?

UPDATE: It's been confirmed that Ubuntu will be switching to a new display server called Mir. Canonical have posted some FUD about Wayland on the documentation site, and it turns out the Mir devs didn't even understand Wayland enough to make a decision.

Yesterday, OMG! Ubuntu! published a news article stating that Canonical are working on their own display server. If you don't understand the technical details of a display server, what it's job is, and how applications talk to it, then you may think this is a good thing. You may think, “Linux is about choice” or “perhaps this will be better than the alternatives”. But you'd be wrong, horribly wrong.

Introducing PasteShare

If you are a programmer, and you collaborate with a team of developers, you probably make regular use of a "paste bin" site. Paste bins are websites where you can enter some code into a text area and share the link with others. Sort of like a public notice board for code.

Sometimes the code that is pasted is useful to others; an algorithm or boilerplate code that might help someone in future. The problem with current paste bin sites is that code is still copyrighted. If someone stumbles across your paste in future, they won't be able to trace you to ask permission to use it, and they don't implicitly give you permission just because it's available to the general public.

PasteShare is different. On PasteShare whenever someone pastes some code, they explicitly release that code into the public domain with the Unlicense license. If you find some code on PasteShare, you are able to use it in whatever way you see fit - there's no need for permission.

I'll continue to improve PasteShare over time, and in particular I want to make finding useful code easier, so expect plenty of improvements on that front. If you think of anything that would be useful to you, feel free to tweet me!

Now, go share your code!

Goodbye Ubuntu

I considered calling this blog post "I'm moving to Debian" but if I did, people would probably assume that I'm doing so in a trantrum, and just posting to rant.

But I'm not, I'm not angry, maybe just disappointed. I've had the love of Ubuntu beaten out of me over the years...