[slidelljohn]

I have a new update:
https://www.mediafire.com/file/93cg9kcifv4kiwk/SNES_Paint2.zip/file

I still need to do a few more tests before I add in the compression. Might take
a few more days. Install QT if you want to learn some coding. I'm currently using
QT 5.6.3 with mingw but there are newer versions.

[Shauing]

I have a new update:
https://www.mediafire.com/file/93cg9kcifv4kiwk/SNES_Paint2.zip/file
I still need to do a few more tests before I add in the compression. Might take a few more days.

Amazing. Practically every character sprite can be viewed (even the sprites that went unused or were censored), albeit all of them using the Prince palette as it is the only one that I assume has been imported here. Missing here are the platform/traps/doors/switches tiles and their masks. They do have a slightly different size though (48x64 pixels).
Take the time you need to finish it, I'll (try to) wait patiently.

Install QT if you want to learn some coding. I'm currently using QT 5.6.3 with mingw but there are newer versions.

I'll try to get the version you are currently using of QT.

[slidelljohn]

The palettes start at the princes I just need to set the pointer at the beginning. Gfx that have 0x0000 as thier 1st 2 bytes in the 3 byte header and the gfx # around 1200-1400 started to display messed up gfx. Are the platforms and traps gfx in the 1200-1400 range of the pointers?

I’m not 100% sure if this is the QT that I have but I think it is.
http://download.qt.io/archive/qt/5.6/5.6.3/qt-opensource-windows-x86-mingw492-5.6.3.exe

[Shauing]

The palettes start at the princes I just need to set the pointer at the beginning. Gfx that have 0x0000 as thier 1st 2 bytes in the 3 byte header and the gfx # around 1200-1400 started to display messed up gfx. Are the platforms and traps gfx in the 1200-1400 range of the pointers?

Yes, from 1249 to 1484. 1249 to 1394 are the platforms/traps gfx, 1395 to 1484 are the masks to them. They're all 48x64. Here's some small info about them:
https://www.princed.org/wiki/SNES_format#Background_sprites_and_masks

Here's more info on the palettes (you probably read them already, but just in case):
https://www.princed.org/wiki/SNES_format#Palettes

I’m not 100% sure if this is the QT that I have but I think it is.
http://download.qt.io/archive/qt/5.6/5.6.3/qt-opensource-windows-x86-mingw492-5.6.3.exe

Downloading it. I'll wait for your guiding.

[slidelljohn]

Can you get me a savestate for when those graphics appear in game? Ether giegers snes or bsnes plus savestate would do. I never played the game before so I don’t know where to find the gfx when playing it. I need to make sure there isn’t another compression algorithm that is used for the gfx.

With QT I recommend following some of the tutorials on YouTube to help get you familiar with how the program works and when I get some free time I can show you how to write some code for editing snes games.

[Shauing]

Can you get me a savestate for when those graphics appear in game? Ether giegers snes or bsnes plus savestate would do. I never played the game before so I don’t know where to find the gfx when playing it. I need to make sure there isn’t another compression algorithm that is used for the gfx.

Here you go, the zip file contains the savestate of the second room of the game, plus all the graphics from 1249 to 1484 from the extracted graphics folder I have (it has an extra one - labeled 1303_j - as this one was censored for the american release but was included on the folder just for completeness sake):
https://www.dropbox.com/s/fw6lbyk84v6nzwp/1249-1484.zip?dl=1

If you need more savestates, let me know.

With QT I recommend following some of the tutorials on YouTube to help get you familiar with how the program works and when I get some free time I can show you how to write some code for editing snes games.

All right, I'll watch them during the following days/weeks.

[slidelljohn]

I think I have the sprite compression algorithm working correctly.
http://www.mediafire.com/file/vlnd83qmnh6fj77/SNES_Paint_compress.rar/file

This algorithm should produce the same exact bytes as the original compressor that Konami used.

You can edit and save the compressed sprite data only to a file called compressed_gfx_bytes.bin.
You cant save it to the rom yet in the editor but you can test out the compression by using a hex
editor to store the compressed data to the rom. If you load the 1st sprite the F8000 next to the
decompress push button is the location of the pointer for the compressed graphics that were loaded
from the rom. The next hex number to the right of that is the location of the compressed graphics
that were loaded from the rom. The save as button is the button that will compress the graphics in
the canvas to the file called compressed_gfx_bytes.bin. When you compress these graphics they use
the same 3 byte header as the graphics that were loaded from the rom. byte 1, byte 2 and byte 3 is
the bytes for the header. byte 3 = size 1 and size 2. size 1 and size 2 is multiplied together to
get the number of 16 x 16 tiles to decompress. Let me know if any of these don't compress correctly.
Its going to take more time before the bg tiles and the palettes are ready but sooner or later these
will be editable as well.

[Shauing]

I think I have the sprite compression algorithm working correctly.
http://www.mediafire.com/file/vlnd83qmnh6fj77/SNES_Paint_compress.rar/file

This algorithm should produce the same exact bytes as the original compressor that Konami used.

You can edit and save the compressed sprite data only to a file called compressed_gfx_bytes.bin.
You cant save it to the rom yet in the editor but you can test out the compression by using a hex
editor to store the compressed data to the rom. If you load the 1st sprite the F8000 next to the
decompress push button is the location of the pointer for the compressed graphics that were loaded
from the rom. The next hex number to the right of that is the location of the compressed graphics
that were loaded from the rom. The save as button is the button that will compress the graphics in
the canvas to the file called compressed_gfx_bytes.bin. When you compress these graphics they use
the same 3 byte header as the graphics that were loaded from the rom. byte 1, byte 2 and byte 3 is
the bytes for the header. byte 3 = size 1 and size 2. size 1 and size 2 is multiplied together to
get the number of 16 x 16 tiles to decompress. Let me know if any of these don't compress correctly.
Its going to take more time before the bg tiles and the palettes are ready but sooner or later these
will be editable as well.

I have just tested the editor with the first frame only, modifying two colors of the pants to look white, saving it to the .bin file, open it on the hex editor and copy all the bytes to my rom. I tested the rom, and sure enough, the frame does appear in-game, in both directions, almost working perfectly. I say almost, because if I do a standing forward jump, when the Prince gets to the other tile, the game crashes. Any other instance I tried so far, doesn't crash the game.

I went to compare the bytes between my rom and the compressed_gfx_bytes.bin and there are a few differences. I did this comparison without doing any modification to the palette and saving the .bin file without saving gfx.

My Rom:
0A 29 31 0F 00 50 AC 80 34 1A 20 68 40 18 20 50 68 20 70 78 0F 40 C0 80 80 80 F8 FC FE 7F 3F 1F 06 07 00 20 28 62 98 D5 51 5C 2A 00 38 1C 3C 6A 6E EE E5 D7 01 3C 72 F4 E1 E1 FA F8 8F 00 9C 0A 52 52 04 68 36 37 00 63 0F 5B 5A 16 1C 30 30 20 F8 70 24 24 08 40 40 01 78 70 71 61 63 0F 0F FF 1F 80 8B 00 6B 13 13 13 13 1D 27 4B 00 64 4C 4C 4C 4C 42 40 24 00 1F 7F 7F 7F 7F 7F 7F 7F FF 00 80 FF 40 4B 29 12 04 02 01 03 50 24 06 05 02 01 03 3F 01 03 E0 7F 3F 1F 0F 07 60 80 80 80 80 80 40 FF 1F 80 FF 7F C0 FF F0 C0 77 FC 22 15 FC 27 1F FC 27 1F FC A0 20 FF FC C0 FF FC E0 13 19 22 FF 00 50 AC 88 34

the .bin file:
0A 29 31 0F 00 50 AC 80 34 1A 20 68 40 18 20 50 68 20 70 78 0F 40 C0 80 80 80 F8 FC FE 7F 3F 1F 06 07 00 20 28 62 98 D5 51 5C 2A 00 38 1C 3C 6A 6E EE E5 D7 01 3C 72 F4 E1 E1 FA F8 8F 00 9C 0A 52 52 04 68 36 37 00 63 0F 5B 5A 16 1C 30 30 20 F8 70 24 24 08 40 40 01 78 70 71 61 63 0F 0F 1F 80 80 80 8B 00 6B 13 13 13 13 1D 27 4B 00 64 4C 4C 4C 4C 42 40 24 00 1F 7F 7F 7F 7F 7F 7F 7F 00 80 80 80 80 80 80 80 80 FF 40 4B 29 12 04 02 01 03 50 24 06 05 02 01 03 3F 01 03 E0 7F 3F 1F 0F 07 60 80 80 80 80 80 40 1F 80 80 80 7F C0 F0 C0 C0 C0 C0 77 FC 22 15 FC 27 1F FC 27 1F FC A0 20 FC C0 C0 FC E0 E0

[slidelljohn]

I'm not really sure why it was doing that because that was the last thing that
I had to fix for it to work correctly. It wasn't even working on my end anymore.
I think I was able to fix it so try this one out and let me know.
http://www.mediafire.com/file/jasifm4w8214202/New_SNES_Paint.zip/file

A new file called window2 gets created but that is just the image in the viewer
converted to snes 4bpp data. That file is just to make sure the conversion to
snes 4bpp is correct.

Here is another one to test. I did as many tests as I could. Hopefully its 100% working now.
http://www.mediafire.com/file/nnag9hk3tboeiqi/SNES_Paint_test_%25231.zip/file

[Shauing]

I'm not really sure why it was doing that because that was the last thing that
I had to fix for it to work correctly. It wasn't even working on my end anymore.
I think I was able to fix it so try this one out and let me know.
http://www.mediafire.com/file/jasifm4w8214202/New_SNES_Paint.zip/file

A new file called window2 gets created but that is just the image in the viewer
converted to snes 4bpp data. That file is just to make sure the conversion to
snes 4bpp is correct.

Here is another one to test. I did as many tests as I could. Hopefully its 100% working now.
http://www.mediafire.com/file/nnag9hk3tboeiqi/SNES_Paint_test_%25231.zip/file

On the original rom, I have modified sprite 0, and sprite 14 (standing pose) of the Prince. No problems so far, though instead of sprite 0 being modified, sprite 15 got modified. I tried again and again, but it kept modifying sprite 15.
EDIT: There were two offsets with similar bytes (at least the first 30 or so), and the one I was actually modifying was sprite 15. Now I applied it to the other offset, and now it does modify sprite 0 but the same graphical issue/freeze for a few frame I mentioned to you appears.
I tried to modify sprite 473 (Princess standing frame with arms up at 90 degrees), but it looks glitched (otherwise game continues):

I'll keep testing a little bit later today, have some stuff to do first.

[slidelljohn]

Everything that I'm able to edit seems like its working correctly.
Sprite #0 and sprite #14 every edit shows perfect in game. After
you make your edit try to load those edited graphics in the editor
and see if it shows that they were edited correctly instead of doing
the in game test. If the edited graphics don't show up some what correctly
then you may be putting the wrong offset for the pointer. If it does show
up correctly in the editor and messed up in game then the sprites could
be doing something like what the backgrounds are doing. I tried using the
save states that you sent me but I couldn't get them to load.

Here is a image showing sprite #473 edited and loaded as sprite #14 in the editor
and bsnes plus. The hex editor in blue shows the location of the new graphics and
the green box shows the new pointer to load the compressed graphics. Its a large
image so the image is a download.
http://www.mediafire.com/view/ke9r2nsnwehli9d/persia.png

[Shauing]

Everything that I'm able to edit seems like its working correctly.
Sprite #0 and sprite #14 every edit shows perfect in game. After
you make your edit try to load those edited graphics in the editor
and see if it shows that they were edited correctly instead of doing
the in game test. If the edited graphics don't show up some what correctly
then you may be putting the wrong offset for the pointer. If it does show
up correctly in the editor and messed up in game then the sprites could
be doing something like what the backgrounds are doing. I tried using the
save states that you send me but I couldn't get them to load.

So, I do the edits, go to ''save as'' (question: do I have to go to ''save gfx'' before, after or I shouldn't click on it?), copy the bytes to the rom via hex-editor, and re-load the rom in the editor to see if they look correctly there?
Do you have a link for the version of bsnes you are using? Maybe the save states I sent you were incompatible, or the rom you have is different from mine.

EDIT: Did the edits, copied to the rom the bytes from the .bin file, re-opened it on the editor, and the changes I did remained. However, when going to ''Rom loaded'' number 27, the editor crashes.

[slidelljohn]

Don't press save gfx that just saves the graphics not compressed to a file. Press save as to
compress the graphics. I could possibly be using a different rom version but idk. Im using
bsnes plus v04.

I looked at it and the editor seems like its working correctly. The reason
why #27 is causing the error for you is because you are probably not
putting the new compressed data in empty space and you are writing over
#27 compressed data. You cant put the compressed data in the same spot
as the original data unless the new compressed data is smaller than
the original data. The graphics pointer to graphics #0 is $1B:CB2C
and for #27 is $1B:CBE9. This image shows the graphics #0 highlighted
and #27 is the next graphics after #00.
http://www.mediafire.com/view/h5jc1ud8k3b41uj/persia2.png

[Shauing]

Don't press save gfx that just saves the graphics not compressed to a file. Press save as to
compress the graphics. I could possibly be using a different rom version but idk. Im using
bsnes plus v04.

I looked at it and the editor seems like its working correctly. The reason
why #27 is causing the error for you is because you are probably not
putting the new compressed data in empty space and you are writing over
#27 compressed data. You cant put the compressed data in the same spot
as the original data unless the new compressed data is smaller than
the original data. The graphics pointer to graphics #0 is $1B:CB2C
and for #27 is $1B:CBE9. This image shows the graphics #0 highlighted
and #27 is the next graphics after #00.
http://www.mediafire.com/view/h5jc1ud8k3b41uj/persia2.png

Oh, so that explains why sprite 14 didn't seem to break other sprites. So, this compressed data from the .bin, should I put it anywhere where there's empty space or there is a specific pointer where I should put it?

[slidelljohn]

Just use empty space for now. Look at the 2nd to last image I posted and it
shows where I put the new compressed data for testing. I put it at $0E:FC00
just before the pointers. If everything works correctly now then I'll do a
little bit of cleaning up the code and the toolbar. After I do that then
I'll do the palettes.

[Shauing]

Just use empty space for now. Look at the 2nd to last image I posted and it
shows where I put the new compressed data for testing. I put it at $0E:FC00
just before the pointers. If everything works correctly now then I'll do a
little bit of cleaning up the code and the toolbar. After I do that then
I'll do the palettes.

Ok, I'll do the test on sprite 0 and 473 again, which were the ones with issues.

[Shauing]

I see, I understand. Don't worry if you cannot really work on it, better not pressure you if you do have a lot of stuff going on and this is just too time consuming and draining for you. Perhaps it'll be best to leave it if it's just that much. I really appreciate that you created it at all, and even if it is unfinished, I'm happy that it works in some capacity.
Thanks again for everything, and hope things will straight up for you.