Projects / Experiences

I wanted to add real-time physics multiplayer support to an audio-visual experiment that I started making earlier to learn the Rust programming language. It turned out to be a great opportunity to learn about Rust API conventions, open-source library maintenance, and some game networking concepts.

As part of a fourth-year agile software development course, a team of 8 of us developed an online platform within 3 development sprints to give public access to some Maori and New Zealand text-to-speech systems that Dr. Catherine Watson and her colleagues have been working on internally. Dr. Catherine Watson was our client for this project. I primarily contributed on the initial UI mockups (in collaboration with Brian), setting up the docker configuration files, and testing various backend components.

This was a simple file system implementation using FUSE, submitted for a third-year operating systems course.

For our third-year software design course, a team of 7 of us built a Unity city-building game to help build awareness about climate change and the tradeoffs that need to be made in a demanding world. In addition to contributing to the game logic, I also helped out with the sound effects and the simple background soundtrack.

For our second-year software design course, Harman and I co-created a desktop application that helps people pronounce names.

This is an early terminal-based prototype for the NameSayer project for our second-year software design course. I incorperated a bit of ncurses tput into my script to provide a text-based user interface.

A NodeJS and browser-based project, started and maintained by Fabian Hemmer, that emulates x86 hardware.

I implemented the Sound Blaster 16 card, completed the VGA controller, and fixed some PS/2 keyboard and mouse bugs. I plan to complete the sound card emulation, and I’ll keep a close eye on the project.

We had a CAD competition for one of our first-year engineering design courses. Unfortunately, I have no idea what the results of that competition was.

A website! I thought: a new year, a new school, welp time to throw the MS Frontpage and whatnot out the window and pull something real together. For what purpose? Well, apparently we need to coexist in both the physical realm and the digital realm. I find it a bit difficult to split myself into two and inject one half of my consciousness into a bunch of silicon, so here’s a website as a placeholder for my presence instead.

I find that I’m not a fan of using ‘prebuilt’ themes. Morally, it’ll be equivalent to using someone else’s hard work. Practically, it will be difficult to extend the theme with consistent quality. Finally, it’d be both fun and nicer if I tried creating my own identity of some sort. Hence, this weird looking, non-responsive website looks the way it does.

I was pretty committed back then but was nonetheless plagued by my over-ambitious attempts at introducing modularity to what should’ve been a simple program for controlling the robot. As a result, I hogged most of the development time and mechanical failures occurred as often as bugs.

The programming aspect was interesting as it had to deal with autonomous routines, drive controllers, flywheel regulators, and data loggers. It was the first time dealing with PIDs and control theory, and I must say that the robotics platform really got me excited about engineering, and was the reason why I chose this degree.

I was also the ‘team captain’ in 2016, but leadership is hard. Our team faced obstacles such as high school exam stress, lack of feeling of success, pessimism, technical inexperience and difficulty, conflicts of interests, all those things just piled on top of each other and the season finished quite crazily, to be honest.

A simple, human-readable communication protocol, a server, and a simple browser app for displaying and controlling subsystems within a Vex EDR robot.

A tool (with potentially zero use cases) that executes a given shell command and loops the stdout back into stdin.

Simulates a simple clawbot to give the team driver opportunity to practice before a real physical robot is built.

A little electronics/raspberry pi project using LEDs as photodiodes that can be used to measure when an object travels past the photogate. It can be used to measure the velocity of an object and the RPM of a spinning object.

I had the privilege of attending the 2016 NZOI summer training camp at Victoria University down in Wellington. I met quite a few awesome people there, and they taught us some really nice compsci stuff, all within a pretty short time to be honest. But most importantly, we were fed well by the catering team at Victoria House. Of course, I didn’t make it into the training squad (especially how I scored zero points in the final competition), but nevertheless, I had plenty of fun.

I had a chance to try out this competition which was held throughout the year. I immediately regretted not knowing it’s existence earlier. Kudos to those who run and manage it.

The translational position of the output linkage is equal to the sum of the translational positions of the input linkages. Pretty cool? Yup. Useful in real life? Nah.

You know when you’re playing a platform game, such as Super Mario Bros, you can make small jumps and big jumps. I never thought about the mechanics until I tried making a game, but, how does it actually work? You see, when you try to jump in real life, once you have left the ground you can no longer control how high you want to jump. Turns out there are some pretty neat tricks used in games to create an illusion that the sprite is moving in a parabola with variable height, and make it appear as if the game magically knew how high the parabola needed to be before you jumped. When I found out how other games have solved this problem, I got so excited that I even posted on gamedev.stackexchange!

My game itself had some features that I thought was pretty cool at the time. There were sound effects and disgustingly low-quality piano game music that I ‘composed’. The art was the best: MS Paint. I even animated the googly eyes! I’m glad those days are over.

I was always fascinated by digital technology. I remember borrowing this book called ‘Practical Electronics for Inventors’ by Paul Scherz, even though I didn’t understand half of it. The bit that I did find particularly interesting was the chapter on digital electronics. Computers seem to make much more sense ever since reading that chapter.

I was inspired by a person called Randomwraith to attempt modelling functional logic gates using lego. His creations were fascinating. My ones, err, barely worked. But nonetheless, it taught me some interesting things, especially something that was later formally taught as De Morgan equivalents.

When I was young, I was overly ambitious in attempting to simulate the world with physics. Ah, the grand dream. Unquestionably my attempts completely missed the point. Especially so when it was used for my year 8 science fair (which, by the way, took me years until I figured out what science fair was really about since my ego was tragically way too high to notice it).

This was nothing more than a maths homework with some GUI over a table, and a simple piece of code that loops over each row, calculates the expected costs, and displays the row with the minimal cost. I’m surprised how inefficient I made it.

It could’ve been worse.