Forem: Melvin Cheah

Build Your First 3D Rotating Cube from Scratch (No Libraries)

Melvin Cheah — Wed, 21 Jan 2026 13:00:00 +0000

Build Your First 3D Rotating Cube from Scratch (No Libraries)

What You'll Build

Want to understand how 3D graphics really work? Most tutorials jump straight
into Three.js or WebGL, but the fundamentals get lost.

By the end of this tutorial, you'll understand the core concepts of 3D graphics by building a rotating cube from scratch using just JavaScript and HTML Canvas -- no Three.js, no WebGL, just pure fundamentals.

You'll learn:

How 3D coordinate systems work
How to convert between coordinate spaces
How rotation matrices transform 3D objects
How perspective projection creates depth

Prerequisites: Basic JavaScript knowledge. That's it!
Time needed: 30-45 minutes
Let's dive in!

Step 1: Draw a square

Open your favourite IDE. I use visual studio code in this case.
Create a file name index.html and write these codes.

<canvas id="canvas"></canvas>
<script src="cube.js"></script>

We have defined a canvas element and a script element. The canvas element is where we will draw the Cube. We will load the file cube.js using the script element.

Then create a another new file name cube.js
Then initialize multiple variable

const BACKGROUND = "#404040"
const FOREGROUND = "#FF5050"
canvas.width = 800;
canvas.height = 800

const ctx = canvas.getContext("2d");

We have created a grey background color and a orange foreground color for the cube . Then change the canvas's width and height to 800px. Then declare the canvas context.

function clear(){
    ctx.fillStyle=BACKGROUND
    ctx.fillRect(0,0,canvas.width,canvas.height);
}
clear()

create a new function call clear(). This is use to fill up the background with gray color.
Open index.html you should be able to see the following

A blank gray canvas.
Now let's define the vertices we will use for our square

let vertices = [
    {x: 100,y: 100}, // top left
    {x: 400,y: 100}, // top right
    {x: 400,y: 400}, // bottom right
    {x: 100,y: 400}, // bottom left
]

Create a draw line function

function drawLine(p1, p2){
    ctx.strokeStyle = FOREGROUND;
    // ctx.lineWidth = 5.0 // (optional) make the line thicker
    ctx.beginPath();
    ctx.moveTo(p1.x,p1.y);
    ctx.lineTo(p2.x,p2.y);
    ctx.stroke();
}

Then call the drawLine() function

drawLine(vertices[0], vertices[1])
drawLine(vertices[1], vertices[2])
drawLine(vertices[2], vertices[3])
drawLine(vertices[3], vertices[0])

This is what you should see at this point.

Full code until now

const BACKGROUND = "#404040"
const FOREGROUND = "#FF5050"
canvas.width = 800;
canvas.height = 800

const ctx = canvas.getContext("2d");

function clear(){
    ctx.fillStyle=BACKGROUND
    ctx.fillRect(0,0,canvas.width,canvas.height);
}
clear()

let vertices = [
    {x: 100,y: 100}, // top left
    {x: 400,y: 100}, // top right
    {x: 400,y: 400}, // bottom right
    {x: 100,y: 400}, // bottom left
]

function drawLine(p1, p2){
    ctx.strokeStyle = FOREGROUND;
    // ctx.lineWidth = 5.0
    ctx.beginPath();
    ctx.moveTo(p1.x,p1.y);
    ctx.lineTo(p2.x,p2.y);
    ctx.stroke();
}

drawLine(vertices[0], vertices[1])
drawLine(vertices[1], vertices[2])
drawLine(vertices[2], vertices[3])
drawLine(vertices[3], vertices[0])

Step 2: Draw a cube

Now, in order to draw a cube we need to first normalize the coordinate system as JavaScript's canvas use the World coordinate system.

Where 0,0 is the top left corner.
X value increase as you move horizontally to the right.
Y value increase as you move vertically downward.

Because most mathematic formula assumes you are using the Normalized Device Coordinates
We need to change from Normalized Device Coordinates back to World coordinate system.

Normalized Device Coordinates

Where the center is (0, 0)
All axis's value range from -1 to 1

// NDC (-1..1) -> canvas pixels
function normalizeCoordinate(point){
    // translate from -1 .. 1 => 0..2 => 0..w/h
    return {
        x:      (point.x + 1) / 2 * canvas.width,
        y: (1 - (point.y + 1) / 2) * canvas.height,
    }
}

So this function translate normalize coordinate to the coordinates system canvas uses.
Let's break it down.

The goal is translate coordinate with (-1 to 1) to (0,0 to w,h)
Step 1:
point.x + 1
Translate (-1 to 1) to (0 to 2)
Step 2:
(point.x + 1)/2
Translate (0 to 2) to (0 to 1)
Step 3:
(point.x + 1) / 2 * canvas.width
Translate (0 to 1) to (0 to canvas.width)

For the y-axis, canvas coordinates increase downward (opposite of mathematical convention), so we flip it:
(1 - (point.y + 1) / 2)

Then update these code
change from

let vertices = [
    {x: 100,y: 100}, // top left
    {x: 400,y: 100}, // top right
    {x: 400,y: 400}, // bottom right
    {x: 100,y: 400}, // bottom left
]

let vertices = [
    {x:0.5,y:0.5}, // top left
    {x:-0.5,y:0.5}, // top right
    {x:-0.5,y:-0.5}, // bottom right
    {x: 0.5,y:-0.5}, // bottom left
]

change from

drawLine(vertices[0], vertices[1])
drawLine(vertices[1], vertices[2])
drawLine(vertices[2], vertices[3])
drawLine(vertices[3], vertices[0])

drawLine(normalizeCoordinate(vertices[0]), normalizeCoordinate(vertices[1]))
drawLine(normalizeCoordinate(vertices[1]), normalizeCoordinate(vertices[2]))
drawLine(normalizeCoordinate(vertices[2]), normalizeCoordinate(vertices[3]))
drawLine(normalizeCoordinate(vertices[3]), normalizeCoordinate(vertices[0]))

Obvious we should use for loop for these

for (let i = 0; i < vertices.length; ++i){
    drawLine(
        normalizeCoordinate(vertices[i]),
        normalizeCoordinate(vertices[(i+1) % vertices.length])
    )
}

Result:

As you can see, the square move to the center because we use Normalized Device Coordinates and (0,0) is the center of the canvas.

Now add more vertices and change the vertices from 2D to 3D
Change from

    {x:0.5,y:0.5}, // top left
    {x:-0.5,y:0.5}, // top right
    {x:-0.5,y:-0.5}, // bottom right
    {x: 0.5,y:-0.5}, // bottom left

let vertices = [
    {x:0.5,y:0.5,z:0.5},
    {x:-0.5,y:0.5,z:0.5},
    {x:-0.5,y:-0.5,z:0.5},
    {x: 0.5,y:-0.5,z:0.5},

    {x:0.5,y:0.5,z:-0.5},
    {x:-0.5,y:0.5,z:-0.5},
    {x:-0.5,y:-0.5,z:-0.5},
    {x: 0.5,y:-0.5,z:-0.5},
];

Now you have a 3D object, but it still seems 2D

That is why we need to rotate the cube to see all its side

Full code until now:

const BACKGROUND = "#404040"
const FOREGROUND = "#FF5050"
canvas.width = 800;
canvas.height = 800

const ctx = canvas.getContext("2d");

function clear(){
    ctx.fillStyle=BACKGROUND
    ctx.fillRect(0,0,canvas.width,canvas.height);
}
clear()

let vertices = [
    {x:0.5,y:0.5,z:0.5},
    {x:-0.5,y:0.5,z:0.5},
    {x:-0.5,y:-0.5,z:0.5},
    {x: 0.5,y:-0.5,z:0.5},

    {x:0.5,y:0.5,z:-0.5},
    {x:-0.5,y:0.5,z:-0.5},
    {x:-0.5,y:-0.5,z:-0.5},
    {x: 0.5,y:-0.5,z:-0.5},
]

function drawLine(p1, p2){
    ctx.strokeStyle = FOREGROUND;
    // ctx.lineWidth = 5.0
    ctx.beginPath();
    ctx.moveTo(p1.x,p1.y);
    ctx.lineTo(p2.x,p2.y);
    ctx.stroke();
}

// NDC (-1..1) -> canvas pixels
function normalizeCoordinate(point){
    // translate from -1 .. 1 => 0..2 => 0..w/h
    return {
        x: (point.x + 1) / 2 * canvas.width,
        y: (1 - (point.y + 1) / 2) * canvas.height,
    }
}

for (let i = 0; i < vertices.length; ++i){
    drawLine(
        normalizeCoordinate(vertices[i]),
        normalizeCoordinate(vertices[(i+1) % vertices.length])
    )
}

Step 3: Rotate the cube

To rotate a cube or any 3D object you would use these formula

Rotate in Y-axis

Rotate in X-axis

Rotate in Z -axis

In this case, we will try to rotate the cube in Y-axis
Now try to derive x, y, z coordinates from the formula

This is how we derive the rotation function. Add this to the code

function rotateY({x,y,z}, angle){
    return {
        x: x * Math.cos(angle) + z * Math.sin(angle),
        y,
        z: x * -Math.sin(angle) + z * Math.cos(angle),
    }
}

Add vertices indices

let verticeIndexes = [
    [0,1,2,3], // front face 
    [4,5,6,7], // back face 
    [0,1,5,4], // top face 
    [2,3,7,6], // bottom face 
    [0,3,7,4], // right face 
    [1,2,6,5], // left face
]

A cube has 8 vertices/corner and 6 faces. We use vertices index because we can reuse vertex without the need of repeatedly defined the same vertex. This is the standard of all modern graphics API as we can save memory and performance by reducing vertex count.

Then add this new function called frame(). We are going to start animating the rotation.

const FPS = 60
const dt = 1/FPS;
let angle = 0;

function frame(){
    angle += Math.PI * 0.5 * dt; // increment angle in each frame 
    clear()
    // Draw cube
    for (let i = 0; i < vertices.length; ++i){
        drawLine(
            normalizeCoordinate(rotateY(vertices[i], angle)),
            normalizeCoordinate(rotateY(vertices[(i+1) % vertices.length], angle))
        )
    }

    setTimeout(frame, 1000/FPS)
}
frame()

Notice this is a recursion function. setTimeout(frame, 1000/FPS) For every 1000/60 = 16ms 16 milliseconds, the frame function will be called once, making this a loop that will run forever.

Note: We're using setTimeout for simplicity, but for production code, requestAnimationFrame is preferred as it syncs with the browser's refresh rate for smoother animations.

angle += Math.PI * 0.5 * dt;
Notice this line, for every seconds, the cube will rotate 1/4 of a rotation. To make every second 1 rotation, you can use angle += Math.PI * 2 * dt
2π equal 1 rotation.

Result:

Notice the shape of the cube is not exactly correct. I will give you a small challenge here, try find out why the shape of the cube is not correct.
Hint: Look at how we're connecting the vertices. We're just connecting them in sequence (0→1→2→3→4→5→6→7→0), which doesn't actually form a proper cube structure!

Solution:

let vertices = [
    {x:0.5,y:0.5,z:0.5},
    {x:-0.5,y:0.5,z:0.5},
    {x:-0.5,y:-0.5,z:0.5},
    {x: 0.5,y:-0.5,z:0.5},

    {x:0.5,y:0.5,z:-0.5},
    {x:-0.5,y:0.5,z:-0.5},
    {x:-0.5,y:-0.5,z:-0.5},
    {x: 0.5,y:-0.5,z:-0.5},
];

The order of the vertices we previously declare is incorrect. A simple solution is to reorder the vertices. But a more robust solution is to use the verticeIndex we previously created.

Update the frame() function

function frame(){
    angle += Math.PI * 0.5 * dt;
    clear();

    for (const face of verticeIndexes){ // Loop through each face
        for (let i = 0; i < face.length; ++i){ // Loop through vertices in this face
        // Connect vertices to form edges of this face
            const point1 = vertices[face[i]];
            const point2 = vertices[face[(i+1) % face.length] ];

            drawLine(
                normalizeCoordinate(rotateY(point1, angle)),
                normalizeCoordinate(rotateY(point2, angle))
            )
        }
    }
    setTimeout(frame, 1000/FPS)
}

The problem wasn't the vertex positions themselves - it was that we were connecting vertices sequentially (0→1→2→...→7), which creates a tangled mess instead of proper cube faces. By using verticeIndexes, we explicitly define which vertices form each face, giving us proper cube geometry.

Result:

Full code:

const BACKGROUND = "#404040"
const FOREGROUND = "#FF5050"
canvas.width = 800;
canvas.height = 800

const ctx = canvas.getContext("2d");

function clear(){
    ctx.fillStyle=BACKGROUND
    ctx.fillRect(0,0,canvas.width,canvas.height);
}
clear()

let vertices = [
    {x:0.5,y:0.5,z:0.5},
    {x:-0.5,y:0.5,z:0.5},
    {x:-0.5,y:-0.5,z:0.5},
    {x: 0.5,y:-0.5,z:0.5},

    {x:0.5,y:0.5,z:-0.5},
    {x:-0.5,y:0.5,z:-0.5},
    {x:-0.5,y:-0.5,z:-0.5},
    {x: 0.5,y:-0.5,z:-0.5},
]

let verticeIndexes = [
    [0,1,2,3], // front face 
    [4,5,6,7], // back face 
    [0,1,5,4], // top face 
    [2,3,7,6], // bottom face 
    [0,3,7,4], // right face 
    [1,2,6,5], // left face
]

function drawLine(p1, p2){
    ctx.strokeStyle = FOREGROUND;
    // ctx.lineWidth = 5.0
    ctx.beginPath();
    ctx.moveTo(p1.x,p1.y);
    ctx.lineTo(p2.x,p2.y);
    ctx.stroke();
}

// NDC (-1..1) -> canvas pixels
function normalizeCoordinate(point){
    // translate from -1 .. 1 => 0..2 => 0..w/h
    return {
        x: (point.x + 1) / 2 * canvas.width,
        y: (1 - (point.y + 1) / 2) * canvas.height,
    }
}


function rotateY({x,y,z}, angle){
    return {
        x: x * Math.cos(angle) + z * Math.sin(angle),
        y,
        z: x * -Math.sin(angle) + z * Math.cos(angle),
    }
}

const FPS = 60
const dt = 1/FPS;
let angle = 0;

function frame(){
    angle += Math.PI * 0.5 * dt;
    clear();

    for (const face of verticeIndexes){
        for (let i = 0; i < face.length; ++i){
            const point1 = vertices[face[i]];
            const point2 = vertices[face[(i+1) % face.length] ];

            drawLine(
                normalizeCoordinate(perspectiveProject(rotateY(point1, angle))),
                normalizeCoordinate(perspectiveProject(rotateY(point2, angle)))
            )
        }
    }
    setTimeout(frame, 1000/FPS)
}
frame()

Step 4: Apply perspective projection

Now the cube we created is not particularly realistic, it is because it is using orthographic projection implicitly, which means that the object in the distance would not become smaller. To make the object in the distance smaller, we need to apply a perspective projection using these formula.

x = x/z
y = y/z

You are right, just as simple as these 2 lines.
This is because objects farther from the camera (larger z values) should be smaller. Therefore it gets divided by a bigger number, making them smaller on screen. This mimics how our eyes see the world!
Lets implement it.

function perspectiveProject({x,y,z}){
    return {
        x: x/z,
        y: y/z,
    }
}

This function could work, but when z = 0 💥things could go very bad. That is why I opted for this solution.

function perspectiveProject({x,y,z}){
    const eps = 1e-6;
    if (z <= eps){
        return {
            x: x/eps,
            y: y/eps,
        };
    }
    return {
        x: x/z,
        y: y/z,
    }
}

Here we use a very small number eps to prevent division by zero

Finally apply the perspective projection.

function frame(){
    angle += Math.PI * 0.5 * dt;
    clear();

    for (const face of verticeIndexes){
        for (let i = 0; i < face.length; ++i){
            const point1 = vertices[face[i]];
            const point2 = vertices[face[(i+1) % face.length] ];

            drawLine(
                normalizeCoordinate(perspectiveProject(rotateY(point1, angle))),
                normalizeCoordinate(perspectiveProject(rotateY(point2, angle)))
            )
        }
    }
    setTimeout(frame, 1000/FPS)
}
frame()

Result:

You will notice this weird line fly around. This is because the cube is too close to the camera. We need to move the cube further away (translate z).

function translateZ({x,y,z}, dz){
    return {x,y,z: z+dz};
}

Add this translate Z function. Apply to the frame() function

function frame(){
    angle += Math.PI * 0.5 * dt;
    clear();

    for (const face of verticeIndexes){
        for (let i = 0; i < face.length; ++i){
            const point1 = vertices[face[i]];
            const point2 = vertices[face[(i+1) % face.length] ];
            const dz = 2

            drawLine(
                normalizeCoordinate(perspectiveProject(translateZ(rotateY(point1, angle),dz))),
                normalizeCoordinate(perspectiveProject(translateZ(rotateY(point2, angle), dz)))      
            )
        }
    }
    setTimeout(frame, 1000/FPS)
}
frame()

const dz = 2
We translate the cube 2 units away from the camera (at z=0). This ensures
all vertices have positive z values after rotation, preventing division issues
and keeping the cube in front of the camera.

And finally we are done:

Final Code:
👜 https://github.com/Montmont20z/JavaScript-3D-Cube

const BACKGROUND = "#404040"
const FOREGROUND = "#FF5050"
canvas.width = 800;
canvas.height = 800

const ctx = canvas.getContext("2d");

function clear(){
    ctx.fillStyle=BACKGROUND
    ctx.fillRect(0,0,canvas.width,canvas.height);
}
clear()

let vertices = [
    {x:0.5,y:0.5,z:0.5},
    {x:-0.5,y:0.5,z:0.5},
    {x:-0.5,y:-0.5,z:0.5},
    {x: 0.5,y:-0.5,z:0.5},

    {x:0.5,y:0.5,z:-0.5},
    {x:-0.5,y:0.5,z:-0.5},
    {x:-0.5,y:-0.5,z:-0.5},
    {x: 0.5,y:-0.5,z:-0.5},
]

let verticeIndexes = [
    [0,1,2,3], // front face
    [4,5,6,7], // back face
    [0,1,5,4], // top face
    [2,3,7,6], // bottom face
    [0,3,7,4], // right face
    [1,2,6,5], // left face
]

function drawLine(p1, p2){
    ctx.strokeStyle = FOREGROUND;
    // ctx.lineWidth = 5.0
    ctx.beginPath();
    ctx.moveTo(p1.x,p1.y);
    ctx.lineTo(p2.x,p2.y);
    ctx.stroke();
}

// NDC (-1..1) -> canvas pixels
function normalizeCoordinate(point){
    // translate from -1 .. 1 => 0..2 => 0..w/h
    return {
        x: (point.x + 1) / 2 * canvas.width,
        y: (1 - (point.y + 1) / 2) * canvas.height,
    }
}

function perspectiveProject({x,y,z}){
    const eps = 1e-6;
    if (z <= eps){
        return {
            x: x/eps,
            y: y/eps,
        };
    }
    return {
        x: x/z,
        y: y/z,
    }
}

function rotateY({x,y,z}, angle){
    return {
        x: x * Math.cos(angle) + z * Math.sin(angle),
        y,
        z: x * -Math.sin(angle) + z * Math.cos(angle),
    }
}

function translateZ({x,y,z}, dz){
    return {x,y,z: z+dz};
}

const FPS = 60
const dt = 1/FPS;
let angle = 0;

function frame(){
    angle += Math.PI * 0.5 * dt;
    clear();

    for (const face of verticeIndexes){
        for (let i = 0; i < face.length; ++i){
            const point1 = vertices[face[i]];
            const point2 = vertices[face[(i+1) % face.length] ];
            const dz = 2

            drawLine(
                normalizeCoordinate(perspectiveProject(translateZ(rotateY(point1, angle),dz))),
                normalizeCoordinate(perspectiveProject(translateZ(rotateY(point2, angle), dz)))      
            )
        }
    }
    setTimeout(frame, 1000/FPS)
}
frame()

Troubleshooting

Canvas is blank: Make sure you're opening index.html in a browser, not just viewing the file.

"canvas is not defined" error: The canvas variable is automatically created by the browser when you give an element id="canvas". Make sure your HTML has this.

Cube looks distorted: Check that your verticeIndexes array matches the vertex order exactly. The indices must correspond to the correct vertex positions.

Weird flickering lines: This happens when vertices pass through or very close to z=0. Our eps value in perspectiveProject helps prevent this.

What You've Learned

In this tutorial, you've built a 3D rendering engine from scratch and learned

Coordinate Systems: How to convert between different coordinate spaces (NDC vs screen space)
3D Transformations: How rotation matrices transform points in 3D space
Perspective Projection: How dividing by depth (z) creates realistic perspective
Indexed Geometry: Why modern graphics APIs use vertex indices to save memory

These are the same fundamental concepts used in engines like Three.js, Unity, and Unreal Engine!

Where to Go From Here

Want to take this further? Try these challenges:

Add rotation on multiple axes: Combine rotateX, rotateY, and rotateZ
Add More Translation: Translate X, Translate Y, Translate Z
Add camera controls: Let users control the camera with mouse/keyboard

Learning Resources:

WebGL Fundamentals - Deep dive into 3D graphics
3Blue1Brown Linear Algebra - Understanding the math behind transformations
Scratchapixel - 3D rendering from scratch

More Projects Like This

If you enjoyed this tutorial, check out my other 3D graphics projects:

3D-Robot-Model-Renderer - A hierarchical 3D Gundam-style robot model built from scratch using OpenGL Fixed Pipeline and Win32 API
Splash Ground - A fast-paced 3D arena survival / territory-control 3D game

See all my work at https://github.com/Montmont20z

Questions? Suggestions? Let me know in the comments! 👇

I Built a Game Engine from Scratch in C++ (Here's What I Learned)

Melvin Cheah — Wed, 07 Jan 2026 10:49:57 +0000

I Built a Game Engine from Scratch in C++ (Here's What I Learned)

I crashed my GPU 47 times before I saw my first triangle on screen.

For 3 months, I built a game engine from scratch in C++ using DirectX 9 and Win32—no Unity, no Unreal, no middleware. Just me, the Windows API, and a lot of segmentation faults.

This is the story of how building a simple Breakout clone taught me more about game development, graphics programming, and software architecture than years of using Unity ever did.

Why Build an Engine?

For years, I built games in Unity. I'd drag and drop GameObjects, attach scripts, hit Play, and watch my game come to life. It was magical—until it wasn't.

Questions started nagging at me:

How does Unity actually render my sprites? What's happening between GameObject.transform.position = newPos and pixels on screen?
Why do people complain about Unreal's performance? If it's "optimized," why do developers still struggle?
Why was Kerbal Space Program's physics so buggy? It's Unity—doesn't Unity handle physics automatically?

I realized I was using powerful tools without understanding what they were doing under the hood. I was a chef using a microwave, not knowing how heat actually cooks food.

Then my university professor gave us an assignment: Build a low-level game engine in C++.

No Unity. No libraries. Just C++, DirectX 9, and the Win32 API.

This was my chance to peek behind the curtain.

What I Built: Breakout, But From Scratch

If you've never played Breakout: you control a paddle at the bottom of the screen, bouncing a ball to destroy bricks at the top. Simple concept, complex implementation.

My engine features:

Custom rendering pipeline using DirectX 9
Fixed-timestep game loop (60 FPS target)
AABB and swept collision detection (no tunneling!)
State management system (Menu → Level 1 → Level 2 → Level 3 → End Game)
Sound system integration
Sprite animation system
Physics simulation (velocity, acceleration, collision response)

The result: A fully playable Breakout clone running at 60 FPS with ~3,500 lines of C++ code.

Tech Stack:

Language: C++17
Graphics API: DirectX 9 (legacy, but perfect for learning fundamentals)
Windowing: Win32 API
Audio: Windows multimedia extensions
IDE: Visual Studio 2022

Architecture Overview: Separation of Concerns

One of my biggest lessons: good architecture makes or breaks your project.

I learned this the hard way (more on that in "Challenges" below), but here's the final structure I landed on:

Class Diagram

Core Components

Game Class (The Orchestrator)

Owns all managers (Renderer, Input, Physics, Sound)
Manages game state transitions (Menu ↔ Level 1 ↔ Game Over)
Runs the main game loop

MyWindow (Platform Layer)

Wraps Win32 window creation and message processing
Handles OS-level events (close, minimize, resize)
Why separate? Platform code should be isolated—makes porting to Linux/Mac easier later

Renderer (Graphics Layer)

Initializes DirectX 9 device
Manages textures and sprites
Provides clean API: LoadTexture(), DrawSprite(), BeginFrame()
Key insight: The game logic never touches DirectX directly

InputManager (User Input)

Polls keyboard state using DirectInput
Abstracts raw input into game-meaningful queries: IsKeyDown(DIK_LEFT)
Why? Game code doesn't care about DirectInput—it just wants "left" or "right"

PhysicsManager (Collision & Movement)

AABB collision detection
Swept AABB for fast-moving objects (prevents tunneling)
Collision resolution with restitution
Lesson learned: Separate detection from resolution (I didn't know this at first!)

SoundManager (Audio)

Loads and plays sound effects
Handles background music with looping
Volume control

IGameState (State Pattern)

Interface for all game states: Menu, Level1, Level2, GameOver, YouWin
Each state implements: OnEnter(), Update(), Render(), OnExit()
This was my "aha!" moment—more on this below

The Game Loop

cpp

while (window.ProcessMessages()) {
    // 1. Calculate delta time (frame-independent movement)
    float dt = CalculateDeltaTime();

    // 2. Update input state
    inputManager.Update();

    // 3. Update current game state
    //    (Menu, Level, GameOver, etc.)
    gameState->Update(dt, inputManager, physicsManager, soundManager);

    // 4. Render everything
    renderer.BeginFrame();
    gameState->Render(renderer);
    renderer.EndFrame();
}

Why this structure?

Modularity: Each system has one job
Testability: Can test physics without rendering
Maintainability: Bug in rendering? Only look in Renderer class
Scalability: Adding a new game state? Just implement IGameState

The Rendering Pipeline: From Nothing to Pixels

DirectX 9 has a reputation: it's old (released 2002), verbose, and unforgiving. But that's precisely why it's perfect for learning—you have to understand every step.

Initialization: Setting Up DirectX 9

Getting a window to show anything requires five major steps:

1. Create the Direct3D9 Interface

cpp

IDirect3D9* m_direct3D9 = Direct3DCreate9(D3D_SDK_VERSION);
if (!m_direct3D9) {
    // Failed to create—probably missing DirectX runtime
    return false;
}

This creates the main Direct3D object. Think of it as "connecting to the graphics driver."

2. Query Display Capabilities

cpp

D3DDISPLAYMODE displayMode;
m_direct3D9->GetAdapterDisplayMode(D3DADAPTER_DEFAULT, &displayMode);

We need to know: What resolution? What color format? This tells us what the monitor supports.

3. Configure the Presentation Parameters

cpp

D3DPRESENT_PARAMETERS m_d3dPP = {};
m_d3dPP.Windowed = TRUE;                          // Windowed mode (not fullscreen)
m_d3dPP.BackBufferWidth = width;                   // 800 pixels
m_d3dPP.BackBufferHeight = height;                 // 600 pixels
m_d3dPP.BackBufferFormat = D3DFMT_UNKNOWN;        // Match desktop format
m_d3dPP.BackBufferCount = 1;                       // Double buffering
m_d3dPP.SwapEffect = D3DSWAPEFFECT_DISCARD;       // Throw away old frames
m_d3dPP.EnableAutoDepthStencil = TRUE;             // We need depth testing
m_d3dPP.AutoDepthStencilFormat = D3DFMT_D16;      // 16-bit depth buffer

This is where modern APIs (Vulkan, DX12) get even MORE complex. You're essentially telling the GPU: "Here's how I want my window's backbuffer configured."

4. Create the Device

cpp

HRESULT hr = m_direct3D9->CreateDevice(
    D3DADAPTER_DEFAULT,              // Use default GPU
    D3DDEVTYPE_HAL,                   // Hardware acceleration
    hWnd,                              // Window handle
    D3DCREATE_HARDWARE_VERTEXPROCESSING,  // Use GPU for vertex math
    &m_d3dPP,
    &m_d3dDevice
);

This is where I crashed 47 times. Wrong parameters? Crash. Unsupported format? Crash. Missing depth buffer? Crash.

Fallback strategy: If hardware vertex processing fails (older GPUs), fall back to software:

cpp

if (FAILED(hr)) {
    // Try again with CPU-based vertex processing
    hr = m_direct3D9->CreateDevice(..., D3DCREATE_SOFTWARE_VERTEXPROCESSING, ...);
}

5. Create the Sprite Renderer

cpp

ID3DXSprite* m_spriteBrush;
D3DXCreateSprite(m_d3dDevice, &m_spriteBrush);

DirectX 9's ID3DXSprite is a helper for 2D games. It batches sprite draws and handles transformations.

Rendering Each Frame

Once initialized, every frame follows this pattern:

cpp

void Renderer::BeginFrame() {
    // Clear the screen to black
    m_d3dDevice->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 
                        D3DCOLOR_XRGB(0, 0, 0), 1.0f, 0);

    m_d3dDevice->BeginScene();           // Start recording draw calls
    m_spriteBrush->Begin(D3DXSPRITE_ALPHABLEND);  // Enable alpha blending for sprites
}

void Renderer::DrawSprite(const SpriteInstance& sprite) {
    // Apply transformations (position, rotation, scale)
    D3DXMATRIX transform = CalculateTransform(sprite);
    m_spriteBrush->SetTransform(&transform);

    // Draw the texture
    m_spriteBrush->Draw(sprite.texture, &sourceRect, nullptr, nullptr, sprite.color);
}

void Renderer::EndFrame() {
    m_spriteBrush->End();          // Finish sprite batch
    m_d3dDevice->EndScene();        // Stop recording
    m_d3dDevice->Present(...);      // Flip backbuffer to screen (VSYNC happens here)
}

Key Concept: Double Buffering

We draw to a "backbuffer" (off-screen), then Present() swaps it with the screen's front buffer. This prevents tearing (seeing half-drawn frames).

Performance Note: Each DrawSprite() call is relatively expensive. In a real engine, you'd batch hundreds of sprites into fewer draw calls. For Breakout (~50 bricks max), it doesn't matter.

Challenges & Solutions: Where I Failed (And What I Learned)

Challenge 1: Architecture Disaster (Week 3)

The Problem:

I made the classic beginner mistake: I started coding without designing.

My first attempt looked like this:

cpp

class Game {
    Renderer renderer;
    InputManager input;

    // OH NO—game logic mixed into Game class!
    Paddle paddle;
    Ball ball;
    Brick bricks[50];

    void Update() {
        // Handle input
        if (input.IsKeyDown(LEFT)) paddle.x -= 5;

        // Update physics
        ball.x += ball.velocityX;

        // Check collisions
        for (auto& brick : bricks) {
            if (CollidesWith(ball, brick)) {
                brick.alive = false;
            }
        }

        // ...300 more lines of spaghetti code
    }
};

This worked fine—until I needed to add a menu screen.

Suddenly I realized: How do I switch between Menu and Level1?

My code had no concept of "states." Everything was hardcoded into one giant Update() function. Adding a menu meant:

Wrapping everything in if (currentState == PLAYING)
Duplicating input handling for menu vs. gameplay
Managing which objects exist when

It was a mess. I was 2 weeks in and facing a complete rewrite.

The Solution: State Pattern

I asked my lecturer (and ChatGPT) for advice. The answer: State Pattern.

cpp

// Interface that all game states implement
class IGameState {
public:
    virtual void OnEnter(GameServices& services) = 0;
    virtual void Update(float dt, ...) = 0;
    virtual void Render(Renderer& renderer) = 0;
    virtual void OnExit(GameServices& services) = 0;
};

Now each screen is its own class:

cpp

class MenuState : public IGameState { /* menu logic */ };
class Level1 : public IGameState { /* level 1 logic */ };
class GameOverState : public IGameState { /* game over logic */ };

The Game class just delegates to the current state:

cpp

class Game {
    std::unique_ptr<IGameState> currentState;

    void Update(float dt) {
        currentState->Update(dt, ...);  // Let the state handle it
    }

    void ChangeState(std::unique_ptr<IGameState> newState) {
        if (currentState) currentState->OnExit(...);
        currentState = std::move(newState);
        if (currentState) currentState->OnEnter(...);
    }
};

What I Learned:

Design before code (ESPECIALLY for 1,000+ line projects)
Separation of concerns makes code flexible
Refactoring hurts, but teaches more than getting it right the first time

The State Pattern is everywhere—React components, game engines, even operating systems use it. This lesson alone was worth the 3 months.

Challenge 2: The Ball Goes Through Bricks (Tunneling)

The Problem:

My first collision detection looked like this:

cpp

if (OverlapsAABB(ball, brick)) {
    brick.alive = false;
    ball.velocityY = -ball.velocityY;  // Bounce
}

This worked at 60 FPS... until the ball moved too fast.

At high speeds, the ball would tunnel—pass completely through a brick between frames:

Frame 1: Ball is here     →  [    ]
                                ↓
Frame 2: Ball is here         [    ]  ← Ball skipped the brick!

The ball moved 50 pixels, but the brick was only 32 pixels wide. By the next frame, the ball was already past the brick, so the overlap check returned false.

First Failed Solution: Smaller Time Steps

I tried updating physics 120 times per second instead of 60. This helped but didn't solve it—at very high velocities, tunneling still occurred.

The Real Solution: Swept AABB

I needed continuous collision detection—checking not just "are they overlapping now?" but "will they overlap at any point during this frame's movement?"

This is called swept AABB (or ray-swept box). Instead of checking the ball's current position, I treat the ball's movement as a ray:

cpp

bool SweepAABB(
    Vector3 ballPos, Vector2 ballSize,
    Vector3 displacement,  // Where the ball will move this frame
    Vector3 brickPos, Vector2 brickSize,
    float& timeOfImpact,   // When in [0,1] does collision happen?
    Vector3& hitNormal     // Which side did we hit?
) {
    // Calculate when the ball's edges cross the brick's edges
    float xEntryTime = ...; // Math for X-axis entry
    float yEntryTime = ...; // Math for Y-axis entry

    float overallEntry = max(xEntryTime, yEntryTime);

    if (overallEntry < 0 || overallEntry > 1) {
        return false;  // No collision this frame
    }

    timeOfImpact = overallEntry;
    return true;
}

Now my collision loop looks like:

cpp

Vector3 displacement = ball.velocity * dt;
float toi;
Vector3 normal;

if (SweepAABB(ball, displacement, brick, toi, normal)) {
    // Move ball to exactly the collision point
    ball.position += displacement * toi;

    // Bounce
    if (normal.x != 0) ball.velocity.x = -ball.velocity.x;
    if (normal.y != 0) ball.velocity.y = -ball.velocity.y;

    brick.alive = false;
}

Result: No more tunneling, even at 1000 pixels/second.

What I Learned:

Discrete collision detection (overlap checks) fails at high speeds
Continuous collision detection (swept/ray-based) is essential for fast-moving objects
This is why bullets in games use raycasts, not overlap checks

The math was painful (lots of min/max comparisons), but understanding this concept changed how I think about physics in games.

Challenge 3: Collision Detection ≠ Collision Resolution

The Confusion:

When I started, I thought "collision detection" and "collision resolution" were the same thing. They're not.

Detection = "Did these two objects hit?"
Resolution = "Okay, now what do we DO about it?"

My first attempt mixed them together:

cpp

if (OverlapsAABB(ball, paddle)) {
    ball.velocityY = -ball.velocityY;  // This is resolution!
}

This caused bugs:

Ball would "stick" to the paddle
Multiple collisions in one frame would cancel out
Overlapping objects would vibrate

The Fix: Separate Phases

cpp

// Phase 1: Detection (PhysicsManager)
bool hit = SweepAABB(ball, paddle, timeOfImpact, normal);

// Phase 2: Resolution (also PhysicsManager, but separate function)
if (hit) {
    // Move ball to contact point
    ball.position += displacement * timeOfImpact;

    // Apply restitution (bounciness)
    ball.velocity = Reflect(ball.velocity, normal) * restitution;
}

What I Learned:

Physics engines have detection and response as separate systems
This separation allows for complex scenarios (multiple overlaps, conveyor belts, one-way platforms)
YouTube tutorials often skip this distinction—they work for simple cases but fail for complex games

What I'd Do Differently

If I built this again from scratch:

Design first, code second (spend 2-3 days on architecture diagrams)
Use a modern graphics API (DirectX 11 or OpenGL 4.5) instead of DX9
- DX9 is fine for learning, but dated (no compute shaders, limited pipeline control)
Write unit tests for physics (I caught so many bugs by hand-testing that could've been automated)
Implement an entity-component system (ECS) instead of inheritance-based game objects
Add a debug overlay earlier (FPS counter, collision visualization saved me hours of debugging)
Profile from day one (I didn't measure performance until week 8—wasted time optimizing the wrong things)

Conclusion & Next Steps

Building a game engine from scratch was hard—way harder than Unity tutorials made game development seem.

But that's the point.

What I Gained:

Deep understanding of rendering pipelines
Practical knowledge of physics simulation
Appreciation for what Unity/Unreal abstract away
Confidence to debug low-level issues
A portfolio piece that stands out

What's Next:

Port this engine to DirectX 11 (modern pipeline, compute shaders)
Build a voxel engine (Minecraft-style, using Three.js for web)
Experiment with Vulkan (the final boss of graphics APIs)

Links:

📦 Source Code (GitHub)
🎮 Download & Play
🌐 My Portfolio
📧 Let's Connect
Originally published on Hashnode

If you're thinking about building your own engine:

Do it. Not to replace Unity, but to understand Unity.

You'll struggle. You'll debug cryptic errors at 2 AM. You'll question why you didn't just use Godot.

But when you finally see that ball bounce for the first time—compiled from YOUR code, rendered by YOUR pipeline, colliding with YOUR physics—you'll understand why people say "reinventing the wheel is the best way to learn how wheels work."

Questions? Suggestions? Let me know in the comments! 👇