Hacking Corpse Party Sprite Replacement with new 3DS Sprites Project. Help using Corpse_Party_Tools.exe?

[dfsa3fdvc1]

Hey, so I found this old thread with this awesome utility called Corpse Party Tools

So basically, what I want to do is replace the lackluster blurry PSP sprites with the new 3DS sprites which are crisper, more detailed, and more accurate to character portraits, ect...

Looking at the PSP sprites and 3DS sprites side by side (attached samples) the sprites are of the same dimensions sotheoreitcally importing the 3DS sprites into the PSP should be easy.

Unfortunately I'm having a bit of trouble using Corpse Party Tools to import sprites. Right now I'm unable to even rebuild the image.bin without the game crashing. I've attached an image of my complete workflow which utilizes UMDGEN and Corpse Party Tools to see if someone could figure out how to get this working so I can hopefully get this project going. Thank you.

Here's what the 3DS sprites look like compared to the PSP ones. So much better IMO.

3DS

PSP

 

[JamRules]

Not sure if it's important but the .gim files aren't the same size, the bit rate is probably different.
Have you tried using the tool to build a copy of the .bin file using the original contents just to check that it actually works?

Also, not the cause of the issue in this case since the tool can't unpack the .bin hinting that's the problem,
but when using UMDGen I would export the filelist from the option under File and then re-import it so that the LBAs stay the same

 

[dfsa3fdvc1]

Not sure if it's important but the .gim files aren't the same size, the bit rate is probably different.
Have you tried using the tool to build a copy of the .bin file using the original contents just to check that it actually works?

Also, not the cause of the issue in this case since the tool can't unpack the .bin hinting that's the problem,
but when using UMDGen I would export the filelist from the option under File and then re-import it so that the LBAs stay the same

Thanks for the tip on UMDGen filelist. That probably would have also become a roadblock for me.
I really think the GIM Conversion is the issue here. Attached screen of the original and converted Gim and they're basically polar oppossites lol.
I really want to believe that the unpacking/rebuilding of the image.bin works and that it's just the Gim conversion that's the issue.

I guess I'll look into GIM conversion. I do want to mention that I've never done any PSP game modding before so any help is welcome, lol.

Also, link for anyone interested: Here's the Google Code page with the source for Corpse Party Toolset

 

[JamRules]

There's a leaked psp sdk which you should be able to google for which has different tools, including ones to view and convert .gim files (gimconv/gimview)

http://www.psdevwiki.com/ps3/GimConv

 

[dfsa3fdvc1]

There's a leaked psp sdk which you should be able to google for

Thanks, I'll play around with that a bit.
The GIMs in Corpse Party were created with version Gimconv 1.42 and the latest leaked version I could find was 1.20h. I'm gonna hope it works.

 

[dfsa3fdvc1]

Pasting GimConv's descriptionof of "sprite 04_Ayumi.GIM"

So considering that big long description, what do I tell GimConv when converting? I'm gonna guess either -bpp4 because it says "FORMAT INDEX4".
But when I try to convert even the simplest of images using "Gimconv file.png -bpp4" I get this error...
>WARNING : index-color conversion not supported.

Anyone know what I should do?

.GIS 1.00

Picture "picture-0" {
Image "image-0" {
Format INDEX4
Order PSPIMAGE
Width 144
Height 96
PitchAlign 16
HeightAlign 8
PlaneMask 0x00000000
LevelType MIPMAP
LevelCount 1
FrameType SEQUENCE
FrameCount 1
Pixels "pixels-0" INDEX4 PSPIMAGE 144 96 16 8 {###IMAGEDATA###}

Palette "palette-0" {
Format RGBA8888
Order NORMAL
Width 256
Height 1
PitchAlign 16
HeightAlign 1
PlaneMask 0x00000000
LevelType MIPMAP2
LevelCount 1
FrameType SEQUENCE
FrameCount 1
Pixels "pixels-0" RGBA8888 NORMAL 256 1 16 1 {###PALLETTEDATA###}

FileInfo "file_info-0" {
ProjectName "04_ayumi.png"
UserName "T_Kamae"
SavedDate "Thu Oct 13 10:29:02 2011"
Originator "GimConv 1.20h"
}

Whoops, accidently posted this before I was done. If you're reading this check back in a few. EDIT: DONE

 

[JamRules]

To be honest I normally just use the input and output filenames args so I don't know much about the other options

I would have guessed from those stats the image is 8bit, indexed with 256 colours.

As a pure guess you might have to convert the png to 32bit and then convert without any extra params, then hopefully they will match the original in size

Uses 32bit pngs and the corspe party tool might work too

 

[dfsa3fdvc1]

I would have guessed from those stats the image is 8bit, indexed with 256 colours.

Yeah, looks like -bpp8 works. Finally able to export a gim from the game to PNG and then convert that PNG into .GIM -bpp8 and have that new gim be the exact same length as the original. There's a few differences in the Image data but GIMVIEWER is still able to open it.
That's a thing I realized about Corpse Party Tools, the GIMs generated seem to never be valid so I won't be using that from now on.

On what you said about confirming that the BIN is able to be rebuilt, I've been completely unable to do so without cause the error from my first post.
Even "replacing" a file with the same exact file will cause the same error where it will seem to successfully make an image.bin but even Corpse Party Tools itself will be unable to unpack this new image.bin

Apparently the tool does work which makes all of this all the more frustrating.
I've read through that thread a dozen times and I think I'm doing everything right but IDK.

 

[JamRules]

Does the mod folder need to contain a copy of every file?
You were just placing the modded files right, maybe it needs a full set?

Or maybe it only works for the script files for some reason

 

[dfsa3fdvc1]

Does the mod folder need to contain a copy of every file?
You were just placing the modded files right, maybe it needs a full set?

Right, just a single file.
If you try to put every extracted file in /mod/ it'll generate an image.bin that is twice the size of the game and causes the same error.

 

[JamRules]

That doesn't sound right,
not sure what else to suggest unless you can get hold of the creator or someone else who's had some success

 

[Lycan911]

Any news?

 

[AttackOtter]

A couple months late, but I actually attempted this same thing back in August. I was able to repack the game assets without it crashing, but I wasn't able to replace the graphics, and even when the GIM files were replaced, it still showed the original sprites in-game, oddly enough.

In fact, after unpacking the repacked Image.bin file, the GIM files themselves are corrupted and crash my GIM file viewer, but the ISO continues to play perfectly fine, just using the original sprites. It makes me think that the MAP/CHAP#/CHARA folders might not actually be where the game reads the sprites from, either that or it reads them from one of the other chapters if it's unable to load the file from the base chapter.

 

[dfsa3fdvc1]

A couple months late....

You should try performing a replacement of the logos that are shown when you first start the game. You may be right in that it's not calling the graphics you replaced but some other graphics. Replacing a logo would be a sure way to test whether it's working.

 

[AttackOtter]

The Logos would be a different story though, because there's only one copy of each in the archive itself. They should be much easier to replace.

 

[dfsa3fdvc1]

The Logos would be a different story though, because there's only one copy of each in the archive itself. They should be much easier to replace.

Right but it would at least prove that the tools works properly which I'd say is still unknown.

 

[AttackOtter]

Question, did you make sure to delete the image.bin file from the ISO before importing the new one? Because that's what was causing crashes for me when I first started out.

 

[dfsa3fdvc1]

Question, did you make sure to delete the image.bin file from the ISO before importing the new one? Because that's what was causing crashes for me when I first started out.

Its been so long I can't recall. IIRC it didn't crash immediately though. Just when it hit the image I replaced.