News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: The Console Tool (by Low Lines)  (Read 252685 times)

Zerox

  • Jr. Member
  • **
  • Posts: 16
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #120 on: September 09, 2010, 09:12:30 pm »
Well Low Lines I decided I stop by and show you what I plan on using your tool for. I'm working on a fan game of sorts for Kingdom Hearts. It's still heavily in development but my hopes are that you will impliment some format to export DS models to a useable format or perhaps you could give me a link to where you have all your current knowledge of the DS model format so I could share it with someone who may be able to write a simple converter for me using that information.

The reason I hope for such a feature is because Kingdom Hearts 358/2 Days (on DS) is the only Kingdom Hearts game I have found that has the actual play areas exportable as a model/models. And I would like to use these playing area models to create my own levels for my fan game.

Now I realize people don't like doing anything without proof that work on said project has actually been worked on some. So here are 3 screenshots from it so far.







I'd really appreciate such a feature or could you at least tell me if you plan to add a feature like that at all? I apologize if this seemed like advertising, it's not my intent here.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #121 on: September 10, 2010, 07:39:21 am »
Zerox the thing is, its not a matter of "if" but "when". I fully intend to do so, just I can't give you like a date or anything right now. You also should probably be a little more conservative on your requests, otherwise it comes across to everyone else as a "noobish" sort of nagging if you know what I mean. I appreciate your eagerness here, but things just don't happen overnight, in fact I can't even work on my project much at all right now since I am not in the right mindset because of my studies.

If you check out the documentation on my temp new site I posted up earlier this week, it has the most complete documentation on NDS 3D models (NSBMD) on the net, including the stuff I've figured out on my own. If you happen to come up with an export implementation that works, feel free to give me a look so I might be able to support it in the future, since there are a ton of different formats to choose from and I'm likely to only support a few on my own.

Zerox

  • Jr. Member
  • **
  • Posts: 16
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #122 on: September 10, 2010, 09:43:59 am »
Well I'm glad to hear it is indeed planned. I was beginning to wonder such. I apologize if I appeared to be nagging. I'm eager is all.

I'll take a look at your documentation and I'll let you know if you get any success.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #123 on: September 19, 2010, 11:16:14 pm »
Nothing like a new game coming out to get you back in the right mode for a bit of game hacking...
If anyone is familiar with the new Pokemon DS file structure, you would know it has been deliberately packed in a way to make it harder to extract files from it. However since my app doesn't rely on filenames to anyalze files, it made the job a little easier. It took about 3-4 hours to go through the 'a' folder, and it gave me an interesting chance to see how well my app faired. I found I was jumping back and forth between the newer version and the older version since one can open images while the other can open models/textures and I also had to restart them both several times because they gradually choked up a lot of memory, and it kind of didn't help I was streaming video to my PS3 and had multiple download apps running at the same time. The LZ77 compression found on a lot of files seems to be another extended version similar to that in kingdom hearts, in that it tries to decompress bytes further back that what is decompressed already, so I am yet to make much progress extracting the pokemon sprites...The few map models I looked at though are pretty damn awesome, really cannot wait until this comes out in Australia.

Here's the 'a' folder structure in case anyone is interested. Most of the key files are located in the first handful of archives. Note if by posting this causes any problems I'll remove it right away :S

Pokemon BW 'a' Structure

[edit]

Two new file formats that were popping up quite a lot in this game were NMCR and NMAR. NMAR is basically a clone of NANR, but NMCR is totally new. I'm not certain but I think these might have something to do with masking, since when you catch a new pokemon on your pokedex and does this cool little swipe up effect from a black silhouette. Can't do much with them though until I can extract the NCGR files which are compressed and probably encrypted too >_<

[edit 2]

The Pokemon Sprites narc (a/0/0/4) is a hefty archive, with 14285 files, which will take a while on any narc extractor to extract. I so need to build a progressbar, because it just looks like my app hangs for 2+ minutes :/

The layout of these files is as follows, each pokemon owns 20 files in sequential order, this further splits in half to cover front and back sprites with the assisting palettes being the last two files of each 20 file batch. This continues for 712-713 occurrences with the left over files all being extra palettes.

A breakdown of one batch is as follows...

Code: [Select]
#1 NCGR
#2 index file (just points to the same offset as the previous file i think...)
#3 NCGR
#4 index file
#5 NCER
#6 NANR
#7 NMCR
#8 NMAR
#9 raw data file
------------------> I assume this is where the break is between front and back sprites
#10 NCGR
#11 index file
#12 NCGR
#13 index file
#14 NCER
#15 NANR
#16 NMCR
#17 NMAR
#18 raw data file
------------------> End of back sprite
#19 front NCLR
#20 back NCLR

All NCGR and NANR files are compressed using a variant of the standard LZ77 compression.
« Last Edit: September 19, 2010, 11:55:04 pm by Low Lines »

Bond697

  • Full Member
  • ***
  • Posts: 249
    • View Profile
    • The Final fantasy 4 Reference Book
Re: The Console Tool (by Low Lines)
« Reply #124 on: September 20, 2010, 01:14:50 am »
i've been going through the white rom manually finding stuff, but i don;t have a way of decompressing the nanr files.  is there anything that exists now that can do it?  crystal tile doesn't, and i can't seem to find anything that will. 

thank you for the breakdown of "a", btw.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #125 on: September 20, 2010, 02:01:03 am »
i've been going through the white rom manually finding stuff, but i don;t have a way of decompressing the nanr files.  is there anything that exists now that can do it?  crystal tile doesn't, and i can't seem to find anything that will. 

thank you for the breakdown of "a", btw.  it helps a lot.
I don't think anyone has yet documented the new compression format, most likely because no one with the skills has yet had reason to bother, which is why I'm hoping one of the Pokemon hackers does since it will probably allow for other games such as Kingdom Hearts to be accessible too. As far as I know, someone has to do a bit of disassembly of the game arm routine that decompresses it, now I can handle a bit of disassembly but I don't know the first thing about finding it in RAM or however they do it.

On a side note, I'm currently putting together a compact version of my app so I can work more on file support instead of being held up by the complexity of the GUI. Big biggest issue I've been having is with the fact that since I've started doing Java at uni, the way I program has changed quite a lot (for the better), and so when I sat down and look at what I had, it was a combination of not being able to understand my own code, and just not liking what I saw :(
Since the start of this project its been a repetition of completely rewriting my code near on from scratch after every significant break I took from it. I really hate doing it but at the same time it also consolidates my understanding of everything much better each time. In general the file management classes were pretty good, albeit needing a clean up, but most the GUI and property management stuff was just a bad case of nasty, which is why I'm doing a compact version without them. What I mean by compact is just a basic side panel and the display panel with maybe a simple toolbar for basic manipulation. The rest of the stuff I was working on in terms of the GUI is gonna be left out until I iron out the class design.

I'm also updating my docs to the XML format as I work through adding each format. My focus is the Nitro Graphics set (NCLR, NCGR, NCER, NANR, NSCR, etc), which will then be followed by my model stuff.

I don't know how much I'll get done since I am in the last month of my studies, but definitely November onwards I should be able to put full focus onto this again, and hopefully get past a few milestones.

[edit]

Here's a sample of the Compact version...


As there won't be a browser, what will happen is when you open the app it will be blank, then all you will have to do is drag and drop a file onto it and it will load it, creating a new window for each one. Each window will behave on its own, with the exception of accessing other opened files to get combined types working together (ie palette with graphic). Really really simple and a heck of a lot easier to implement, meaning less time hopefully :D
« Last Edit: November 17, 2010, 08:21:37 pm by Low Lines »

Klarth

  • Sr. Member
  • ****
  • Posts: 492
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #126 on: September 21, 2010, 03:04:11 am »
It's pretty rocking that this project is still going.  It's quite a lot of work on the programming part...and just as much on the reverse engineering side as well.  :thumbsup:

Garyong

  • Jr. Member
  • **
  • Posts: 15
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #127 on: September 21, 2010, 06:08:28 am »
I've hacked the 0x11 compression format quite a while ago already. I've uploaded a C# and Java source of the decompression code here; http://code.google.com/p/dsdecmp/ feel free to use it however you like =). (you can also find a compiled version of the Windows command line version there)



By the way, the pokemon list file order is actually like this:

Code: [Select]
#1 NCGR (front, single frame)
#2 NCGR (front, single frame, female. pointer to previous is no gender difference)
#3 NCGR (front, frame parts. (limbs, eyes, etc. used for animation))
#4 NCGR (front, frame parts, female. pointer to previous if no gender difference)
#5 NCER (I think this is only for NCGR #3 and #4, looking at the labels stored in the LBAL section)
#6 NANR
#7 NMCR
#8 NMAR
#9 raw data file
------------------> end of front sprite data
#10 NCGR (back, single frame)
#11 NCGR (back, single frame, female)
#12 NCGR (back, frame parts)
#13 NCGR (back, frame parts, female)
#14 NCER
#15 NANR
#16 NMCR
#17 NMAR
#18 raw data file
------------------> End of back sprite data
#19 NCLR (normal)
#20 NCLR (shiny)

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #128 on: September 21, 2010, 06:16:47 am »
I've hacked the 0x11 compression format quite a while ago already. I've uploaded a C# and Java source of the decompression code here; http://code.google.com/p/dsdecmp/ feel free to use it however you like =). (you can also find a compiled version of the Windows command line version there)
Dude you are a legend!!
You know I was actually wondering why they had zero size files in archives (have seen it in other roms too), seemed totally weird, but using in that way with genders makes total sense!!
I'm working on some assignments for uni right now but I'll have to have a look through your code hopefully on the weekend so I can fix my code up. Mine is based on GBATek which is probably a little outdated by now :(

RetroHelix

  • Full Member
  • ***
  • Posts: 148
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #129 on: September 21, 2010, 04:20:40 pm »
Sorry for posting offtopic but I have a to ask, where guys like you, Low Lines and Garyong, are publishing their knowledge about new fileformats or anything else related to reverseengeneering binary files. (besides this site)


Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #130 on: September 21, 2010, 05:31:35 pm »
Not actively no, but I plan on making it a habit to keep my docs updated from now on. They'll be held on my site (which is in dire need of more monthly user visits) once I push the new design forward. I could have probably found Garyong's googlecode with a quick search but the last time I did do that, there hadn't been much progress on that front. Plus, no offense to Garyong but knowing what keywords to write to actually find the site I think would be hard since typically if I were to search for LZ77 decompression, I'd write that or maybe "ds lz77" etc which doesn't put his google page within the first page of results (and probably not the second or third either). Whereas if you put in "console romhacking" you get this forum as the second result, which is a more likely kind of search a person would make. "low lines" actually gets my old site on the first page too XD. This is all to do with accessibility in websites, which doesn't just mean people with disabilities as things such as search engines need a bit of help to better find stuff, which is why having a meta keywords list or try using words more likely to bring up your page is handy. Stuff like flash decrease accessibility since you can't access text stored in them easily, and japanese websites are worst with their images of text >_<
I want it that if someone wants to find docs on formats they can hopefully get my site on the first page, or at least someplace on romhacking.net so it can then point to my site. It probably the only benefit of having a doc submitted to the database here, it shows up in a search really quickly due to the large amount of visits to this site. It would be better if they were just linked though so I can make changes to the docs without having to resubmit them to the database...Mind I haven't really looked much into it as of yet.

Garyong

  • Jr. Member
  • **
  • Posts: 15
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #131 on: September 21, 2010, 07:04:03 pm »
Plus, no offense to Garyong but knowing what keywords to write to actually find the site I think would be hard since typically if I were to search for LZ77 decompression, I'd write that or maybe "ds lz77" etc which doesn't put his google page within the first page of results (and probably not the second or third either). Whereas if you put in "console romhacking" you get this forum as the second result, which is a more likely kind of search a person would make.
None taken, as I have to admit I just filled in some terms that came to mind when filling the tags.

I must admit most file formats I've hacked only have a somewhat-documented format on my own computer, scattered over the various tools I made (most of which were for personal use only). That is, unless I hacked a format to fulfil a request, the format is still not known to the general public (although most are just simple formats, or slight derivatives of more well-known formats). The formats hacked for requests usually get their format posted at the place where the request was made, but I don't have an organized online storage of any of these.

Zerox

  • Jr. Member
  • **
  • Posts: 16
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #132 on: September 22, 2010, 10:51:35 pm »
Plus, no offense to Garyong but knowing what keywords to write to actually find the site I think would be hard since typically if I were to search for LZ77 decompression, I'd write that or maybe "ds lz77" etc which doesn't put his google page within the first page of results (and probably not the second or third either). Whereas if you put in "console romhacking" you get this forum as the second result, which is a more likely kind of search a person would make.
None taken, as I have to admit I just filled in some terms that came to mind when filling the tags.

I must admit most file formats I've hacked only have a somewhat-documented format on my own computer, scattered over the various tools I made (most of which were for personal use only). That is, unless I hacked a format to fulfil a request, the format is still not known to the general public (although most are just simple formats, or slight derivatives of more well-known formats). The formats hacked for requests usually get their format posted at the place where the request was made, but I don't have an organized online storage of any of these.

I apologize as this is a bit off-topic but would any of the formats you worked with involve Kingdom Hearts on the DS?

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #133 on: September 24, 2010, 05:22:18 am »
Finally had a chance to go through Garyong's code and after a bit of fiddling around, I've successfully got it working in mine. When ever I go through someone else's source code the first thing I do is look for comments, and he has some really good ones in there, however they don't match up with his code.

Here's an updated version on his notes on the NDS LZ77/LZSS Compression...

Code: [Select]
----------------------------------------------------------------------------------------
NDS LZ77/LZSS Compression -> Credit goes to Garyong
----------------------------------------------------------------------------------------
Data header (32bit)
  Bit 0-3   Reserved
  Bit 4-7   Compressed type (must be 1 for LZ77)
  Bit 8-31  Size of decompressed data. if 0, the next 4 bytes are decompressed length
----------------------------------------------------------------------------------------
Repeat below. Each Flag Byte followed by eight Blocks.
----------------------------------------------------------------------------------------
Flag data (8bit)
  Bit 0-7   Type Flags for next 8 Blocks, MSB first
----------------------------------------------------------------------------------------
Block Type 0 - Uncompressed - Copy 1 Byte from Source to Dest
  Bit 0-7   One data byte to be copied to dest
----------------------------------------------------------------------------------------
Block Type 1 - Compressed - Copy LEN Bytes from Dest-Disp-1 to Dest
----------------------------------------------------------------------------------------
  If Reserved is 0: - Default
    Bit 0-3   Disp MSBs
    Bit 4-7   LEN - 3
    Bit 8-15  Disp LSBs
----------------------------------------------------------------------------------------
  If Reserved is 1: - Higher compression rates for files with (lots of) long repetitions
    Bit 4-7   Indicator
----------------------------------------------------------------------------------------
      If Indicator > 1:
        Bit 0-3   Disp MSBs
        Bit 4-7   LEN - 1 (same bits as Indicator)
        Bit 8-15  Disp LSBs
----------------------------------------------------------------------------------------
      If Indicator is 1:
        Bit 0-3   LEN1
        Bit 4-7   Indicator
        Bit 8-15  LEN2
        Bit 16-19 Disp MSBs
        Bit 20-23 LEN3
        Bit 24-31 Disp LSBs
        LEN = (LEN1 << 12 | LEN2 << 4 | LEN3) - 0x111
----------------------------------------------------------------------------------------
      If Indicator is 0:
        Bit 0-3   LEN1
        Bit 4-7   Indicator
        Bit 8-11  Disp MSBs
        Bit 12-15 LEN2
        Bit 16-23 Disp LSBs
        LEN = (LEN1 << 4 | LEN2) - 0x11
----------------------------------------------------------------------------------------
« Last Edit: September 24, 2010, 05:31:35 am by Low Lines »

Garyong

  • Jr. Member
  • **
  • Posts: 15
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #134 on: September 24, 2010, 05:57:29 am »
@Low Lines: The GBATEK-like specification of the compression was indeed more geared to how I interpreted it, instead of how it actually should be. I thought I got the format right, but apparently not (which is why I didn't use bit-numbers in the in-line comments).

Also, when LEN is composed of LENx's, it should be +0x11 and +0x111, instead of -0x11 and -0x111 ;]
(Oh, and would you mind crediting me as either Barubary or Aygox if you decide to upload the specs somewhere? I've no idea why I used another username when registering here =/)

@Zerox; I sent you a PM instead, since we do not need to derail this topic. The answer's yes by the way.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #135 on: September 24, 2010, 06:11:17 am »
@Low Lines: The GBATEK-like specification of the compression was indeed more geared to how I interpreted it, instead of how it actually should be. I thought I got the format right, but apparently not (which is why I didn't use bit-numbers in the in-line comments).

Also, when LEN is composed of LENx's, it should be +0x11 and +0x111, instead of -0x11 and -0x111 ;]
(Oh, and would you mind crediting me as either Barubary or Aygox if you decide to upload the specs somewhere? I've no idea why I used another username when registering here =/)
Yeah I personally hate dealing with compression formats because they explain them so poorly. The GBATEK style is incredibly clear and easy to understand, aside from that minus value stuff which I was considering editing anyways, you or I might be able to understand it, but if you read it like any normal person would, you'd get the wrong impression, which I think I did do when I first read GBATek all those years ago...

When I manage binarys like the above, I prefer putting them into one variable as it's much simpler referencing only to one rather than 4 like in yours (and probably 95% of programmers out there who do it and love short meaningless variable names >_<). I actually had to write them down on paper just to work them out properly myself, but I'm not complaining, these compressions have been a thorn in my back since I started working with binary files so I'm more than happy to think a little if it means I'm going to get somewhere with it :)

Will do on the credits part too. That's kind of why I try to be as consistent with everything I do, if a lowlines is on this forum, he's the same lowlines as the one on x forum etc :p Though I've kind of made a migration from writing it as "Low Lines" to "lowlines" because it's shorter and often fits better as a username in games :p

Koetsu

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #136 on: September 26, 2010, 12:10:05 am »
So this new LZ77 compression is the reason why your tool couldn't open some compressed overlay files in another game? I think they could be the same as the Pokemon and Kingdom Hearts LZ77 compressions. Should I send you some samples?

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #137 on: September 26, 2010, 12:28:27 am »
Correct, Kingdom Hearts and Pokemon BW both used this variant of the LZ77 compression. It's easy to pick it out since the first byte in the file is 0x11, whereas the standard LZ77 will have 0x10.  If you want to test files, you can use Garyong's app (just drag the file over the exe and it should do it automatically, but basically any file his app decompresses, mine will do also (except for Huffman which I haven't added yet). The one other exception is where the compressed file has a "LZ77" stamp at the start of the file, which his app will hang, and the public releases of mine might bring up an error, but those are fixed too (Super Mario 64 DS is one game that uses them).

If people can send me Huffman compressed files though that would be great, because whenever I add another person's code, I like to be able to understand it first.

[edit]

And just to clarify a little, I probably wouldn't call it a new compression format. It's used to better compress files with a lot of long repeated sequences such as zeroed bytes in an image. The normal compression I think can only compress up to 15 bytes per flag, whereas this variant allows for several hundred. So instead of five bits required to compress a long sequence of zeros, it could be done using one bit, etc. That's the basic gist of it anyways.
« Last Edit: September 26, 2010, 02:05:25 am by Low Lines »

Garyong

  • Jr. Member
  • **
  • Posts: 15
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #138 on: September 26, 2010, 07:21:34 am »
Since files with a LZ77 stamp do not get passed on directly to the decompression routine, but first through the code of the game itself, I haven't included such format(s) in DSDecmp. (and, to be fair, I didn't encounter such files while creating the tool)

This archive contains several files with huffman compression. I think they're from Summon Night: Twin Age, but they can also be from Summon Night X.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #139 on: September 26, 2010, 07:25:10 am »
Since files with a LZ77 stamp do not get passed on directly to the decompression routine, but first through the code of the game itself, I haven't included such format(s) in DSDecmp. (and, to be fair, I didn't encounter such files while creating the tool)
I know, I'm just pointing it out in case someone actually tests it and gets an error :p It produces a weird error though.
Thanks for the files btw, will have a look at them at the end of week hopefully :)

[edit]

The image below is a prime example of something I figured out while going over the NCGR file format.


As you can see, the sprites come in two flavours, your standard 96x96 still sprite, as well as a Yoshi's Island style body part one for animations. First off the animation one is not tiled, but forget about that for now. With the standard sprites, they seemed to lack a buddy file that you'd assume be used for arranging the cells as a 96x96 block (if you were to open this file in the old console tool you wouldn't get a nice 96x96 image like above. But interestingly there were values stored in the width and height spots, but if you apply a bit of logic in there its kind of obvious. The first chunk of tiles make up a 64x64 block, then the following makes up the remainder on right hand side which is then followed by two blocks on next row, it turns out the width and height are used to arrange the tiles, I think this was how it was done in the GBA.

Code: [Select]
< - - - -  96 - - - - >
1 1 1 1 1 1 1 1 2 2 2 2
1 1 1 1 1 1 1 1 2 2 2 2
1 1 1 1 1 1 1 1 2 2 2 2
1 1 1 1 1 1 1 1 2 2 2 2
1 1 1 1 1 1 1 1 2 2 2 2
1 1 1 1 1 1 1 1 2 2 2 2
1 1 1 1 1 1 1 1 2 2 2 2
1 1 1 1 1 1 1 1 2 2 2 2
3 3 3 3 3 3 3 3 4 4 4 4
3 3 3 3 3 3 3 3 4 4 4 4
3 3 3 3 3 3 3 3 4 4 4 4
3 3 3 3 3 3 3 3 4 4 4 4

This only applies to one way the ncgr file seems to store an image, the other two being like the animation graphics above where you have a straight graphic that is drawn line by line, and the last type being one without any type of internal alignment and relies on a NCER file to position everything (these are normally very complex sprites that makes use of layering cells on top of each other).

[edit2]

Wrote a quick batch routine and exported all single frame sprites (normal, shiny, gender, forms) for BW to PNG :) Some of the new ones look awesome! I'm not going to put them up since this image ban is on, and I also doubt I'm the first to extract the images, but its an odd feeling, going back several years I was one of those noobs following fileb and all those other hackers as they hacked the games :)

Anyways just a few things I noted on the archive...The first 712 batches of 20 follow the format already mentioned, then you have the substitute doll sprite, followed by about a dozen palettes which I think are used for battle effects (ie lightning makes your poke go funny color). Also with the nmcr and nmar, this is still an theory but seeing how the ncer and nanr handle animations of a pokemons limbs separately, I think these last two files are like layer on top of that. So the nmcr would position each body part (which are a group of cells), and the nmar would manage the animation for them. I'm still only up to adding NCER cells so I can't test my theory yet, but due to the similarities in the file structures and the way pokemon sprites are animated, I think it's highly likely :)
« Last Edit: November 17, 2010, 08:20:40 pm by Low Lines »