Chip-8

I wrote this C++ CHIP-8 VM/interpreter because I wanted to experiment with cmake, QT and learn about emulator development. This project combines it all!
The project is fully functional, except for sound. However, I'm doing my graduation work on gameboy sound and will probably add sound support here afterwards.

Emulation

Opcodes are the heart of any emulator (or cpu). For Chip-8 each opcode is 2 bytes (big-endian) consisting of bits to identify the opcode and bits that contain data. For example, "00EE" returns from a subroutine and "2NNN" calls a subroutine at whatever value "NNN" has. The following code is used to identify an opcode and know which function it relates to.

We can then simply loop over a vector containing our OpcodeDetails and call the appropriate functions like this.

Sprites

Chip-8 has an interesting way of handling sprites and collisions. Drawing a sprite uses opcode "DXYN" which provides us with both the registers for the x and y coordinates and the height of the sprite (n). To actually draw the sprite, we read a byte for each row in the sprite (n) at the memory address stored in I (this is a special 16bit register meant to store memory addresses). Each bit represents whether or not a pixel is white. The pixel is then xor'ed onto the display, if an older pixel is unset, a collision flag is set for later use. This way, we can draw sprites that are 8 pixels wide (1 byte) and n-rows long.

In the code snippet underneath, vm.Vx is the virtual machine's array of registers.

QT

The hardest part of setting up QT for this project was figuring out how to render the emulator's viewport. I tried opengl but eventually decided that was overkill and settled for the built-in QPainter class. In the end, I made a widget that inherits from QOpenGLWidget and overrides the paintEvent method like this.

Cmake

The cmake for this project ended up being really simple. The CMakeLists for QT is almost entirely managed by QT creator. The Chip-8 part is compiled as a stand-alone library like this.

We then tie together the project like this:

EasyTextures

Description

Easy textures is a small (2 files) plugin that allows users to drag and drop an image into Maya to use it as a texture. Much like the behaviour in 3dsMax. Next to automatically creating and applying the shaders, the plugin also keeps track of the existing ones to prevent duplicates.

Automating shaders

The heart of the program is creating a shader, which I do like this:

Drag and drop

We change the default drag and drop behaviour by overriding the "performFileDropAction" function. I altered Meatplowz' gist for this and kept his implementation for the "open", "import" and "reference" buttons. The following condensed code snippet shows the "apply texture" button that I added, and how I managed to execute my python script from MEL.

NOX

Description

Nox is a 2,5D atmospheric puzzle platform game set in an 80's arcade. Made for the DAE course "game projects". Most of the codebase is written in Unreal C++, although we also used blueprints when that made more sense. The entire project was under perforce version control.

Team

We were a team of 2 programmers and 4 artists (Both me and the other programmer had no prior unreal C++ experience). Everyone put in around 80-100 hours. I myself did most of the gameplay programming, including:

• Pushing/Pulling
• Spiderwebs that lock objects
• Climbing
• Ziplining
• Rope splinemeshes
• Collectables base
• General purpose levers, easily extensible in blueprints for our level designers
• Bossfight (generating leg movement through IK, spider-pushable and spider-player interactions)
• ...

The Crunch

Game Jam

I made this game with a good friend for the Ludum Dare 42 game jam. This was before I started studying at DAE and even though I knew a decent amount about C++, the good practices were definitely not there.

Mistakes

There's so much wrong with the codebase that I can't possibly give you focused code snippets. Restarting the game was an afterthought I fixed with a goto, causing the biggest memory leak imaginable. I knew about constructors, but not about the initializer list and didn't use the destructor. So goodbye RAII principles and hello even more memory leaks! The Spaceship's render method wasn't const and has a shocking amount of gameplay logic in there.
The list goes on, really.
(You can find the code via our LDJam page, but I won't link to it directly to prevent people from opening it without reading this.)

Conclusion

I guess the reason this project is still on my portfolio is simply that it was my first "real" game, we did a pretty good game jam even though our skillset was lacking to say the least.
It's also an indicator on how far I've come since then and a reminder of why I got into videogames.

Tug of TAR

Tug of Tar is a game where two people can place space stations in a shared AR-space to have epic battles over precious oil.
We used the Unity engine, MLAPI (now called Netcode for GameObjects) for networking, Azure spatial anchors to synchronize our shared spaces, tested MRTK for our client and version controlled everything with perforce.

The team and responsibilities

We were a team of 3 programmers and 2 artists. Initially, my main responsibility (next to game design which we all did together) was everything networking related. We used the old Netcode for GameObjects (when it was still called MLAPI) library for this.

As the project continued, I took care of the backbone while the rest focused on gameplay. I tried to make all our systems play nice together and ensured everyone's features would still work in multiplayer and AR. When the project grew more stable, I also ended up making most of the logic for the HUD.

Videos!

Team members

RUIN

Can't wait to share more. More info coming soon.

IO Interactive

I became the sole maintainer of all core audio tech at IOI immediately after university. Despite starting as a junior, I increased stability and quickly earned the confidence of my colleagues. This led to a very strong rapport with the sound design team and fast-tracked my growth into architectural-level decision-making.
While it was an intense start in the industry, we have since grown to a team of three, allowing us to bounce cool ideas over lunch!

What I do

I am responsible for everything from a sound designer's work in Wwise, to its final playback at runtime. This means providing a user-friendly, and more importantly, bulletproof API to our gameplay programmers as well as providing the sound designers visual scripting capabilities that bring as much freedom as possible, while introducing minimal risk. (A good system is defined, not by what it can do, but by what it can't do!)

Besides working together with sound design to try and make their lives easier, I think my biggest mark at IOI has been in terms of stability. Since I began my journey here, I have been steadily re-architecting the sound engine. Clearing up and solidifying interfaces, reclaiming ownership of resources audio should have never exposed and ultimately redesigning our propagation tech to be concurrency-friendly. My efforts brought audio from one of the most crash-prone modules, to a model of stability.

References

I'm sure some of our sound designers or senior programmers wouldn't mind sharing how they've experienced our collaboration. References available upon request.

Gameboy sound [WIP]

I'm doing my graduation work on gameboy sound. The minimum goal is to have an emulator play sound. I'm still looking for a research question and interesting topics to explore later on. It might be interesting to hear how the music sounds when you apply more modern sound processing to the emulator for example.

Relevant topics

I can reuse what I learned from the chip-8 emulator to know which opcodes to add/implement. I'm also looking into how PCM works and how to play back generated waveforms through SDL.