Homebrew How to see ZL Files ?

[Trekeln]

Hi, I met a problem on DesMume. I extracted Skate It files, however, a good 90% of them are actually .zl files.
After some research, it appears that it's an extension for use with some software called "zlib". But I can't figure out what the hell I must do for seeing those files as images!
So, if anybody knows about it, please tell me some advices!
Thanks!

 

[FAST6191]

While it could be something like that it is not always the best to read into it.

That said here you might well have got lucky.

Had a look myself. Does appear to be some form of compression (the data itself does look compressed) but I am not sure why the devs chose some files and not others -- sometimes it will be those over a certain size get got but here I have files way larger than whole directories of ZL files.
Anyway it does not have any of the standard markers of compression formats we normally see on the DS; such things tend to start with 10, 11 or in some later games 40, though there are some others even more rare. Here 78 hex seems to be the main starting value, maybe 78DA.
Otherwise when the extensions are bmp then it does appear to be just that -- my normal image editors (not ROM hacking tile editors, straight image editors) show me all sorts of nice game graphics. Not the first time I have had that but a rarity in DS games (I am going to be hard pressed to name much more that used it this extensively since either the web browser or .

You have four choices.

1) If indeed it is some basic zlib type deal (and not basic zlib with their own little twist) then hopefully one of its library implementations somewhere just handles it. Don't know that I have seen one just doing the rounds (some Japanese computer peeps use some odd formats for compression) but there might be, and you could possibly implement one.

2) You can try to figure it out by simple analysis. Compression is usually fairly similar and https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf acts as a nice primer. The DS is not that powerful so you will not likely be getting much in the way of exotic file types
I have done things here by hand, it sucks a lot but is feasible.

3) Games tend not to use compressed data. To that end you might find an example of decompressed data in the RAM somewhere, though as the DS itself struggles to use BMP the game probably has to convert it to a format it understands so you might have to go first before it appears in VRAM.
3a. I noticed there is a DWC folder. In this is typically another ROM (as in another basically .nds you can peer at the files for using ndstool/crystaltile2/ndsts/nitroexplorer2/tinke/dslazy/dsbuff/whatever your chosen ds unpacking tool is) used for download play options. If it should use the same file (maybe a menu, maybe a piece of the UI) the same as a compressed file elsewhere then it could be a way to get one. Most stuff in dwc files is generally compressed with DS standard compressions https://www.romhacking.net/utilities/826/ so you might get lucky there, have not checked it though.

4) You do big boy tracing a la https://www.romhacking.net/documents/361/ but using no$gba debug. This will tell you exactly what it does to decompress the file so you can later replicate it. Means you have to learn ARM assembly programming, though most compression is usually "copy this much from this location, this is not compressed so skip to the next section, this is not compressed, copy this much to this section... oh good you are at the end of the file" and does not then involve the crazy maths nor exotic operations (what few the DS processors and BIOS have).

 

[Trekeln]

Thank you so much for your reply! The thing is that I don't really know how to use zlib, or how to really "see" directly the images. I've downloaded no$gba, but I cannot figure out what's where...
I also figured out that I can use Tile, Map, and OAM viewers for seeing directly the files. However, I cannot export them into my computer.
Anyways, thanks again!

 

[FAST6191]

zlib is two things it seems.
https://www.zlib.net/
which appears mostly as gzip.
http://www.zlib.org/rfc-gzip.html
The format did not appear similar here to what was detailed there, and for the size of some of them I would be surprised.

http://www.zlibc.linux.lu/
A separate project but the way most games work mean it could be something in this world.


Anyway back to the first
zlib these days as the name kind of implies is mostly a library, which is to say a bit of code used by other programs to do their internal decompression needs rather than something end users might do to make zip files* to send to their friends.
Depending upon the library you can implement it as a binary to allow people to simply compress and decompress files, or indeed write a simple wrapper program to do it for you.
http://gnuwin32.sourceforge.net/packages/zlib.htm appears to have a few for Windows if you are on that.
http://www.winimage.com/zLibDll/ has a file called sfondo.zip that specifically mentions BMP (which this game otherwise uses and has as extensions earlier in the file name) so might be something worth investigating too.

https://stackoverflow.com/questions/12147484/extract-zlib-compressed-data-from-binary-file-in-python being an example of the wrapper thing done for python (a common scripting language).

Whether any of these will work for this I don't know but if indeed it is some flavour of zlib (and it is one of the rare custom compressions on the DS -- I am not sure I have other examples offhand right now that were not random archives left in the ROMs by devs that did not do a bit of cleanup. Have a few for the GBA) then this would be where most start.

It might all still be a red herring and sending us down the wrong path but hey. Nobody likes making a truly custom compression though so using an existing thing, especially one so free and clear like this, is generally a solid plan for the would be lazy dev stuck with making a DS game (especially if whatever they are porting from also used it).

As far as tile, map and OAM. The DS (and frankly most consoles) don't care to have to convert files on the fly (generally a waste of time) so have formats baked into the hardware. Those are various viewers (tile is basic what is in the video memory, map is usually what is in the background but arranged according to its various formats also in hardware for that job, and OAM is short for object area memory aka what objs are controlled with, objs being what you and I would likely call sprites). Some emulators will have export tools, others will want you to head back to the plain old memory viewers (or maybe a savestate -- it is a copy of memory after all) and go to the relevant locations ( http://problemkaputt.de/gbatek.htm#dsmemorymaps , which many of said viewers should note somewhere). Some tile editors (crystaltile2, tinke, tiled2002, tiled-ggd being some I like) also will speak to savestates and emulators but we will leave that for now.
However while I said on the fly conversion is usually frowned up I have to wonder what goes here -- normally fetching things sitting in VRAM and comparing them to the compressed versions can see you figuring it out. Here though if the BMP files are first decompressed and then converted to VRAM compatible formats you will have to either intercept at the first stage, or go from VRAM to find when the conversion happens and then work backwards again, which is on the more annoying side of the tracing thing I mentioned above).


I should also note that if you only want the images to use in your own game or something then print screen works quite well -- I would bet 90% or more of the sprite sheets you see were someone pressing printscreen on such a thing.
They were probably helping themselves out a bit -- don't play a whole game to get to the end boss, chuck some cheats in there to help out make it go quicker, find saves on the internet.
Or in this case you sound like you have already managed to pull the game apart -- if it turns out thrasher_BLANK.bmp.ZL is the main thing seen before you do a whole load of sidequests then in the same folder is thrasher_SM.bmp.ZL of a similar size. Chances are the latter if you overwrote the other file with it and changed the name would display whenever the blank image displays and thus you might grab it sooner.


*though I will note in the locations folder is a bunch of what look like plain and normal zip files, appear to open as such as well.