New Munin-plugin for HAProxy

I committed a new Munin-plugin for HAProxy. It’s a multigraph plugin, it discovers all the configured frontends and backends automatically – all you need to provide is the username/password for the haproxy status page.

It produces 8 graphs, + subgraphs for some of the backends, where it presents the same graphs, but with server-specific metrics.

Some of the root-graphs:









Do you use HAProxy and Munin? Check it out!

Posted in Munin, Planet Redpill-Linpro | Leave a comment

Birthday boy.

I’m 28 now.

Those people who invented the term “grownup” were weird. There’s no such thing.

Posted in Uncategorized | Leave a comment

Experiment of the week: Bump mapping in OpenGL

With a lot of help from my friend Zerd, I finally managed to get bump mapping to work. I’ve been pondering on how bump mapping can be used with 2D graphics – and after playing around a bit, I don’t see any reason not to use this.

A built version for Windows can be downloaded here: http://dl.dropbox.com/u/1287557/bumptest.zip … The source code is included, and it builds fine on Linux. It also works just fine in wine if you don’t want to bother building it. The code is fairly minimal.

A couple of screenshots with light illumination from different sides; (NOTE: This looks better in motion)

Posted in Uncategorized | Leave a comment

WTF anno 2005: Secure File Downloading.

When I started as a system administration at my old job, one of my first tasks was to help a consultant – from a company I won’t name – with their proprietary solution for “Secure Internet”. My workplace needed a secure way to download files, and their solution should cover all this… in various interpretations of “secure”.

The design was fairly simple:

  1. Clients connect to a terminal server (being Citrix or RDP, it doesn’t really matter).
  2. The Internet connected session can’t access the secure network, but is able to store files on a temporary home directory in the DMZ.
  3. The files in the DMZ are picked up and transmitted by email to a special account.
  4. On the MS Exchange server, a trigger reacts on incoming emails to this particular account, and then writes the attachment to the user’s home directory.
  5. The user can access the downloaded files inside the secure network.

If we say that it’s acceptable for the user to deal with untrusted files downloaded from the Internet, this is a fair design. It does the job. However, this is not what I wanted to present to you. I think it’s more interesting to look at how the file-transfer is performed.

When the user saves his file at his temporary home directory in the DMZ, a scheduled job runs and picks up the file. The same job constructs an email formatted like this:

FROM: filelockaccount@acme.org
TO: filelockaccount@acme.org
SUBJECT: \\fileserver\home$\username\filelock\iloveyou.exe
ATTACHMENT: iloveyou.exe

On the Exchange server, the trigger picks up the email, and writes the attachment to the path defined in the subject. The Exchange server ran this job with administrative privileges.

To see whether this could be exploited, I used an Internet connected computer outside the network – just connected via ordinary ADSL. I made Outlook Express use the ISP’s SMTP-server, and made an email formatted like this:

FROM: filelockaccount@acme.org
TO: filelockaccount@acme.org
SUBJECT: \\somewebserver\c$\OMGLOLZ.txt
ATTACHMENT: OMGLOLZ.txt

A couple of minutes later, I could see OMGLOLZ.txt in the root of C:\ on somewebserver. We also tested whether we had access to potentially execute malicious code… and since the magic process on the Exchange server ran with administrative privileges, we definitely could.

Turns out the secure way of downloading files from the Internet could be used to compromise server security in the entire network.

The hole were patched shortly after, and I got my attaboy.

Posted in Uncategorized | Leave a comment

Goals for 2012

  • Get better at drawing.
  • Make a chiptune.
  • Participate in more competitions, more often.
  • Co-create a game with someone (compo or not, whatever – it’s for fun).
  • Post more stuff on this blog.
  • Release more code.
  • Release more tutorials.
  • Enjoy life more.

I drew a guy, he has weird proportions, but I’m happy with him. I didn’t attempt to create Cody from Final Fight, but I was thinking about his colors. I didn’t put a lot of work in it.

(Looking at the ambitious-level of my own goals, it’s easy to understand why I’m usually not happy with my own effort.)

Posted in Uncategorized | Leave a comment

Links house, analyzed: Part 3 – The wall

The wall can be broken down into 3 parts, + the floor-edge, since it’s not technically a part of the wall. It always sticks next to the wall. The wainscot, the wallpaper and the crown-molding. I’m not 100% sure that this is what it’s supposed to be – 16 bit graphics often leave some room to interpretation.

With the exception of the corner-area, the wall is built up by these 7 tiles (not 8, because the two tiles for the border are identical). Looking up close, the tiles are fairly simple. The detail here, is the combination of the tiles.

The floor-edge

Closest to the wall, it starts off with two pixels of dark color. This gives us the impression of being in a corner next to the wall.
Most of it is filled with a solid color fitting to the rest of the rooms palette.

The wainscot

Consisting of two tiles – together they could create a simple brick-wall pattern. The reason it looks like wood, is because it’s brownish of color. Fairly simple dithering; Not too much, not too little. The corner-tile is just a few pixels marking the corner itself – without any additional dithering/shading in the area.

The wallpaper

When I look this closely at it, I get the feeling it’s stained. These two tiles alone, proves how much detail a tiny amount of randomness can add to a scene. The corner tile got extra “stains” added around the corner for shadowy effect. This also adds to the illusion of perspective, as this tile is higher up than the wainscot.

The crown-molding

This is the most detailed of the four parts – yet, still fairly simple. If you alternate the two tiles, you get perfect tiling.

So, the walls in Zelda are fairly detailed – yet, also fairly simple. If one break down the wall into individual components, one can see what kind of tricks has gone into making of the wall.

Posted in Game development, Graphics | Leave a comment

Links house, analyzed: Part 2 – Perspective of things

From a perspective point-of-view, this game fails when you’re indoors. The walls are treated differently when you’re indoors, than when you’re outside. Everything on the floor is still treated as if it was outdoors.

All walls are equally visible. As if we were looking directly downwards.

You're not looking directly down anymore. We're clearly looking at the scene from an angle.

One could have treated the entire game as if it was located outdoors. However, Zelda without dungeons wouldn’t have been Zelda. Adding the top-down view for just the walls, is most importantly done for navigational purposes – you will enter and exit doors on all four edges of the screen. This is not a problem when we’re roaming around outdoors, as the screen will pan entirely when we touch the edges of it. Entrances can be limited to be located pointing south.

To add to the illusion of depth, one technique that you’ll see all over the place on Zelda is this; The tallest part of an object is brighter than its foot. It will also appear larger than its foot. The change in light and size gives us the illusion of distance. The bricks on the entrance next to the floor is only 1×2 large, while the topmost brick is clearly 2×4 large. Making the door wider on the top than its bottom also adds to this illusion. The same concept is applied to three other items attached to the wall. Note; I did flip the door upside-down from what it appears in the room for comparing purposes.

The corner is doing the “large on top”-technique, too – just not entirely as visible as on the other objects. The corner-line has a thicker shadow on top, than on the bottom. It is also fairly dark at the bottom of the entire wall – as it’s got a two pixel thick line close to it.

Posted in Game development, Graphics | Leave a comment

Detailed network metrics with Munin (Linux)

Munin already does a great job on graphing – but I noticed that there weren’t any plugins dealing with the metrics in /proc/net/snmp and /proc/net/netstat. I didn’t know what all the metrics could mean, so I made some generic code that gathers all the data – and asked a couple of bright coworkers to pitch in with what they know. It doesn’t have any thresholds set, as we haven’t considered using it for alerting yet. Patches and feedback are welcome.

The plugin creates 22 (!) new graphs. A detail level of this magnitude is for most people too verbose, but if you have a large rig that pushes a lot of traffic – frontend nodes perhaps – you may want to learn more about what goes on.

This is a Multigraph plugin, it requires Munin 1.4, and it’s easy to extend. It does not suggest to be enabled by default, because it’s so verbose.

I just committed it to the project – and it’s available here; Trunk

I expect that it’s included in Munin 2.0, but I don’t know for sure.

The samples below shows one frontend node pushing a lot of traffic – the huge spike is a soccer-match (Norway and Denmark).

Posted in Munin, Planet Redpill-Linpro | Leave a comment

Links house, analyzed: Part 1 – The tilemap

This is a picture of the interior of Links house, in “The Legend of Zelda: A Link to the Past”. It’s the first room in the game. It looks very good. I will attempt to analyze what they have done to achieve this – what techniques have been applied, and why. Some techniques has been used because they are great artists – and some techniques have been used, because the SNES has very little memory.

First, a little bit about the SNES. The old game consoles got hardware-support for tiles. This means two things; Re-using small pieces of graphics was easily achieved – as the console can flip the tiles horizontally, and vertically, without consuming more memory. The only console in sale today, that still makes use of this – is the Nintendo DS.

A screen consists of a grid of tiles. When you look at a grid with 8×8 spacing, you can easily tell that the tiles are being reused. In some places, you’ll see variations that are achieved by just flipping every other tile.

The floor is the simplest pattern in this scene. It is made out of two tiles, simply alternating each other. One can also create this pattern as one 16×16 tile.

The bed is fairly simple. It consists of 6 tiles. The bed is symmetrical, so the right side is just repeating the same tiles as the left side, but flipped horizontally. Rows 2-4 are identical.

This cares to demonstrate some of the limitations the graphic artists were working under. Even though the game looks very good, it’s needless to say that the artist would be able to create more detail if he wasn’t confined to the limitation of maximum X tiles in the tileset. We now know that the bed is symmetrical, because of technical limitations – and not because the artist thought it was the best way to draw a bed. You will find this literally everywhere in 16-bit era games.

It still looks good, but it was also a sacrifice to make room for more art. Unless you are making graphics for a platform with strict limitations on how detailed your graphics can be – you should remember that this is not a compromise you need to deal with. You may chose to do so, for your own reasons – e.g. you want to mimic the 16-bit era graphics more accurately. But you don’t have to. You’re free to ignore it.

Posted in Game development, Graphics | Leave a comment

Drawing tiles: Some lessons from an amateur

So, I’m quite happy with the tiles I ended up with in SUBJECT:7 – so I’ve decided to make a guide on how to draw them. It’s fairly easy to learn – one just have to apply the knowledge.

I mainly use Gimp for drawing – but I suspect that any drawing application that’s capable of dealing with layers, opacity settings on the layers, and radial gradients will do (yes, I’m aware that gradients is a nono when doing pixelart – I don’t care).

First a couple of words about what you see here:

Two tricks are used to give you the illusion of depth. The first technique is to make the bricks on the top appear larger than the bricks on the bottom. The second technique is to make the bottom somewhat darker than the top. This is a very common way to do things – one very good example would be “The Legend of Zelda: A Link to the Past”.

You should also note that on the corner-tiles, the brick-spacing is moving slightly towards the corner – this adds the illusion of perspective.

Things appear larger on top, smaller on the bottom. Brighter on top, darker on the bottom. Thus adding to the illusion of perspective. These tiles are from The Legend of Zelda: A Link to the Past

When you create a new image, you start with a background layer. I usually never want to do anything with this layer – except for maybe give it one opaque color covering the entire thing. I always apply details on different layers, because I never know if I want to reorder anything later on. I also like to configure a grid to match my tile size immediately – always showing the grid, and zooming in as far as 1600%.

Step 0:

We will create tiles that are 16×16 large. The wall tiles will for practical reasons be made in groups of 8, so create a new image that is at least 48×48 pixels large. Set grid size to 16×16, and turn on the grid. You should now have a blank image, with grids showing the 16×16 borders clearly to you.

Step 1:

Create a new layer, name it ‘step 1′. Make the changes on the new layer.

Give the corner tiles one straight line from the center and to the edge – create four squares within eachother. Note that the squares have different spacing – this is to add to the illusion of depth. Leave the square of 16×16 in the center empty.

Step 2:

Create a new layer, name it ‘step 2′. Make the changes on the new layer.

It’s time to add the space between the bricks. On the corner-tiles, it should move slightly towards the corner itself – on the top/bottom/left/right tiles, they should always be straight.

Step 3:

Create a new layer, name it ‘step 3′. Set its opacity to something low, like 25%. Even though the picture make it look like we’re drawing with grey – we’re still using solid black as the color. Make the changes on the new layer.

It is time to draw some cracks in the bricks. The purpose are to give the players some illusion about how great you are. The cracks are just semi-random shapes on each brick. If the shape can start from an adjent brick-space, it may add some appeal.

Step 4:

Create a new layer, name it ‘step 4′. Make sure that it’s ordered to be between the background and ‘step 1′. Fill everything, except for the middle 16×16 with a color of your choice. I’ve used red.

Step 5:

Adjust the opacity of ‘step 1′ and ‘step 2′ according to taste. I’ve set my ‘step 1′ to 70%, and ‘step 2′ to 65%.

Step 6:

Create a new layer, name it ‘step 6′. Make the changes on the new layer.

Create a solid black square, partially covering the brick wall. I’m covering 7 pixels in on my tiles here.

Step 7:

Adjust the opacity of ‘step 6′ to 30%. Look! We have shadow!

Step 8:

Repeat step 6/7 with a slightly smaller square.

If you’ve followed my instructions, you have a set of tiles that points inward in a room. You still lack the tiles pointing outward – but these steps can be repeated. All you have to do different, is to reverse the two techniques that achieve the illusion of perspective, which I explained early in this tutorial.

The layer composition should be something along these lines;

Posted in Game development, Graphics | Leave a comment