so in short, as many people knows, at auritech.eu we are working (and mainly succeeding) on hacking the psx game Final Fantasy Tactics. so far everything is going smoothly, but we are having problems with sprite editing. the .spr files seem to have a part that is just uncompressed picture, and a "lower" part that is somehow compressed..... and that is what we are having problem at understanding. can someone help, or point us to the right direction? we have no clue about psx file compression, and those compressed parts are important for having a perfectly working sprite. also, do any tool for editing those files exist? I'm GRATEFUL for ANY kind of help you people can provide! karsten
actually we already discovered it's not so we are well aware of that page, but we have eceeded it, also he has a new url. by the way from my (poor) understanding, all the pics are non compressed up to the garbage mess. the garbage mess is supposed to be a compressed attack animation
If I knew more about PSX dev, I could try cracking the compression format (I've cracked a few before, but for Megadrive games). As I don't have a PSX dev kit or debugger, is there an emulator out there that provides good debugging functions?
it would be better to share one file or try Tile Molester tool at first ( I dont know what did you tried already )
Probably nothing, but it might be in MJPEG format (ie, the same format used for PSX movies and hardware-decrypted by the MDEC chip). I've never played FFT so I wouldn't know how this animation looks so I can't really tell for sure. Have you tried running the game in an emulator and monitoring VRAM? Perhaps you can isolate the routine by setting breakpoints. Send me a PM if you need help.
i'm completely clueless about special emus and VRAM i guess you guys should have a chat with the main hacker, zodiac... would you guys register at auritech.eu to help? by the way i've uploaded a .spr file here www.auritech.eu/H61.SPR we have a tool that allows to see the sprite and palette, but the tools builder didn't figure out the last part of compressed data that form what zodiac said is "from hex 0x9200 to the end of file"
The sprites have a 4bit color dept, so I suppose MJPEG would be out of the question. As monitoring VRAM, I wouldn't even know where to start. When the event is loaded, every used sprites are loaded in memory, then it will call for some routine and store the sprite in another format. After that only routine, the loaded sprite file becomes completely useless. I don't know what are the instructions used to load bytes in another file either. I hate debugging though, my comp sucks so much; it's awfully slow.
Ah yeah, the MDEC thing was just a guess, to be honest. My Caetla setup is currently non-operational (heck, I dont even have a copy of the game), and my current PC isn't really up to spec either. However, if you want, I can provide help with disassembling the routine if you could isolate it for me.
I've checked the data and it appears to be like common output Question - what is the deep reason to find any more details ?
otherwise the sprites won't show the attack animation. all the animation is uncompressed (magic, kneeling, singing, etc) except for what concern the attacks, and we need that to be able to completely hack the game. also the info you quoted are inaccurate, it was just a guess made years ago.
ah, I see the point - it looks that no deep debugging researches/tools being made and that is where the help is needed. Hope you will find someone.
it has been figured out! http://www.romhacking.net/forum/index.php/topic,5553.0.html now we just need a windows tool to change bmps to spr files!
but still no tool, even tought we have the code for decompressing/compressing the files... i hope that soo it'll be released!