It's been a while since I've put something new on this website. That might give the impression that I haven't kept myelf busy over the past three years or so, but it's more that the nature of my work has changed. All of the prior work I have here was completely self-motivated, made using abilities that were mostly self-taught, and were not part of any organized course or curriculum. Since I entered college, however, I've been mostly satisifed with the assignments that I do for class, which have included a Kiosk application for Brigham and Women's hospital in Boston and a robot that delivers pizza. I don't publish most of the source code for these because professors often reuse projects or parts of projects for future terms and I don't want to just publish the answers on the internet. However, I've recently been working on a personal project called SlippiMusic which is more fitting for this website than my course projects, since it's completely Free software and is meant to be useful to other people.
I've been playing Super Smash Brothers Melee competitively for a little over three years now, and while in-person events are certainly preferable to online ones, playing the game online is still preferable to not playing it at all. Recently, some amazing developers have created a modification of Dolphin which allows for Melee to be played using rollback netcode. Most Netcode works by running a separate instance of the game on both players' computers and having each host send their inputs to the other. There is a fixed delay for all local and remote inputs, and if a remote input takes more time to arrive than the delay, the game freezes until it recieves the next input. However, this "delay-based" netcode is generally considered inferiror to "rollback netcode", where the game continues running while making guesses for the opponent's missing inputs. If the receieved inputs are different from the guess, then it "rolls back" the game and recalculates the characters' positions based on the received inputs. Project Slippi is an impressive implementation of Rollack Netcode for melee, but since we don't have melee's source code and use an emulator to run it, is rather imperfect; anything that is loaded from the disc and into memory at the start of the game works fine, but things such as stage music which are loaded from the disc during the game don't work. A lot of Melee's music is incredible and was recorded by a live orchestra. For many people, it's an important part of playing the game, so I created SlippiMusic to help improve the emulation of Melee while playing it online. The goal was to create a program that watches a running instance of the Dolphin emulator to determine which track should be playing, and plays the correct one.
I decided to implement this using Python since I believed that it would be fairly easy to play music through Python relative to languages such as Java or C++. To improve compatability with multiple operating systems (particularly MacOS) and with future versions of the Slippi Dolphin emulator, I communicate with the emulator using its local spectator feature rather than by directly reading the program's memory. On startup, the emulator starts a server for local spectators to watch a game in progress. This is meant to be used for streaming tournaments and therefore just sends a byte stream of data from the game, but I was eventually able to parse this into the information that I needed: game start, game end, and the stage. With this information, all I needed to do was play music. I tried a few audio libraries for Python, but found that Pygame has the best performance due to its ability to loop tracks well and queue up future tracks, which is crucial for properly emulating Melee's music. Like most video games, Melee's music has an "intro" section and a "looping" section; the intro section is played once and the looping section is played forever. Pygame doesn't directly allow for looping in this way, but by keeping the "looping" section queued as the next song to play, pygame is able to seamlessly play the music files as they sound in game, as long as they are cut at the loop points, which can be extracted from the game itself.
Releasing something for other people to use comes with challenges that aren't present in any of my school assignments. For one thing, I needed better error handling in general than I would in my school assignments. The program should work in many different environments and should give a plain English description of any problems which occur. It also needed to work on multiple operating systems, though I was working at such a high level of abstraction that most of the code didn't require big changes to be cross-platform compatible. I also need to maintain it and fix bugs. Until release 1.2.1, there was a crashing bug caused by some of the CPython code that Pygame uses to play music not respecting Python's GIL, forcing me to make the whole program run in a single thread. I've also fixed some other issues with the program, such as the timing of the menu music as well.
So far, with the exception of a GUI for configuration, I've added all of the features that I want to, but if someone makes a good suggestion or if I think of something else, I'll definitely consider adding them. Based on analytics data from the first month or so after my release, I would estimate that about ~30 people or SlippiMusic to improve their experience of playing Melee online, and while that isn't a large number, there's something exciting about having your code run on someone else's machine. While this project is nearing its completion, I hope that it will be the first of many useful programs that I write on my own or with a team throughout my lifetime.