Category Archives: Software

Modest Bricks

Modest Bricks gameplay video

Modest Bricks is a Tetris clone. Originally written in 2005, it uses SDL 1.2 and the SDL_Mixer library for sound effects and music. This was one of the first “serious” games I wrote – though I did a number of QBasic and Visual Basic things before, I had never attempted a game in C, or with this level of polish. I wrote this for a few reasons:

  • Learn SDL and practice game dev in C, tools used (at the time) by Professionals to make Real Games
  • Make the source available so I could teach and demonstrate SDL to the University of Arkansas Game Development Club, a group I helped co-found around the same time.
  • Follow the advice of this GameDev.net tutorial, “How do I make games?” which recommended to start small by creating a polished version of Tetris to get the basics down and have something to show.
  • Put my music into a game!

Recently I took an interest in revamping some old code, and ended up rewriting much of this. The effort is complete so I’m releasing it. A Windows version is included in the .zip below, as well as the source code in C. Recompiling on *nix should be easy: cc `sdl-config --libs --config` -lSDL_Mixer -o modest main.c should be reasonably close, assuming SDL and SDL_Mixer development libraries installed.

Probably the most interesting thing about this game is that after writing, I pushed it to the SDL webpage, which (at the time) had a gallery for people to post their games Made With SDL. From there it caught the attention of a Dreamcast homebrew developer Ian Micheal, who was porting SDL games to the DC. He altered the graphics and added more sounds and cool effects to create “Ghouls ‘N TriX” – a Tetris game for the Dreamcast! It was really cool to know my code was running on a video games console, and I made sure alllll my friends knew about it 🙂

Download the game:

BBCode Parser (in PHP)

For a while now I’ve been working on a little blog engine in PHP. As part of the post rendering, I’ve settled on BBCode to do all markup and layout.

This meant I would need a BBCode parser. So, I started writing one. And because my projects always go this way, I ended up sinking more time into the BBCode parser than the blog engine itself – trying to get every weird corner case and not produce malformed HTML on output. The primary goals were:

  • Easy to use (one file with one function)
  • Correct (Unicode safe, always-valid HTML, reasonable fallbacks)
  • Easy to understand (avoid massive regexes)

Eventually, I ended up just splitting this piece off into its own project, since it may be useful beyond just my tiny blog.

https://github.com/greg-kennedy/php-bbcode

I know there are a million BBCode parsers out there (and even a PHP extension to do it), some extensible and so on. This one is mine. Would love pull requests.

Writing a WebSocket Client in Perl 5

WebSockets are the latest way to provide bi-directional data transfer for HTTP applications. They replace outdated workarounds like AJAX, repeated polling, Comet, etc. WebSockets are a special protocol atop HTTP (which in itself runs over TCP/IP), and can be wrapped in SSL for security (as in HTTPS). Being a Web Technology, it seems to have been developed by the JavaScript people exclusively for the JavaScript people – working with it outside a web browser or Node.js server can seem convoluted. But that’s the world they built, and we just we live in it.

Basic Perl support / documentation for WebSockets was difficult for me to find. The Mojolicious framework (specifically the UserAgent module) has native WebSockets support and can act as a client, but I was looking for info on using with WebSockets on a lower level / without Mojo or other frameworks. Hopefully, this post can shed some light on how you can use Perl to connect to a remote server using WebSockets, and get access to those sweet real-time services using our favorite language.

First off, if you can, you should just use AnyEvent::WebSocket::Client or Net::Async::WebSocket::Client (depending on your preference of async framework). This package has already done the hard work of combining the two packages you’d probably use anyway, Protocol::WebSocket::Client (for encoding / decoding WebSocket frames), and AnyEvent (for cross-platform non-blocking I/O and doing all the messy TCP socket stuff for you). Having already established my status as a Luddite a desire to know what’s really going on, let’s try to reinvent the wheel and write our own client.

A Client for the Echo Test Service

The goal of this project is to interoperate with the WebSocket Echo Server at ws://echo.websocket.org. The Echo Server simply listens to any messages sent to it, and returns the same message to the caller. This is enough to build a simple client that we can then customize for other services. There are two things we need to make this work:

  • a plain Internet Socket, for managing the TCP connection to the remote server, and
  • a Protocol handler, for encoding / decoding data in the WebSocket format.

The second part of this is already done for us by Protocol::WebSocket::Client: given a stream of bytes, it can identify WebSocket frames and parse them into data from the server, and it can take data from our program and encapsulate it for sending. This tripped me up at first, so pay attention: Protocol::WebSocket does NOT actually do anything with the TCP socket itself – meaning it does not send or receive any data on its own! The class is responsible for only these things: packing/unpacking data, generating a properly formatted handshake for initiating a WebSocket connection, and sending a “close” message to the server signalling intent to disconnect.

Given that Protocol::WebSocket::Client doesn’t do any TCP socket stuff itself, we have to manage all that. Fortunately, there’s the core module IO::Socket::INET which we can use. Protocol::WebSocket::Client also provides some hooks for points in the WebSocket flow, so that we can insert our own handlers at those points. Let’s get started with some code.

Continue reading

Info Page – @FPAdventuresBot

@FPAdventuresBot currently posts images from the following games:

  • Myst (1993)
    • Extract tool: Riveal
    • Image count: 1531
    • Data files / areas covered:
      • INTRO.DAT
      • MYST.DAT
      • STONE.DAT
      • CHANNEL.DAT
      • SELEN.DAT
      • MECHAN.DAT
      • DUNNY.DAT
  • Lighthouse: The Dark Being (1996)
  • The 7th Guest (1993)
    • Extract tool: Custom
    • Image count: 482
    • Data files / areas covered:
      • AT, CH, DR, GA, HTBD, JHEK, LA, MB, MU, P, B, D, FH, HDISK, INTRO, K, LI, MC, N
  • The Journeyman Project (1993)
    • Extract tool: ffmpeg
    • Image count: 2045
    • Data files / areas covered:
      • CALDORIA/C1_NAV.AVI
      • CALDORIA/C4_NAV.AVI
      • CALDORIA/C5_NAV.AVI
      • FINALE/FINALE.AVI
      • MARS/MM_NAV.AVI
      • MARS/MU_NAV.AVI
      • NORAD/N_NAV.AVI
      • PREHIST/P_NAV.AVI
      • TSA/T_NAV.AVI
      • WSC/W_NAV.AVI
  • Return to Zork (1993)
    • Extract tool: Custom
    • Image count: 256
    • Data files / areas covered:
      • MS-DOS
      • Mac
  • Riven: The Sequel to Myst (1997)
    • Extract tool: Riveal
    • Image count: 3480
    • Data files / areas covered:
      • a_Data.MHK
      • b_Data.MHK
      • g_Data.MHK
      • j_Data1.MHK
      • j_Data2.MHK
      • o_Data.MHK
      • p_Data.MHK
      • r_Data.MHK
      • t_Data1.MHK
      • t_Data2.MHK

Secret of Evermore (Bugfixed)

Secret of Evermore is a game for the Super Nintendo released in 1995. It continues to be a somewhat controversial title in the otherwise spotless Squaresoft SNES library… but I like it, and my wife plays it as a “comfort game” whenever she is feeling sick.

IPS is an antiquated binary patch file format, used to provide a “diff” of raw bytes that should be applied over an existing file. IPS patches for SNES games are widespread, and often do things like enable cheats, alter graphics, translate text, etc. In some cases, people have found bugs or glitches in the original code, and release an IPS patch to fix it. Often these are found from the work of speedrunners, who spot a glitch and exploit it to break the game in some way. The SNES hackers then identify the code problem behind the bug, and patch the raw binary code to close the hole. There’s a whole black art to crafting binary bugfixes – the space for a fix is severely limited, and if the new code is too big you have to find additional unused code area elsewhere to jump into (or optimize a different routine to make some free space!)

For some games, more than one bugfix patch is available. Managing these with the ubiquitous LunarIPS tool is a pain – you have to generate a bunch of intermediate ROMs, and the patches may conflict / overwrite one another without indication of the problem. There are better IPS patchers around, but I didn’t want to go on a research quest to find one. Besides, IPS is a pretty simple format – why not just write my own patcher?

I wanted a way to take a binary file, apply a complete “patch set” to it, and return the resulting bin. I wanted it to check for conflicts in patches, and give a descriptive message of which exact patches were colliding. And then I didn’t want to just serve up a cooked file, for copyright and maintainability reasons. “XYZ (Bugfixed)” hacks are too frequently outdated, as new patches are released. So I put a simple PHP frontend before it and a folder full of patches server-side.

The tool is here: https://greg-kennedy.com/SecretOfEvermore/

Users can upload a file. If the SHA-1 matches, it gets patched and they download the fixed version. This tool is for Secret of Evermore, with all the patches (i.e. “hard work”) done by Assassin17.

I may stand up sites for other games as I run across them, or merge these into a single “bugfixer” tool if it gets too out of control.

The patch.pl script follows.
Continue reading