Semester in Review

Now that the semester has ended, here is an overview of how this project has evolved over the past...twelve(?) weeks and what we've been up to.


PART I
We dove in learning everything we could about the system itself, and the basic "theory" behind how it works. The various components that make up a Super Nintendo and how they all communicate and work in conjunction. This lead to the obvious jump to learn assembly, specifically 65c816 asm. The first four weeks or so were spent learning this, Yoshi's Super Nintendo Document and the Wikibook on SNES Programming being particularly helpful. There was also a really great starters guide called the SNES-Starterkit that was extremely useful to me and helped get me started off. After accomplishing the first sort of intro to the language (making the SNES boot with a green screen), went on to poke around a few other things such as a "hello world" and editing the assembly in simple roms from the starter kit. Around this time I also started to experiment with vSNES and Super Street Fighter II, just poking around basic hex adjustments and seeing what I could do. I was specifically interested in messing with the PPU, where the tile maps and sprite data are stored. After poking around in SFII some I worked my way on to Killer Instinct and Mortal Kombat II, all fighting games. The earliest videos we have were the results of this.

PART II
While this was going fairly well, I was still having a difficult time working with WLA-DX and getting the roms to assemble properly all of the time. As a result, I started looking more into third party apps that jumped the need for the assembly. I found a particular interest in pallete swaps, which natrually led to sprite and tile set editing, and eventually text editing. I got really into Tile Layer Pro, which is designed so any old fool can use it, and the previously mentioned Pallete Finder app was a life saver. At this time I was also interested in finding out how to transfer ROM data from PC to a cartridge via EPROM and was really eager to pursue it, but unfortunately was something that we were never able to get around to. I continued to experiment with SFII, as well as a little with F-Zero and Mario RPG. I abandoned a lot of hope for Mortal Kombat II after about two weeks of trying to figure out how the graphics were compressed in the tileset.

PART III
As the last portion of the semeseter began to approach, we began to narrow down the direction we wanted to take the project, and I found a particular interest in SFII, specifically working with sprite editing and text editing. Eventually one night when doing a bunch of sprite tests I worked out the simple "block fighters" test, which seemed to jump out from all of the other tests I was doing at the time. Chris and Jeff both seemed to like it, and over the next few weeks we eventually worked it into the final concept of the deconstructed fighting game, "Street Friends II." The idea behind it was to take the linear fighting videogame, a stereotypical product imbeded throughout our childhoods, and play off of it by creating a simplified game that denies what it was made to be. Instead of travelling the world fighting tournaments, you travel the world visiting friends. No health bar, no conflict, only high fives and good times. We were also looking to deconstrcut the image of the fighting game, with its predicatble characters, dialogue, and settings, and utilize that imagery to our advantage. The final few weeks were spent using what I had learned from experimentation over the past ten weeks into creating the final version of the ROM, which included custom built controllers by Chris featuring a joystick (literally a stick) and one button, simplifying the gaming experience.

Around week nine Chris and I also started to take apart our Super Nintendos and see what we could do simply with analog hacks, and after losing a few nintendos, Chris designed this great modular-bending system for SNES Carts. The end results were great, and we should have some videos of that up soon. I'll also be uploading the final ROM edit soon, so you all can give it a go. Additionally, I have a bunch of palette files for Tile Layer Pro as well as offset locations for the palette data which I'll post here, just in case anyone is interested in editing the tile set in SFII themselves, because it'll save you a lot of time in the long run. More videos to come as well, and all questions/critiscism are welcome


-dylan

Week Update

look at that! i really like where this is heading. So serene, so simple, so atari. Ive spent the past week digging through SFII's tileset and converting the whole game into this, and im getting close to being done. Then after that, new, simple interfaces to play it with!

-dylan

Palette Swaping

So I finally got it together and figured out how to swap out palettes. There were a number of stupid things going on, but now its pretty simple to find where a tile references its tile and to change it (at least, for Street Fighter 2). I think the biggest problem I was having before is that I wasn't having trouble finding the palette for the title screen, but when I tried to find one for a character i never got anything. I thought the problem was in the transparency color and that value was messing things up, but that wasn't it. The whole time I was searching for palette data on the Player 1 character--the character that faces screen right. This meant all of my palettes corresponded with this. However, in the tileset, all of the characters are facing to screenleft. No wonder my palette searches weren't coming up with anything, i was looking for a mirrored version of what was there (silly japanese people and their backwards everything). After that, there were (and still are) a few small speedbumps in the process, but its nothing too painful now. Mostly just manually insterting the palette RGB values, because Tile Layer Pro still seems to have trouble importing palette files generated from Digisalt's apps. Still, im glad to have figured this out, as this now opens up a world of infinite (well, almost) color combinations. Tinkering can be seen below (abstracting further as you go down). The last one I liked so much theres even a video of it. Man, check out ryu's blood when he gets hit at 00:23. Radical








On a tangent to this issue and my problems with TileLayerPro, i stumbled on this wonderful java-based graphics editor today called Tile Molester (great name, right). Though really it's showing the same exact tile set in pretty much the same manner, for some reason after scrolling through SFII in it I discovered so many new things I never noticed before. Maybe it was looking at the tileset through a different program's eyes, im not sure. Either way, theres some fun stuff I found that ill have to look more into later. I cant say that Tile Molester is as useful as TileLayerPro as far as actual editing is concerned, but it is a great overall program for viewing and moving things around (it can also view graphics from other-gen systems i believe, like n64 and whatnot, which is pretty awesome. also, just the fact that it runs of java is sweet enough in itself).

The Tile Molester in all its glory

Also, here's a few videos from last week I forgot to put up here. The first is my attempt to decode the horrendous graphics problem of Mortal Kombat while the second was basically some glitch tests i happened to come across while i was jumbling around graphics in MK. Basically, changing the visual representation of hex data in TileLayerPro and seeing what happened. Also concerning Mortal Kombat, I really wanted to work more with MK than SFII because of its..."features" i suppose (lots of blood, fatalaties, etc), but after spending the past two weeks trying to crack its graphics and still being stuck Im not sure how hopeful its looking. I beleive the graphics are actually compressed, which if they are, means ive pretty much hit a brick wall because i definitely dont have the time to figure out how to decompress them at this point. Maybe some time in the future though. Ill give an update on the actual physical bending of the SNES sometime soon as well.

(a bunch of tests stitched together)

-dylan

FINALLY

Took me nearly three weeks. More on this later. But first, lunch.

Website Update

Updated the apps/resources page on the website. I'm going to try to keep a running list of things I use there, just because there's so much to go through (you have no idea how many zip files I have on my desktop of miscellaneous, half-working snes apps) and it's really getting to be too much for me to keep track of. This is helping though, and seeing just the ones I use laid out like that makes it look simpler than I thought it was.

-dylan

More Videos

Masking Test


Abstraction Test 01


Abstraction Test 02

2SNES

Finally arrived, although not quite with enough time to tinker for this week. I have to say, Salvation Army Seattle did the best packing job I have ever seen.

Text Hacking/Translating

A few weeks ago I made a nice breakthrough on text hacking, as I think I mentioned somewhere earlier. Though it wasn't my initial goal when setting out that week, I think it's a valuable skill to have that can have quite a bit of power to it. The process itself, however, not so user friendly. Or rather, just a pain to go through. I'll try to explain it as simply as I can.

All of the text in a game is stored as hex data. Basically, each character is assigned a graphic tile, and a hex address will bring up that graphic to create words. Our first objective in text editing is to find out what hex symbols which character. You can basically think of it as cracking a translation code. I start off by finding a very specific word or phrase in a game, one that will probably only appear once. In this case, I'll translate the word "battle" from Mario RPG.

1. We have to start somewhere, so we can hypothesize that "01" is equal to "A". Thus, "02" would be "B," "03" would be "C," etc. all the way up to "1A" for "Z" (Remember, we're working with hex, so after 09 would be "0A, 0B, 0C," not "10, 11, 12"). After we have our alphabet-to-hex key, we can translate the word "battle" as 02-01-18-18-0c-05 in hex. This isn't to say that the programmers in Mario RPG chose "01" as "a" and "02" as "b" etc. However, there is a relative change in hex value to the word "battle" regardless of where "a" starts at. Using a program called Windhex, there is a function called "relative search" that does all the hard work for you. If you load up a Mario RPG rom and do a relative search for 02-01-18-18-0c-05, it will go through all the possible translations of that pattern, and if you did everythign right, it will tell you what your "b-a-t-t-l-e" values are, giving you enough information to decode the alphabet for Mario RPG. Also, be aware of capitalization, because they do affect the result. If the original word you looked at was "BATTLE" as opposed to "battle" or even "Battle," you will get two different character sets (one for capital letters and one for lowercase, obviously).

2. Now that we know what characters represent what in Mario RPG, we have to make what's called a table to translate the hex to alphabet. This is exactly what it sounds like, and the program that I found to be the simplest was TaBuLar. Just go in and fill in what your table should be. You can save from TaBuLar to a .TBL file for thingy.


3. When you start Thingy you are asked for a rom location and a .tbl location. If you load both, you'll see on the right hand side a translation of the hex and voila, you can go about editing the text as you wish. A little bit of a roundabout way of doing it, but it works. Pretty simple right? Well here's the best part.

Personally, I can't stand Thingy's GUI and just overall design, and it hurts my head to look at it for more than ten minutes. So I switched to a different Hex editor that I happened to stumble upon during my various endeavors: Translhextion. Translhextion lets you edit hex in a rom, save it, and it can also read Thingy .tbl files. But wait, it gets even better. Turns out Translhextion has its own relative search function, which, if it finds what you're looking for, will automatically translate the hex to english characters. And even more, you don't even have to do that original "hypothetical" translation like in step one. If you type in the word "battle" it will do the rest of the work for you. all with the press of an enter key. Sweet, right?


So what was the point of all that other garbage I just went through? Well, it was actaully a great way to understand it conceptually and poke around various pieces of software. It kind of does take the glory out of doing what I was doing, but after using that original method a few times, I am quite glad to say that I happened to notice that feature in Translhextion, because it's saved me hours of work now. Radical!



-dylan

Week 07 Update

I'm not really sure where to start with this thing, since there's so much to go over since we've started. I suppose the best thing to do is start with where I'm at now and try to work my back backwards as I find more time to update. I was trying to focus on graphics this week (more specifically, sprites), and ended up look into how to swap out palettes for certain graphics. Essentially in a super nintendo tile there are 16 color slots which can be used to make up any single tile. The tile then refers to a palette, which tells the super nintendo what color values to put in those slots. It's a great concept for saving space, but can be a headache when you open up the tileset of a rom and get this because you don't have the right palette data:

So what that means is you have to find a way to decode the palette data for the tile you're looking to edit, as well as find where the palette data is referred to in the game (if, for example, you wanted to make Ryu's robe neon green). Conceptually its actually quite simple, and this wonderful person Digisalt has released this wonderful set of programs with an equally wonderful tutorial to accomplish this task (available here). Of course though, as things seem to go with this, my computer seems to have some disagreement with some form of software required or another. I don't think it's Digisalt's programs, which seem to be doing exactly what they're suppsosed to, but rather Tile Layer Pro, which is having a hard time loading palette data extracted from Digisalt's exe's (or rather, not loading any palette data at all). I'm working on figuring this out now, and I have a hunch it might be my computer (Windows XP and my graphics card seem to be very disagreeable with a lot of these programs floating around for rom hacking), so we'll see what happens with that. It's a nice trick to be able to have under your belt, and is actually quite simple as long as everything works properly.

Either way, that ended up not working, but as a result I did end up developing a (very crude) method of translating palette data from the game so that I could edit the "color slots" of the graphics (not the paletta data, but the acutal image itself). When first looking at that mess of tiles in Tile Layer Pro (see above) I thought, "Man, I'm never going to be able to do anything with this." But, after three weeks of staring at these tile sets and reorganizing them, they actually start to get pretty clear.

By focusing on a very distinct tile, such as the single tile that makes up Ryu's left foot when he's standing, it isn't too hard to sort through the tileset until you find what you're looking for. Then, taking a screenshot from ZSNES, i simply compared the actual in game palette colors to what was being read in Tile Layer Pro. After that it was a simple matter of copying over the 16 RGB values and all of a sudden the tile set is as easy to read as a Dr. Suess book. You can see a comparison below.

Once you get it to that point you can really do with it as you please. Of course, a videogame is an animation, not a still image, so even doing one little change would require you to modify every frame where that change is visible. As a test I added a little stupid red mask to Ryu. Kind of tedius, yes, and very pointless, yes, but it shows what can be done with this. I was even able to find in the tileset where Ryu's portraits were located so I could put the mask on the character select screen, as well as a badass scar on Ryu's right cheek (the portraits, by the way, required me to define a different palette to read them, which is always exciting). You can see a screengrab and a little video below of masked Ryu in action. You can see there are a few frames of his face I missed, and man, did i draw a lot of little red masks on little red faces.

(I just realized how bad the quality on this video is, sorry. But it gets the idea across)

On another note, I found out that the text in Street Fighter II is in fact editable. I was worried that the text would simply be some simple graphics located somewhere in the rom because really, how much text is there in Street Fighter? Well, more than I remember, apparently, because there's a whole lot you can change around, which is pretty exciting. In fact, pretty much every word in that game is changeable due to the fact that the amount of text in the game is so small. It makes it very easy to single out what you want to change and just go for it. Some screen shots below, I'm not really sure where to go with this, just that it's a very fun thing to have control over. I'll go over the process of translation/text editing sometime this next week, it's really quite easy and wonderful.


This is just a brief runover of what I've been up to this week, I'll keep in mind more thorough and clear explanations of this for the future. I also spent a lot of time messing around with F-Zero, which I unfortunately never really got a chance to play on the super nintendo as a child--a tragic story. It's so beautiful, i really would love to do something with it, but with its fancy "3D Engine" and bells and whistles, everything I did to it just made it crash and beep at me. Maybe I'll find something out with it in the future.

-dylan

Welcome

A start.