hgh dose
Vintage computing, old video games

One of my favorite retro sports games is Ice Hockey for the NES. This game gets overlooked a lot because it’s a bit on the simplistic side and not tied to a real-life franchise, but it’s still a good time.

I’ve started getting into watching women’s hockey leagues streaming, so I’ve been playing this game as something to do during intermission or when waiting for the game to start.

To fit the experience better, I made a romhack to change the sprites over to be female looking.



Some more gameplay

Here’s a demo of the romahack tool I made walking through a simple task of crossing-out the puck sprite

Instead of crossing out the puck I made other changes to the sprites of course, and used this tool to import them back into the ROM.

Ultimately it may have been possible to use someone’s already-made tool in lieu of making a new one. I tried one, YY-CHR since it’s one of the most highly esteemed. But, I had problems getting it to understand externally-pasted or externally-imported images, and YY-CHR’s built-in image editor was not sufficient for my workflow. If that one didn’t pan out, it may not bode well for the others. Since I was familiar with the image formats it was not too much to simply make a new thing.

About this game’s mechanic, if you aren’t familiar- this is 4-on-4 hockey. Skater players come in three varieties: light, medium and heavy.

  • The light skater is fast but has a weak shot and can be knocked over easily.
  • The heavy skater is slow but has a strong shot and tends not to get knocked over.
  • And, the medium skater is in the middle.

You pick what type your 4 players should be. A typical game involves a balance of skaters, although ultimately it’s up to you.

The players, ref, goalie and zamboni driver are edited. Good stuff! It’s just a bit of fun so don’t worry about it too much.

To play it you don’t need to use the tool, of course. I’m posting a patch so you can just patch your ROM.

Click here to download the patch (IPS). Patch was created using LunarIPS. LunarIPS is also recommended for applying patches. Apply the patch to an unzipped, NA release ROM, size 40976 bytes. Don’t hesitate to contact me if you want to play but don’t know how any of this works, I’ll set you up.

And click here to download the source spritesheets if you want them for some reason.

If you want to change the sprites to fit your own creative inspiration, you too can use the tool I made, posted to GitHub here.

Update (1/15/2020): Fixed missing bun in one frame of heavy player animation, fixed back-of-ref’s-head-during-penalty animation

January 13th, 2020 at 8:25 am | Comments & Trackbacks (0) | Permalink

I made a tool for converting a spritesheet into an animated GIF.

This program was borne out of a similar situation as the text editor one. I needed some functionality that was super simple but couldn’t find exactly the right thing in an existing program.

I used to use a web application for doing work like this, but I don’t like depending on web apps where it’s not strictly necessary. Why, because when you upload your files or data somewhere, you’re putting a lot of trust in that other party. They probably wouldn’t mis-use your data, and the data isn’t anything sensitive anyway, but the principle of it is undesirable.

There’s also the fact that a web application is so much overkill for the task at hand. Think about it. Why do I need a full web stack, javascript interpreter, communication across text protocols, etc for something so simple like resizing an image, or changing the encoding? It boggles the mind. It’s like SHOUTCLOUD but not ironic. I have nothing against web applications, but I don’t think everything needs to be a web application. That stack is too thick.

As for the whole world heading to web applications, maybe that’s inevitable. This idea could become feasible as internet infrastructure improves- in many countries it is not all that fast or always-on-and-everywhere, right now. The principle of a thin client with a smart server and a good internet connection seems interesting.

But why do these this future “web app” need to run in a browser? Why does it need to be built on HTTP, of all things? Remember, there’s a difference between “internet” and “web pages”. There was internet before web pages. There might well be internet after them. What is so holy about HTTP? It’s hard to see anything good or holy about it, other than it’s a standard (ish!) borne out of 2 decades of blood and tears. If you’ve had to do any work on a web browser, you’d know.

Indeed, a thin client can’t even be all that thin if it can parse and display web page content. HTML5+Canvas, CSS, JS, SVG, weird extensions and back compat… there are a lot of sub-technologies required to get a competent web browser and light up even basic, typical scenarios. A lot of things could work via a simple page but in practice they do not. In the late 2010s it’s not uncommon to see >10MB payloads for viewing a single site, and for pages where that payload isn’t all images or video- pretty common- you can imagine the CPU necessary for unpacking some of that.

Put it all together with the fact that local computation, device battery life and internet connectivity haven’t really kept up with rising web site complexities. If they did, none of this would even be a problem.

It’s nice, the idea of side-stepping that entire stack and running a program natively on your computer. If the program was written competently, it has a good chance of not being flaky. At least, it is not likely to be screwed by tech on which it is built.

Web pages are good for some things, things based around displaying text and images which are updated remotely. Maybe some light games. But you should probably not run your traffic lights, your pacemaker in a web app. Extreme examples of the need for reliability but you get the picture.

Anyway, as for this program- it runs natively, and includes some features that are useful for what I need.

Find it here on GitHub.

November 20th, 2019 at 12:22 am | Comments & Trackbacks (0) | Permalink

This might be an example of the old does it take longer to painstakingly solve a problem, or to create a tool to make it less painstaking?

I keep around a lot of ASCII art diagrams and charts– some new, some carried forward from ancient times. For Aaezure Odyssey MUD, the game is played in ASCII and therefore so are all the in-game maps. In any case, sometimes there’s a need to edit them by moving around regions of content. In a conventional text editor, this is a gigantic pain in the neck. Sometimes you can cheese it using special key characters with find-and-replace but it’s not a great way to go through life.

I also thought that surely, there’d be an obvious choice for an already-existing text editor that supports this kind of diagramming function with moving around blocks of text. The best one I found was ASCIIFlow. I loved the UI of ASCIIFlow– it’s really cool and modern. However, it had a problem where the import/export was lossy. It’d take some characters, and replace them with other characters. Dealbreaker. Besides that, there’s Emacs or vim but those tools haven’t been part of my life thus far and I didn’t care to investigate. And then there was one other option, Notepad++ which I knew to support column-based selections but there didn’t appear to be a way to move around the blocks of text.

See I thought I could go through life without ever feeling motivated to make my own text editor. I’ve been liking the program, so while using it I added more features outside of what it was originally intended for– supporting cut, paste, undo, and so forth. Besides the diagrams it’s been good as a general purpose editor and I’ve already gotten a lot of mileage from that.

The program can be found on Github here.

February 26th, 2019 at 5:38 am | Comments & Trackbacks (0) | Permalink

I made a Winamp plugin that broadcasts what song you’re playing as a Discord Rich Presence.

An uncommon scenario? Sure, although I’m not too worried about that. This idea of functionality came from the integration Spotify has with Discord right now, plus there are a lot of other interesting ways in which app developers are implementing Rich Presence.

The main challenges for this project were understanding not one flow of communication, but two; the Discord RPC API and Winamp plugin architecture. You figure out how to do one, then how to do the other, and then merge the result together. One thing I am grateful for is the fact that Winamp is debugger-friendly and can also be launched by a debugger without issue. There wasn’t anything too gnarly that happened for this project but it helped to be able to step through some things- for example, the plugin configuration menu code– to debug. There was one problem where DialogBox was being called with NULL instead of the proper module handle, and it would indeed create a dialog box but of an unexpected type. It helped to be able to step through and debug this.

What it looks like, in action:

The source + binary distributed through GitHub repository here: https://github.com/clandrew/wdrp

Problem solved!

January 20th, 2019 at 4:54 am | Comments & Trackbacks (0) | Permalink

Project– Porting a Tetris game I wrote a long time ago in X86 to run on modern 64-bit Windows

The game was written in about 1000 lines of X86, and assembled with the A86 assembler tools. This was 12 years ago, in 2006.

It is extremely low tech and not super complicated or flashy, it was meant to be a personal effort back then to learn about it and becoming more comfortable debugging it. It was built as a 16-bit DOS COM executable. Although it ran on Windows at the time, the binary format was not very current even back then. Sadly time passed, the binary rotted and it does not run anymore.

There are three reasons why it does not run anymore
1. It’s a .COM executable. Running these requires an MS-DOS emulation subsystem of Windows which is not present on 64 bit Windows
2. It’s a 16-bit executable, which does not have support on 64 bit Windows
3. It uses DOS interrupts in order to work. These interrupts are not supported in modern OS. Modern Windows behavior is that they just crash the app

In addition to the broken binary, I had the source code still. So I decided to resurrect it by porting it so that it can be run natively now on a modern 64 bit Windows OS (where ‘natively’ here means ‘not with an emulator’). Yeah you can run it in DOSBox, but where’s the fun in that?

Although the program was originally assembled with A86, I ported it to use MASM (a Microsoft product). I want to say using MASM is not necessary for fixing the above problems. It would actually be possible to fix the above problems while still using A86. As it turns out, building Win32 programs with A86 is easier than ever because the author has (since 2006) created a new set of convenience tools for that, just barely too late for me to have taken advantage of. Looks promising.

The thing is, if I’m going to set out to make it work on Win32 anyway, it is almost certainly going to be easier with MASM. It has easy-to-set-up integration with Visual Studio, it’s basically automatic setting up my project to link against the right libraries, and there are built-in conveniences which make the Win32 APIs (or anything) syntactically nicer to call for the purposes of doing this. MASM has different syntax than A86 but switching over to its syntax wasn’t such a bad price to pay. Mnemonics themselves and the syntax for the addressing modes are basically the same. I thought I’d have to change over some things on this front, but as it turned out I didn’t. In general I don’t think the compatibility of mnemonics is standardized or guaranteed, but I didn’t run into problems in this area.

The annoyance– which would been there for MASM or A86 regardless– was graphics, because this part had to be changed the most. I decided to go with GDI which is not going to be anything like mode 13h (If you haven’t had to ever program with mode 13h it basically gives you a pointer to video memory and writing to it draws indexed-color pixels on the screen) For GDI on Win32 the program needs to be structured a lot differently. It needs to create a window and window resources, the code for drawing the grid needed to be moved to a paint message handler, needs to update with a timer, it should be scaled up too since a 320×200 resolution 1:1 is not a great time on a modern display, etc.

Coming at this I had wanted to be able to treat the game as a black box. Change a few things to get it working in Windows and that’s it. But in the end, I needed to understand nearly all parts of it to do what I wanted to do. There were all these long stretches of code organized horribly where I’d long forgotten how they work. Doing this was a gigantic hassle

Still, It works. It is still extremely low tech but that’s kind of the point, and to just get it working. I got to add a couple new things too:
– Different colors for the different pieces
– Fixed a bug where rows would sometimes not get cleared correctly
– Added a ‘next piece’ UI
– When you get game over instead of crashing it displays a message and you can press Escape to start again

I wonder… when it will rot again?? (As a GDI Win32 app) maybe it’s good for a while

The code for the Win32 version is all in one file located here.

May 14th, 2018 at 10:43 pm | Comments & Trackbacks (0) | Permalink

This game was made for a graphics course that had an open-ended choice of a final project. We were allowed to produce any sort of demo that used either OpenGL or raytracing techniques. I chose to do a use OpenGL (realtime) for the opportunity to make an interactive demo.


  • Textured meshes exported from 3DS Max in OBJ format, then saved as a serialized format by the game
  • Environment/cube map to serve as a background
  • Instanced geometry for faster drawing
  • Samples from the environment to create a reflective metal effect
  • Uses Cairo to render font glyphs to a texture, and composes them to make text
  • Uses a deformable mesh to create an animated explosion

In the game, the player shoots down enemy ships and scores points. The missles are shot from the player’s ship outward depending on where the ship is pointing.

The ship is controlled with the I,J,K, and L keys. Dragging the right mouse button can be used to rotate the camera, and the scroll wheel zooms in and out.

Pressing ‘S’ will enable/disable some sliders which control certain program parameters, used mostly for debugging/testing.

Pressing ‘Z’ fires a missile. If an enemy ship is hit by a missile, it disappears and the player’s score is increased.

The source code is compiled using Visual Studio 2008.
Download binary (Windows .exe)

Download Source

September 13th, 2012 at 5:00 pm | Comments & Trackbacks (0) | Permalink

This is a game submitted for a contest held by UW GameDev Club, where the game has to be done entirely in 24 hours (honour system). Any choice of language or API was allowed, and all entries have to follow the theme: the theme this time was “color, or a lack thereof”. I decided to make a small 2D arcade game. My entry was in C++ using GDI+ for graphics.

My entry (2nd place winner) was called Color Dungeon, and overhead-view arcade game where the main character walks around the map, avoiding orbs of the opposite color, getting to the stairs in the lower right corner.

There are 4 floors, each successive one is a little bit harder. The enemies are more numerous, move more quickly and a higher proportion of them will ‘home’ toward the character.

The maze as generated by recursively partitioning the map area into rectangular ‘rooms’. At each step the room will either be partitioned vertically, horizontally, or have another ‘room’ placed within it. ‘Exits’ (clearings in the wall) are added for reachability. Reachability is ensured for all areas in the map.

Arrow keys are used to move the character around the map. Touching orbs of the opposite colour will damage the character. The goal for each floor is to make it to the stairs, which are placed near the lower right corner.

Swords are an area-of-effect item that can be found scattered around the map; they are more frequent when there are more enemies. To use one, press ‘b’.

Download Game Binary (Win32)

The source code is compiled using Visual Studio 2008. There is one project file for the game.

Download Source

September 13th, 2012 at 5:00 pm | Comments & Trackbacks (0) | Permalink

This is a tool for estimating the amount of shift (displacement) between two images using FFT (Fast Fourier Transform). The images can be of different sizes. This method is faster than enumerating all the possible (x,y) shifts and selecting the right one, especially for large images. To perform the transforms it uses the fftw library.

More specifically it uses the 2D convolution function between the images. The steps for this are:
1. take the Fourier coefficients of the first image
2. take the same the second image,
3. find the element-wise product of the two results,
4. find the inverse Fourier transform of the above.

It shows the resulting image, with scaled colour channels so the darkest is black and the lightest is white. The light areas indicate likely amounts of shift. For example, a light area at co-ordinate (5, 6) means the second image was probably shifted 5 pixels across, 6 units down from the first.

As an example of using it, consider cropping an image so that the resulting image is 47 units across and 30 units down.

Point the program toward the two image files and hit ‘Estimate’.

The dialog will (quickly) show a visual result of the convolution, and the estimated shift. The shift matches with where the image was cropped. The units are the position of the first image, in pixels, relative to the second one.

A brute-force implementation of the same thing is very doable but takes around 30 seconds on this sample, so it’s a pretty significant speedup!

Download binary (Windows .exe) + sample images

The source code is compiled using Visual Studio 2008. There are three project files. ConvolveShift is the main executable, a Windows Forms program in C#. Native is a C++ DLL that does most of the real work. NativeDriver is a non-graphical program for testing Native.

Download Source

September 13th, 2012 at 5:00 pm | Comments & Trackbacks (0) | Permalink

NOTE: Twitter has geared up and improved security for their API, changing login to use OAuth. Unfortunately, it makes the extension below obsolete. It’s still online as a proof-of-concept only.

This is a Game Maker extension used to send Twitter messages. It uses an unmanaged DLL that calls into the managed .NET runtime library to connect with Twitter. It sends an HTTP POST message to send an update. The reason for doing it this way was because Game Maker can only call into native code, but the circumstances for making/using this were competition-based so 3rd party libraries were allowed (all code must be original). Yes it’s kind of a judgement call. Anyway there is no standard C++ networking library that provides enough abstraction, but the standard .NET runtime library makes it easy.

In Game Maker, it provides the following functions:

twitter_set_user(user :string)

     – Call this first to set the Twitter username to use.

twitter_set_password(password :string)

     – Call this to set the Twitter password. The game author may want to take some form of security measures.

twitter_send(message :string)

     – Tweets a message.

twitter_set_timeout(timeout :real)

     – Optional. The maximum time, in milliseconds to wait for a network message to be sent. The default is 5000 (5 seconds).

The user name and password only need to be set once.

The extension was built for/tested on Game Maker 8.

Download Game Maker Extension (.gex)

The source code is compiled using Visual Studio 2008. There are two project files, one that builds the DLL itself and one .exe used for testing the DLL. I made the DLL into a .gex using Extension Maker.

Download Source+Binary

September 13th, 2012 at 5:00 pm | Comments & Trackbacks (0) | Permalink

This game was a team effort with myself and 4 other students, for a contest called Games4Girls. The contest is run by University of Illinois. The objective is to make a 2D game, of any kind, targeted toward a female highschool-age demographic, with the restriction that we use Game Maker. Game Maker is a proprietary program used for scripting 2D games, using a C-like language. The choice of Game Maker had something to do with problems with past entries that depending wide assortment of platforms/runtimes; many games wouldn’t run. So, they ruled that all entries had to use Game Maker.

We decided to make a platformer type of game, which is familiar to most people. The player controls a character named Alessa, and uses her various weapons to defeat enemies and move through the levels.

Because there were restrictions on using copyrighted content, we created all the graphics and music ourselves.

My personal role was

  • coding object collisions
  • coding scene transitions, scoring
  • creating sprite and background graphics and getting them into the game

Overall the project was a lot of fun to work on.

As it turned out, our entry was very well-recieved and we finished in first place. We won a cash prize for our team and some money donated to our CS faculty at University of Waterloo.


The levels contain various enemies and obstacles.

The game includes some dialogue segments, illustrated by our group, with larger character graphics illustrated by my super-artistically-inclined groupmate! The dialogue provides some story background to the game.


  • Left/right arrows: move Alessa
  • Up arrow: Jump
  • Any arrow(in water): swim
  • A key: Shoot an arrow
  • S key: Swing a sword


My team consisted of (with thanks!):

Download Win32 binary

The game was originally built and tested on a Windows 7 environment.

Notes for running on Windows 10:

  • Windows may mark the game executable as protected by SmartScreen. Although anything downloaded here is at your own risk, I can attest that we did not put malware into the game and do not distribute it knowingly with any malware. To proceed past the SmartScreen filter should you choose to do so click “More Info” and “Run”.
  • The Game Maker environment relies on DirectPlay which, from Windows 7 to 10, was changed from a built-in feature of the OS into an optional component which is downloaded on demand. If Windows prompts you to download it, choose Yes to proceed with downloading it and enable playing the game.


June 18th, 2010 at 3:00 pm | Comments & Trackbacks (0) | Permalink