Projects, aren't those fun. I'm the kind of man that always needs to work on something, whether is be remotely successful or not. Here's just the ones that evolved past a box on a blank screen or something equally unimpressive. They're presented in reverse-chronological order.
Sonic R Hacking
- Sonic R Model Downloads
- Exporter Utilities Github Link
- IDA 5 Free project (1550KB, offsite, horrifically outdated)
- Cream the Rabbit Lap Announcer patch (512KB, offsite)
- Running Amy video (Youtube)
- Running Amy patch (388KB, offsite)
This has been the time sink to end all time sinks. And you know, Sonic R isn't even a good game. But there's that little piece of me in the back of my mind that thinks that I can make it into an awesome game. Considering that working towards that taught me assembly, GUI development, 3D modeling, level design, animation, and a whole host of other things, I'm fine with sinking time into this thing. (Although one of these days I need to release something to make this time feel like it was worth something...)
After messing around with that Gameboy emulator, I looked at my shelf and saw my copy of Sonic R sitting there. I was playing it a bit recently and had some fun with it, but I knew it had definite room for improvement. Then I realized "Hey, those people on the internet hack Sonic games all the time. Why don't I?" So I did.
Granted, most normal people would start with something like Sonic 1 and work their way up to something like this. At the time my experience with ROM hacking was rather lackluster. Under my belt of experience was the Oregon Trail stuff below and an experiment with the Special Stages in Sonic 2 in an attempt to make them flat. (I never did.) So going into this I basically had no idea what to do.
First order of business, I decided, was throwing it through the free version of IDA and seeing what came out. The result was an unholy mess but I slogged through it in an attempt to figure out how the game worked. Then I remembered that the Cheat Engine was a thing that existed. Being able to map the memory really helped the disassembly process. The Gameboy emulator certainly helped as well in figuring out what the ASM was doing.
After a while of that, I figured I had enough of a grip on the layout of the program to start some simple edits. Specifically I figured out how to manipulate the call to display the HUD. So I started simple. I made some of the calls to the small character icons point instead to the big character icons. Then I said "Well, that worked. Let's implement a Latiku clone!" You'll notice this is a recurring theme. Somehow I managed to pull that off, shuffling around half the game's graphics and then fixing most of them in the process. The result was pretty nice, but I was running out of ways to mess with the ASM without saying "I'm just gonna rewrite half the game!". Trust me, I probably would have started to and then stopped a quarter of the way through. (That's pretty much the same fate my Oregon Trail experiments led to.) So I decided to mess around with the levels.
Of course, in order to mess around with the levels, you had to have some idea of how the levels were laid out. Now the thing about Sonic R was that nobody really cared about it for more than about 3 months at a time, so therefore nobody ever got around to actually researching the level format to any serious degree. So I got out a ROM corrupter and went to town with it. After a while with that I managed to get a good chunk of the format down. Not enough to make a complete level, but enough to impress the guys on Sonic Retro and get an account there. So that's nice.
I was a bit stuck on the latter half of the format, though, so I decided to take on the character format. Thankfully it was already researched, so all I had to do was write an importer/exporter. After doing so I dumped the models onto the Models Resource. Shortly after they managed to get included in some Garry's Mod mod. And now they're popping up in a surprising number of places. At least if anyone asks I can say something came from all this.
So then I figured "Hey, if I can go one way, why not go the other way?" Looking on the Sonic Retro forums I saw some dude had issues when he tried to import a Sonic with the head from Sonic Adventure, so I tried to replicate that. As it turns out, it also crashed. I shelved that for a while before I wondered if the filesize had anything to do with it. As it turned out, the game only allows files at the same size or smaller than the ones you're replacing. So I tried replacing Sonic's body with a cube and it worked just fine. I posted my results on the Sonic Retro forums and got a not-quite-a-request-but-more-just-wishful-hope to implement Amy Rose outside of her car (because in the game, she's confined to a horrible 1980-something convertible which makes her arguably one of the worst characters in the game). I had nothing better to do that weekend, so I did. People were impressed. However, there wasn't much more I could do in that direction, so I went straight back to figuring out the level formats.
The level format was one of those things that's dauntingly impossible at first glance but really easy in retrospect. (Actually, scratch that. The metadata part is still an enigma to me. Who puts metadata in a geometry file?) Of course, I quickly realized that whether or not I cracked the format was more or less irrelevant for the time being. I couldn't do anything with an altered geometry file simply because everything was hardcoded. Textures were hardcoded. Heck, which polygon groups were item boxes and which were gates were hardcoded. If I was going to make a custom level, I needed to patch out these bits with the bytes I want. So, of course, I needed to make a patcher. The more observant of you will notice this is eerily similar to how the Oregon Trail hacking had it's downfall. The difference this time, however, is that I knew (roughly) what my end goal was.
So I went ahead and wrote a patcher. In C. For Windows 95. Word of advice, if you're in the 21st century, don't do that. That being said, it was fun. Knowing not much about C and literally nothing about Windows programming, it certainly was an educational experience. Sure, even if the technologies are mostly dead (that's directed more at Win32 than C), just making a decent sized project like that was something I needed to do eventually. And while I'll admit the codebase is slightly a mess, it's a mess I'm proud of.
Turns out it took about a year and a half (and counting!) to write this. Again, I reiterate: don't write a program in C for Windows 95 today unless you're either sadistic or desperate. Just use QT and C++. Your life will be so much easier. But really the programming language wasn't that big of a part in why this took so long. It's the little things I simply didn't anticipate. Like the fact that about half way through I realized the core concept of my mod loader was flawed, so I had to patch in a way to make it work. That took a while to do. That happened a few times, actually. Feature creep was also an issue. I called the mod loader "feature complete" in October of 2016, and then realized that, you know, adding this little thing here would simplify this a lot, and adding that little thing would... Yeah. (Watch this space!)
During the development of that, I made some assets for a future hack I plan on making. So far, I have five new character models and one new level layout. In order to make those, I needed to really learn Blender. And I'd say I have 3D modelling at least a little bit down. I'd throw up some comparision images but I gotta keep up the anticipation somehow.
I also finally figured out the geometry format on at least a structure level. This should mean that level hacks might be possible soon. Again, there's that whole "everything is hard-coded" thing, but resolving that will be reasonably easy once the mod loader is complete. Whenever that happens.
Stay tuned for more!
In 2013, I was in the world's most counter-productive computer class, because I needed a schedule filler. (Seriously. Within the first 9 weeks the class had to make a single Powerpoint and a Prezi. That was it. They weren't even impressive, either.) To pass the time waiting for things to actually be due, most people would play Happy Wheels or Bloons Tower Defense or whatever.
I, for whatever reason, decided to make a Github account and make a Gameboy emulator that could allow me and my friend to play Pokémon or whatever over the DB-9 serial port conveniently on the back of every computer. Or, more accurately at the time, stare at a terminal that says "Illegal Operation! (Got 0xfe)" I had weird ways of entertaining myself.
And then somehow it morphed into a shoddier version of libretro or something like that. The goal is to eventually be just a modular framework on which one could build an emulator. You want OpenGL graphics? Switch out the rendering plugin. You want to get inputs from an IRC Chat? Switch out the imput plugin. You want to emulate a Mega Duck? Nobody's going to stop you.
I never actually got around support graphics or sound or, indeed, anything at all. (Half the CPU opcodes aren't even implemented!) I'm done working on it, and I have been since about when that class ended. It was, however, a nice learning experience. And I'd say knowing basic ASM helped a lot with the whole Sonic R hacking thing.
Oregon Trail Hacking
This one needs a bit of backstory. There's this dude on Twitch (MonotoneTim) that played the Oregon Trail before just about every livestream. I thought "Hey, I know, I'll do one of those Sonic hack things, but with the Oregon Trail!". It was remarkably easy to hack, but it just required a lot more effort to replace everything than I thought it would.
Graphics, for instance, were just bitmaps. I could open up a hex editor, dump in some graphics, and presto! New hack! But trying to find the right memory location got really tedious. I could have kept going, but automation was so tempting.
I ended up trying to code an auto-patchy Swiss Army Knife thingymajigger in C# with GTK# with an image editor and the works to automate the tedious parts. I barely knew C#. I didn't know GTK#. I really didn't know anything about GUI design, or planning, or even enough to pull off a backend. I don't even think GTK# was even actively maintained at the time, let alone documented. Note to the future: if you sidetrack, you better have a plan in mind. I'll probably revisit this some day, just for the heck of it. (Not the C# thingymajigger, though. That just isn't worth it. That Sonic R Mod Loader should do the trick quite nicely, though...)
This, for the record, is garbage in retrospect. It was made back when Firefox 4 was still in beta and SVG still seemed kind of neat. This is in no way, shape or form indicative of what I could do today, but I still think it's neat in it's own special way.
This was an interesting attempt in creating my own game engine. The general "goal" of this was to have a fully-featured 2D platformer like Super Paper Mario. Mr. Square was some child's doodle who went around with his turbo-charged hot glue gun filled with whatever (ala Megaman) to go stop some evil white collar worker with a paper shredder or something. (I honestly can't remember, but that feels right.)
I stopped because every update after this seemed to break the collision detection, and it was a hacked together mess made before I bothered to look up what "inertia" actually meant, among other things. I was making games earlier in The Games Factory when I was a wee lad, but I'm not gonna post those as they were, for the most part, generic platformers with Mario's face on them with roughly 2 levels each.