Jon Thysell

Father. Engineer. Retro games. Ukuleles. Nerd.

Tag: software

Making some retro games with LÖVE


I was in the mood to make some games this past week, when I discovered the wonderfully powerful yet lightweight LÖVE game framework.

After watching some videos on YouTube highlighting games others have made*, I set to work on one of my own. Within a couple of hours I had Pong running on my phone!

I decided I’d keep exploring the APIs by building a suite of simple retro games, the source of which I’ve uploaded to a new GitHub repo named RetroLove.

So far I have decent clones of Pong and Breakout. I’m thinking maybe Asteroids next. It’s so much fun, and the framework couldn’t be easier to use.

Check it out,

/jon

*: The story on how I found LÖVE is actually a little bit longer and shows the circuitous way by which I find myself doing these kinds of projects. I was working on another project, my first Universal Windows Platform app (that is, an app that runs on all Windows 10 devices). The project itself is something I’ve had on the back-burner for years, and I was primarily using it as an excuse to practice using XAML, which is the UI framework for UWP apps. (My day-job is on the XAML team at Microsoft, so using it myself only helps me to better understand our customers.)

Anyway, my app needed an embedded scripting language, and I wanted to use Lua, but I needed something that would work within a UWP app, which, because it needs to work on lots of different kinds of devices, meant I couldn’t use the native Lua libraries easily.

This led me to the very cool MoonSharp project, which is a Lua interpreter implemented entirely in C#. After I got that up and running, the app also needed a kind of visual editor, so I needed to do some 2D graphics work. It was then that I discovered the Win2D project, which makes it easier to do GPU-powered 2D graphics within XAML.

Then an idea hit me: what if I had a 2D game engine designed similar to retro consoles? Where the engine would be responsible for maintaining backgrounds, sprites, and drawing to the screen, and the game developer would provide the game in the form of a package of Lua code and game assets? I could make a UWP app that used MoonSharp to interpret the Lua and used Win2D to draw to the screen.

It had been some 15 years since the last time I’d made a game engine. In college I made a decent Mario-style platformer in Java; it had realistic physics, collision detection, music, sprite animations, scrolling, power-ups and enemies. I only ended up making one tech-demo of a level, but in the process I learned a ton about game engine design. (Though looking at that old code now… yikes.)

I spent a weekend trying to implement my idea for a sprite-based 2D game engine for Windows 10. It took me the two days to realize the true scope of such a project, and unfortunately I couldn’t get MoonSharp and Win2D to cooperate. Knowing that my idea probably wasn’t a unique one, I started searching online for other Lua-powered 2D game engines.

That’s how I found the free and open-source LÖVE. After seeing the size of its community, and how mature it was, I quickly abandoned my own broken code and started work on Pong.

SegaController v1.3.0 now available

I’ve released an updated version of the SegaController Arduino library. If you don’t know, SegaController enables your Arduino sketches to read Sega Genesis (Mega Drive) and now Master System (Mark III) controllers.

What’s new in v1.3.0?

  • Now supports Sega Master System (Mark III) controllers
  • Optimized code to reduce compiled binary size
  • Reduced read latency
  • Fixed issue with errant button reads when inserting/removing controller
  • Temporarily disables interrupts while reading to prevent misreads
  • Added DB9 pinout diagram to readme and examples

So if you’re interested in reading Sega controllers in your Arduino projects, check out  SegaController Arduino library on GitHub.

I’ve also updated How To Read Sega Controllers with information on reading Master System (Mark III) controllers.

Enjoy and happy hacking!

/jon

Introducing the AtariController Arduino library

After releasing my Arduino library to read Sega Controllers, I decided it might be fun to create a suite of such libraries for reading other retro controllers.

So today I’m introducing my new AtariController Arduino library on GitHub. This initial release only supports the classic Atari 2600 joystick, but I hope to add other controllers in the future.

The code is provided as a proper Arduino library, making it easy for Arduino enthusiasts to use in their own sketches. As with SegaController, I also include two examples, one which reports the button states via the serial port (good for testing) and one which sends Keyboard key presses (good for driving other software).

And of course, I’ve created some documentation of my own in the AtariController wiki at How To Read Atari Controllers.

Enjoy and happy hacking!

/jon

Introducing the SegaController Arduino library

A couple years ago I tried my hand at building an interface for reading Sega Genesis / Mega Drive controllers with an Arduino. I documented my first attempt with Reading Sega Genesis controllers with Arduino, and my updated version with Sega Genesis controllers and Arduino revisited.

That was three years ago, and I’ve gotten a lot of feedback about those projects. While they worked well enough for me, many people had problems getting my code to work. My research had led me to an implementation that relied heavily on having correct timing delays, and others found they had to constantly tweak those timings.

Of course, as any decent programmer will tell you, if your code relies on a bunch of seemingly random sleeps to work properly, you’re probably doing it wrong. And it turns out I was.

I recently found the Six Button Controller page on SegaRetro, where I gleaned some new vital pieces of information:

  1. The controller must be cycled through 8 different states.
  2. Reading the controller involves knowing the current state.
  3. If the state isn’t changed for 1.5 ms, the controller resets.

Using this information, I decided to take another crack at my Arduino code. And with a little bit of work (not all of the information on the SegaRetro page was accurate) I created a much more deterministic, stable, delay-free program. Taking it a step further, I refactored the code into a proper Arduino library, both to learn how to do that, and to make it much easier for Arduino enthusiasts to use in their own sketches.

So if you’re interested in reading Sega controllers in your Arduino projects, check out my new SegaController Arduino library on GitHub. Replacing the original sketches are two new examples, one which reports the button states via the serial port (good for testing) and one which sends Keyboard key presses (good for driving other software).

Also, since my research into how the controllers worked led me to mixed results (no one’s documentation had it 100% right) I’ve created some documentation on my own in the SegaController wiki at How To Read Sega Controllers.

Enjoy and happy hacking!

/jon

Automatically generating version numbers in Visual Studio

Having intelligible version numbers is one of the easiest ways for developers to keep track of their software in the wild. However, having to maintain version numbers manually across multiple projects can be an annoying, error-prone process, especially if you’re trying to build and release often.

So how can we automate this task away?

The Goal

I have a Visual Studio solution with multiple projects, that therefore generates multiple assemblies for my app. In no particular order, here’s what I want:

  1. Every assembly has the exact same version number
  2. The option to manually specify a version number (say for infrequent builds that I release to the general public)
  3. The option for VS to auto-generate a build number (say for frequent builds that are released to beta testers)

So, what are my options?

Sharing one version number

Let’s tackle the first requirement. By default, every code project in a Visual Studio solution has its own AssemblyInfo.cs, and each specifies their own version number that needs to be updated and maintained.

But there’s no reason we have to stick with that. A better idea is to:

  1. Remove the AssemblyVersion attribute from AssemblyInfo.cs in all of your projects
  2. Create a new file, say SharedInfo.cs in one of your projects (typically the one the builds first) and put the AssemblyVersion attribute there.
  3. For all of your other projects, simply add that SharedInfo.cs as a link. (In the “Add Existing Item…” dialog, click the arrow next to the “Add” button and choose “Add As Link”.)

Now you only have one file to update your version information in, making it much more manageable. Bonus, you can move all common assembly tags you want in your SharedInfo.cs, like Copyright, Product, etc.

Automatic versions

Being able to manually specify a version number is easy enough. Whether you keep the default Visual Studio AssemblyInfo.cs paradigm or the SharedInfo.cs method above, it’s just a matter of you picking and setting a new version number when you feel like it.

But now let’s see what we can do about having automatic versions.

Option 1: Use the built-in wildcards

The first option is given to us right in the default AssemblyInfo.cs, letting us know that we can simply set our version to Major.Minor.* and let Visual Studio auto-generate the Build and Release numbers.

Visual Studio then sets the Build based on the number of days that have passed since January 1st, 2000, and sets the Release to the number of two-second intervals that have elapsed since midnight. Sounds good so far, and of course you can always switch back to a manual version at any time. But there are a couple of caveats:

  1. This only works with AssemblyVersion, not AssemblyFileVersion. To make this work for both, you have to specify just the AssemblyVersion (comment out or delete the AssemblyFileVersion line) and then Visual Studio is smart enough to use the same value for AssemblyFileVersion.
  2. Both numbers are generated at the exact time the particular project was built. So if you have multiple projects in your solution and any one takes more than two seconds to build, you will end up with different versions for different assemblies.

Option 2: Use an extension

The next option, one I used for years, is to simply hand over the responsibility of generating versions to the VS extension Automatic Versions.

If features a very nice GUI and there are lots of styles of automatic versions you can specify for your projects. It resolves both of the issues with using the built-in wildcards, letting you specify AssemblyVersion and AssemblyFileVersion, and also making sure that every project has the same version number (whether you share a linked file or not).

Downsides?

  1. You might not find a version style that you like. While there are lot of version number patterns to choose from, if you have a specific format you need to adhere to (say to match existing releases), you might be out of luck.
  2. You’ve just added a dependency to your code. Are you sharing your code with other developers? Now they have to install the extension too.

Adding dependencies means adding risk. For over a year, the VS Performance Profiler simply would not work for me, throwing an error and crashing whenever I tried to analyze my applications. I thought maybe my VS 2013 install was simply borked, but the problem followed me to VS 2015.

Turns out Automatic Versions was the culprit. Now, to be fair, once I reported the bug the developer very quickly issued a fix and now the Profiler is fine. But I searched for a solution to that Profiler error for a year, and at no point did it occur to me that an extension might be causing the problem.

Option 3: Use a T4 text template

The last option I want to talk about, is using a T4 template. What are T4 templates? From Code Generation and T4 Text Templates on MSDN:

In Visual Studio, a T4 text template is a mixture of text blocks and control logic that can generate a text file.

I’ve you’ve ever made a website in ASP.NET or PHP, then you’ll have no problem with T4 text templates. Basically, you can create a template file with some in-line blocks of C# that will get run when you build your project to generate your actual file.

So, instead of creating a straight SharedInfo.cs like we did before, now we create a SharedInfo.tt and write a little bit of code to handle generating new version numbers.

Simply add a new T4 text template to your project paste in the following to get started:

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
    int major    = 1;
    int minor    = 0;
    int build    = 0;
    int revision = 0;

    // TODO: Write code here to automatically generate a version

    string version = String.Format("{0}.{1}.{2}.{3}",
                                   major,
                                   minor,
                                   build,
                                   revision);
#>
// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.

using System.Reflection;

[assembly: AssemblyVersion("<#= version #>")]
[assembly: AssemblyFileVersion("<#= version #>")]

Now, if you’re having trouble reading this, basically, the first couple lines are directives that the template is going to create a .cs file. The code in the <# #> blocks will be run when the project is built, and where you’re going to need to decide how you want to generate your build numbers. After that is the static template text of the output file, and you can see where you see <#= version #>, that’s where the value of the version string will be inserted.

As it stands, if you created a SharedInfo.tt with the above template, you’ll get a SharedInfo.cs with the following:

// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.

using System.Reflection;

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

And just like before, you can then add links to that SharedInfo.cs (not the .tt file!) into your other projects. So all you need to do is write the code that generates the automatic versions. What does that code look like? It’s up to you!

In my projects, I usually have a “manual” mode whereby the version numbers I entered are used for public production builds, and overwritten by something based on DateTime.UtcNow for private or test builds. If you want plain, auto-incrementing numbers, you might go with reading in your current SharedInfo.cs to parse out the previous version number, increment, and save it back out.

Well, there you have it, completely customizable automatic versioning in Visual Studio solutions. Like it? Have a different approach? Sound off in the comments!

/jon

P.S. If you want to see a “real-world” example of how I pick version numbers check out What the Chordious version numbers mean.