Packing Sprites into a Texture Atlas in MonoGame

While building Vulcard for the Game Programming Lab at ETH Zurich, we accumulated dozens of individual sprite PNGs for icons and UI elements. Loading each as a separate texture works fine early on. It’s not how you want to ship, though. Every SpriteBatch.Draw call that switches textures flushes the GPU batch, and 60 sprites can easily mean 60 separate draw calls per frame. The fix is a texture atlas: one large texture containing everything, so the batch stays intact.

We have already been using MLEM which supports spritesheets in the form of its DataTextureAtlas. However, images have to be manually merged into a single file and documented in a .atlas metadata file. To automate this process I built Vulcard.AtlasPacker, a content pipeline extension that reads a plain-text .atlaspack file and produces a packed texture plus the companion .atlas metadata file at content build time.

This post walks through installation, the manifest format, processor options, and how to load the result at runtime using MLEM’s DataTextureAtlas.

Formally Verified ASN.1 Encoders and Decoders

When a satellite sends telemetry data to a ground station, both sides need to agree on exactly how that data is structured in binary. The same goes for network protocols, aircraft systems, and anything else where machines exchange precisely formatted messages. Get the encoding wrong and you get garbage. Get the decoding wrong and you may silently recover incorrect data.

Bundling a Game Made with MonoGame

While developing Vulcard for this year’s iteration of the Game Programming Lab at ETH Zurich, we wanted to integrate the Steam API and package the game for multiple platforms. This process came with a few unexpected hurdles.

In this post, I’ll walk through the complete solution we ended up using. If you’re looking to publish a MonoGame project on Steam, this might save you some time.

Loading Sass files with Lit

Like Polymer before, Lit-Element uses javascript or typescript files for code, templates and styles by default, to enable the use of javascript variables. While this may be useful in some cases, personally I prefer having my style definitions in separate files mainly to benefit from Sass, but also the added benefit of editor assistance like highlighting and autocompletion. Fortunately this can be changed with a bundler like Webpack.

Some technical information about the Polyring widget

As those following the news about the Polyring may have read on xyquadrat, our widget can now be styled with themes. For those interested about the inner workings I will provide some technical information here.

The component makes heavy use of css variables alongside the attribute theme, which can be set on the component. Let’s walk through the needed setup, which consists of both javascript code and css descriptions.