Thursday, May 7, 2015

Wolfenstein: The Old Blood

In case you missed New Order, a prequel called The Old Blood is now available. Check it out!

Wednesday, February 19, 2014

Wolfenstein: The New Order

Long time since last post. Here is the trailer of the game I'm currently working on.

Edit: Trailer removed.

Thursday, December 27, 2012

Server down

All download links are broken until the server machine is fixed.

Tuesday, October 30, 2012


Flipcode is back and alive! It used to be my favorite web site for game development and programming in general. Let's hope it gets a little more activity.

Friday, May 18, 2012

New music pack for PSP Legacy

Antonio Aiello sent me a new music pack for PSP Legacy. It includes music for all versions of DOOM but there are no music for Heretic. You get to decide for yourself which sound you prefer. I've added a download link to the original post which can be found here.

Try it out! And big thanks to Antonio for creating this.

Saturday, March 10, 2012

aamp (An Accurate Module Player)

So I finally pull my thumb out and release my old module player. There is certainly code left from 10 years ago, but most were rewritten during the summer of 2004 and 2005. But it isn't until now I've made a decent command-line interface for it.

It should have quite accurate .XM (FastTracker 2) and .S3M (ScreamTracker 3) playback, better than most other players and libraries out there. Support for .MOD and .MTM modules is there, but not to the same degree of accuracy because of all different trackers available for MOD. I've spent quite a lot of time fixing bugs and comparing against other players. XMPlay would be the most accurate I've tried, but hopefully mine isn't too bad either. Anyway, if you find any bugs just let me know and I will happily fix them.
  For now just a Windows executable, but compiling for Linux and other platforms should be fairly trivial (I've had it working on Linux before). I'm also planing a mobile version.

aamp v1.0 - 32-bit x86 for Windows
aamp v1.0 - 64-bit x86-64 for Windows

7 April: Recompiled x86 and x86-64 executables.

Sunday, October 9, 2011


So the game I've been working on for the past three years recently got announced. It's a reboot of the Syndicate series developed by Starbreeze and published by EA. I'm currently working as a graphics programmer on this project. Check out the announcement trailer below.

Monday, June 6, 2011


I have become more and more eager to code something for Android recently. I'm thinking of porting my old XM / S3M / MTM / MOD replayer. I have spent quite some time on making sure that the XM and S3M playback is accurate. From my internal tests it does better than most other players, even better than XMPlay on some tests (and worse on others).

Sadly, I do not have much time right now. But soonish I hope..

Saturday, February 26, 2011

PSP Legacy Release 4

DOOM Legacy is a source port of the original DOOM for PC, which plays DOOM, DOOM 2, Final DOOM, and Heretic. PSP Legacy is DOOM Legacy for the PSP, which was ported by kgsws and later updated by Duke. I've made some additional changes for things that annoyed me when playing.Change log:
  • Fixed auto map rendering. Toggle with START button. You can zoom in by holding and zoom out by holding .
  • DOOM 1 - E3M1 no longer has clipped geometry and sprites in the beginning (bug in GU hardware renderer).
  • DOOM 2 - MAP01 no longer has invisible walls and flats (BSP precision issue).
  • Stick input is now analog and not digital. Added sensitivity controllers for both X and Y.
  • Increased the number of sound channels from 16 to 24.
  • Optimized sound mixing code.

  • Standby will most likely crash the game (not related to my changes).
  • Some levels have rendering errors (holes in floors and walls), but these are also found in the PC version of DOOM Legacy and has nothing to do with this port.

PSP Legacy R4, 1.8 MB
PSP Legacy R4.01 update by Six-Shoota, 2.3 MB
PSP Legacy Music Pack by Duke, 263 MB
PSP Legacy Music Pack by Antonio Aiello (no Heretic), 91 MB

Thursday, January 27, 2011

Sony NGP

Sony NGP, the successor to the PlayStation Portable, was announced a few days ago. As a big fan of handheld gaming, I can not wait to play WipEout with 60 frames per second and the PS3-like graphics.

Early rumors said that it might have a Cell processor with four SPUs. Now we know it has a quad-core ARMv7 processor. I had some hopes for a less mainstream processor, but in the end I think it was a good choice. A Cell processor is a beast to program and would have made things difficult for the homebrew community. I really hope to see some emulators for the NGP that weren't possible on the previous generation (like CPS3, Dreamcast and PS2) and an ARM will make that much more likely than a Cell would.

I also think there is too much focus on hardware these days. For power efficiency, I think it's equally important to optimize the software as it is to optimize the hardware. Today's smartphones are ridiculously inefficient and have big trouble scrolling a user interface smoothly on a 1 GHz processor + GPU. I have seen far more impressive things on the Amiga. The NGP will have a huge software advantage over smartphones. Java-free, low-level APIs and the proper use of SIMD instructions will make it perform much better per Watt.

Thursday, August 5, 2010

SSAO and Gamma Correction

SSAO is a really popular technique these days. Before SSAO there were parallax mapping and lens flares. One thing that bugs me when it comes to the majority of SSAO screenshots is that most of them seems to have wrong gamma curve.

A typical SSAO buffer contains linear values from 0 to 1. Since the buffer is linear it will tend to look harsh or too dark when displayed on a regular PC monitor. The standard gamma for PC is around 2.2, so the next time you're posting screenshots of your SSAO algorithm, please correct the image with pow(Pixel, 1/2.2) first. :)

I might as well post an image of my SSAO implementation (quite old now). 16 samples distributed randomly in a hemisphere. With a non-fancy box filter. And gamma corrected.

Saturday, July 31, 2010


So my four weeks of vacation are now over. The only computer I had access to during the vacation was my 10 inch netbook, Samsung NC10. Not very big or powerful, yet pleasing enough. One evening I was in the mood for pushing some pixels. So I went to google to find a minimalistic library to help me setup a framebuffer. For some unknown reason I chose TinyPTC over PixelToaster. With a framebuffer in my hands I could now freely push as many pixels as I wanted to, but I still didn't know exactly what I wanted to achieve.

Anyway, this is what it eventually became; a DOOM map renderer. It doesn't implement all features, but it were never meant to either! Most noticeable is that wall textures not are aligned properly, but that shouldn't take too long to fix. Other missing features includes transparent walls and sprites.

At first I did my own map format but that turned out to be way overambitious, after all, it was my vacation.

It think the biggest misconception regarding DOOM is that it uses raycasting, much like Wolfenstein 3D does. So let me clarify that; DOOM, DOES NOT USE RAYCASTING! It could have cast rays in the BSP and do some kind of line intersection test, but that would have been both slower and inaccurate. Secondly, there is no point in doing so because the BSP already gives you front-to-back rendering with zero overdraw (not counting transparent walls and sprites). As I said DOOM uses a 2-dimensional BSP tree for rendering, so any kind of animation in the third dimension is possible. That is how lifts and doors works, by altering the floor or ceiling height.

In my implementation walls are drawn as 3-dimensional polygons with perspective correction for every column, in other words, any vertical wall slice have constant Z and thus, very fast to rasterize. The same applies for floors and ceilings but horizontally instead. Floors and ceilings are basically marked in screen space as gaps between walls and later rendered as horizontal runs.

In the screenshot, wall textures was stored row-by-row which implies one extra multiplication and addition in the inner loop, now these are gone and the FPS should be a bit higher.

Over and out.

Thursday, January 28, 2010


Been busy with work and such lately, but I have done some experiments with fog volumes (i.e. volumetric fog). Looks promising, will post about that later on.

Friday, January 15, 2010

True-Type Fonts

I've added support for true-type fonts using stb_truetype, a minimalistic public domain library written by Sean Barrett. While working it's still an early implementation so some polish still needs to be done. The code for loading and raster glyphs is really small and simple. However, as you can see the anti-aliasing doesn't look very good. Could be a problem on my side so I'm gonna look into it sometime. I've a also done a fairly sophisticated font cache where glyphs are more or less optimally packed when needed.

On the subject of public domain libraries I can also recommend stb_image for loading bmp, tga, png, jpeg without zlib and stb_vorbis for ogg vorbis.

Saturday, January 9, 2010

Content Pipeline

The content/data pipeline in my engine is pretty simple and fast. Two main data folders exists, one for raw data (intermediate) and one for pre-processed data (build). Raw data would be .tga, .png, .fbx and so on and pre-processed data is in a engine specific format.

The tool for pre-processing data from intermediate to build is called jdpp (jmb data pre-processor). jdpp can be executed on specific file or directory. Typically when you sync data you have to run a batch file which executes jdpp and updates the build folder.

When the editor is running a background thread is constantly monitoring the intermediate folder for changes and any change will automatically be reflected in the build folder. For instance, any resource file (model, texture) that is saved it will automatically reloaded in the editor.

In my first attempt each resource type had it's own pre-processor exe but it turned out to be horribly slow to execute an exe 10 000 times. I gained a lot of speed simply by having one master pre-processor exe (jdpp).

Yesterday I also added support for utilizing all CPU cores when processing data. I even gained about 30-40% speed on my single core hyper-threaded netbook. I guess mainly because there are a lot of I/O blocking going on...

Friday, January 8, 2010

Slim your loops

The most common way to write for loops in C++ would probably be

for (int i = 0; i < size(); i++)

Since size() is a function call here one may want to store the value of size() in a variable before entering the loop. If the iteration order is not important you can do it this way

for (int i = size() - 1; i >= 0; i--)

This however look less clean and is longer to write. Now there is an old less common variant of the above line which does exactly the same

for (int i = size(); i--;)

Faster to write and the compiler outputs less assembly code. So this would actually be faster to write and execute faster, in raw execution cycles that is. It might affect the data cache in a negative way on non-x86 platforms, maybe I should check that before posting.