Portfolio - Andrea Radaelli

Music Reactive Led Matrix

Sun, 30 Jan 2022 00:00:00 +0000

Introduction

For New Year’s Eve 2021, I decided to build a LED matrix that would react to the music being played.

I got inspired for this project by visiting the Cyberdog store in Camden Town. I wanted to recreate the same feeling I had when seeing for the first time the awesome DJ booth they have in the basement.

I started planning and building it one month before. However the project was too ambitious for my experience with electronics, I made a few mistakes and I had to cut the features short to meet the deadline.

I am very proud of the final result, I managed to implement the main effect I saw in Cyberdog and make it work just in time for new year. It was far from perfect but enough to create the right atmosphere:

The Original Plan

My initial requirements were:

build a LED matrix by cutting up a few meters of LED strips
use an ESP32 microcontroller to drive the strips
have an app on my smartphone to create the animations in sync with music
make the app and the ESP32 communicate via Bluetooth LE (partially reusing code from my previous project)
be as portable as possible
budget of £100

The biggest cost would come from the LED strips so I checked EBay and decided to buy 20 meters of WS2812B Addressable RGB LED strips with a density of 30 LED/meter. With that I could create a 20x30 matrix and if I spaced each strip by 10cm I could make it 2x1 meters big. Big enough for a strong impact.

The WS2812B LED strips work with 5V. I estimated that 600 (20x30) LEDS would need a big 200W 5V power supply and thick wires to sustain the amount of current needed (about 36A assuming each LED consumes 0.06A at maximum brightness). To avoid buying the power supply and the thick cables I decided to just use my bench power supply instead, with a higher voltage (12V+), and then connect a few buck converters right before the LED strips to bring the voltage down to 5V.

The LED strips come with adhesive tape so I decided to stick them on a frosted vinyl film in order to be able to roll everything up when not in use. The frosted finish of the vinyl film helps hiding the cabling, leaving a cleaner look.

On the software side, I could build upon the code of my previous project and extend it to transmit an RGB matrix from my phone to the ESP32 which would in turn transmit it to the LED strip. In the app I could make some nice animations that would use the sound from the microphone as input.

With all this in mind, I ordered the material, waited for delivery, and started building.

Assembling the LED Matrix

Mistake 1: Bad Power Estimations

My biggest mistake was over estimating the power capacity of the buck converters.

I had experience with the super compact “Mini 360” buck converter and I remembered from its spec that it could output up to 3A.

I had read somewhere that a single WS2812B LED could consume a maximum of 0.06A, so two strips of 1m should consume a maximum of 2 * 30 * 0.06A = 3.6A. I thought 0.06A was probably an extreme case and that the real limit would be lower so I decided to connect each Mini 360 to 2 strips.

However, I overlooked the fact that 3A was the peak output of the Mini 360, only sustainable for a short period of time. In my practical tests the Mini 360 becomes dangerously hot over 1.5A and I realized that only when testing the LED matrix after all the soldering and cabling was done.

The deadline was close, un-soldering and re-soldering everything to add more Mini 360s would mean hours of work which I simply didn’t had. In order to avoid missing the deadline I added some code to the ESP32 that would automatically limit the maximum brightness of the LEDs thus reducing the maximum current to a safe limit.

Lessons learned:

double check the specifications of your components
thoroughly test a subset of your project before soldering everything
if you underestimate the power you may be able to scale down the usage your components and get away with it 😉

Mistake 2: Mixing 5V and 3.3V Logic

The WS2812B LED strips are driven by 5V data signals. The ESP32 uses 3.3V, so common sense dictates that you need a level shifter to interface the two. However this was not apparent to me because the LED strips work quite well most of the time even with a 3.3V input.

This is because 3.3V “high” signals are high enough to be recognized as “high” from 5V components, most of the time. Glitches and flickers start appearing when refreshing the LED strips at high frequency:

However, I disregarded this problem as either some weak soldering or wrong voltage levels on my buck converters and went onward finishing building the LED matrix. Only at the very end, when I took the time to properly debug the issue I found the actual cause of the flickering.

Since I did not want to wait for the delivery of a level shifter I started tinkering with the voltage levels of the buck converters and discovered that if I lowered the voltage of the buck converter that powered the first line of LEDs where the ESP32 was connected to, all the flickering would disappear.

This makes sense since I am actually making the LEDs work in a voltage range closer to the ESP32. This ‘hack’ works but it left my first two strips emitting a slightly different color than the rest. Luckily it is hardly noticeable when playing fast animations.

Lessons learned:

3.3V and 5V circuits require a level shifter to interface them
lowering the supply voltage of the 5V circuit (in this case) is enough to get away with it 😉

Mistake 3: Assuming Real-Time Programming Is Easy

Another mistake I made was to underestimate the complexity of building the software to drive the LED matrix.

I assumed that extending the code I already had from my previous project would not take much and left it for the last week before New Year. I did the change fairly quickly but then I hit a serious problem.

The communication between my phone and the ESP32 is done using Bluetooth Low Energy. The ESP32 supports Bluetooth 4.2 which, configured with a large Maximum Transmission Unit (MTU) and the Data Length Extension Enabled (DLE), should about 478 KBit/s as measured in this article (see Case 3).

For my use case I would need to transmit the color for 600 pixel at least 30 times per second.

600 * 3B (number of RGB colors) = 1800B
1800B * 30 = 54000B = 54KB
54KB * 8 = 432KBit

432KBit are about 10% lower than 478KBit, so, when planning, I thought I would not have any problem.

However, reality is not that straightforward. The Bluetooth API are not really made for maximum throughput out of the box and optimizing both an Android app and the ESP32 requires reading lots of documentation and lots of trial and error. In the end, I did not have enough time to properly do it.

My initial tests showed miserable performances, in the range of 1 to 5 frame per second, with noticeable change in speed from time to time. That was unacceptable to show animations that react in real-time with the music.

Animations that slow are very hard to watch so I decided to create the animations directly on the ESP32 instead of my phone. That is not ideal because it is much faster to develop and release for a smartphone than a microcontroller.

With the short time left I chose one animation, the histogram of the audio frequencies, and hardcoded it in the ESP32. My phone would then only calculate the height of the histogram bars and send it. Since the histogram itself is very little (20B, 1 byte for each column) I could get away with my limited bandwidth.

I had to make the histogram on the phone because it was the only device with a microphone. The ESP32 by itself cannot listen to sounds.

For curiosity, the histogram is calculated using the Fast Fourier transform.

Lessons learned:

real-time task are a long process of optimization, plan accordingly
if you can’t meet the deadline, cut the features and you may get away with it 😉

Mistake 4: Dangling Power Cables

I guess this is one of the things one has to learn the hard way.

Much like in software development you never do tests in Production, in hardware you do not leave your “delicate” components close to “dangerous” equipment like a power supply.

When testing the LED matrix I had my power supply at 12V connected directly with alligator clips. My ESP32 was also nearby supplying the data to the LED strips. Accidentally, the data line from the ESP32 entered in contact with the alligator clips of the power supply, immediately destroying my ESP32 development board and a few meters of LED strips.

Luckily this happened quite early so I could wait for the delivery of a replacement ESP32 and new LED strips. I now make sure to always isolate my dangling cables with some masking tape.

Lessons learned:

isolate parts of your projects that operate at different voltage

Final Result

Here is a video that shows the internal cabling of the LED matrix. Before hanging it on the wall I simply folded the rest of the vinyl film to cover the circuit.

Final Result

Conclusion

When I turned the LED matrix on at New Year my friends were ecstatic. It made all the hours spent soldering and testing worth it.

I have learned a lot from this project. It is something I had never attempted at this scale and I am now working on improving it to match my original plan. Stay tuned.

Comments

Bluetooth RGB Light

Sat, 30 Oct 2021 00:00:00 +0000

I was scouting Amazon and eBay for a controllable light to bring to parties, but I was left disappointed. The low end market is full of low power lights which are not bright enough and are controlled through a lousy remote controller. To get decent devices you need to go in the high end space where you can easily spend a few hundreds quids.

So I thought I should come up with my own solution.

I started by coming up with a list of requirements:

Portable and battery powered
Multicolor
Powerful enough to light up a dark room
Controllable with a smartphone app
Programmable with custom effects

Given those requirements I started searching online for electric components that would fit the requirements.

Since the light would be battery powered, energy consumption is critical. The most efficient form of lighting is provided by LEDs. I wanted a multicolor light so it needed to be an RGB led. I settled on a 10 watts Chip-on-Board (COB) RGB LED.

For communication between the light and my smartphone I chose the ESP32 microcontroller which, for less than 5 quids, gives you: Wireless, Bluetooth, 32 KiB of RAM, and 34 programmable pins, Pulse-width modulation (PWM) signals, and much more which is not relevant for this project.

For driving the LED, I was initially thinking of buying 3 separate LED driver modules, but they are quite expensive (compared to buying the individual components separately) unless you order them from China through Aliexpress or similar. However that would mean waiting for at least one month for delivery, so I decided to build my own LED driver from discrete components. Comparing the chips that existing LED driver are using and the availability of those chip I settled for using the PT4115.

Only when the chips arrived I realized that I had ordered them in the Surface-mount technology (SMD) package. Those are intended to be soldered on a custom printed circuit board (PCB). However for my prototype I intended to use a simple soldering protoboard, so I had to solder “legs” to all the SMD components in order to be able to plug them in the protoboard.

Adding “legs” to the PT4115

The circuit to run the PT4115 is quite simple and a reference design can be found in the official specifications along with the rules to pick the side components.

For Reference:

DIM is the PWM control pin
CSN is the control sensing pin which helps the chip detect the amount of current going in the LED
SW is the switch pin which is turned on and off automatically to keep the right amount of current flowing through the LED.

PT4115 sample circuit

Initially I thought to build my own case for the light, but after a quick search on eBay I found many variations of outdoor flood lights which I could simply modify for my purposes.

Light Front

The light from eBay came with its own LED driver mounted on the back. It was quite bulky and unnecessary so it was the first thing I removed.

Original LED Driver

Then I proceeded to open the led compartment and finding out how much space I had to fit my own circuits. I was pleased to find out that the case was quite oversized and I had plenty of space to fit everything I needed.

Frame unmounted

Original LED

The next step was to build the LED driver. I used a small piece of protoboard and duplicated 3 times the circuit that I have showed earlier for the PT4115. In the next photo I have highlighted the small SMD resistors for “Rs”. It is not an elegant solution, but it works.

RGB LED Driver

I had to do the same trick of adding “legs” to the ESP32 module as well in order to solder it. For powering it I chose to use a premade buck converter module, the mini-360.

ESP32 WROOM

Then it was time to connect everything together and test the result. In the next video you can see that the the LED turns on only for a brief moment. That’s because as soon as the ESP32 finishes booting its pins enter a low state, effectively turning off the LED drivers and the LED itself.

Having verified that the circuit works I proceeded fitting everything nicely in the light case. I used the black tape to set in place some transparent plastic in order to isolate the circuit from the metal case and avoid shorts. The dangling cables that you can see taped at the top of the next photo are used to flash the firmware on the microcontroller.

Fitting everything in the light case

Next, it was time to write the firmware for the ESP32 so that it can control the individual colors and receive the commands from my smartphone. I read extensively the documentation for the ESP32 and found a couple of API for my use case: the LED Control (LEDC) API which allows me to output PWM signals and the NimBLE library for Bluetooth Low Energy communication.

After spending a couple of days understanding the examples from the documentation I managed to put together my own firmware that exposes one Bluetooth LE characteristic that directly maps to the 3 RGB channels of the LED. The code is available on GitHub.

The last remaining task was to build an Android App to connect to the ESP32 and send the light colors. I quickly hacked together a proof of concept that allows me to toggle the basic colors for testing, automatically switch between all colors randomly, flash the color at different speeds, smooth the color transition and control the light intensity (brightness). The code, again, is available on GitHub.

And here you can see the final result.

Overall it has been a fun project that allowed me to play with electronics and learn a lot. The prototype hits all my requirements but the brightness is much less than I expected. I think a proper flood light should be at least 50W to make a good impression. I’ll come back at this project and see if I can upsize the LED while still keeping everything battery powered.

Map My Mountains

Fri, 01 Feb 2019 00:00:00 +0000

Introduction

In Jan 2018, shortly after my graduation, I was offered a contract to work for a team of PhD students lead by Prof. Piero Fraternali. The team operated as part of the “Department of Electronics, Information and Bioengineering” inside the university of Politecnico di Milano.

I was hired to develop a Geographical Information System (GIS) from scratch to provide good quality data for an ongoing research project. The research project goal was to develop a Machine Learning (ML) algorithm to recognize mountain peaks from the Digital Elevation Model (DEM) of the earth. Essentially a fancy way to find mountains using the 3D model of the earth.

The outcome of any ML project is highly dependent on the quality of data used as input therefore it is worth to have a good pipeline in place that can clean and filter data.

Furthermore we planned to use the data produced by the new GIS for “Peaklens” (created by the same team) which is an app that recognizes mountains using the camera of your smartphone. It works great and it is completely free, you should try it out for yourself!

The Project

The project consisted of three main tasks:

Create a data model to store geographical data coming from different data sources with annotations and corrections.
Create multiple data pipelines to import publicly accessible geographical data sources into our data model.
Create a web application to allow human annotators to review the data and validate it through crowdsourcing.

Annotation View - 3D globe

1. Data Model

I kicked off the project with an iterative process of:

Collecting and defining the requirements as use cases.
Designing a data model to account for the use case.
Simulating the usage of the data model and finding new questions for the stakeholders.

The process required an interactive process with the people involved in the ongoing ML research project.

I sketched the data model as Entity-Relationship and iteratively improved until it satisfied all the requirements the system needed to support. You can see the final result here.

We had informal meetings to decide which database to use. The alternatives were either a traditional relational database (PostgreSQL) or a NoSQL document database (MongoDB).

In the end we decided to go with PostgreSQL because:

no need to scale (storage expectations <100GB, user base <100 people)
it supports geometrical types out of the box which are convenient for geographical data (points, polylines, polygons)
strong data consistency (the schema enforces types and relations)
we expected the need for multiple JOINs between different data sources and user annotations

Annotation View - 2D map

2. Import from Geographical Data Sources

Once the data model was defined, the next step was to import as much data as possible. For this reason I investigated publicly accessible geographical data sources, studied their format and APIs, wrote and tested scripts to download their data.

The data model is able to store reference to the unique original identifier of each downloaded element so we could have potentially contributed back to each source following the Open Source spirit of giving back to the community.

By the time my contract ended I had written scripts to import mountain peaks from:

View to toggle permissions per user

3. Crowdsourcing Web App

The last task was the development of a Web App to annotate and review the data. Here you can peek the requirements specification document.

For the tech stack we agreed on using Node Js for back-end and Vue Js for frontend, the main reason being keeping all the code base in Javascript. The web app was hosted on the private cloud of Politecnico di Milano which is based on Open Stack.

For visualizations I have used Cesium Js which provides interactive 3D globes and Leaflet Js for rendering 2D maps. For the UI I have used BootstrapVue which provides ready to use Vue components based on Bootstrap.

For the development process I have followed an Agile approach with 2 weeks sprints after which I demoed the new features and collected feedback for the next iteration.

I really enjoyed working on this project because it allowed me to get full-stack development experience and also some planning skills as I was fully entrusted in defining my tasks and delivering them. During the project I also mentored a student who then helped me in some development tasks.

View to create new crowdsourcing campaigns

Live Demo

Before writing this article I decided to host a live instance of the Web App on Amazon AWS so that you can could see it live. I contacted Piero who kindly gave me permission to share the source code of the Web App for my portfolio, since it is not in use anymore.

“Resuscitating” a project that is “only” 3/4 years old proved to be more difficult than I thought.

I expected it to be fully working as I left it. However simply running it locally, using the latest stable Node Js resulted in some weird connection issues with the database that kept making my unit tests fail. I traced it back to the NPM library I used to connect to the DB (pg-promise) and updating it fixed the problem promptly.

I have also fall victim of a strange bug where the Vue CLI Service did not exit after finishing building the production bundle. This didn’t cope well with my goal of having a CI pipeline because it makes the automated process hang and timeout. I fixed it again with more targeted package updates.

I have tried updating all the NPM packages at once but that resulted in many incompatibilities appearing between my code and the new packages. Since I did not want to spend time fixing code, I only did targeted updates for specific packages.

This proved me how unstable is the entire NPM/Node Js ecosystem. Today I rather use a self-contained web framework that provides everything out of the box such as ASP.NET, Django, Ruby on Rails, or Laravel, and stay away from the dependency hell that is the Javascript ecosystem with NPM.

For hosting the Web App I have used: Amazon RDS for the database (I created a PostgreSQL instance), Amazon Elastic Beanstalk for the back-end REST API, and Amazon S3 for the front-end (configured to serve a static website). Both the back-end and front-end are served on vanilla HTTP to avoid having to deal with SSL certificates.

Overall the setups works quite nicely, it fits well within the limit of the Amazon Free Tier. It also has continuous deployment thanks to Github Actions.

You can find the live demo at: http://mapmymountains.aradaelli.com

Source code: https://gitlab.com/wds-co/mapmymountains

Credits

I want to mention the whole team at Politecnico di Milano with whom I have worked from 2018 to 2019. In 1 year I have learned a lot and I still have a great relationship with them:

Piero Fraternali (Website-Linkedin-Google Scholar)
Chiara Pasini (Linkedin-Google Scholar)
Darian Frajberg (Linkedin-Google Scholar)
Carlo Bernaschina (Website-Linkedin-Google Scholar)
Nahime Torres (Linkedin-Google Scholar)
Sergio Herrera Gonzalez (Linkedin-Google Scholar)
Federico Milani (Website-Linkedin-Google Scholar)

Product Configurator

Fri, 01 Sep 2017 00:00:00 +0000

Intro

In parallel to my master studies I enrolled in an honor program called Alta Scuola Politecnica. The greatest thing about this program has been the graduation project which consisted in a collaboration with a real business.

I joined a team of brilliant colleagues, from different backgrounds in management engineering, mechanical engineering and physics. Together we acted as a consulting team for a business, understood their problem, performed a research about the state of the art and delivered a solution.

Screenshot of the website at the end of the configuration process

Background

The project I joined was sponsored by Inkmaker Srl.

Inkmaker is a global producer of ink dispensing machines. These machines mix ink to produce the exact color required for printing or painting products at industrial scale.

The ink dispensers are large and quite specialized machines. Clients may have strict constraints concerning the available plant area or uncommon requirements on the ink mixing capabilities. Therefore the development of each machine tends to be quite customized for each client.

However Inkmaker also have a portfolio of entry-level machines that address the demand of their smaller customer with just a few variations. The vision of Inkmaker was to enable their small customers to self design their equipment by providing a set of standard modules to be mixed and matched. Those modules could be combined producing different assembly combinations and layouts to satisfy most request with minimal involvement from Inkmaker, thus increasing the overall efficiency.

The solution identified by Inkmaker to realize this vision consisted in the development of a product configurator that would allow clients to design their own machines with a few clicks, resulting in reduced lead time and errors in order interpretations.

Screenshot of a machine assembly

My Contribution

My work was based on the results of my dear colleagues who took care of:

Analyzing the business processes of Inkmaker (sales, design, purchase).
Understanding the mechanical constraints of the product and define how to modularize it.
Developing a model for generating a machine starting from the client requirements using the available modules.

I applied my skills in two areas:

Performing a research of the state of the art of existing product configurators.
Implementing a prototype product configurator to showcase to Inkmaker.

State of the Art

My first task consisted in researching existing product configurators to identify the best ones suited for the requirements of Inkmaker.

I researched both:

Software available “off the shelf” that could be used to customize a generic product.
Established product configurators from major retailers to study their offering and capabilities.

I wrote a report that summarized the pros and cons of each product, their features, their user interface (UI) and their configuration process.

The outcome of the research lead to the discovery of a few products that were fit for Inkmaker use-cases. Here is a feature matrix comparing the products against our requirements:

Feature matrix comparing selected configurators

The best candidate “A” was Autodesk Configurator 360 (now discontinued).

Prototype

My second task consisted in learning the inner workings of Configurator 360, understanding how to integrate it in a customized experience for Inkmaker, and developing a prototype.

Configurator 360 was a cloud based software as a service (SaaS). CAD designs could be uploaded to it and then displayed through an interactive web widget.

I decided to build a web application that would first guide the customer through the configuration process, then calculate the best configuration for the ink dispenser, and finally provide the result to Configurator 360 which would then generate the engineering drawings, 3D visualizations, and bill of materials.

Screenshot of the website during the configuration process

The web application was built in C# ASP.NET with Javascript and JQuery for frontend. It was deployed on Amazon EC2 to provide a demo to show to Inkmaker. Customer details would be saved in a SQL database for reference and potentially integrate with the company ERP.

Architecture diagram

Credits

I want to credit the rest of the Modula team from which I learned a lot and together we delivered this fantastic project.

Alex Saja (Linkedin)
Alfredo Fantetti (Linkedin)
Arianna Rosa Brusin (Linkedin)
Giovanni Prencipe (Linkedin)
Sara Mottola (Linkedin)
Stefano Amato (Linkedin)

We Are Made of Dreams

Sun, 12 Oct 2014 00:00:00 +0000

Intro

For me, Minecraft could easily be the greatest game of all time. The main reasons being that it is a “meta-game”, a game that allows you to build other games.

Minecraft

The first time I played it I was confused by the absence of a story to follow or objective to complete. But the more I played it, the more I started to be addicted because I was building my own world and creating my own rules! The utter simplicity and freedom that a world made of blocks could create really impressed me. Furthermore, people online created (and still are creating) staggering detailed worlds and custom games using official and custom servers.

After playing Minecraft for a long time, I could not resist to try to build my own 3D engine and replicate the technology behind it. I read many articles which explained the inner workings of the game and then get to code.

When I got a prototype working, I was puzzled on what to make out of it.

I didn’t want to embark in making a full video game, so I decided to build a self-contained experience, a demo; or in simpler terms, an “interactive video”.

Analysis

The code is written in D as at the time I decided it would become my go to language after a long search for a modern alternative to C++.

Reading through the code today, the most interesting things are: the world data structure and the renderer architecture.

The world is implemented as an octree. An octree can be visualized as a giant cube that encloses all the space available for your world. Each node of the octree divides the space inside the cube in 8 sub-cubes. Then again each cube is recursively split in 8 more sub-cubes, until you arrive to the leaf nodes. A leaf node is the smallest representable unit of the world and it is represented as a single block on the screen.

Octree representation, source: mshgrid.com

An octree is ideal for a “Minecraft like” world for two reasons.

First, it naturally fits a world made of cubes beacause of its direct mapping of leaf nodes to world blocks.

Second, it is very memory efficient when there are big empty spaces because the leaf nodes are not required to exist at all in memory. That is in contrast to a simple three-dimensional array which would still need to allocate the memeory but mark all the empty elements as “null”.

The renderer is built using OpenGL3 and therefore it uses the modern rendering pipeline using shaders. The render is also multithreaded by using multiple worker threads that build meshes in real time every time a world chunk is modified.

Another thing I love is the built in map editor that allowed me to create the world that you can see in the demo.

Downloads

The source code is available on GitHub and it can be readily compiled on Windows and Linux. Pre-compiled binaries are also available.

Jump And Run

Fri, 02 Sep 2011 00:00:00 +0000

Intro

“Jump And Run” is a game I developed towards the end of high school and the first project I am really proud of.

I was always attracted by the idea of building my own game but I had never tried it before. I had some basic experience with graphics from reading books and articles online but I only dabbled with some small graphical demos that I made during the long boring ours in our school lab.

One day I decided to build proper game that would be fun to play with levels and enemies to kill.

The end result suprised me, it turned out that I could turn my ideas into reality just by putting enough effort into it.

Here is a gameplay video of the first level:

Background

When I was a kid the first type of video games I played were 2D Side Scrollers.

I still remember the two games which influenced me the most: Super Mario Land and Captain Claw.

Super Mario was the first game I ever played. I played it on a Game Boy which my cousins lend to me because my parents were against buying game consoles (“You would waste all your time!”, so true in hindsight).

Super Mario Land gameplay

Later, when the first computer arrived in my home, my first PC game arrived shortly after. Captain Claw was so difficult for me and I never managed to beat the second level until a friend of mine (who had an internet connection! I still had not) discovered that cheat codes were a thing.

Captain Claw gameplay

“Jump And Run” is my tribute to those games and the endless hours I spent on them. I drew the art myself using Gimp, downloaded the music from the Free Music Archive and sounds from Freesound.

Analysis

Re-reading today the code today I see a lot of “code smells” like huge functions and bad names, however keep in mind that I just finished high school when I wrote it :).

The game runs on a custom 2D Game Engine which I wrote in C++.

I appreciate how neatly the generic parts of the engine are split in virtual classes that make sense. The framework of the engine with its initialization code is separate from the game logic. I remember being deeply influenced from the code of famous game engines of the time such as Unreal Tournament and Quake 3 Arena.

To draw on the screen I used OpenGL and for playing sounds I used OpenAL.

I have forgotten how much time I spent rewriting much functionality of the standard library such as string and memory functions, file access, and various data structures. I was motivated by the fact that many game development articles recommended to avoid the standard library as it is not optimized for speed in most cases.

Map Editor

I was very proud of the built-in map editor which allowed me to build maps with my basic drawing skills that would become alive with sound and enemies.

The game world is composed of small squares. Each square has a background and foreground texture taken from a sprite sheet. Furthermore each square has a “type” property that can make it interact with the player by being solid, lethal, or a coin for example.

Particle System

Another thing I remember fondly is the particle system. It makes killing enemies very satisfying by releasing a swarm of “blood” particles which collide with the game world.

Downloads

The source code is available on GitHub and it can be readily compiled on Windows and Linux. Pre-compiled binaries are also available.