Topic: DS Sprite-ripping simple question

[TheouAegis]

OOh that is useful. I didn't know they stored the palettes in the overlays. I messaged SmithyGCN about where the palettes were and don't think I've heard back from him yet. ... Okay, so I haven't checked actually.

The NCGR/NCLR format is so much easier to work with. Sure, the sprites aren't all right there up front and typically they're compressed, but still, all the data is easy to find as it's lumped right there and often even named appropriately. ... I gotta study how the names are actually stored. It's just so convenient scrolling through Front Mission DS and seeing all the wanzers labeled accordingly and all the subdirectories labeled for you (Parts for Setup, Parts for Shop, Battle Parts, etc.).

[TheouAegis]

Status update on my NCXR loading program. Already had the NCLR palette file worked out at the basic level (remember, right now I'm just worried about ripping Front Mission DS graphics... OF WHICH THERE ARE THOUSANDS!!!!) and implemented into my current mini project an NCLR loader with palette display and BGR<-->RGB swapping (which, logically, was the easiest thing to implement). Tonight I worked on reading and drawing an NCGR file uncropped (but unpacked, I don't know how to decompress files) to a surface using said NCLR file and then saving that NCGR as a tile set. So far so good. Tomorrow night I'll go back to working on reading the NCER file and combining all three files into a full sprite. I know it's been done elsewhere. I think Tinke, the program whose author's notes I've been reading, did this already. I just don't know if his program saves the images. And anyway, I don't read Spanish, so his program does me little good anyway. That's why I'm working on this one for my own. That and it's also a challenge. I like challenges; great way to pass my life away so death seems so much closer.

[TheouAegis]

Haha been making stupid shit in GM again like creating a surface 8 pixels wide then trying to draw a 32x128 image to it. Herp-a-derp.

NCLR and NCGR reading complete. This is essentially how the OAM (object assembly manager, or something) would look assuming No$GBA had that more readily available. This is the NCGR data of one of the parts legs in Front Mission using my 0.1a version of my NCLR (palette) and NCGR (sprite) reader. This weekend I'll work on putting it all together with the NCER reader. It's only version 0.1a because I'm taking a lot of shortcuts in programming this, such as not actually reading offset data... I might have to implement that in later versions. Also, sadly, not very many NDS games use NCLR/NCGR/NCER data formats (Konami doesn't, I don't think), so this won't help you much.

[Lelygax]

Wow, you are a genius, I never expected to something like that be made in a so short time, I thought it would need a month or something like that. I mean the sprite assemble thing :O

Good luck polishing the code, since it seems to be complete.

[TheouAegis]

This last bit of code was a pain in the ass. It's most definitely far from fast code, but I wasn't trying to make it fast, I just wanted the damned thing to run from start to end.

So current iteration loads one file at a time, displaying the palette (required to load first), the OAM (required to load second), and the sprite (required to load last). Loading a new palette or toggling the byte order updates the image automatically. Furthermore, you can export the palette as a Microsoft Palette (*.pal) file compatible in most graphics programs (I think, at least it is in Photoshop and Paintshop Pro). And most importantly, the program outputs this, which is what I spent the entire weekend doing when I wasn't watching Garbage music videos or "Magic Knight Rayearth" episodes:



Go ahead and download it, then open it in a graphics program or hex editor. All the data was written entirely by my program.

The final stage of development will be batch loading. Since I've never worked with the file_find functions in Game Maker, it may take a while. I just hope it goes more smoothly than writing that damned bitmap image did.

Update: I forgot to include the file size in the bitmap data, so here's another bitmap sprite with the file size included as well as a reversed palette:

[Gunlord]

Hmm...Theo-sama, didn't someone rip the Front Mission DS sprites already? I coulda sworn I've seen em floating around somewhere...

[Lelygax]

Hey gunlord :p
I think he is doing this more because of the research and programming than doing this for getting sprites.

[TheouAegis]

Besides, did they rip ALL the sprites?

There are actually a buttload of sprites. I didn't realize when I was ripping the SNES sprites just how many sprites I was actually ripping because I was using save states, which sped things up considerably. With this program, I'd be able to compile the sprites for the parts setup, the battle animations, the shop pieces (which should just be the battle sprites, but I could have been mistaken about that when I ripped the SNES ones...) eventually the map data, the backgrounds and cinematics, and pretty much almost anything else. ... In one click.

[Gunlord]

Ah, ok. Sounds kewl then

[TheouAegis]

And yet in the time I've spent working on this program, I could have ripped two directories already. Oh well, it's almsot done now anyway, just gotta get this damn batch loading sorted out. It helped me find a couple bugs in the original code I hadn't considered testing. Considering the bugs I'm having now, I think I have the batch load/write part done, so now it's back to debugging.

[TheouAegis]

Insofar as preloading a palette file, I got batch conversion done, more or less. Once I remove the surface write from my default code (forgot I defaulted it), batch conversion of NCXR files  should be a matter of click-click-done. If I do say so myself, using ds_grid instead of surface rendering was a great idea; it yields 4bpp bitmaps at least 300% faster than surface rendering! I will have to share it as source due to lack of uniform naming conventions and file ordering. Case in point, Front Mission has 4 different conventions -- parts have guns and wanzers together, but both have their own palette, which is generically named for guns and header-named for wanders; battle icons have either generic or specific names; in both cases and similar cases, you also have the paint scheme palettes stored separately; then you have graphics like menu and icon  and maps with their own individual palettes for each graphic. I may include a palette cycle option for multipalette NCLR files, but for now I will just focus on getting it up for you guys to play around with it.

Out walking around right now, so it will still be a few more hours.

Update: Had some issues with code and then I tried adding subdirectory reading... That didn't go very smoothly. Now I have rudimentary subfolder reading and succeeded in compiling the entire PartsForSetup subdirectory in FMDS. It went very slowly, much to my dismay. Then for whatever reason Algem and Gloster loaded up the wrong palettes (why there were two palettes I can't say) so when I tried to recompile just those two (which required more recoding), the compiler took forever to make them. I think my compiler has issues with large sprite (like Gloster, Clinton, Gigas, etc.). I also came across another odd issue where I couldn't compile the Faces subdirectory; it just yielded garbage. The files are all normal files, so I don't know why they're being read differently.

[Lelygax]

I also came across another odd issue where I couldn't compile the Faces subdirectory; it just yielded garbage. The files are all normal files, so I don't know why they're being read differently.

Maybe these use different sizes for tiles compared to these robot parts?

[TheouAegis]

Yeah I"ll have to hold off on releasing a little longer. Although the more I dick around with this, the more bugs I create. It's really fun when you try to debug and then you realize your code is skipping an entire line that you thought was being run. I found one ore two more sets of graphics that didn't compile properly at all and the way they were "compiling" leads me to believe my coordinate system is out of whack. In both those cases, even the surface drawing method resulted in the same error... so it has to be in the data handling. The weird thing is I could just read the NCGR data and save all those but I want to know why the NCER files are making garbage.Then another couple sets of files were giving me out-of-range errors for some reason, so I have to look into those. This was all from the same game, still!

The compiler worked for all the PartsForSetup files and MOST of the Battle Parts graphics for FMDS. For some reason not all of those worked. So yeah, it has some issues I have to work out.

... It would be so much faster for me to just compile these all by hand, y'know? Actually no. Just those two file sets alone would have driven me insane. That's a lot of files.