Thanks again for everything, and hope things will straight up for you.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
I've started to rule out the Smb2 music editor. I've spoken to dtothefourth and they seem to be doing a lot of other things.I see. Better to keep doing process than wait for a tool that might not be ready that soon.
I have also managed to change some things in boss battle music with Birdo. I would rather focus on graphics and level design.
I could compose the music in Famitracker but that's just for reference, since the smb2 music engine is something completely different.
If you are willing to take on the challenge with hacking the music I couldn't be happier!
The Soundtrack:I have my few doubts on what specific parts of a song you want for a few pieces (the three parts of ''It's All Too Much'' for example), but we'll see how it works.
Intro - With a little help from my friends
Selection - Sgt. Pepper's Lonely Hearts...
Overworld - Yellow Submarine
Subspace - Nowhere Man
Underworld - Lucy In The Sky With Diamonds
Bonus Game Start - It's all too much 1
Death - It's all too much 2
Bonus Game Win - It's All Too Much 3
Game Over - All Together now
Star - Sgt. Pepper's... (Reprise)
Boss - Eleanor Rigby
Wart - Hey Bulldog
Wart Beaten - Lucy In The Sky With Diamonds (intro)
Ending - All You Need Is Love
There's a Discord for this. Come join us.
All together now!
Just use empty space for now. Look at the 2nd to last image I posted and itOk, I'll do the test on sprite 0 and 473 again, which were the ones with issues.
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.
Don't press save gfx that just saves the graphics not compressed to a file. Press save as toOh, 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?
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.
Everything that I'm able to edit seems like its working correctly.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?
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.
I'm not really sure why it was doing that because that was the last thing thatOn 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.
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.
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.
I think I have the sprite compression algorithm working correctly.
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.
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.All right, I'll watch them during the following days/weeks.
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:
I’m not 100% sure if this is the QT that I have but I think it is.Downloading it. I'll wait for your guiding.
I have a new update: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).
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.I'll try to get the version you are currently using of QT.
I’ll make it edit all graphics and palettes just need to find the rest of the gfx pointers.Awesome.
If you need help finding the pointers I can show you how to find them. With the source code you can add anything you want to it. I’m using QT to program the c++ code.Sure, in both cases. I practically have no experience in programming/coding, so I will be happy to learn.
If you ever want to learn how to program using QT let me know and I’ll help you out.
@ShauingSo the software as you will leave it would only be able to modify character sprites (i.e. Prince, Princess) and save them to the rom?
The code I'm using for the painting system is something I had for awhile
now and I was just slowly working on it. I original used it for 7th saga
but I never finished it because I wasn't happy with how I had to program
the code to paint in the snes format. Now I have It programed a lot better.
I have the persia graphics decompressing and most of them look correct. I'll
try to have gfx and palette edits working sometime this weekend. After I
get those working Ill give you the source code for it. Thats probably as
far as Im going to go with persia. My gfx editor will still be slowly worked
on but Im not sure when Ill have it posted on my projects page because I still
want to make other changes to the painting system. Im probably going to move
the whole toolbar from the top of the screen to the left side of the screen.
Still got lots of things to test out for it.
That's good that they are all in a table file. I'll create a spinbox that scrolls through the
different sets of graphics. I have been playing around with the painting system and here is
what I have so far: http://www.mediafire.com/file/wylgafun9rhyqut/SNES_Paint.zip/file
Keep in mind this test painting system is nowhere near complete.
After I make a few more modifications to the painting system I'll get it to start decompressing
and compressing the persia graphics.
The pointer for the 3 16x16 tiles is located at $0F:802A-$0F:802C. The actual pointer is $1B:D871(71 D8 1B). These graphics
get decompressed starting at $7F:9DC0 in ram. The compressed graphics has a 3 byte header and the 3rd byte in the header
controls the number of 16x16 tiles to decompress. The 3rd byte in the standing still graphics header is at $1B:D873 (0x31).
It looks like a lot of the pointers start at $0F:8000 but I'm not sure if that is just the main characters graphics or all graphics.
If you just find the pointers then I could probably get a small graphics editor written for you by the end of next week.
I'll give you the source for it to so you or anyone else can add to it if they want to.
Yea, just let me know when you get the data put together. I’ll see about getting a small program put together to where you can do the compression yourself but I’ll have to do a little more research on the game because the compressed graphics pointers also have data for some tile positioning. For the most part you should be able to use the same data for tile positioning as the original unless you are changing height width of graphics.
If you have the updated graphics for the main character standing still I could try to compress those while you try and get the other pointers. The standing still graphics pointer is the only pointer that I currently have so it’s the only one that I can try to compress. The standing still graphics should be 3 16x16 tiles.The standing graphic as I have it from the extracted graphics package at Princed, is originally 9x42 (or 3 tiles of 9x14). I did a 16x48 version by expanding the canvas. I saved both on two formats, .bmp and .png (the .png should have a transparent BG). You can download the four standing graphics here: https://www.dropbox.com/s/6p9778e22vhadkm/Prince%20Standing.zip?dl=1
I looked at the other site you posted on and I see you talked about custom music. I’m not sure if you got all of your custom music in the rom but if not you could try using MSU-1 for the custom music. I have never done anything with MSU-1 so I wouldn’t be much help with that but I’m sure other people could help with it if it’s something you could use.
I have never played this game before but seeing how the game loads the graphics(which is not good) and it’s a slowrom I am assuming there are slowdowns in the game. Have you noticed slowdowns in the game? If so, and if you would like to remove some slowdowns, I could do a fastrom hack for it if you are willing to document all of the assembly code the same format I did for gradius 3 assembly code(gradius 3 asm doc is uploaded). I have a small program that can convert most of the data from assembly files to the correct format for fastrom. The left over asm code that would need to be changed for fastrom would have to be done by hand but it shouldn’t be much. I used giegers snes debugger to create the disassembled snes code.Yes, there is slowdown in the game, but those who have played this, are very accustomed to it. It would be great too to have a fastrom hack, though. There is a disassembly document of the SNES Prince of Persia. I'm not sure if its complete, but it is pretty extensive. Here's the thread (the last post has the newest version of the dissassembly): https://forum.princed.org/viewtopic.php?t=3652
I looked at the decompression algorithm and it seems pretty simple. If you can put together your new snes formatted graphics and the pointers to the compressed graphics that you want to change then I could compress the graphics for you. I’ll do the compression but I’m not going to look for all of the pointers. I could probably get the graphics compressed this week if you have them ready to go.
I'm currently developing a snes tool that has a snes painting system in it and it’s going to include algorithms to compress and decompress graphics for various games. After I get the painting systems code cleaned up I’m going to start adding the compression/decompression algorithms and I’ll make sure
I include one for this game. I’m juggling a bunch of projects right now so I’m not sure when my tool would be ready.
I took a quick peek at your project, and phew you guys really get into it over there at princed! You guys have the graphics decompressed and everything. I didn't try your romhack yet but it looks amazing.
If you look at this thread I helped a translator decompress the graphics and insert them into the rom uncompressed. More like guided as he did all the real work cranking out translations.
I was hoping PoP would decompress all the sprite graphics at once into work ram, then move the tiles it needs at any moment onto the screen in vram. The Mystical Ninja and a lot of games have the whole font in wram and copy the letters needed into vram as needed. With PoP, they don't seem to utilize the snes hardware as well as they could probably due to all the ports they made. All I see in wram and vram is the current sprite of the kid, so I'm guessing that the sprite is decompressed as needed, again I only took a peek.
I see all the decompressed graphics using the php code, I would guess the graphics are really mashed together, and the code joined the fragments together to make the output files. If you simply have a large sheet of tiles before combining together, it'd be pretty easy to insert that into the rom as uncompressed. They used compression back in the day because a 1MB rom chip was cheaper than a 2MB. It would be simple to use up to 4MB for PoP snes.
If you find someone who wants to go crazy and recompress new graphics into the ROM that would be awesome (I see some blank space in the ROM here and there), but it'd be much simpler to put the decompressed graphics into expanded space (just make the ROM larger in a hex editor.)
Maybe the Konami SNES Compressor could help?
Great job on the rom hack!
Overview of what to do...
- Code a program to convert indexed bitmaps to byte data. I suggest using Python.
- Figure out where the pointers are stored in the game.
- Figure out how to encode the pointers (likely in the LoROM format or little endian)
In bsnes-plus, I would try locating where the graphics are stored in the VRAM. Set a breakpoint there. Once the breakpoint is hit, you can figure out how the game reads points by look backwards in the code.
Obviously, easier said than done, but this is more or less how I figured out how Metal Slader Glory DX for SNES compresses graphics...