<aside> 💡 js13k is 30-day competition to create a browser game in 13kb of code or less. I am documenting my project here and on twitter.

</aside>

Pt 2: Writing a 3D Engine (after trying not to)

Pt 3: Using Bitmap Caching to Unlock 60fps in 3 Dimensions

Contents

JS13k 2020 is a wrap, and I'm happy with what I learned and many of the things I built, though I missed by a mile on delivering my overall vision for my game. This last post is a quick rundown of what I thought was most notable about my final architecture, with a focus on the camera and procedurally generated bitmap caching that enables scenes like this one to be rendered at 60fps in Canvas2D contexts:

Camera that caches

As background, I set a few requirements for my game at the onset which took some creativity to meet:

The rendering of shapes was to be done using Canvas2D, not WebGL. Otherwise the project would quickly swell in size since the WebGL API is so verbose (also, I didn't have time to learn all that I needed to make a WebGL renderer from scratch).
The game entities were to originate in Blender. That way, I could quickly design and iterate using a GUI, and export objects and revisions directly to my game.
The geometries were to be in 3 dimensions. This was just a personal challenge to myself and reflected the isometric style I was going for.
The game was to run between 45-60 FPS. Despite the complexity in my 3 dimensional geometries, I was certain that I could still write a performant game if I was able to unlock the GPU acceleration behind many Canvas2D implementations.

In part 2 I wrote about the construction of my 3D engine. However, in order to get it to operate well in Canvas 2D I knew I needed to offload the vast majority of the work to the GPU. The geometries I ended up creating in Blender typically had between 6-17 faces consisting of 3-8 vertices each. It was infeasible to have the CPU calculate the vertex position for each point during each frame.