Castlevania Dungeon Forums

The Castlevania Dungeon Forums => Fan Stuff => Topic started by: Lelygax on August 06, 2013, 10:56:59 PM

Title: DS Sprite-ripping simple question
Post by: Lelygax on August 06, 2013, 10:56:59 PM
Which method is better/right?

This "Nintendo DS (in GBA Mode)"
(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FjsfVEuW.png&hash=4fb7d6546dfecf0273d4b0f2ccdc004c8c2648d4)

or this "VGA (poppy bright)"?
(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FNj5rl9f.png&hash=d8adac3487e05385de717057ac4aba1e7a978eb9)

At least to me, VGA looks better (also I've seen in almost any place with sprite rips that they are using this brighter and more vividly pallete), but maybe I can be wrong. I plan to rip some things now, but since I want to share, I want to do this right.
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 07, 2013, 05:58:13 PM
Help? Someone? No one knows a answer? It can be only a opinion.
Title: Re: DS Sprite-ripping simple question
Post by: Jorge D. Fuentes on August 07, 2013, 06:16:03 PM
Poppy Bright is always better than washed-out gray, IMO.
But I'm no expert on these things.
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 07, 2013, 08:29:17 PM
Poppy Bright is always better than washed-out gray, IMO.
But I'm no expert on these things.

Thanks and you are kidding? You are a expert at least to me, I heard about you since my first day on the internet without even knowing english, also you do a lot of good sprite sheets from scratch.

More opinions are welcome even so. :)
Title: Re: DS Sprite-ripping simple question
Post by: Jop on August 08, 2013, 03:14:51 AM
I prefer poppy bright too, the sprites looks better
Title: Re: DS Sprite-ripping simple question
Post by: Koutei on August 08, 2013, 07:01:06 AM
I am vote to VGA. This matches official screen shot.

http://www.konami.jp/gs/game/dracula_ds2/system/index.html (http://www.konami.jp/gs/game/dracula_ds2/system/index.html)
Title: Re: DS Sprite-ripping simple question
Post by: KaZudra on August 08, 2013, 09:07:09 AM
VGA, Harmony of Despair uses the exact same color palette
Title: Re: DS Sprite-ripping simple question
Post by: darkmanx_429 on August 08, 2013, 10:17:07 AM
I vote VGA as well.
Title: Re: DS Sprite-ripping simple question
Post by: VladCT on August 08, 2013, 10:44:56 AM
I can see VGA being the unanimous decision.
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 08, 2013, 12:02:03 PM
Thanks guys, thats really helpful (Koutei aven sent official material to show thats the best option lol). I've started ripping some whips from PoR since I cant find them in no place. Talking about that, I need to share my PoR and OoE saves with you guys after, since when I needed it for sprite-ripping no one had one handy copy to share, this can help someone else in the future (I've all items, less the birthday cake in PoR). Now I only need a Dawn of Sorrow save, but I can complete this game again xD

edit: ripped all whips and its effects from PoR, since Spriter-Resource doesnt have any of them, to say the truth almost all are only recolors, and some have a tip in he end of the whip, but let me know if someone is interested in them. Here is a example:

(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FgYKjP7t.png&hash=6d864361efe9a1b8b27fec5f65c6952969eb6106)

(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FwkF8fD9.png&hash=b36949f8e49e927c392194af07c5220db2a13911)

All the others are variations from these 2, I can post them if needed. Nebula whip (I noticed its inspired from Saint Seiya's Shun's Andromeda chain, even the critical art is the same) is done via code and use the same chain parts from any other chain whip.
Title: Re: DS Sprite-ripping simple question
Post by: Jorge D. Fuentes on August 12, 2013, 11:57:48 PM
Put 'em in Sprite Showcase Thread. >.>
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 13, 2013, 12:19:10 AM
'kay :)
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 13, 2013, 05:09:46 AM
If you don't have it yet, download Crystal Tile 2. It's a GBA/DS decompiler. Couple it with Batch LZ77 (I'm looking for a decompiler for Japanese games still or something, Crystal Tile won't open some of my games). Then open the files in GGD.

Right now I'm working on Front Mission DS graphics.

If anyone wants the Front Mission DS instruments, let me know. (You can't rip the songs, just the instruments. The songs are sequenced.)
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 13, 2013, 12:13:43 PM
They are easy to do things? Im ripping with NO$GBA using "Esco method", where you simply need to resize a window and printscreen things. I've tried Tile GGD but its a pain to find palletes and things, remember that I dont know anything about hacking, hex or values, only the most basic things.

If that helps I've changed one sprite from Pokemon Gold for a friend following a newbie tutorial days ago, my first and only hack. So Im a newbie but not a dead horse I think :P
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 13, 2013, 09:59:01 PM
I'm actually learning how some of the things were made. The DS has some nifty features I guess Nintendo provided for developers. Crystal Tile will let you view the sprite layout data (I'm working on understanding that right now... then I'll go back to coding my Castlevania engine), as well as palettes and apparently animation data too... though not too sure about that one. And for the music it has the sequences stored. It reads the data and apparently in the DS games (or many of them), there are certain 4-byte codes which tell the DS where certain file data starts and ends. Inside that file data, among other things: palette indexing. Althoguh, even without the indexing, I could still figure it out through tria and error.

In Front Mission DS, the wanzer parts use a  palette using little endian 4bpp RGB 15bit palettes. The weapons use little endian 4bpp BGR 15bit palettes. I'm trying to write up a code (in Game Maker for now) that will take a BMP of the tile data you rip from GGD and arrange the tiles based on the sprite layout data. As I said, though, I'm still trying to understand how that data's written. When the description is SSDPPMMMXXXXXXX, it's kinda tricky.

I haven't tested Crystal Tile with any other consoles like GBA. Right now I'm just playing with FMDS.
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 13, 2013, 10:06:27 PM
You're creating this system with game maker to rip things faster or it just a test project? I'll try it in CV games soon then, thanks, now Im trying to rip SOTN from Saturn (without sucess), maybe I'll need to rip them in the old fashioned way, using a emulator that removes layers and pressing printscreen :(

I only want these exclusive enemies and areas, even if no one likes them.
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 14, 2013, 11:38:31 PM
Well from my experience, sprites aren't too hard to rip using GGD. It's the bigger graphics that I always had issue with.

Also, try using instead of Tiled GGD, use the original GGD. The UI is much more basic and most of it is in Japanese, but I find it a little easier to work with. That could just be me, though. I'm using GGD for Front Mission DS instead of Tiled GGD.
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 14, 2013, 11:52:31 PM
I've searched for the classic GGD but I couldnt find it, you have a link? :-/
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 15, 2013, 01:06:50 AM
No. I'm surprised I even have it.

And the GM program's just to help me compile the images, but it's not going very well. In order to write the program, I need to know how to combine this:


52 45 43 4e ff fe 00 01 7b 00 00 00 10 00 03 00
4b 42 45 43 48 00 00 00 01 00 01 00 18 00 00 00
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 00 14 08 00 00 00 00 2f 00 3f 00 00 00 00 00
30 80 28 00 00 00 08 80 28 40 01 00 08 80 00 40
02 00 00 80 08 c0 03 00 4c 42 41 4c 17 00 00 00
00 00 00 00 43 65 6c 6c 41 6e 69 6d 65 30 00 54
58 45 55 0c 00 00 00 00


with this:

(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fimg407.imageshack.us%2Fimg407%2F1866%2Fgkfb.png&hash=a50b7be788720124129ebb1043472ae946617e65)

To yield this:

(https://si0.twimg.com/profile_images/2420388951/wp01type90.JPG)

(Well, just the body part, not the arms and legs. Those are in separate files.)
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 15, 2013, 01:55:39 AM
You can PM GGD to me or them share it here in this topic?
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 17, 2013, 11:12:56 PM
http://randomhoohaas.flyingomelette.com/ai/spriterip/GGD-e.zip (http://randomhoohaas.flyingomelette.com/ai/spriterip/GGD-e.zip)

Download it when you can. It's rare. I have the Japanese version. This is the version translated into English by Dazz, the host of Spriters-Resource.
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 17, 2013, 11:50:29 PM
Thanks, I've found it in spritedatabase or something like that and shared a link too, I think its on saturn sprites thread. :)
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 18, 2013, 03:35:36 AM
It ain't much different from TiledGGD, but I don't think more is always better. GGD is simple and that's all I want. Once you learn how to read NCLR and NCGR files using CrystalTile, you can view the files in GGD pretty easily. For example, byte $1C in the NCGR file should tell you if it's 4bpp (03) or 8bpp (04). Byte $04 tells you if it's Big or Little Endian (FFFE is little endian and I think FEFF is big endian). Also, annoyingly and I'm working on a program to fix this, GGD and YY-CHR (yes, YY-CHR works with DS sprites too with some tweaking) read the spec data as sprite data. I think GGD or TiledGGD had an option to ignore all that. Or maybe I was in Tile Molester. One of the programs had an option to calculate where spec data (I guess I should call it the header) would be ignored. Not ignoring the header makes NCGR files hard to work with in YY-CHR. Might cause some nuisances in GGD.

NCLR files (palettes) are similar. Byte $04 is the endianness. Byte $18 should be the palette depth 4bpp (03) or 8bpp (04). Byte $20 should be the size of the palette. Byte $30 should be the start of the palette, but that could change from file to file.
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 18, 2013, 04:21:34 PM
Thanks for these lessons, if when I try something with DS again I somehow understand all that you explained it can help me finding their bpp and endian types, thanks.
Title: Re: DS Sprite-ripping simple question
Post by: KaZudra on August 18, 2013, 05:18:47 PM
when you or anyone gets to ripping OoE tiles and maps thou would be so awesome...
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 18, 2013, 07:07:30 PM
I'll use this thread for posting my stuff as I get around to finishing it.

http://www.mediafire.com/download/24sig1sddkqa486/nclr2pal.exe (http://www.mediafire.com/download/24sig1sddkqa486/nclr2pal.exe)

The first file share should convert up to four 4bpp NCLR (palette) files into .PAL files which would be compatible with YY-Chr and other programs. The code is definitely in its alpha stage, as I haven't tested on anything other than a couple Front Mission DS NCLR files. So if you find any games that this doesn't work right for, please let me know the game and NCLR file(s) you were trying to convert.

To view an NCGR (graphic) file in YY-Chr, you may need to extract it (they are often compressed), then YY-Chr will be able to view it using the GBA 4BPP setting. As I said earlier, there is some junk data that prevents you from viewing the NCGR files correctly in YY-Chr. I'm working on another alpha-level program to compensate for this, as I much prefer YY-Chr over GGD (and GGD over TiledGGd).
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 18, 2013, 09:09:06 PM
Wow, you did it with Game Maker, I will check that and comment about it after using, thanks :P
I plan to rip SOTN (PSX) holy water now, since I can rip Saturn things later (I've ripped somethings already, like Maria shots, owl, dragon, heal and fire. I cant do this thing that summon all for animals in a keyboard for now, since this emulator is giving some delay.)

I heard you about OoE BGs, Kaz. Which one you need?

edit: LOL, forget about Maria invicibility, it only changes her pallete to yellow and green, since I was ripping her effects and not Maria itself, Im almost done with her (I will rip these balls that protect her in her boss fight agains Alucard).
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 20, 2013, 02:31:05 AM
CrystalTile won't let me open most games. I don't know why. So it's manually dumping every file for now, I guess.

Order Of Ecclesia file findings:

I haven't found the palettes yet. So far, I have sound data (obvious) and various sprites. In the data subfolder under sc and sc2 is sprite data. Sprites are simple, so 4bpp and 8bpp both work. It should be 4bpp, but I had issues seeing some sprites at 4bpp whereas at 8bpp I could make them out.

SC
Door
Map
Sky
Barrel
Damned Floating Spikes
Enemies and Parts
Icons
Explosions
Bosses
Walls
Candles
Chest
Pretty much anything not in SC2


SC2
Albus
Area Titles
Castlevania
Dracula
Ending Graphics
Cat and Chiropteran forms
Prologue (16bit)
Spells and Effects
Smoky Effects (look cool in greyscale!)
Shanoa
Other..... stuff? (Holy Water, Giant Roast, Grand Cross, male puppet?)
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 20, 2013, 02:40:43 AM
Nice find :D

Other..... stuff? (Holy Water, Giant Roast, Grand Cross, male puppet?)

Why...? No one uses them, maybe they planned more modes or used PoR as a base?
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 26, 2013, 12:48:24 AM
Ok, I've failed miserable at using these high-tech programs, this makes me dumb right? :p

I've tried to acess some OoE things and find the Richter's and Alucard's holywater gfx in SOTN without sucess (I've used PSX-VRAM for SOTN ripping, I can see all tiles in the area from the savestate though, but with incorrect palletes or black and white only).

It seems that I will need to continue ripping DS sprites using No$GBA Debugger unless someone have a good tutorial and a little of patience. I've already extracted all internal files from the OoE ROM, so it will be easier to work with them.

Hey Theou, this article can be interesting for you and everyone that is interested in these sort of things
http://badderhacksnet.ipage.com/badderhacks/index.php?option=com_agora&task=topic&id=1037&Itemid=3 (http://badderhacksnet.ipage.com/badderhacks/index.php?option=com_agora&task=topic&id=1037&Itemid=3)
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 26, 2013, 10:01:50 PM
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.).
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 28, 2013, 01:30:18 AM
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.
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on August 31, 2013, 02:09:52 AM
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.

(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fimg5.imageshack.us%2Fimg5%2F9900%2Fuv16.png&hash=176e49cb0da8f68ccfddcc90c82152484971004d)
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on August 31, 2013, 02:17:53 AM
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.
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on September 02, 2013, 01:32:03 AM
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:

(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fimg547.imageshack.us%2Fimg547%2F5586%2Fheoq.png&hash=aad84d149b3ae435de9a73f686e651bff4901bc5)

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:

(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fimageshack.us%2Fa%2Fimg31%2F7949%2F2bh.bmp&hash=661743db8614fbb73519cb99f043fa70dfd86dfa)
Title: Re: DS Sprite-ripping simple question
Post by: Gunlord on September 02, 2013, 05:39:34 PM
Hmm...Theo-sama, didn't someone rip the Front Mission DS sprites already? I coulda sworn I've seen em floating around somewhere...
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on September 02, 2013, 06:46:59 PM
Hey gunlord :p
I think he is doing this more because of the research and programming than doing this for getting sprites.
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on September 02, 2013, 08:38:21 PM
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.
Title: Re: DS Sprite-ripping simple question
Post by: Gunlord on September 03, 2013, 04:38:54 PM
Ah, ok. Sounds kewl then 8)
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on September 03, 2013, 10:04:07 PM
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.
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on September 14, 2013, 07:33:17 PM
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.
Title: Re: DS Sprite-ripping simple question
Post by: Lelygax on September 16, 2013, 03:36:29 PM
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?
Title: Re: DS Sprite-ripping simple question
Post by: TheouAegis on September 16, 2013, 04:50:29 PM
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.