DEV Community: Gift Mugweni

Is It Necessary to Create a Website for Every App?

Gift Mugweni — Sat, 30 Nov 2024 17:54:27 +0000

Hello 👋👋. Ive been away for a while, but I thought Id get back into writing again. To ease into it, I decided to start by asking a question thats been on my mind recently.

Does every app need to be on a website?

To give context to my self-indulgent question, Ill start by saying Im primarily a Web Developer. Whilst Ive done a bit of systems programming, I do not claim to be deeply knowledgeable, and the bulk of my professional experience lies in Web Development and all it entails.

With this foundation in mind, its not unreasonable to say that I often find myself around other web developers and also consuming content on social media platforms regarding web development so that I always stay informed and up to date. From these interactions, Ive naturally picked up on a fair number of often-said topics like serverless computing, the framework wars, micro-services vs monoliths etc and whilst theres much to be said about any of these debates, I found myself in an interesting situation.

As I listened to these debates and seriously contemplated their ramifications, I noticed a growing group of people who seemed to believe that the only way to make apps was via websites. If you listened to this group of people, youd think that if you were not spinning up lambda functions or deciding which service provider youll be saving your files to then youre not doing real programming and your solution wont scale.

I must confess, I didnt arrive at this observation by some big-brain thinking or other nonsense. I came to it by realizing this mindset in myself when I was working on a side project.

To summarize a long story. Whilst working on my game engine, I got stuck in a rut. I didnt know what features to add to it and a recent bug Id discovered and fixed had made me question some of the foundational architectural decisions Id made. Since I couldnt find a way to break through, I decided to learn from others and see if I could get inspiration by looking at different more standard game engines. This led to me messing with Godot and making a few toy games to familiarize myself with the engine.

During one of these toy projects, I got inspired by the wild niche of stickman fight videos on YouTube. A few personal favourites of mine are Combat Gods, Combat Gods II, Animation vs Math, and Nhazul - Weapons Demo. All this led to me wanting to make a stickman fighter game that can try to replicate some of the crazy moves you see in the video clips.

I remember someone saying that Game Development is just solving a series of problems and boy were they right. I immediately ran into my first problem when I needed animations for my character. Luckily I got a great asset pack from itch.io which would do the job for me but there was a catch. I initially bought it thinking it used a Skeletal Animation rigging model which the pack does include. Sadly, I couldnt get it working in Godot. Thankfully, he also included a bunch of image sequences which I could use with the traditional animation model but this also ended up being a problem.

It turns out, I had so many images for both my animations and the various skins that I effectively broke Godot and my editor became unusable because it frequently froze and crashed a lot. Naturally, I thought the simple solution was to just group all the separate images into a single or a few sprite sheets. After much Googling and begging on Stack Overflow, I eventually figured out how to write a basic program that could do this. At this point, I had forgotten about the game and was quite interested in this world of texture packing when I noticed that there werent any simple one-stop solutions that you could easily use to pack textures.

This didnt mean that there were no solutions, there were plenty of command line applications that did it but I found my options quite limited if all I wanted was something that quickly and simply did what I wanted without going crazy in the configuration. So I figured, I already had a dodgy script that fit the bill, why dont I polish it slightly and release it for free for people to use if anyone cared for it?

It was at this specific point in time I saw myself almost do something incredibly stupid. As I stated earlier, I didnt intend to make any money with this tool, yet here I was about to spin up a website, deciding whether to use AWS or Azure for temporarily storing the files and all in all going crazy by thinking how to make a simple serverless solution to achieve all this. It was during these planning sessions that I came to a scary realization.

I WAS PLAYING WITH FIRE!!!!! Why would I use all this services if I didnt expect to earn any money?

Maybe Id gotten too used to the free tiers. I didnt need to do all this. I had tricked myself into believing this was the only way to do things. The problem I wanted to solve would have led to lots of files being stored and significantly long processing times if the particular user had a lot of files of particularly high resolution. Both these things correlated with higher costs for bucket storage and serverless functions which meant if I had gone ahead with this incredibly idiotic plan I could have bankrupted myself if this site got any decent amount of traffic.

And so, I found myself wondering

Does every app need to be on a website?

The clearly obvious answer is

NO!!

Sometimes its worth thinking about the ramifications of what youre doing and remembering any sufficiently complex task will have multiple solutions with pros and cons.

In my situation, the potential incurred costs werent worth it and so I decided to do a hard pivot and make my solution a desktop app instead of a web based app. This ironically led to a much simpler and saner solution which given the time constraints and budget allocated to it($0.00) left me satisfied. You can check out the app here if youre interested. Its very much a version 1 product but feel free to let me know if you like it and maybe I can improve it and add to it if there are enough requests.

So yeah, I thought Id share this little story in case it might interest anyone. Although we rarely feel it sometimes, it is worth remembering that Software Development is a form of engineering and like any good engineer we should always assess the sanity of our actions if only for the sake of not giving our bank accounts a heart attack, especially in these economic times.

]]>

How to Set Up a Simple Rendering Loop in WebGPU

Gift Mugweni — Tue, 24 Sep 2024 10:00:29 +0000

Hello 🙋🙋 you good? How have you been 😁? I'm great and all, sorry for the delayed article but I think we both know my release consistency by now. So with that out the way lets get down to business.

In my last article, I showed how to set up the WebGPU project for TypeScript which I find to be a nicer working experience but your mileage may vary. It worked great and we got to see our lovely, beautiful, one-of-a-kind triangle aaaaaannnnndddd thats the problem.

As I mentioned previously, we're making a game engine and well, we need to do a loooottt more than just drawing a single triangle on the screen but hey, baby steps you know. So, lets add more features to our rendering class to make it a bit more interesting.

By the end of this article, you should have done the following

Implemented automatic canvas resizing to fill the window
Learned a bit more about WebGPU features (uniforms, vertex buffers, bind groups, etc)
Created slightly more complex shaders that render arbitrary shapes and colours
Created a rendering loop using RequestAnimationFrame
Created a wrapper class for our Game Engine features

Canvas Resizing

This is a simple piece of code which will automatically resize the canvas to fill the screen. Its not perfect but I found it works well enough for my purpose.

// Renderer.ts
   private setupCanvasResizing() {
        function resize(renderer: Renderer) {
            renderer.canvas.width = Math.max(1, Math.min(document.body.clientWidth, renderer.device.limits.maxTextureDimension2D))
            renderer.canvas.height = Math.max(1, Math.min(document.body.clientHeight, renderer.device.limits.maxTextureDimension2D))
        }

        window.addEventListener('resize', () => resize(this))
        resize(this)
    }

As seen from the function, it detects when the window resizing event occurs and sets the canvas to fill the window but it has a min of 1 and a max value based on the maximum texture dimension supported by the GPU device.

Rendering Abitrary Shapes

At the moment our shaders look like this

/** Vertext Shader **/
            // data structure to store output of vertex function
            struct VertexOut {
                @builtin(position) pos: vec4f,
                @location(0) color: vec4f
            };

            // process the points of the triangle
            @vertex 
            fn vs(
                @builtin(vertex_index) vertexIndex : u32
            ) -> VertexOut {
                let pos = array(
                    vec2f(   0,  0.8),  // top center
                    vec2f(-0.8, -0.8),  // bottom left
                    vec2f( 0.8, -0.8)   // bottom right
                );

                let color = array(
                    vec4f(1.0, .0, .0, .0),
                    vec4f( .0, 1., .0, .0),
                    vec4f( .0, .0, 1., .0)
                );

                var out: VertexOut;
                out.pos = vec4f(pos[vertexIndex], 0.0, 1.0);
                out.color = color[vertexIndex];

                return out;
            }

/** Fragment Shader **/
            // set the colors of the area within the triangle
            @fragment 
            fn fs(in: VertexOut) -> @location(0) vec4f {
                return in.color;
            }

The issue with the shader is that it is not configurable. Once youve run it youll always get back the same triangle with the same color. To resolve this, we need to use more functionality of the GPU namely, Uniforms and Vertex Buffers. Now you might ask what are these things?

What are Uniforms and Vertex Buffers?

Lets start by explaining vertex buffers. As you recall from one of my prior posts, when the GPU is rendering things, it uses the vertex and fragment shader. The vertex shader defines the bounds of where the rendering will occur and the fragment shader is responsible for filling in the shape with the appropriate colors.

Whilst an oversimplification of the process, it gets the idea across and if you want to learn more, check out this article. As you can imagine, the vertex buffer is probably gonna get used by the vertex shader but for what? Well in short, we use the vertex buffer to pass in whatever information we want to the vertex shader but you might typically add in all the vertices that define the boundary of the shape we want to render. To learn more about vertex buffers check out this article.

Moving on to uniforms, theyre also a facility offered by GPUs where we can pass in information to the GPU but whose contents will remain constant across each render. They can also be used by both the vertex and fragment shaders and can be thought of as global variables. This is again an oversimplification and you can learn more from this article.

With this all said, lets now refactor our code to use uniforms and vertex buffers.

Rewriting the shaders

Create a new file called shaders.ts and you can dump in the following new shader code.

export const Uniforms = /* wgsl */ `
    @group(0) @binding(0) var<uniform> color: vec4f;
`

export const SimpleVS = /* wgsl */ `
    struct VertexIn {
        @location(0) pos: vec2f,
        @builtin(vertex_index) index: u32
    }

    ${Uniforms}

    @vertex
    fn vs(in: VertexIn) -> @builtin(position) vec4f {
        return vec4f(in.pos, .0, 1.);
    }
`

export const SimpleFS = /* wgsl */ `
    ${Uniforms}

    @fragment
    fn fs() -> @location(0) vec4f {
        return color;
    }
`

The first thing youll notice is the new uniform that I defined that will store the colour information of my final output. For my purposes, I only care about rendering things with a constant colour and not an interpolated colour because itll make things easier to predict as time goes by. Im also passing in the input into the vertex shader as a struct because itll keep things neater.

An interesting thing you might notice is the @group(0) @binding(0) and the @location(0) in the struct. These will be used in TypeScript land to map the information we want to pass into our uniform and vertex buffer respectively as is shown below.

Configuring the buffers

In our Renderer.ts we now need to rewrite some of our code to allow the loading and setting up of the shaders and buffers.

First, we rewrite our function for loading in the shaders.

    public loadShaders(vertexShader?: string, fragmentShader?: string) {
        this.loadVertexShader(vertexShader)
        this.loadFragmentShader(fragmentShader)

        this.configureBindGroupLayout()
        this.configurePipeline()
    }

Youll notice that we now also have the ability to pass in our vertex and fragment shaders respectively. We also introduced the configuring of the pipeline and something called the bind group layout. This is because we need to reconfigure the pipeline to reference the new shaders.

Moving on, lets look at the loading of the vertex and fragment shaders

    private loadVertexShader(shader?: string) {
        this.vertexShader = this.device.createShaderModule({
            label: "Vertex Shader",
            code: shader ?? /* wgsl */`
                @vertex
                fn vs() -> @builtin(position) vec4f {
                    return vec4f(.0);
                }
            `
        })
    }

    private loadFragmentShader(shader?: string) {
        this.fragmentShader = this.device.createShaderModule({
            label: "Fragment Shader",
            code: shader ?? /* wgsl */`
                @fragment
                fn fs() -> @location(0) vec4f {
                    return vec4f(.0);
                }
            `,
        })
    }

As you can see, these functions are relatively simple with the addition of default shaders shaders that effectively render nothing.

Next lets configure the pipeline

    private configureBindGroupLayout() {
        this.bindGroupLayout = this.device.createBindGroupLayout({
            label: "Bind Group Layout",
            entries: [
                {
                    binding: 0,
                    visibility: GPUShaderStage.VERTEX | GPUShaderStage.FRAGMENT,
                    buffer: { type: "uniform" }
                }
            ]
        })

        this.pipelineLayout = this.device.createPipelineLayout({
            label: "Pipeline Layout",
            bindGroupLayouts: [
                this.bindGroupLayout
            ]
        })
    }

    private configurePipeline() {
        this.pipeline = this.device.createRenderPipeline({
            label: "Render Pipeline",
            layout: this.pipelineLayout,
            vertex: {
                module: this.vertexShader,
                buffers: [
                    {
                        arrayStride: 2 * 4,
                        attributes: [
                            { shaderLocation: 0, offset: 0, format: "float32x2" }
                        ]
                    }
                ]
            },
            fragment: {
                module: this.fragmentShader,
                targets: [{ format: this.presentationFormat }]
            }
        })
    }

Something to take note of now is that we are specifically creating a layout for the pipeline instead of passing in the auto keyword that tries to generate the layout automatically. This is no longer possible because we have uniforms that need specific mappings. Aside from that, we also set provisions for the vertex buffer in the vertex pipeline. Now there are a lot of moving parts here but you can find out why we need to do this by reading this, this, and that article. 😁 Enjoy yourself.

Rendering Loop

To lay the ground work for more complex rending, were gonna need to set up a rendering loop. This will allow us to add things like animation in due time but baby steps as they say. So lets rewrite the init function to do this.

    public async init() {
        await this.getGPUDevice()
        this.setupCanvasResizing()
        this.configCanvas()
        this.loadShaders()
        this.confiureBuffers()
        this.configureBindGroup()
        this.configureRenderPassDescriptor()
        this.startAnimation(60, this)
    }

Most of the functions should look familiar from the previous article but we do now have a few new kids in the block namely, configureBuffers, configureBindGroup, and startAnimation. Lets check them out.

    private confiureBuffers() {
        const vertices = new Float32Array([
          // X     Y
            -0.5, -0.5, 
             0.5,  0.5, 
            -0.5,  0.5,
            -0.5, -0.5, 
             0.5, -0.5, 
             0.5,  0.5
        ])
        const fillColor = new Float32Array([1, 1, 1, 1])

        this.loadVertexBuffer(vertices)
        this.configFillColorUniform()
        this.setFillColor(fillColor)
    }

    public loadVertexBuffer(data: Float32Array) {
        this.vertexData = data
        this.vertexBuffer = this.device.createBuffer({
            label: "Vertex Buffer",
            size: this.vertexData.byteLength,
            usage: GPUBufferUsage.VERTEX | GPUBufferUsage.COPY_DST
        })

        this.device.queue.writeBuffer(this.vertexBuffer, 0, this.vertexData)
    }

    private configFillColorUniform() {
        this.fillColorBuffer = this.device.createBuffer({
            label: "Color Fill Uniform Buffer",
            size: 4 * 4,
            usage: GPUBufferUsage.UNIFORM | GPUBufferUsage.COPY_DST
        })
    }

    public setFillColor(data: Float32Array) {
        if (data.length != 4) {
            throw new Error("Data must have 4 elements")
        }

        data.forEach((entry) => {
            if (entry < 0 || entry > 1) {
                throw new Error("Data values must be between 0 and 1")
            }
        })

        this.fillColor = data
        this.device.queue.writeBuffer(this.fillColorBuffer, 0, this.fillColor)
    }

The code should look pretty straightforward. Here, were asking the GPU to create a Vertex Buffer and a Uniform Buffer of a known fixed size of 16 bytes (i.e 4 elements * 4 bytes/element) for the uniform buffer and 48 bytes(i.e. 12 elements * 4 bytes/element) for the vertex buffer. This is because memory allocation is not handled automatically in WebGPU and we are responsible for the allocating and freeing up of allocated memory.

At the moment were planning on rendering a purple square hence, the all ones for the fill colour and the symmetrical vertex positions. An interesting thing you may notice is that some of the (x,y) are duplicated. This is because GPUs only generate fragments using triangles hence to draw a square, we need to use two triangles.

Lets move on to the configureBindGroup function.

    private configureBindGroup() {
        this.bindGroup = this.device.createBindGroup({
            label: "Bind Group",
            layout: this.bindGroupLayout,
            entries: [
                { binding: 0, resource: { buffer: this.fillColorBuffer } }
            ]
        })
    }

This function creates our bind group which is the glue between our uniforms in GPU land and the Buffer weve created in TypeScript land. As you might notice, the fillColorBuffer is mapped to a binding value of 0. This corresponds to the @binding(0) value in our shaders.

Lastly, lets set up our animation loop and connect all these moving parts.

    private startAnimation(targetFps: number, renderer: Renderer) {
        let start: number | undefined = undefined
        const targetFrameTime = Math.round(1000 / targetFps)
        renderer.render()
        requestAnimationFrame(animate)

        function animate(timeStep: number) {
            if (start === undefined) {
                start = timeStep
            }

            const elapsed = timeStep - start
            if (elapsed >= targetFrameTime) {
                start = undefined
                renderer.render()
            }

            requestAnimationFrame(animate)
        }

    }

    private render() {
        for (const colorAtachments of this.renderPassDescriptor.colorAttachments) {
            if (colorAtachments?.view) {
                colorAtachments.view = this.context.getCurrentTexture().createView()
            }
        }

        const encoder = this.device.createCommandEncoder({ label: "render encoder" })

        const pass = encoder.beginRenderPass(this.renderPassDescriptor)
        pass.setPipeline(this.pipeline)
        pass.setVertexBuffer(0, this.vertexBuffer)
        pass.setBindGroup(0, this.bindGroup)
        pass.draw(this.vertexData.length / 2)
        pass.end()

        this.device.queue.submit([encoder.finish()])
    }

This now looks a bit more complex but were essentially using the requestAnimationFrame function to call the render function at our ideal target framerate. Aside from this, were also adding the vertex buffer and the bindGroup to our render pass. Lastly, we now call the draw function based on the number of points in the vertex buffer.

Game Engine Wrapper

As you might now appreciate, there are a lot of moving parts going on in the rendering and for the potential game developer, they dont need to care about this so lets create a wrapper around all these things that will be visible to the developer.

Create a file called EngineCore.ts and add the following code.

import { Renderer } from "./Renderer"

export class gEngine {
    private constructor() { }

    // graphics context for drawing
    private static _Renderer: Renderer
    public static get GL() { return this._Renderer }

    public static async initializeWebGPU(htmlCanvasId: string) {
        document.body.style.backgroundColor = "black"
        const canvas = document.getElementById(htmlCanvasId) as HTMLCanvasElement

        if (!this._Renderer) {
            this._Renderer = new Renderer(canvas)
        }

        await this._Renderer.init()
    }

}

This sets up a global static class that initializes the renderer and also exposes the renderers public functions.

We also need to rewrite our main.ts file to use our new code structure.

import { main } from "./MyGame";main()

In the MyGame folder in the index.ts the following is added

import { gEngine } from "../EngineCore";
import { SimpleVS, SimpleFS } from "../shaders";

export async function main() {
    await gEngine.initializeWebGPU("GLCanvas")

    gEngine.GL.loadShaders(SimpleVS, SimpleFS)
    gEngine.GL.setFillColor(new Float32Array([0.5, 0, 1, 1]))
}

As you can see, this is a much cleaner code for the developer and they need not worry about all the wizardry we had to do to get this to work. and now BEHOLD your beautiful square.

🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔

Some of you might be thinking That aint a square Gift. Did you make a mistake?. Well, not quite, the issue is that our screen is not a square and as such, although coordinates range from -1 to +1 in clip space for the horizontal and vertical axis, in actuality, the horizontal axis is longer and as such, the final output looks like a rectangle. This isnt a big issue and can be fixed by taking the canvas resolution into account which well see in a future article.

Conclusion

🎉🎉 Congrats for finishing the article. Although the visual might look underwhelming, weve learnt many powerful concepts about WebGPU such as buffers, bind groups, bindgroup layouts, the rendering loop, etc. I hope you enjoyed the process and in the next article, well add more and more functionality to our engine as we continue to learn more about WebGPU and other things. 👋👋

]]>

How to Set Up WebGPU with TypeScript and Vite: A Simplified Guide

Gift Mugweni — Sat, 24 Aug 2024 14:31:27 +0000

Hello 👋, how are you doing? It's a lovely day right? In my last post, I said I was making a game engine and thought instead of writing documentation for it I might as well make blog articles to document my journey (I mean it's basically free content).

I'm decently far in the project at present but, it didn't feel right to start from my current point as there's too much missing context. So let's use the power of time travel and go way back to when I started the project.

Setting up the project

So far, we've been using vanilla JavaScript to work with WebGPU and I probably could make the entire engine that way. I didn't want to though as I feel more comfortable working with TypeScript because of its sweet sweet useless types that operate on the "Trust me bro" ethos. As such, we're gonna have to create a basic build setup. I used to use Webpack but thought I'd give Vite a try for a change as I'd heard good things about it.

To create a project you run the below command in your terminal.

npm create vite@latest

We're not making anything extra so the vanilla-ts template will do just fine. Here's a screenshot of the options selected in the setup.

When opening the project you should have the following files present more or less.

We don't need the counter.ts, style.css, and typescript.svg files so you're free to delete those at your pleasure.

The next thing we need is to add the types for WebGPU since they do not come pre-added at the moment. To download the types run the below command.

npm i @webgpu/types

This downloads the package but we still need to link it to our project so modify the tsconfig.json to look as below.

{
  "compilerOptions": {
    "target": "ES2020",
    "useDefineForClassFields": true,
    "module": "ESNext",
    "lib": [
      "ES2020",
      "DOM",
      "DOM.Iterable"
    ],
    "skipLibCheck": true,
    /*********************THIS IS THE IMPORTANT PART!! ******/
    "types": ["@webgpu/types"],
    /******************************************************/
    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "moduleDetection": "force",
    "noEmit": true,
    /* Linting */
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true
  },
  "include": [
    "src"
  ]
}

When I did this my types still weren't showing and after some googling, I also modified the vite-env.d.ts file to look like this.

/// <reference types="vite/client" />
/// <reference types="@webgpu/types" />

If you're using the VSCode IDE, you can also download these extensions that introduce some much-needed syntax highlighting in the wgsl shader code.

Next, replace the index.html and main.ts files with the below code.

index.html

 <!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Web Game Engine</title>
    <style>
      html, body {
        margin: 0px;
        padding: 0px;
        width: 100%;
        height: 99.74%;
      }
    </style>
  </head>
  <body>
    <canvas id="GLCanvas">
      Your browser does not support the HTML5 canvas.
     </canvas>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

main.ts

import { Renderer } from "./Renderer";

const canvas = document.getElementById("GLCanvas") as HTMLCanvasElement

const render = new Renderer(canvas)
render.init()

The index.html file should look familiar. Its main point is to set up a canvas where the output will be displayed. The canvas has also been resized to fill the window.

The main.ts file contains code that will make sense as we go further down. To understand this, we need to ask a basic foundational question.

What is the purpose of a game engine?

Fundamentally, a game engine exists to make developing games easier by abstracting away important but unessential parts of the game-making process. For better context on what this means let's use a basic example of a like FromSoftware's Elden Ring game.

As far as the player is concerned, they are playing Elden Ring to enjoy exploring the open world, overcoming tough bosses, and getting lost in the scenery, music, and breathtaking visuals. All these things are difficult to get right and require a lot of effort and time from the game designers to perfect.

What the player forgets is that they are interacting with the game via their controller or keyboard and mouse. They might be playing the game on drastically different screens, using devices with varying ranges of specifications. Aside from this, Elden Ring is a 3D game but they are playing it on a 2D screen so how does that work? How does the animation work? What about the lighting? How does the game handle the multiplayer aspects to ensure no one is cheating or that multiple players see the same thing? Now that we're down this rabbit hole, how even is that music getting played in the first place?

All these questions must be answered before we start dealing with anything the player cares about and as I'm learning, they have no easy answers. As a game designer, you don't want to worry about these things. You're trying to make a game and provide memorable experiences. Could you make these things yourself? Yes, but that needs time, people, and money.

This is where game engines come in. They don't guarantee you've got a good game and aren't all you need either. They're a small part of the bigger process of making games that focus primarily on key things like rendering, audio, networking, input, physics, lighting, modelling, etc. Hence my initial explanation of them abstracting away important but unessential elements.

Now that we've answered this question we'll start working on the first element of the game engine, the rendering system.

Building the basic rendering system

What is a rendering system? In short, it's the thing responsible for drawing stuff on the screen. Practically speaking, this is where we'll be putting most of our WebGPU and shader logic as it directly relates to drawing stuff.

To start, we'll be remaking our triangle example as that's the foundational building block. The implementation will be slightly different as I chose to wrap up this logic in a class so it is more compact and makes it easier to add more features.

The init func

The first thing is to define the Renderer class in a new file we'll call Renderer.ts that will house all this logic.

export class Renderer {
    private device!: GPUDevice
    private context!: GPUCanvasContext
    private presentationFormat!: GPUTextureFormat
    private vertexShader!: GPUShaderModule
    private fragmentShader!: GPUShaderModule
    private pipeline!: GPURenderPipeline
    private renderPassDescriptor!: GPURenderPassDescriptor

    constructor(private canvas: HTMLCanvasElement) {
    }

    public async init() {
        await this.getGPUDevice()
        this.configCanvas()
        this.loadShaders()
        this.configurePipeline()
        this.configureRenderPassDescriptor()
        this.render()
    }

When we instantiate the class, we pass in a canvas reference. This allows the class to work with any canvas which could be handy in the future maybe🤷‍♂️. The init function is responsible for setting up the rendering loop which I'll now explain.

Getting a GPU device and configuring canvas

The first thing we need is access to the GPU device on the host machine.

    private async getGPUDevice() {
        var adapter = await navigator.gpu?.requestAdapter()
        const device = await adapter?.requestDevice()
        if (!device) {
            this.fail("Browser does not support WebGPU")
            return
        }

        this.device = device
    }

    private fail(msg: string) {
        document.body.innerHTML = `<H1>${msg}</H1>`
    }

Next, we need to set up the canvas to accept the output from our GPU.

    private configCanvas() {
        var context = this.canvas.getContext("webgpu")
        if (!context) {
            this.fail("Failed to get canvas context")
            return
        }
        this.context = context

        this.presentationFormat = navigator.gpu.getPreferredCanvasFormat()
        context.configure({
            device: this.device,
            format: this.presentationFormat
        })
    }

Loading shaders

After setting up the canvas, we load in the vertex and fragment shaders.

    private loadShaders() {
        this.loadVertexShader()
        this.loadFragmentShader()
    }

    private loadVertexShader() {
        this.vertexShader = this.device.createShaderModule({
            label: "Vertex Shader",
            code: /* wgsl */ `
            // data structure to store output of vertex function
            struct VertexOut {
                @builtin(position) pos: vec4f,
                @location(0) color: vec4f
            };

            // process the points of the triangle
            @vertex 
            fn vs(
                @builtin(vertex_index) vertexIndex : u32
            ) -> VertexOut {
                let pos = array(
                    vec2f(   0,  0.8),  // top center
                    vec2f(-0.8, -0.8),  // bottom left
                    vec2f( 0.8, -0.8)   // bottom right
                );

                let color = array(
                    vec4f(1.0, .0, .0, .0),
                    vec4f( .0, 1., .0, .0),
                    vec4f( .0, .0, 1., .0)
                );

                var out: VertexOut;
                out.pos = vec4f(pos[vertexIndex], 0.0, 1.0);
                out.color = color[vertexIndex];

                return out;
            }
         `
        })
    }

    private loadFragmentShader() {
        this.fragmentShader = this.device.createShaderModule({
            label: "Fragment Shader",
            code: /* wgsl */ `
            // data structure to input to fragment shader
            struct VertexOut {
                @builtin(position) pos: vec4f,
                @location(0) color: vec4f
            };

            // set the colors of the area within the triangle
            @fragment 
            fn fs(in: VertexOut) -> @location(0) vec4f {
                return in.color;
            }
            `
        })
    }

You'll notice I've now split the vertex and fragment shaders into separate variables. This will allow us to easily change the vertex and fragment shaders on the fly as we go forward. A downside of this is the duplication of the VertexOut struct but that's not so bad right?

Another important point is that the @builtin(position) pos: vec4f in the vertex and fragment shaders do not contain the same values. For the vertex shader, the pos effectively only contains three values. These three points form a region that encompasses some pixels which are determined by a process called rasterization. The fragment shader is then executed for every pixel. What this means in practice is that the pos variable in the fragment shader contains the respective pixel coordinates and has as many elements as pixels in the defined region. This is an important point to remember if you want to do any fancy shader stuff and you can find more details about it in this article.

Configuring pipeline

Our pipeline is still pretty basic so it hasn't changed from our last version

    private configurePipeline() {
        this.pipeline = this.device.createRenderPipeline({
            label: "Render Pipeline",
            layout: "auto",
            vertex: { module: this.vertexShader },
            fragment: {
                module: this.fragmentShader,
                targets: [{ format: this.presentationFormat }]
            }
        })
    }

    private configureRenderPassDescriptor() {
        this.renderPassDescriptor = {
            label: "Render Pass Description",
            colorAttachments: [{
                clearValue: [0.0, 0.8, 0.0, 1.0],
                loadOp: "clear",
                storeOp: "store",
                view: this.context.getCurrentTexture().createView()
            }]
        }
    }

Rendering function

This too is still the basic implementation with nothing special

    private render() {

        (this.renderPassDescriptor.colorAttachments as any)[0].view = this.context.getCurrentTexture().createView()

        const encoder = this.device.createCommandEncoder({ label: "render encoder" })

        const pass = encoder.beginRenderPass(this.renderPassDescriptor)
        pass.setPipeline(this.pipeline)
        pass.draw(6)
        pass.end()

        this.device.queue.submit([encoder.finish()])
    }

Conclusion

Congratulations 👏👏👏. You just spent all this effort to recreate the same thing you made last time. But, now you have TYPES 🎉🎉. I recognize that this might be a bit annoying but I felt it important to show all this so that we can start on the same page moving forward. Sadly I'll have to stop here for now as this article is already pretty long but next, we'll begin refining this foundation and shaping it into our wonderful dodgy engine.
]]>

I'm making a game engine with WebGPU

Gift Mugweni — Sun, 18 Aug 2024 07:03:23 +0000

Background

In my last graphics article, I showed the relatively straightforward process of drawing a triangle on the screen. Whilst not perfect, practical, scalable, or all that interesting, I felt it important to help set the scene of what you can expect when working with the WebGPU API. From my experience, it's a relatively low-level API which means two things in practice.

It can be quite verbose when you want to do some simple things
It's surprisingly flexible and customizable owing to all the freedom it gives you.

So, why don't I think of a use case that seems more realistic and allows me to explore more of what WebGPU can do?

As should be apparent at this stage, I'm new to the world of graphics programming but, it has sunk its claws deep into me and I can't stop because it's just too much fun. Hence, I decided to go with the flow and learn how to make a Game Engine.

But why a Game Engine?

Gift, why would you make a game engine? Do you not know how hard that is? Have you not seen those horror stories about how long those things take? Who's even going to use the engine anyway?

Are all these valid questions? yes, they are. But, I remembered a video I watched by the YouTuber ThePrimeagen where he talked about the importance of taking the hard road sometimes even when there's no reason. I had also learnt about the Handmade Hero series by Casey Muratori where he made an entire game from scratch with no dependencies and that just looked fun. The nail in the coffin though was that I wanted to know if I could do it. I've heard the horror stories of it all and couldn't help diving into the fire to see if I'd come out the other side. So yeah, do I need to make a game engine? No. Do I want to make a game engine? Absolutely!!!!

How am I going to make it?

This was an interesting question to answer. I knew nothing about making a game engine and I didn't know anyone who did so Google was my friend.

The first question I had to answer was will my engine be for 2D or 3D games. From my initial runnings with Graphics Programming, I knew that the complexity increased exponentially when you moved from 2D to 3D so I humbled myself and decided I'd have to make a 2D engine for now.

This helped a bit but not much since I still didn't know where to start. My problem was extra interesting owing to WebGPU still being so new there didn't seem to be any resources out there that I could find for making a game engine using it so I had to use tangential resources to accomplish my goal.

Surprisingly, there are many good resources in different languages such as the Handmade Hero series which is wonderful when you're using C++ or the Coding a 2D Engine in Java series. Sadly, there were too many differences between these and my potential TypeScript-based implementation so I had to keep searching. Eventually, I found this wonderful book called "Build your own 2D Game Engine and Create Great Web Games using HTML5, JavaScript, and WebGL". I mean, the title practically speaks for itself. It was also a bonus that it was written using WebGL which precedes WebGL2 which precedes WebGPU.

So yeah, I haven't finished making my engine and there's still a lot of stuff I need to work on but I feel I've made decent progress on it. You can find the code here and in the following graphics articles, I'll give rundowns on what all that code is doing and what I had to modify to get it working for the WebGPU API.

]]>

Why do I write?

Gift Mugweni — Sat, 27 Jul 2024 14:51:23 +0000

In the past few weeks, I found myself struggling to write an article. It's interesting how easily one can begin a task and as time passes by, slowly, ever so slowly, you find your motivation diminishing. You question who you are to do this action. What information could you possibly know? What people would want to read your writings?

I had the analytics that showed me that although not crazy numbers, my words had indeed been read more than I thought possible. And although I told myself this, I found my convictions crumbling little by little. It didn't start strong, merely a slight procrastination in my starting time, or the words not quite coming to mind as they should. The writing became less and less appealing and I found my hands getting weaker and weaker as a voice grew stronger and stronger that asked a question I increasingly could not ignore. "Why am I writing?".

Why am I writing? Why am I writing? Why am I writing? This one single question gripped me. It's a simple question at its face but not to me. To me, this question grew grander and grander. It encompassed my mind and invaded my dreams. It asked and asked and asked. It lingered, it festered and it scared. Initially, I wanted to impart what I've learned and share it with others. But that wasn't right. The answer whilst not quite wrong also didn't feel right. Maybe I'll write and make this a side hustle business, I've heard such stories. Again that didn't feel right for I know how statistically unlikely that is. The odds didn't seem in my favor and I always knew that. Do I do it for fun? Do I do it for reflection? Do I do it for attention? Do I do it for spite?

I looked at my last posts and re-read my first post, and as I did a growing realization dawned on me. In my first article, I was emotional and animated. I spoke from my heart and told a tale that whilst not unique and unheard of, felt right to me. As I went on, to my next article, I adopted the framework of a textbook. A cold, factual, unfeeling textbook. I pushed my personality aside in favor of getting straight to the point and being informative. I told myself articles should get to the point and tried to game the SEO with the help of AI. I chose images to intrigue what I might not have felt. I presented words of fact but no worlds with meaning could be found. I made a site with my name, and I couldn't be found in it.

So my strength faded and the words stopped coming. Sadly, I failed to be the bringer of information for it seems, I could never truly be that to begin with. Why can I not be that I asked and the answer was self-evident. I do not enjoy reading textbooks, I enjoy reading stories. Sadly I cannot be clinical in my writing and I have a bad habit of getting lost in my ramblings. Information it seems is not my passion, nor is it my desire, nor is it my goal. A story I seek to tell. A story I seek to share. To speak and maybe be heard. To speak, even when not heard.

And so, I abandon the land of facts for it seems not to be my home. I continue my journey, through the great unknown. I'll wander into the land of dreams, and hopefully tell tales of the sights I see. Facts it seems are not where I am meant to be. Facts it seems, do not call to me.

With all this said, the question comes to me again. "Why do I write?". I do not know why. But I will continue to try. I'll write tales. I'll write articles. I'll write poems. I'll write nonsense. But write I must, for it seems, that writing is for me.

What is recursion?

Gift Mugweni — Sat, 22 Jun 2024 19:26:48 +0000

This is a submission for DEV Computer Science Challenge v24.06.12: One Byte Explainer.

Explainer

Recursion is solving a problem by breaking it into smaller simpler problems that follow a set pattern.

Additional Context

WebGPU Basics: How to Create a Triangle

Gift Mugweni — Sat, 22 Jun 2024 19:19:16 +0000

Hello 👋, it's been a minute. How's life and all that good stuff? Anyway to get myself back into the groove I thought I'd start where I left off, Graphics Programming specifically using WebGPU.

In this series, I'll give semi-tutorials on working with WebGPU and the shading language WGSL which I'll explain as and when is necessary so hopefully you can also dive into this crazy world of making art with code and maths.

To keep things simple, this article will teach you how to make the equivalent of a "Hello World" in shader land which is a triangle because drawing text to screen turns out to be really hard. See this video if you think I'm lying. With this example, you'll fully get to experience the basic flow of working with WebGPU and I'll also point to some resources I came across that you can read up on that helped me start this journey.

Before we begin, let's answer a few obvious questions.

Question: What is WebGPU?

Answer: It's a graphics API

Question: What does that mean?

Answer: It is software that helps you utilize the Graphics Card(GPU) that comes with every modern computer/smartphone to either draw stuff on the screen or do more general computations on the graphics card e.g. matrix math.

Question: Why would I ever need to use a GPU can't my CPU do all that already?

Answer: Yes it can but because of how a CPU is designed, as you get more sophisticated with your graphics or you need to do a lot of simple stuff in parallel, it will struggle a lot and not be efficient. That's where we use GPUs that have been purpose-built for such tasks.

With that preamble in place, let us talk about browser support. As I mentioned in my previous article, WebGPU is still relatively new so, browser support hasn't fully rolled out yet at the time of writing, you can only use the API on the latest Chrome, Edge, Opera, Chrome for Android, Samsung Internet and Opera Mobile browsers. Safari support is present in the Technical Preview only so far. So yeah, as you can see, it hasn't rolled out fully yet but the rollout is being actively worked on and you can check on this site, where support will be as time goes on. I don't think this browser support state is much of an issue but, it is something to be aware of.

Now that's done, let's see what we will be drawing today.

Looks beautiful right? This triangle and all the following code come from this wonderful site called WebGPU Fundamentals that goes in-depth into WebGPU and is a great resource to learn about Web GPU but, it does look a bit intimidating when you first visit it so I thought I'd make this series to give an easier entry point to jump off from.

Although I did say it's an easier entry point, I still need to make some assumptions for brevity. The first assumption is that you are familiar with modern JavaScript and are comfortable with basic HTML and CSS though we won't use the latter two all that much. If you are not familiar with any of these, here are some great playlists made by the YouTuber The Net Ninja that will get you up to speed. He also makes other great videos in general so feel free to check him out.

Assuming you have explored those resources or already have the basics covered, let's set up our basic HTML page.

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>WebGPU</title>
        <style>
            html, body {
                height: 100%;
                margin: 0;
            }

            .container {
                display: flex;
                min-width: 100%;
                min-height: 100%;
                align-items: center;
                justify-content: center;
                background-color: black;
            }

            .display {
                min-width: 100%;
                min-height: 100%;
            }
        </style>
        <script src="main.js" defer></script>
    </head>
    <body>
        <div class="container">
            <canvas id="webgpu-output" class="display"></canvas>
        </div>
    </body>
</html>

So there's nothing fancy with this code snippet here. Just make a basic page and resize the canvas element to which we will be drawing to to fill the entire page. Aside from that, we also include a "main.js" file which will contain all of our code from here on out.

Before I begin though, look at this meme and internalize it for the rest of this article.

The GPU exists in a different world from the CPU. In GPU land, many things are different and some things that might be simple in the CPU are a nightmare in the GPU and vice versa. Because of this, drawing a triangle ends up being a bit involved.

Having set your expectations, let us draw our lovely triangle.

First, we need to get permission to use the GPU. For that, we enter the below code.

 function fail(msg) {
    alert(msg);
}

async function main() {
    // get GPU device
    const adapter = await navigator.gpu?.requestAdapter();
    const device = await adapter?.requestDevice();
    if (!device) {
        fail('need a browser that supports WebGPU');
        return;
    }

Now, I could go in-depth into the fine details going on here but this is a beginners' course so all we need to know is that if the device variable is not undefined, congratulations 👏👏👏 we now have our GPU device and can continue forward. For a more in-depth explanation, check out the Fundamentals Article on the WebGPU Fundamentals website.

Moving on, we need to prepare the canvas so that it understands the eventual commands we will send to it.

    // Get a WebGPU context from the canvas and configure it
    const canvas = document.getElementById('webgpu-output');
    const context = canvas.getContext('webgpu');
    const presentationFormat = navigator.gpu.getPreferredCanvasFormat();
    context.configure({
        device,
        format: presentationFormat,
    });

The main role of this section of code is to ensure that the canvas understands the draw commands it will eventually get from our drawing code.

Moving on, let's set up our shader code.

    const module = device.createShaderModule({
        label: 'our hardcoded triangle shaders',
        code: `
            // data structure to store output of vertex function
            struct VertexOut {
                @builtin(position) pos: vec4f,
                @location(0) color: vec4f
            };

            // process the points of the triangle
            @vertex 
            fn vs(
                @builtin(vertex_index) vertexIndex : u32
            ) -> VertexOut {
                let pos = array(
                    vec2f(   0,  0.8),  // top center
                    vec2f(-0.8, -0.8),  // bottom left
                    vec2f( 0.8, -0.8)   // bottom right
                );

                let color = array(
                    vec4f(1.0, .0, .0, .0),
                    vec4f( .0, 1., .0, .0),
                    vec4f( .0, .0, 1., .0)
                );

                var out: VertexOut;
                out.pos = vec4f(pos[vertexIndex], 0.0, 1.0);
                out.color = color[vertexIndex];

                return out;
            }

            // set the colors of the area within the triangle
            @fragment 
            fn fs(in: VertexOut) -> @location(0) vec4f {
                return in.color;
            }
        `,
    });

This right here is the meat of the topic. I understand that this code can be overwhelming so, let's make broad strokes for now. To understand this code, we need a basic understanding of how GPUs draw stuff on the screen.

The first important point is when drawing, GPUs only understand points, lines and triangles. Thats it. Everything that appears on the screen is decomposed into these fundamental elements. Hence, we need to think of things from this perspective to get our lovely visual showing.

The next important point is the order in which the GPUs carry out the drawing. First, it establishes all the points(vertices) of the shape we want to draw. Then it groups all three points into triangles. Afterwards, it colours in all the grouped triangles.

With this framework in mind, we can see a function called vs and another called fs . The vs function is where we process all our points and do any transformations if we want to whilst the fs function is responsible for the colouring of the respective triangles. For our starting point, I think this is good enough and if you want to know more, check out the Fundamentals Article on the WebGPU Fundamentals website.

Now that we've had our meat, it's time to face the bone and that's us doing all the necessary plumbing to actually draw the triangle. Right now, we're still writing stuff in CPU land and we need to send this information to GPU land. and for that, we use the below code to do that transfer.

    const pipeline = device.createRenderPipeline({
        label: 'our hardcoded red triangle pipeline',
        layout: 'auto',
        vertex: {
        module,
        },
        fragment: {
        module,
        targets: [{ format: presentationFormat }],
        },
    });

    const renderPassDescriptor = {
        label: 'our basic canvas renderPass',
        colorAttachments: [
        {
            // view: <- to be filled out when we render
            clearValue: [0.3, 0.3, 0.3, 1],
            loadOp: 'clear',
            storeOp: 'store',
        },
        ],
    };

    function render() {
        // Get the current texture from the canvas context and
        // set it as the texture to render to.
        renderPassDescriptor.colorAttachments[0].view =
            context.getCurrentTexture().createView();

        // make a command encoder to start encoding commands
        const encoder = device.createCommandEncoder({ label: 'our encoder' });

        // make a render pass encoder to encode render specific commands
        const pass = encoder.beginRenderPass(renderPassDescriptor);
        pass.setPipeline(pipeline);
        pass.draw(3);  // call our vertex shader 3 times.
        pass.end();

        const commandBuffer = encoder.finish();
        device.queue.submit([commandBuffer]);
    }

    render();

Again, quite a chunky bit of code here but at its core, we're just setting things up so that we can transfer our shader code to the GPU. You'd be correct to feel that this feels like too much work for such a basic triangle but bear in mind that our current use case isn't what WebGPU was made for. It's designed for drawing multiple objects moving in potentially complex patterns. At that point, it helps to think of drawing stuff in batches and the above code structure helps support that method of thinking.

And with that, we're done. You, my friend, if you've followed along now have your first-ever triangle on screen and you are destined for greatness. So what's next after this?

If you're hooked, try out the Google Codelab project where you get to recreate the classic Conway's Game of Life and learn more about WebGPU.

I've placed all the code discussed here in a GitHub repo here. I'd recommend you write it yourself instead. You always learn more that way instead.

In my next article, I'll talk about making much nicer visuals and hopefully get deeper into exploring shaders now that we've gotten the foundation in place.

A Beginner's Journey into Graphics Programming

Gift Mugweni — Sat, 08 Jun 2024 21:34:08 +0000

One fateful night, I was scrolling through my YouTube feed when I came across an interesting Kishimisu channel video introducing me to the wild world of graphics programming. In the video, I saw a beautiful visual created with nothing but mathematical concepts and I got hooked. Here I was, lamenting my horrible hand-eye coordination and thinking I was doomed in art when I could have put all those years of learning linear algebra and calculus to good use. Here was an excuse to use maths for entertainment that I could get behind. So, I decided to see what happens in this strange world of drawing stuff on the screen.

To start my exploration, I thought it'd be great if I could reproduce the visual I saw in the Kishimisu video. In the video I watched, he made the visual on this amazing website called Shadertoy where a bunch of incredibly smart people make visualizations and share the code on how they made them. For reference, these are some of the visuals on the site that blew me away.

shadertoy.com

Now, you'd think that since I wanted to reproduce the visual I'd create a Shadertoy account and start coding away right? Well, that was my plan at the beginning. As I was in the process of staring at those visuals, I found myself wondering how the Shadertoy website worked. As such, I found myself entering much deeper waters.

From my research, I learnt about the magic of shaders. Now, what are shaders? As far as I understood, shaders are just programs that run on your graphics card which is one of the key gadgets that allows you to play all the new amazing games these days. Like any programming language, shaders can be written in various languages like OpenGL, DirectX, Vulkan or Metal. However, strangely enough, when it comes to websites, there seems to be only one language at its core which is called WebGL which is just a port of OpenGL.

In a wild twist of fate, as I was learning about WebGL, I learned that a new graphics API was released last year called WebGPU that is meant to succeed WebGL considering it was initially released in the early 2010s. This felt amazing as that means we are possibly at the cusp of a graphics revolution for the web. This means I can get an opportunity to experience a potentially new world-shaking technology regarding computer visuals on the web in real-time and experience the technology evolve with me.

So, I instantly pivoted and started to see if I could reproduce the initial visual not in WebGL on Shadertoy but in WebGPU using my hacky code. Below are some visuals I made using WebGPU.

Having played around with the new API I have to say I was greatly impressed so, I decided to make this a series where I talk about my learnings in graphics programming and hopefully I get to show you all more and more amazing visuals and also explanations of my learnings as I go on.

Transform Game Visuals Using Meta AI

Gift Mugweni — Sat, 01 Jun 2024 22:03:03 +0000

Overview

In my last article, I ended with a promise to explain how I prepared the assets for the Flappy Bird clone I made. The game is simple, so basic features like sound and fonts could be easily sourced or created. As such, the true difficulty for me lay in the visual assets.

Now, I have a confession to make. I have zero art skills and it might lean in the negative. For some reason, I find the field more difficult than any engineering or calculus classes I attended with many difficult topics like colouring, proportions, framing, lighting, symmetry, placement, and probably other things I don't even know I don't know.

This was a problem considering I in my infinite wisdom gave myself the challenge of producing my assets for the games I would be making within reason. So what to do?... what to do? This was the question that troubled me as I explored the rabbit hole of learning pixel art. Initially, I just stuck to my guns and continued learning about pixel art. And for my effort, I obtained these wonderful images as assets for my Flappy Bird game.

The Background

The Bird

The Pipe

🤔🤔🤔 Now I don't know about you but I was mighty pleased with my pipe image ... Though the bird and background left a lot to be desired.

Solution

As I was coding forward and ignoring the funky visuals, I habitually opened the WhatsApp app on my phone and after getting annoyed by the new update that changed the layout of things, I noticed the new shiny blue button for conversing with the Meta AI bot.

Like everyone, I was very aware of the current hype regarding AI tools like ChatGPT, and Github Copilot. I even remembered about the image generation models like Stable Diffusion. Though I personally never found much practical use with them, and hence ended up not using them all that much, Something about the Llama model being just there on my WhatsApp without me having to go to separate sites or download dodgy apps just compelled me to test it out.

Initially, I just typed random messages and tried conversing with the bot. I quickly realized that was a dead end and gave up on that vector. I then learnt that it can also generate images which was great and so I gave it a prompt to test it out.

/imagine an anime fight scene between superman and micky mouse

To which I got.

At that moment, it clicked for me. Why don't I use this bot to generate my game assets? It obviously wouldn't be perfect but I was sure if I prompted it just right I should be able to get something reasonably decent.

To test if my idea was feasible, I proudly asked the bot.

/imagine a pixel sprite of a dog

To which it fully complied and gave me the below image.

😅Yeah this one was on me. I should have seen it coming but I refused to give up and made a follow-up response.

Use only 8 of color bits

This finally gave me what I was looking for.

After this point, there's not much more to tell really. I just went about prompting the bot and tweaking my responses to get images more aligned with what I wanted. I found this strategy worked great for big background scenes which was truly a sight to behold.

The New Background

/imagine an 8 bit image background showing clouds floating in the air and mountains down below... There's bright green grass with trees and flowers dotting the land scape

/imagine an 8 bit pixel image background of rolling hills

Make the image so that it can be tilled in both left and right directions

The last one is the image used in the game though I had to edit it a bit to remove the none nonexistent tree which was way easier than trying to draw this scene in any reasonable amount of time.

The New Bird

Like the background, the bird was also relatively easy to make with only a few minor prompts here and there.

/image an 8 bit image of a bird flying through a forest in a side scroller game

make the bird yellow

make the bird more simplistic

increase the pixel density

The New Pipe

Now for this one, I gotta be honest. It wasn't worth it. Sadly I realized belatedly that the model struggled quite a lot with creating the pipe which was likely caused by the dataset it learnt from and my use case probably falling on the fringes. In the spirit of completeness and sharing here are some of the responses I got.

/image an 8 bit green pipe like in Mario with a forest background for a side scroller game

/image an 8 bit green pipe shooting from the ground and sky with a forest background for a side scroller game

This one was interesting in how it generated a watermark in front to hide the AI watermark 🤷‍♂️.

simplify the pipe and remove the bends

/image a green 8 bit vertical pipe in a side scroller game

Anyways... these are a few of the responses I was getting and this back-and-forth went on for quite some time before I got the somewhat passable pipe I ended up using in the game.

In all honesty, though I probably should have just used the one I made. It would have been quicker and more in line with what I had envisioned in my head.

Conclusion

Overall, I was quite impressed with how useful the Meta AI bot was in helping me create assets that are not only presentable but downright beautiful. Even when it failed to create what I had in mind, I still found myself in awe at the visuals it created.

From a more utilitarian perspective though, the bot excels greatly at generating large background scenes and characters which gives some much-needed life to your game's visuals and I plan to continue using it for these use cases going forward. However, it must be noted that for much simpler objects like the pipe, it's probably best to just make those on your own.

Achieving Success in Online Learning: A Practical Guide

Gift Mugweni — Sat, 25 May 2024 18:43:09 +0000

In my last article, I mentioned how I started my programming journey with the CS50 course. As luck would have it, in the process of going to their site so I could properly reference it, I learnt they introduced a bunch of new interesting courses. For me, my interest was piqued by the below courses

Although I know all the above subjects at a surface level, I thought it'd be interesting to dive deep into one of the topics and see what new stuff I could learn.

Considering my current experience in programming, the courses I thought I'd learn the most from were the Game Programming and Artificial Intelligence courses. I also wasn't in the mood to learn Artificial Intelligence as I did two courses that dove deep into machine learning at university which gave me a good impression of what to expect from the course. Hence, intending to learn and have fun, I decided to do the Game Programming course.

With the course decided upon, I tried determining what key things I wanted to ensure I obtained so I would approach it with the right frame of mind. For this, I considered my state of being and made the following observations.

I'll likely only be able to allocate an average of 1 to 2 hours per day to this course
My primary goal is entertainment
I don't need the certificate
I'd like to be able to know how I can go about making my own unique exciting game that all my 3 users will fall in love with

With my priorities set, I skimmed through the course to get an idea of what to expect, what I might like and what I might hate about the course. From this, I set the following constraints for myself.

I don't just want to copy the code exactly
Where I can, I should create my game assets (e.g. sounds, music, sprites) within reason.

Aside from this, I noticed the 2D game section was written using the Lua programming language, and the 3D game section used the Unity Game engine. Having played around with Lua for a bit, I realised I didn't like using it. There wasn't any rational reason for my dislike. It was mostly vibes but, considering one of my primary goals was entertainment, it was a real issue I had to resolve otherwise I'd likely drop the course as time went on.

And so, I started looking into alternative tools I could use for making 2D games which would satisfy the fun factor for me. After endless Googling with a hint of Bing, Chat GPT,... and Bard, I learnt about these alternative tools I might enjoy more.

Unity Game engine which uses C#
Pygame which uses Python
Godot which uses GDScript or C#
Phasor which uses TypeScript or JavaScript
PixiJS which uses TypeScript or JavaScript

With my list present, it was time for the hard part, deciding what to use. From what I had seen from the initial course videos, the games were being built using a relatively low-level approach since they used Love2D. This meant things like physics, state machines, and event propagation were being built as we went and I got the impression that the only thing mostly abstracted was the rendering (showing stuff on the screen). This meant I'd need a tool that didn't hide too much stuff from me and allowed me to drown in complexity. This left me with Pygame and PixiJS since they were the most similar in functionality to Love2D as far as I could tell with the only difference being the language used.

Of the remaining two tools, I did enjoy both so ..., I flipped a coin and ended up choosing PixiJS as my tool.

With all this said, this is how I set myself up for potential success in tackling the course and I even went about finishing the first two lessons along the way. You can find the Flappy Bird game here (Fifty Bird (stelele.github.io)) and here is the link to the repo (https://github.com/Stelele/pixijs-flappy-bird) though considering this is for fun, you're gonna need a keyboard to play it.

Making the flappy bird was quite fun and in my next article, I look forward to explaining how I went about making it and preparing the assets for it.

How I Entered the World of Programming: A Personal History

Gift Mugweni — Sat, 18 May 2024 20:54:05 +0000

Games have always been a part of my life in some shape or form. Whether it be the Pokemon game I obsessively played on my GameBoy I got as a consolation prize for a would-be PSP, or the Tomb Raider disc a friend of mine and I broke by playing it so often that it shattered in the CD reader. As time passed, I played more games, which gave me many memorable firsts. Elder Scrolls Skyrim made me realize the beauty of an open world that you can get lost in. BioShock Infinite is a story that I still contemplate today. Limbo, while seemingly simple, inspired awe in me at how so much can be said without any words ever being spoken. Finally, Undertale gave me an interesting perspective on how I as a player might appear to the NPC characters.

As time went on and I continued playing games, I found myself growing more and more curious about how they are made. How did those healing spells I spammed in Skyrim work under the hood? How can entire worlds exist in a laptop that fits on my lap? How did Flowey in Undertale mess with me so much? As these questions grew, I found myself naturally curious about this laptop, console, and phone that housed my entertainment. And so in 2014, I decided to learn about computers in high school. At the time, I never realized how much that choice would impact my future but looking back on it now, I'm surprised that I even considered not doing the course because I was afraid it'd be too hard.

In high school, I had the preveladge of doing the CS50 course as our teacher at the time believed it would greatly benefit our future prospects and honestly, he was right. This one course introduced me to the field of Computer Science in a completely different way from the dry lifeless textbooks that were part of the curriculum. Through the course, I saw myself progress from struggling to print "Hello World" as we used the C programming language, to spending 2 weeks pulling late nights with my study mates trying to solve the pyramid problem (this was the first time I appreciated that (" ") was a real character). As time went on and I continued failing forward, I saw myself progress through the course material and learn deeper concepts like pointers, memory management, data structures, and at some point in that journey I was reading the JPEG documentation because one of the tasks in the assignment I had to do was recover deleted images from a supposedly erased storage device (Best assignment ever by the way .... took me a month to get it working somewhat though).

From this course, and the expert guidance of my teacher, I got a taste of many computer science fields like low-level programming, game development, and web development which gave me a firm foundation when I later went on to study Electrical and Computer Engineering in university. It was a great program and I will always recommend it to anyone who wants to learn about Computer Science (It's free by the way).

Now having shared all this, some may wonder if I am getting to any point of greater truth. The simple answer is no. I just wanted to share this story to express how strange and beautiful life can be. I never imagined that the Gift who was busy messing around with his Pokemon cartridge would later learn so much about computers and programming and even get the opportunity to create more programs that I believe help make life for a small group of people that much better. Granted, I'm not a professional game developer but, that was never really my intention. To me, games became a part of the greater body of computer science and became one of the many reasons I love this field. From those games, I learnt about computers. From computers, I learnt about the Internet. From the internet, I learnt about web development. And finally, from web development, I got to enjoy solving interesting and difficult problems at work. And to think my path in life would have been completely different if I had been afraid to take that 1 simple computer science course in high school. It made me wonder how often we leave the potential of a wonderful future because of our fear of our present-day reality. And so, I thought I'd share this post in turn so hopefully someone else might find the courage to take that first step on their journey. You never know where the road will take you.

With this article. I've also decided to take my own advice and start this blog that I've been thinking of doing for over a year now. So, look forward to more completely unrelated posts or maybe they'll be related. I'm sure time will tell as they come out.