Hello! I'm Baldur Karlsson.

I've worked for four years as a graphics programmer, five years in total

I'm a Graphics Programmer with about 4 years of experience in graphics, 5 years experience total. I've worked at Crytek UK (recently reformed as Deep Silver Dambuster Studios) since 2010, shipping several titles and working on CryENGINE generally. I have professional development experience on PC, PS4/XONE and X360/PS3.

I work primarily in C and C++ but I also have some experience with other languages including C#, PHP, Ruby, Lua and Python.

Professionally I've worked on rendering and graphics, covering everything from shading and rendering techniques to renderer internals. Mostly I've worked on the back-end side by writing and supporting the systems code, more than I have on shading and visual effects. I've also had quite some experience writing tools while working on my side project RenderDoc, detailed below.

Here's how to contact me:

Email: baldurk@baldurk.org
LinkedIn: LinkedIn
Twitter: @baldurk
Skype: baldurk

RenderDoc has been my hobby project for over 2 years. I started it at the end of June 2012, originally motivated by difficulty getting existing debuggers to work during the development of Crysis 3. Since release it has met with appreciation from hobbyist and professional developers alike from across the world.

I've worked continuously to improve support for RenderDoc and fix bugs as they have been reported, as well as adding new features and improvements to bring RenderDoc up to be a competitive tool.

In working on RenderDoc I've put the needs and wishes of its users first and aimed to create a tool that is easy to pick up and use without difficulty, putting emphasis on making it - as much as is feasible given the complexity of graphics work - intuitive and easy to use.

RenderDoc is a graphics debugger I've written in my spare time, currently supporting D3D11 & OpenGL

Project highlights:

• The project started at home in June 2012.
• With Crytek's blessing, it was released to the public in February 2014, and the source code was published to github in May of that year.
• It is used by many professional studios and hobby developers across the globe.
• Full support for D3D11 and in progress support for OpenGL, with further support for new APIs like AMD's Mantle and D3D12 coming also.
• I've learned a lot about UI design and how to write a tool that is user-focussed.

I was hired at Crytek UK just as Crysis 2 was finishing and moving towards Beta and Gold, and I was dropped in at the deep end on that project. From there I worked with the rest of the Crytek UK R&D team and the R&D team in Frankfurt on the engine and in particular the renderer.

I've worked on most areas of the CryENGINE renderer at some stage or another - mostly working on the back-end supporting, maintaining and driving forward the underlying systems used to render the scenes and graphics techniques. I worked on CryENGINE across all PC and Console platforms: Windows, Linux, OS X, X360/PS3 and PS4/XONE.

In particular, in 2011 I took over ownership of the shader system within the renderer from the previous programmer responsible. The shader system handles parsing shaders, managing permutations/combinations of uber shaders, compiling and loading the binary blobs, reflection, and auto-binding of textures and management of constants.

My work on it has been maintenance and bugfixing in large part as it is a large and complex system, but I've also driven and handled improvements and cleanups of the code to ease the life of shader authors and improve workflows, to allow new features. Most recently I improved the build times of pre-generated shader caches by more than an order of magnitude, which significantly aided turn-around times on builds and common shader changes.

CryENGINE is Crytek's engine behind the Crysis series, Ryse, Homefront 2 and many external titles

Project highlights:

• I was hired as a graphics programmer in late 2010 and I worked on the CryENGINE renderer for the remainder of my time at Crytek.
• From 2011 I was solely responsible for the shader subsystem within the renderer, covering everything from shader loading & parsing to resource auto-binding and constant management.
• At Crytek I worked with the main engine team in Frankfurt on future improvements to the engine.
• I also contributed to other areas of the renderer such as instancing, LOD transitions, dynamic framebuffer resolution.
• With the rest of the team I helped maintain and improve the underlying systems behind the look of the games.

Homefront 2 is a sequel to Homefront developed by Deep Silver Dambusters Studios. It is set to come out on Windows, OS X, Linux, Playstation 4 and Xbox One.

I worked on the renderer for this game as with my previous work on CryENGINE. Homefront 2 had many new requirements for the renderer, necessitating support and feature work from the whole UK R&D team. I worked with the rest of the rendering team to implement these new features and maintain the existing renderer tech as it was applied in an open world setting.

While working on this title I also had the chance to make some larger structural improvements to the renderer and shader system that I had previously been working on, including removing a lot of legacy code and updating rendering paths that could be refactored to take advantage of modern graphics APIs and hardware.

In particular while working on the Linux and OS X ports I implemented a change to the renderer to output correct authored GLSL from the shaders, which had significant benefits compared to the previous method using HLSLcc to convert shaders at a bytecode level.

Homefront 2 is an open-world FPS sequel to Homefront

Project highlights:

• As well as prior general CryENGINE support for the project, I moved full-time onto Homefront 2 after the end of Crysis 3 development in mid 2013.
• I worked with the UK R&D team to implement new features and rendering techniques used in Homefront 2.
• We worked with Tech Art to define the look of the game and the necessary rendering support, and implemented new functionality to define the look of Homefront 2.
• I spent some time working on the Linux and OS X ports of the engine, together with the programmers who had already been implementing that support in the main CryENGINE branch.

I joined Crytek UK as Crysis 2 was entering final bugfixing stage. This was rather a baptism of fire as I was dropped into the deep end to fix any bugs I was able while still trying to learn the codebase.

After Crysis 2 completed, development shifted to the PS3/360 port of Crysis 1 - which had been underway for some time (primarily focussed on memory optimisation to fit into memory on those consoles) but was suspended before I joined to focus on finishing Crysis 2. I was the primary rendering support for a few months until the team grew towards alpha, and helped fix rendering bugs and tweak and tune the LOD transitions and vegetation sprite baking that was very necessary for the foliage-dense game.

On Crysis 3 I was present throughout the whole development, and here I was the contact for shader system support during the game's development. I focussed on fixing long-standing bugs and workflow issues that were blocking people - in particular several issues that were found and raised during development of Crysis 2's DX11 upgrade patch.

The Crysis series is a sci-fi FPS series based around a super-powered Nanosuit

Project highlights:

• While working on Crysis 2 I learned my way around the renderer with the help of the R&D teams in UK and Frankfurt.
• I also contributed to the latter part of development of Crysis 1 for PS3/360, and worked on Crysis 3 from start to finish.
• On Crysis 1 I worked to update and fix rendering issues that came up within the last few months of development before alpha, in particular helping with fine-tuning LOD transitions and vegetation sprite baking.
• In the latter half of Crysis 3 as the UK studio was split between early work on Homefront 2 and Crysis 3, I was on the team that did final bugfixing as the game went to gold.
• On Crysis 3 I pushed for whitelisting of console variables as the community for any Crytek game is known to want to fine-tune and tweak, and I wrote a small tool to help expose these variables that was well received by the community.

The Shoot is a game developed by Cohort Studios for SCEE's Liverpool studio, as a launch title for Sony's Playstation Move motion controller. Developed entirely using Cohort Studios' internal technology Praetorian Tech.

After finishing on the Buzz Junior games, I worked for a brief time on The Shoot aiding in bugfixing and design support. After this stint on The Shoot I moved onto some internal prototypes, experimenting with gameplay systems and new technologies.

Initially the prototypes were a cut-down fork of the Shoot codebase. As development began to diverge it was clear that the stability Shoot required was not compatible with a rapidly developing prototype. For this reason we separated the common code into two different parallel development paths.

As work continued on the prototypes, we were free to develop while still porting changes from Shoot's codebase and backporting bugfixes to ensure that the common framework stayed as close as was possible. I also switched back to The Shoot as necessary to aid in bug searching and squashing, particularly surrounding my implementation of the game's movie playback.

The Shoot is a fast action shooter based around Motion Control with the Playstation Move

Project highlights:

• I worked on The Shoot primarily for engine support.
• The Shoot's development ran mostly in parallel with the prototypes.
• I was involved in setting up parallel development repositories to allow bidirection integration of code, while maintaining a separate codebase for the prototypes.
• I was solely responsible for the encoding to a compatible format and integration of video playback into the game, including intro and front end movies.
• The movie playback involved refinement and bugfixing in a movie player I wrote to use Sony's internal playback libraries for the earlier Buzz projects.

The Playstation Network Buzz Junior games were entirely re-created games with an emphasis on properly updating the game rather than simply up-resing textures. Five minigames were selected from the original game's lineup and using Cohort Studios' Praetorian Tech they were re-implemented in a downloadable game.

Cohort Studios worked on three of the Buzz games - Robo Jam, Monster Rumble and Dino Den. Of these, only Dino Den had been originally implemented by Cohort on the Playstation 2.

I joined the team immediately after graduating, and I went immediately into the Beta period of Monster Rumble. This was my first experience with the Praetorian Tech so there was a great deal to learn in a short period of time. I worked on the Buzz games for a total of about 4 months - they were quite short term and small team projects. Following these I spent a brief time with the Shoot team, before moving on to internal prototyping work.

When it came time to begin work on Dino Den, I laid the groundwork by forking the Monster Rumble code and removing any specific assets. Working on Dino Den was interesting since I was one of the few people on the project who had worked on the original Playstation 2 version.

The PSN Buzz Junior games were mini ports of 5 minigames from the PS2 children's titles

Project highlights:

• The Buzz games were the first chance I had to use internal tech, and I learned the organisation and design from a client project point of view - no deep engine internals.
• On Dino Den, I wrote a movie player that utilised Sony's internal movie playback libraries, and provided a high-level wrapper library.
• I was solely responsible for the encoding to a compatible format and integration of video playback into the game, including intro and tutorial movies.
• With the design of the game easily segmentable, I took total responsibility for the coding of two of the minigames.

The Playstation 2 Buzz Junior games were new entries in the series of children's games. The games were the first projects I worked on at Cohort Studios, in my two internships I spent there, during the Summers of 2007 and 2008.

When I started at Cohort Studios in the Summer of 2007, I was immediately engaged in the development of Dino Den. I spent the first month doing bugfixing and general tasks so that I could gain familiarity with the codebase as well as gaining comfort within the company.

Shortly after, I began to work on a single minigame as the sole programmer, writing the whole of a game and having some definite ownership over one part of the game. Dino Den was my first shipped title, and it meant a great deal to me.

The next summer, in 2008, I worked on Ace Racers, an additional game in the series. In this case, with my familiarity with both the engine and the company I was able to immediately jump into the thick of things and contribute.

The Buzz Junior games were collections of minigames utilising the Buzz controllers, and aimed at children.

Project highlights:

• I learned to work with source control in a large team.
• With Magenta's engine, I learned to use unfamiliar code and to liaise with external teams over support.
• When working on a minigame as the sole coder, I learned basic time management and estimation, as well as higher-level code organisation within a large codebase.
• Balancing the AI settings across all minigames, I gained experience working closely with design and QA, and providing and receiving feedback.
• I also gained the valuable experience of shipping a game from fairly early development to master submission, and the process that a game goes through.