Forem: Roman Shapiro

Content Pipeline in MonoGame: Why I Don't Use It

Roman Shapiro — Tue, 26 May 2026 02:42:17 +0000

Introduction

The Content Pipeline is the official way to handle assets in MonoGame. However, there has long been a significant group of developers in the community who dislike it and prefer to load assets in their "raw" form. This approach is especially popular in the FNA community (another XNA 4 implementation) — almost everyone there uses it.

I’ve also been part of this "party" for a long time, and in this article I’ll explain why.

First, let’s go over the real advantages of the Content Pipeline, then its main drawback, and finally — what practical alternatives exist.

Advantages of the Content Pipeline

1. Loading Speed

Assets processed through the Content Pipeline are saved in an optimized binary format (.xnb). They have already undergone all necessary transformations (for example, premultiplied alpha for textures), so they load very quickly.

However, for most indie projects, this advantage is greatly overrated. On modern hardware, even large sets of assets load almost instantly — with or without processing.

Moreover, if you need maximum speed, you can simply pre-convert textures to modern formats (DDS, KTX, Basis Universal) using ImageMagick or other tools.

2. Asset Protection

Some developers consider it important to make assets harder to steal. In this regard, XNB files are indeed slightly better than regular PNG or WAV files.

But let’s be honest: with minimal programming skills, extracting assets from .xnb is quite easy.

Furthermore, strong asset protection has a downside — the more you "protect" them, the harder it becomes for players to create mods.

3. Platform Optimization

The Content Pipeline automatically selects the optimal compression format for the target platform (e.g., DXT, PVRTC, ETC, etc. for images). This point is genuinely useful, and it’s hard to argue against it.

The Main Disadvantage

Despite all the advantages, the built-in capabilities of the Content Pipeline are usually insufficient even for simple games. For example, it has no built-in support for texture atlases.

Hence most likely you'll have to add support for a new asset type. And to do so you'll have to create a full pipeline:

Importer — loads the asset into an internal object
Processor — processes it (premultiply, compression, etc.)
Writer — saves it to .xnb format
Reader — loads it from .xnb

Because of this, the amount of code and overall complexity increases dramatically. When loading assets in raw form, steps 3 and 4 are simply unnecessary. Less code means fewer bugs, easier maintenance, and faster development.

Separately, it’s worth mentioning debugging your own pipelines — it used to be a real quest (at least it was several years ago when I tried it).

Alternatives

Fortunately, MonoGame allows you to load assets without the Content Pipeline:

Texture2D.FromStream() — for images
SoundEffect.FromStream() — for sounds
Effect — has a construcotr that accepts a shader compiled via mgfxc (fxc for FNA)
SpriteFont — has a constructor that accepts a texture atlas and glyph data. In FNA, this constructor is available via reflection.

Based on this, it’s easy to write your own asset loader.

Over the years, I’ve also written and actively maintain several libraries specifically for this approach:

Library	What it does
XNAssets	Universal alternative to the Content Pipeline. Loads textures, sounds, SpriteFonts, and effects from raw files. Easily extensible.
SpriteFontPlus	Creates SpriteFont of the required size and character set from TTF files.
FontStashSharp	Library for rendering text with dynamic atlas, rich text, HarfBuzz, styles, and much more.
DigitalRiseModel	Loads 3D models from glTF/glb + full animation engine.
PlMpegNet	Simple library for loading video.

Links

Opinion from the creator of FNA: The XNA Content Pipeline Is Bad and You Shouldn't Use It

MonoGame - A Game Engine for Those Who Love Reinventing the Wheel

Roman Shapiro — Sat, 23 May 2026 01:12:37 +0000

Introduction

When creating a new game, one of the very first questions is choosing a game engine.

The main candidates everyone knows about are Unity, Unreal Engine, and Godot.

However, besides them, there are quite a few second-tier engines that few people know about.

One of them is MonoGame, which is exactly what I want to talk about in this article. I will briefly go over its history, discuss whether it is worth choosing, and share a couple of useful links.

History

The C# programming language was created by Microsoft in 2002. Microsoft positioned it as a general-purpose language, so they developed a number of technologies and libraries demonstrating its use in different fields.

One of these libraries was XNA, released in 2006. It was based on DirectX 9 and allowed developers to create games for the Microsoft ecosystem of that time, namely Windows, Xbox, and Windows Phone.

XNA immediately gained considerable popularity within the gamedev community, which naturally wanted their games to run on other devices and operating systems as well.

MonoGame was the answer to those demands. It aimed to be fully API-compatible with XNA while also running on Android, iPhone, Linux, and so on.

In 2013, Microsoft discontinued XNA support. As a result, MonoGame eventually had to expand to Microsoft platforms as well.

MonoGame Today

At the moment, MonoGame more or less implements the XNA4 specification.

In other words, it is essentially an abstraction layer over gaming hardware, providing fairly low-level access to graphics, audio, mouse, keyboard, gamepad, and so on.

At the same time, it also contains some higher-level functionality:

A linear algebra and 3D geometry library. Matrices, vectors, rays, transformations, and so on. There are many methods for 3D graphics, such as creating perspective and orthographic projection matrices. There are also bounding boxes, bounding spheres, and much more.
SpriteBatch, or the ultimate tool for working with 2D graphics. In particular, it allows rendering text.
An audio library.
Content Pipeline, a framework for processing assets and converting them into a format suitable for runtime use. It is a fairly controversial feature. Personally, I am not a fan of it and see nothing wrong with loading assets in their raw form.
A simple 3D model library. It has two major problems: a hard dependency on the Content Pipeline (meaning models cannot be created dynamically at runtime through code) and the lack of animation support. That is why I do not use it either.
Several simple shaders for 3D graphics. For example, BasicEffect, which implements lighting using the Blinn-Phong model, and SkinnedEffect, which does the same while supporting skeletal animation. Incidentally, the demo at the beginning of this article is built on top of these shaders. It is worth noting that they only support directional lights. Point lights and spot lights are unfortunately not supported.

Why Choose It?

The meme is almost true. Though it is probably worth clarifying that this mostly applies to very simple 2D games.

In the general case, however, it must be admitted that if maximum development efficiency is your goal, I would recommend using Unity or Unreal.

But if efficiency is not the top priority and you mainly want to enjoy the development process, then MonoGame is worth choosing for several reasons.

First, love for C#. Yes, Unity supports it too, but Unity uses its own framework that traditionally supported older versions of the language and runtime. MonoGame, on the other hand, works on top of the official modern Microsoft .NET ecosystem.

Second, appreciation for open source and permissive licenses.

Third, if you have a certain mindset often described as "think in code." If you dislike the designer-centric approach represented by Unity, Unreal, and Godot, and instead prefer the "bare" game loop approach offered by MonoGame.

Finally, if you enjoy digging into technical details and reinventing the wheel. Yes, there are many libraries built for MonoGame (the author of this article developed some of them). However, you are unlikely to find every piece of functionality your game needs. Most likely, you will either have to create your own libraries or extend existing ones.

Useful Links

Official MonoGame Site

Make sure to visit the Showcase page in order to learn about some well-known titles that were developed with XNA/MonoGame(i.e. Terraria and Stardew Valley)

FNA - Another XNA Implementation