A profiler session running on a monitor at a studio bench, seen over a shoulder in morning light

Workstation 08:00 / White-cut proof

The Windows stack, ready for the workbench

Leave the manual open on the workbench

Windows is our home platform. Every game we ship and every application we build runs on it, and the pieces below are the ones we actually reach for when we build. Not a list of logos — a working stack, what each part is for, and where it stops being worth the effort.

Send us a project brief See how we run an engagement

DirectX 12, DirectStorage and the rest of the Windows stack

The order below follows a build, not a marketing diagram: the rendering layer, then streaming, then input, then the tooling that makes all three legible under a profiler. Read it as a manifest for a Windows project.

Rendering: DirectX 12
Streaming: DirectStorage
Input: GameInput
Applications: .NET, C# and MonoGame

The stack, row by row

What it is / how we use it

DX12 Rendering layer Low-level graphics, paired with C++ and the platform profiler — custom engines and engine-integrated renderer work. Frame budget
DS Asset streaming DirectStorage for large-world and asset-heavy projects — a change in what a level can be, not just how fast it loads. Streaming
GIn Input runtime GameInput 3.2.134.0 with device registry mappings — the difference between a finished-looking game and a finished one. Reliability
C++ Compiler, linker, debugger, profiler Platform tools first, because they see what the operating system sees. Measurement
.NET C#, MonoGame, applications One toolchain for desktop apps and lightweight engine-style projects on the same pipeline. Applications
PT PowerToys and daily friction Command palette and workspace tooling. Trivial per keystroke; the hours come back over a production schedule. Daily ops

How we build it

Four moves, in order, every Windows project

We open with a white-cut proof of the scene, then narrow the frame: each stage only goes as deep as the frame budget asks. Nothing here is a checklist for its own sake — every move answers a measurement.

Render

Draw it once, honestly

Start with engine defaults. Reach into DirectX 12 only when a technique the engine does not expose, a submission pattern that costs more than the scene can afford, or memory behaviour that shows up in a long session but not in a benchmark forces the decision.
Stream

Plan the world before you build it

DirectStorage is a design decision. A door that used to be a load screen can become a corridor, and that changes level layout, art direction and pacing — so the streaming plan is settled before the level is blocked out, not after.
Input

Give input its own milestone

GameInput earns a line in the plan. The failure mode it prevents is the one players write forum posts about: a controller that works for most people and not for them. It is not exciting, and it is the difference between a finished-looking game and a finished one.
Profile

Make the argument shorter

We profile with the tools that came with the platform before reaching for anything third-party, because they see what the operating system sees. A profiling culture changes the type of argument a team has: instead of opinions about what is slow, there are measurements.

How we build it

Four moves, in order

Each stage only goes as deep as the frame budget asks. Nothing here is a checklist for its own sake — every move answers a measurement.

Render

Draw it once, honestly

Start with engine defaults, reach into DirectX 12 only where the frame budget or a memory behaviour forces it.
Stream

Plan the world before you build it

DirectStorage changes design — a door can become a corridor. Settle the streaming plan before blockout.
Input

Give input its own milestone

GameInput earns a line in the plan. The failure mode players complain about online is exactly what it prevents.
Profile

Make the argument shorter

Platform tools first, because they see what the operating system sees. Measurements replace opinions.

When to optimize at the API level

Going low-level is a decision about your frame budget

Engine defaults are engineered for a broad range of projects, and they are usually good. The cases where we go lower are specific and narrow.

1
A rendering technique the engine does not expose through any public path.
2
A submission pattern that costs more than the scene can afford on the frame.
3
Memory behaviour that shows up in a long session and not in a short benchmark.

If the frame budget is comfortable and the art direction is served, going low-level is an expense without a return. We would rather say that plainly than bill for it.

Copied to notes as plain text

Save this line

The rendering layer

DirectX 12 and the frame you actually ship

Microsoft lists DirectX 12 as a core technology for games and immersive experiences on Windows, used for advanced graphics performance and rendering quality. It is commonly paired with C++ and profiling tools, which is exactly how we use it.

The API is relevant to both custom engines and engine-integrated low-level rendering work, which means the same knowledge applies whether we are writing the renderer or fixing one. The decision to work at that level is a decision about your frame budget, not about prestige.

DirectStorage

A change in what a level can be

Microsoft highlighted new DirectStorage capability updates in its 2026 game-development notes. The technology is designed to improve asset streaming and loading performance and forms part of the Windows performance stack for PC games.

The practical effect for large-world and asset-heavy projects is a change in what a level can be, not just how fast it loads. A door that used to be a load screen can become a corridor. That is a design gain as much as a technical one, and it has to be planned early.

GameInput

The difference between a finished-looking game and a finished one

Microsoft released GameInput version 3.2.134.0 in its 2026 notes, with device registry mappings and stability improvements among the changes. It is part of the Microsoft gaming runtime and tooling ecosystem.

On PC the failure mode it prevents is the one players write forum posts about: a controller that works for most people and not for them. Input reliability deserves a milestone of its own in a project plan. It is not exciting, and it is what finishes a game.

Applications and .NET

When your product is not a game, but has real-time needs

.NET, C# and the application side

The same toolchain, a different product

Not everything we build is a game. Windows applications built on modern .NET share most of the toolchain with game work: the build pipeline, the asset handling, the profiling habits. The people who ship one can ship the other without learning a new room.

Teams often ask whether a desktop framework or a game engine is the right base for a product that is not a game but has real-time needs. That is a fair question, and the answer usually turns on how much scene-based content the application has and how many traditional UI components it needs.

MonoGame

The .NET game-development option

Microsoft lists MonoGame among current .NET game-development options. It is an open-source framework for 2D and 3D game development, built around flexible C#-based workflows, and it is frequently chosen for lightweight, custom-engine-style projects. For a team already comfortable in C#, it removes an entire language and toolchain from the learning curve. We use it where it fits, and say so where it does not.

PowerToys

Developer productivity, which compounds

PowerToys appears in Microsoft's 2026 Windows game-development workflow guidance, aimed at speeding access to command palette and workspace tools and reducing friction in daily developer operations. It sounds trivial. Over a year it is not. A team that saves a few minutes per task across a production schedule gets those hours back for work that shows up in the game, and in a small studio that is a real budget line. We standardise on a modest set of these tools rather than collecting them.

Putting the stack together

One build pipeline a team can actually run

The pieces are only useful as a whole: rendering, streaming, input, tooling and profiling in one build pipeline that a team can run. We set that up so that a new engineer can be productive in days, and so that a build produced today can be reproduced months from now.

Reproducible

A build you can re-run

The toolchain is pinned and documented so today's build carries forward.

Onboarding

Days, not weeks

A new engineer gets builds, profiling targets and debug symbols working in their first week.

Where we stop

Engine defaults, unless a measurement says otherwise

We would rather ship the project on the defaults it already runs well on than bill hours for a guarantee the frame budget never needed.

Send us a project brief Read about our engines work See how we run an engagement