Zelda: The Minish Cap Tile Ripping Proyect

[Ailos]

Last Updated 18/11/14  10: 38 P.M (time of Mexico).

longer update times due to not having enough time, maybe 2-4 days.
I update the files when i make a big progress over the last time i edited them

This post is to show some of the work i'm going to do in the couple weels/months on fully ripping all the tiles and make a image for each area tileset

I need some help on organizing all the sprites i got
if someone can help me it would be great as i could finish this faster and publish it to the Spriters Resource page

News: All the old news get deleted.
Really busy at work and i'm adding new tiles on the sheets as i need them for another proyect when one is done i'll publish it

There's so much unused content on the sheets like bomb-able walls for the houses and some other indoor wall pieces that are not shown in the game

Currently i am working on the House Tiles

about a 30% done on the House Tiles

Progress:

Special Stuff: 0%

Animated Water: 40% (just some on a 16x16)    
Animated Water Borders: 0%
Animated Green Water: 0%
Animated Green Water Borders: 0%

Overworld Areas: 1%

• Castor Wilds: 45% (green water, water, water stuff, the grave, texture cleanup and all the animated tiles)
  
• Wind Ruins: 24% (rocks, walls, some color palettes, rock walls and texture cleanup in general)
  
• Royal Valley: 4% (just created the files i need to start ripping)
  
• Castle Town: 0%
  
• Cloud Tops: 0%
  
• Eastern Hills: 0%
  
• Elemental Sanctuary: 0%
  
• Hyrule Castle: 0%
  
• Lake Hylia: 0%
  
• Lon Lon Ranch: 0%
  
• Melari's Mines: 0%
  
• Minish Village: 0%
  
• Minish Woods: 0%
  
• Mt. Crenel: 0%
  
• Mt. Crenel Base: 0%
  
• North Hyrule Field: 0%
  
• South Hyrule Field: 0%
  
• Tower of Winds: 0%
  
• Tribly Highlands: 0%
  
• Veil Falls: 0%
  
• Western Woods: 0%
  

Dungeons: 0% (done sorting some files)

• Deepwood Shrine 0%
  
• Cave of Flames 0%
  
• Fortress Of Winds 0%
  
• Temple of Droplets 0%
  
• Royal Crypt 0%
  
• Palace of Winds 0%
  
• Dark Hyrule Castle 0%
  

House interiors: 30% (found all the floor tiles but they're too complicated to use and some unused stuff)
some of the tiles are sorted into this file
Left to add:
-Objects (such as the ones in the blacksmith house like the anvil and tools on the walls)
-special floor tiles

Shop Interiors?: 0%
(this is a little bit complicated to explain, some shops have different colored tiles as well as other special places like the training dojo but they're all using a different tileset most of them... the shop uses one, the bakery another one and so on.)


Gallery: (just to show off some of the stuff that can be made with the tilesets)

   
One of the things i made with the Castor Wilds Tileset not really imaginative and i didn't had idea what to do but might do something better another time

   
I love these things

[Raccoon Sam]

Hello and welcome!
I think I might be able to help tremendously, at least in a technical knowhow sense. With the right set of tools I think we could do the entirety of this in a matter of days. There's a trick involving VBA's save states that let's you get like, complete tilesets very quickly.
I'll elaborate on this later this night.

[Ton]

Raccoon Sam for president.

[Ailos]

would be great if there's an easier faster methode to rip the tilesets.
And btw it's taking me about one hour to take an area and start trying to make sense of the all the tiles, the problem with the minish cap is that there's too many variants and trying to identify them all is difficult i'm going to keep up with this for the moment i almost got all the static tiles for the Castor Wilds

[Raccoon Sam]

Well, I must apologize. SGMs nametables can be spoofed to overwrite the level data to display all the tiles instead of the original area's tiles.. BUT, turns out that Minish Cap has really really many tiles. I don't know if the classic screenshot method is viable here anymore, but this will surely help, despite probably needing a programmer.

First off, go to the area you want the tilesets from. Then, make a save state (SGM).
Decompress the SGM and head over to 0x35493. You'll see a bunch of bytes; eight bytes make one 16x16 block, and two bytes makes one 8x8 tile and they're read tile ↖, tile ↗, tile ↙, tile ↘.
You must read 0x4000 bytes, so you get all the 0x800 16x16 blocks of the tileset.

The two-byte combos are read like this:

You get the palettes from 0x1FC7F, it's $200 bytes and it's BGR 555.

And the graphics are read from 0x485DF, it's $C000 bytes, 4bpp linear, reverse order.


I've never played the game so I don't know too much about it, but with this method, someone will be able to create a program that takes decompressed SGM as input and spews out full tilesets of the area in question.

Note: There are probably many many areas with unique tilesets in the game, so you'll need a separate SGM from each area.

Also, the SGM decompression is just like uh, rename the .SGM to .gzip and open it in your un-gzipper of choice.

[Ailos]

Thanks for this i think i'll get to work on those tiles as soon as possible, i had noticed the 8x8 tile format just yesterday as when i was ripping some areas i noticed that none of the tiles i found we're normal 16x16 and having so much variants would be impossible.

After reading your message i started looking trough the files i got but no save of mine is that far on the game so i can't get that many tiles via saves, so i'll have to play trough the whole game again :/ but at least while playing using an emulator i found out that i can get the animated tiles using the tile viewer

I think i'll be done compiling the animated water soon and make a small gif to show some of the new tiles i got

Edit: It's done, not the best and in the final product there's more wait time between frames but i got the water ripped
   
(infuriated water running >:-D)

[puggsoy]

I've never played the game so I don't know too much about it, but with this method, someone will be able to create a program that takes decompressed SGM as input and spews out full tilesets of the area in question.

*rubs hands together*

You may have already noticed, but I love making programs that do byte-level stuff. It's just so fun and interesting to take binary data and turn it into proper, usable results. Not to mention it's good experience and practice.

I'll get to work on this!

EDIT: I'm looking at your explanation more carefully now and I get pretty much all of it. I want to make sure of something though; at 0x1FC7F there are $200 bytes of palette data, BGR555 means 2 bytes per colour, and hence $100 colours total. I assume that there are $10 palettes, with $10 colours each (because $10 x $10 = $100), and that the 4-bit value in those two-byte tile values refers to one of those palettes, and that each 4bpp pixel refers to a colour in that palette.
Is this correct? It probably is but I figured I'd check I'm seeing this right.

[Raccoon Sam]

Yes you're exactly right.
Also awesome thank you.

[puggsoy]

OK so I've pretty much made the program, but the output looks wonky. That is, it's all glitchy and it's not really giving any proper tiles. I'm not sure why, but if you could give some clarification on a couple of things that might help.

When you say 4bpp linear "reversed", does that mean that instead of byte 1 = first bitplane of first row, it's actually the fourth bitplane of the first row?
So for example, format 11 in this document explains 4bpp linear. So instead of it going like this:

Code:

[r0, bp1], [r0, bp2], [r0, bp3], [r0, bp4], [r1, bp1], [r1, bp2], [r1, bp3], [r1, bp4]
[r2, bp1], [r2, bp2], [r2, bp3], [r2, bp4], [r3, bp1], [r3, bp2], [r3, bp3], [r3, bp4]
[r4, bp1], [r4, bp2], [r4, bp3], [r4, bp4], [r5, bp1], [r5, bp2], [r5, bp3], [r5, bp4]
[r6, bp1], [r6, bp2], [r6, bp3], [r6, bp4], [r7, bp1], [r7, bp2], [r7, bp3], [r7, bp4]

It goes like this:

Code:

[r0, bp4], [r0, bp3], [r0, bp2], [r0, bp1], [r1, bp4], [r1, bp3], [r1, bp2], [r1, bp1]
[r2, bp4], [r2, bp3], [r2, bp2], [r2, bp1], [r3, bp4], [r3, bp3], [r3, bp2], [r3, bp1]
[r4, bp4], [r4, bp3], [r4, bp2], [r4, bp1], [r5, bp4], [r5, bp3], [r5, bp2], [r5, bp1]
[r6, bp4], [r6, bp3], [r6, bp2], [r6, bp1], [r7, bp4], [r7, bp3], [r7, bp2], [r7, bp1]

Is this correct?

Also are multi-byte values read in big endian? Or little endian?

Also, I've attached a (decompressed) savestate that I'm using to test this (it's in a ZIP so I could attach it). If you could give me some images of 16x16 tiles found in it, along with the offsets of their 8-byte information chunks, then I can know what sort of output I'm trying to get.

[Ailos]

i mostly don't understand how the texture format works tried using some tile ripping tools around and couldn't work with any of those because i could never find the palettes

but i could get you something out of the tile viewer of the emulator

EDIT: i was messing with tile molester switching between 4bpp linear and reverse order and got some interesting results

    download this

top 8x8 one is 4bpp linear
the bottom 8x8 is 4bpp linear reverse order only thing that changes is that the columns of 2x8 pixels switch places

EDIT 2: here's some of the tiles i got from an area i'm using VBA with the tile viewer and OAM viewer i actually got 16 palettes here from wich i can use them all for some reason

                   

[Raccoon Sam]

To be fair, I have no clue what "linear, reverse order" even means. It's just always been a codec option in Tile Molester as long as I can remember.
Ailos is on the right track, though – those graphics shown in the VBA Tile Viewer are exactly the same as the graphics in your state, puggsoy. This is a screenshot from Tile Molester, with graphics from 0x485DF and palette from 0x1FC7F:


Those 8x8 tiles get arranged to 16x16 tiles exactly the way 0x35493 tells them to.

[Ailos]

that's amazing i couldn't find them when i used tile molester

[puggsoy]

OK, looks like the "4bpp linear" that the document was talking about is different than how this is supposed to be done. After comparing expected results with what I was getting, and looking at the instructional bytes themselves and their bits, I figured that it truly is linear. That is, each half byte has all 4 bits for a pixel, and they're just read in order. No bitplanes, which is way simpler and quicker. "Reverse order" probably means reading the 4-bit chunks from right to left, which also explains Ailos's comment "the bottom 8x8 is 4bpp linear reverse order only thing that changes is that the columns of 2x8 pixels switch places". I sort of did it from right to left intuitively anyway though.

After some more testing, I also realised that both the palette and the instructions are in little-endian; I had been reading the former in that manner already, but I thought the latter was in big-endian.

Anyway, now that I'm managing to extract them properly, how should the program go about doing this? Do you want it to extract all the 16x16 tiles, or only the unique ones (i.e. skip duplicates)? And should it extract them all as separate 16x16 images, or as one big image?

[Raccoon Sam]

Great job!!
And, that's a good question. I'd go for full 16x16 sets for completeness' sake. But I don't really know how many of those duplicates there really are. Can you give us an example output?
Overall I think the most important feature would be a built-in un-GZIPper so people could use it right out of the box; place the exe in your save states-folder, play the game, save a state, run the program, DONE.

[puggsoy]

Here's an image of the total output:

   
I arbitrarily chose to put it in a 64x32 grid of 16x16 tiles. As you can see it's not very organised, if anything actually less so than when looking at the tiles in a tile viewer. It does give them the proper palettes though.
If I removed any duplicate 16x16 tiles it would be much more compact and probably also easier to use, since all those black ones get in the way.

As for automatic uncompressing, that was actually one of the first things I did. The program just accepts straight-up SGMs.