Game Boy Emulator: Project Update

I'm excited to announce two big things! First, the emulator can now play most Game Boy games with minimal issues! Secondly, the emulator is now open source on github! Go check it out at the following link,

Github Repository: https://github.com/Salgat/GameBoyEmulator-GBS

Above are some screenshots of the emulator in action (The Legend of Zelda: Link's Awakening, Pokemon Red, and Super Mario Land 2: 6 Golden Coins). As of now two apparent issues occur: First, upon first starting the game, graphical glitches occur. Second, the timing is off which is most obvious with the scanline, which is out of sync and causes a slight graphical glitch. While the instruction test ROM works fine, the instruction timing ROM fails.

Additionally, even basic interface features are missing. The big issue that was holding me up for the past week was an issue where some games would randomly crash when trying to load a new section of the game. When checking the logger for my emulator and comparing the assembly instructions and memory state against BGB's emulator output, I was finding that the ROM was reading from the wrong memory bank. Unfortunately, nothing in the memory bank controller code looked wrong. I ended up having to log the entire output of the emulator up to the point of the crash, which included the register data, program counter, and some other relevant data, and stepping through BGB's emulator, instruction by instruction, until I could find the discrepancy which took about an hour to do. Eventually, I saw a point where the vertical blanking interrupt vector would trigger and set the wrong memory bank. It was only for a few instructions and not something I expected, but when the LCD is disabled, the current horizontal line stops incrementing. This isn't in any of the documentation I came across, so I'm guessing it's just assumed that you would know this. Unfortunately, I didn't make the assumption but thankfully the problem is now fixed.

While there is still a lot more work to be done (including adding more memory controller support), I'm glad to say that the emulator works on most of the games and works well! It's awesome seeing my favorite games from my childhood running in my own homegrown emulator.

Game Boy Emulator Update

Tetris running on the emulator, showing the graphical glitch it has with sprites.

On week 3 of this project, and am excited to say that the Game Boy Emulator can now play *some* games! As of now it is only failing for the "HALT" instruction, with all other instructions passing Blargg's CPU instruction tests. Additionally, rendering of the background, window (untested), and sprites are implemented. The above picture shows the one problem with sprite rendering for now: Sprites do not render on the bottom 16 pixels of the screen and worse yet they sometimes render a bit funny. With the current progress of the emulator, you are able to play Tetris, which is pretty awesome considering this is not just my first game that works on the emulator, but was also the first game I received when my Dad gave me my Game Boy over 15 years ago.

New Project: Game Boy Emulator

Game Boy Emulator running a "test rom" which tests instructions to see which work

Over the past week I started one last big project in my spree to test out what I can do these past few months. As seen in the above screenshot, I've been working on a Game Boy emulator! As with my past projects, the only dependency is SFML which I use for rendering (I'm thinking about splitting up the project into two to remove the SFML dependency, since the SFML code is literally a few dozen lines).

The project has been pretty smooth so far and I'm able to run very basic ROMs but am still a ways off from running full fledged games. Probably the most difficult part of setting up the emulator is that you need quite a lot already established to run even the most basic ROMs, and on top of that I had to manually implement over 400 instructions for the modified Z80 processor being emulated, which took 3 days of grunt coding to finish. Thankfully, I was able to use Imran Nazar's jsGB emulator as a base off which I implemented the instructions. Unfortunately, while a good reference, I had to use another reference to go over every instruction and correct mistakes I found, which were quite a few and a bit frustrating (and I'm still not sure I caught all the mistakes).

At least for me, it's almost guaranteed that writing hundreds of instructions will result in some typos and mistakes, which is where test roms come into play. Thankfully, there exists an entire suite of test ROMs that test all the instructions and features of the Game Boy to see if it is compliant. I've been using the BGB emulator's debugger as a base to compare my emulator to. I go through each instruction and make sure they, and the registers, match BGB's.

On GitHub there is a private repository for this project setup, and hopefully in the next few weeks I can make it public. This project really takes me back because the Game Boy is my all time favorite console, and it's really fun to be able to implement my own take on it.

New Library: SerializeQueue

Recently I completed the first draft of a new header only C++14 library I've been working: "SerializeQueue". The basic idea is that you push all your values onto the queue, serialize it to a binary file, then later load and deserialize the binary file back into a queue to pop data off of.

Github (project page): https://github.com/Salgat/SerializeQueue

This library has been especially fun because I've had a chance to delve into several programming tricks I wasn't familiar with before. The first and most basic is a method for converting a binary value into the specific type to be returned. SerializeQueue supports T pop< T >(), which, using type information, pulls the top information off the binary file and converts it to the type given. To prevent any compiler intervention, the binary is loaded directly into a uint64_t variable and then the following is done,

What this does is it takes the address of the variable, treats it as a pointer, then tells the compiler to treat that pointer as a pointer to a different type before dereferencing it.

The next "trick" I had to use was something called tag-dispatching. The purpose behind tag dispatching is that, for ambiguous cases, you create a way for the compiler to distinguish between two different overloads. Below is an example,

These functions are inline, and the tag itself is just an empty struct, so it ends up being optimized out of the program which eliminates the overhead of the tag. The basic idea behind this, for cases of std::vector, is that a special overload exists that accepts a tag of std::vector among other types specialized for.

The last and current problem I'm working on is implementing tuples. Tuples are difficult because it is a container that holds multiple data types, and requires template metaprogramming to implement. I just started reading Modern C++ Design to try to get a better grasp on this new programming method, but it's definitely a wall that I've hit with what I can do. Hopefully I can come back and flesh out the tuple implementation once I learn more about how to deal with generics. For now this library only supports tuples of basic types.

Game Release: BubbleGrow

Main Menu

After a month of development, BubbleGrow is finally ready to be released as open source. BubbleGrow is a simple game whose gameplay revolves around building an army of bubbles to gather resources and fight against other players, with the winner being the last man standing.

Github (project page): https://github.com/Salgat/BubbleGrow
Documentation (wiki): https://github.com/Salgat/BubbleGrow/wiki
Download (64 bit): https://github.com/Salgat/BubbleGrow/raw/master/BubbleGrow-V0.1-Windows-x64.zip

BubbleGrow's only dependency is SFML, which, along with only using the standard library, makes this game cross-platform across Windows, Linux, and OS X.  It's been tested on both 32 and 64 bit platforms with no performance issues (even ran it on an old dual core Pentium from 2007 with embedded graphics). BubbleGrow takes advantage of OpenMP to support multithreading up to as many cores as you can give it (assuming you have up to 1 thread per player, or up to 16 threads for default gameplay). The beauty of OpenMP is that it won't prevent compilation on compilers that do not support it, since it only uses preprocessor pragmas which can be ignored.

Gameplay: Two players battling each other

This game is almost completely licensed under the MIT license, with the only exception being the audio and font, which have their own licensing. The source code is completely open and free to modify, and for anyone who chooses to use the source code, they can do it without any requirements as long as they do not redistribute the source code without the MIT license.

Enumeration Iterator Library (EnumIt)

In the new game I'm making, I've been using enumerations along with constant arrays for some quick configurations and needed a quicker way to iterate through all available enumerations (for example, when loading images who are identified by their enum class value). I created an enum iterator library (EnumIt) which is a single header file. It comes with functions to get an enum's Begin and End iterator and also provides an interface which supports ranged-based for loops. Although very simple, hopefully it will be helpful to someone else. Below is an example which can be found on the github page: https://github.com/Salgat/Enum-Iterator

 #include <iostream>  
 #include <string>  
   
 #include "enumit.hpp"  
   
 enum class SampleId {  
   FIRST,  
   SECOND,  
   THIRD  
 };  
   
 /*  
 enum SampleId {  
   FIRST,  
   SECOND,  
   THIRD  
 };*/  
   
 int main() {  
   for (auto iter = enumit::Begin<SampleId>(); iter != enumit::End<SampleId>(SampleId::THIRD); ++iter) {  
     SampleId entry = *iter;  
     std::cout << "Current SampleId: " << static_cast<int>(entry) << std::endl;  
   }  
   
   for (auto entry : enumit::Iterate<SampleId>(SampleId::THIRD)) {  
     std::cout << "Current SampleId: " << static_cast<int>(entry) << std::endl;  
   }  
   
   return 0;  
 }  

New Project: BubbleGrow

In game screenshot

A couple weeks ago I decided to do one more project before going back to developing my other game. From the above screenshot, you can see a preview of the game, titled "BubbleGrow". The basic idea is that you collect resources (green bubbles), purchase and upgrade your bubbles, travel around the map, and fight other players (such as you (red) fighting the computer (teal) in the above screenshot). The arrow indicators on the edges of the window show where other players are.

The goal for this game isn't so much being fun or for selling, but as a free and open-source project for learning. I've been using GitHub for revision control. I've kept the external dependencies to a minimum (only SFML at this point) and licensed everything (including the artwork I made) under the MIT license, so that anyone can use anything from this project for whatever they wish.

Mock-up main menu (only Quick Match games are currently supported)

The game is structured in a simple manner, is well commented, and is designed to be easy to dive into. To break it down quickly, there exists a "World" class that holds all players, a "Player" class that holds the state of each player, and a "Unit" class that holds the state of each bubble. There is a single subclass ("Resources") that is a specialization of the "Player" class in that it handles those green resource bubbles that the players can mine for purchasing units. The only other class is a "Renderer" class that handles the display and input. I plan to expand the "Renderer" class since it's approaching over 500 lines of code and has way too much scope. A few additional classes are needed to handle sound and batch drawing.

As a learning resource (which is the whole point of making this open source) I hope this project allows people the chance to learn how to download and setup a build environment for a medium sized project. I plan to heavily document instructions for new programmers to be able to build and modify the game. As of now, all that's needed to build BubbleGrow are the library and include files downloaded from the SFML website, CMake, Make.exe, and MinGW.

The different bubble types you can purchase and upgrade to

Additionally, with the way the program is structured, it should be easier for newer programmers to dive right in and start changing things. The entire game state is focused around 3 major functions, "Update" which updates the unit's health and other stats, "MakeDecision", where each unit has a view of the game state and submits a Request for processing, and "ProcessRequest", where the Unit executes either its current action (such as finishing an attack) or starts a new action based on the Request (decision) it just made.

Finally, as a bonus, this game supports multithreading using OpenMP, which is awesome because it is both cross-platform and compiler safe (since OpenMP uses pragma compiler directives which will simply be ignored if not supported) and because this is accomplished without using any threading libraries. While it would have been nice to use a concurrent container from a library like Threading Building Blocks, by following certain rules (such as only calling const methods on containers that don't modify the internal state of the container) and setting only a few variables to atomic, thread-safety is maintained.

Anyways, progress is rapidly underway and I hope to finish it in the next couple weeks. It's certainly a fun personal project and hopefully will be helpful to others!