I spent some time messing around with WebGL trying to render some better looking 3d mazes, which I have no doubt you can do. There are plenty of examples of WebGL being used to make some captivating 3d content and that challenge is enticing.

However, it wasn’t long until I came across WebGPU, the Next Generation™ of 3d rendering technology for the web.

Digging in a bit, it felt very familiar. The API is very ‘Vuklanesque’, inspired by it, as well as other modern graphics APIs (Metal, Direct3D 12 etc.).

I thought, why not revisit StaticRectangle? The Vulkan powered renderer wannabe-game-engine I started this devblog with a few years ago.

---

What happened to StaticRectangle? Well, I fell into a common trap, I didn’t have a goal to shoot for. It was first and foremost a learning experience, but it got to the point where I had to ask – what am I doing this for? Do I want to ship a game? inevitably yes. Would I do that with my own engine? no, probably not.

While I find the problem solving and engineering challenges that come with engine development generally enjoyable, I don’t think I quite have the chops just yet.

Looking at WebGPU, I know I can set myself some realistic targets. I like the idea of being able to embed a renderer directly into my blog / website as I try out ideas, learn new concepts etc.

Being able to share this work where you’re able to interact with it instead of just looking at screenshots/GIFs (which aren’t always that fun to make to be honest) is objectively better. It would be nice to look back on.

---

So as StaticRectangle develops, these are my general goals

• Embed 3d content into the browser for visualisations, interactions and sandboxy things
• Possibly develop simple 3d browser games to strengthen my development skills and pretend like there is a point to that, even though Sam Altman is hellbent on making me obsolete¹
• OpenSource it?

I figure the engine can mature over time as needs arise, and this helps reframe development efforts from developing games for the engine, to developing the engine for games. The correct way.

Of course, this is not without its challenges. And that’s OK, I like a challenge! Here is a very non-exhaustive list

• I’m not a web guy
• I haven’t really used JavaScript in 15 years
• I’m not a render engine developer
• I’m not an engine developer
• I’m not a game developer of any sort, at least not professionally

---

So where am I with this today? I have been toiling away on this for the last week or so, working my way through the WebGPU Fundamentals, researching TypeScript servers and deployments, and all that fun webby stuff.

Because I do have experience from StaticRectangle 1.0 I knew exactly where to start. Good logging² and an events system.

Before I even had a single line of render code written, I had a CLI like terminal that you can open and a reasonably fleshed out events system in place. Thankfully JavaScript does a lot of the heavy lifting here (a benefit of the web target), so I can focus on how I want it to work rather than how to make it work.

A case in point, today I was moving something around and the logger caught something. I may not have noticed before.

I have been testing on Safari (that has WebGPU disabled by default, at least in the version I have) and Chrome. I expect Safari to land on the “Sorry” page, which is something that happens when something bad happens, expected (no WebGPU support) or otherwise (something broke).

I hit that with Chrome when I wasn’t expecting it.

The logs told me exactly what the problem was, and I fixed it immediately. Previously, I would need to be aware there is even a problem (a lot of web stuff just fails silently, and it’s difficult to know that when you’re working on a renderer that can’t render anything yet), then manually open the JavaScript Console and hope there was an exception that made sense without a lot of digging.

So yep, logging tools, especially in the early stages of development are important and can save you some time/frustrations.

When this happens, and I happen to know it’s a critical error it takes you to this page and the Terminal is opened for you. The Terminal itself is pretty barebones right now, that’ll get fleshed out as time goes on and needs arise.

And finally, after quite a few days of typing and reading, here the namesake ‘Static Rectangle’

While I admit, this is far from exciting. It’s not even a very nice colour (1.0 had a nice green static rectangle as the first shape drawn). In this case, the colour choice is intentional, it’s the ‘error’ shader that is used when the requested shader isn’t available (and you can see that in the terminal I opened). However, just like last time things can move a lot faster now, the majority of the initial time is in design and setup, and once you can render one rectangle (technically two triangles), you can render many, in any configuration you want.

1. I know this is dramatic and not true at all. But this is my devblog 🙂 ↩︎
2. Those that know me (at least professionally) will know that poor logging is one of my biggest bugbears. I will undoubtedly flesh out the logger a lot more, right now it’s very basic. ↩︎