News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

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.

Messages - Shauing

Pages: [1] 2
ROM Hacking Discussion / Re: Help! Prince Of Persia SNES Custom Sprites
« on: December 09, 2020, 05:52:52 am »
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.

Personal Projects / Re: SMB2 - Super Beatles - Pepperland
« on: January 18, 2020, 01:24:18 pm »
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 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!
I see. Better to keep doing process than wait for a tool that might not be ready that soon.

It's a good idea to use Famitracker for reference, but yeah, the engine on SMB2 is a different story.

I would love to! I just need to document carefully to have what it's needed pin down, so attempts for implementation can be done effectively.

The Soundtrack:

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!

Pepperland Discord:

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.

I'll join there! Thanks!

Personal Projects / Re: SMB2 - Super Beatles - Pepperland
« on: January 17, 2020, 08:37:01 pm »
I'm a huge Beatles fan and couldn't have been more excited for this.
I see that you want to implement Beatles music, but don't know how and you're waiting for the music editor to be created and use it.
I have been reading some documentation of how the SMB1 music is written on the ROM, and started to compare it with SMB2. It seems that its written in a similar way (not sure up to what point).
I see there's the ROM map for SMB2, and it is helpful in locating each track, as well as its pointers, headers and music data.
I have modified a few notes (and rhythm) of Pulses 1 and 2 for the title screen, but I still need to experiment and document a little more in order to know how it is done properly. But, I would love to adapt the music.
I saw that you had a couple of music lists intended for the game but, have you decided which songs and where do you plan to put them?

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.

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.
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?

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.

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.

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.
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.

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.

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

ROM Hacking Discussion / Re: What happened to ROMhacking culture?
« on: June 02, 2019, 08:26:40 pm »
I can only speak for the Prince Of Persia DOS and SNES hacks, as I have worked on that modding community and have made at least one hack for the SNES port. For both systems they have done some wonderful hacks, and most of them try to tell a different story and expand what its possible for gameplay, without necessarily fixing ''broken'' stuff.
My own SNES hack has a different story (within the limits of what its shown, as custom sprites is still not a possibility, but custom palettes are), at least one original tune composed by myself and some new mechanics in addition to the old ones, just to try to bring something different and maybe fresh for this hack.

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):

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.

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:

Here's more info on the palettes (you probably read them already, but just in case):

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:
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.

I’ll make it edit all graphics and palettes just need to find the rest of the gfx pointers.

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.
If you ever want to learn how to program using QT let me know and I’ll help you out.
Sure, in both cases. I practically have no experience in programming/coding, so I will be happy to learn.

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.
So 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?
Hopefully with the source code we can also add editing for the background/foreground sprites, title screen, pixel art, etc.

Again, can't wait.

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:

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.

Incredible, pretty intuitive despite being a test only. Sprite edits can be saved to SNES_4BPP.bin, though no palette edits, and there are no changes in-game (probably both were not implemented here). Hopefully there'll be things like undo and a visible square/pixel brush to see exactly where we are editing. Another suggestion could be a Paint.NET like-tool called Recolor, where it can replace regions of one color with another. But that's all up to you.

I just can't wait to see it finished and working. I'll try to stay calm.

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.

I think I found them all. Thanks to the pointer (71 D8 1B) and the folder of extracted graphics, I realized that the filename of each of these extracted graphics is actually a sprite number. The standing Prince is sprite number 15 (labeled as 0014). I looked for the pointer in the hex-editor, then started to count backwards every 3-byte as one pointer up to 0F:8000, and turns out, this is pointer number 15.
So, by this logic, and following the numbering in the extracted graphics, the graphic pointers go from 0F:8000 to 0F:9166, that means 4455 bytes, which compose 1485 sprites.

I went to search if I could find the other graphics like the Title Screen, End Credits and maybe the levels, and I think I found them too (I'm less sure about it). I found the font that is used on the Menu and Pause screens, I think it goes from 04:8000 up to 04:8C93, 3220 bytes. These can actually be viewed on the a SNES tile editor as they are uncompressed and are 2BPP. I think the rest of the graphics (each layer for every type of level, logo/pixel art screens) are below, based on the extracted graphics folder. I think these are compressed the same way as the sprites, though I can sort of recognize some graphics on 2BPP. I'm trying to find up to where these type of graphics end, but I am mostly sure they end at 0E:F94E, as there is empty space from there.

Not all the sprites and graphics were used; some were changed/added for the American release, others are unused, and others were dummied out so they are empty.

Here are the resource tables:

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.

At least for this mod, I don't plan in any changes in height or width for the 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:
By the way, could you give me the standing graphics pointer? If I manage to find a match on the documentation, maybe I will find the rest. 

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 managed to insert my composition for the title screen, plus an arrangement (also composed by myself) of the Menu music. I didn't attempt to do a complete new soundtrack, as I want to compose all new music for it, but I need to think another 10-20 tunes and within the space I have to write them on the ROM, but that might take another year, and not sure if I'm willing to spend that much time. Another reason I have (or had if this works), was to wait until inserting custom graphics was possible.
I'm also considering in doing a MSU-1 version of my mod, but probably after finishing the normal SNES version one.
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):

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.

That's awesome! I'm currently modifying all the sprites for the characters I want to be modified, and I am also searching on documented files by the guys at Princed (and asking them too) if they have located the pointers to the compressed graphics of those characters. I'll try to have them all by the end of the week, hopefully along with the pointers.

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.

First of all, thank you for writing and try to help me with this. I hope you try my mod, it's the first one I have ever done, and worked for a little more than a year on it.

Indeed, those guys at Princed are crazy for PoP indeed; I'm just a very curious amateur who only knows how to follow instructions, but from there I can figure out stuff, at times what I was looking for, at other times I get something different but that could be interesting and perhaps work in some way.

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.

Looked at the thread you linked, and pretty much I think I can follow instructions if guided like that, though I will still have some doubts on certain stuff.

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.

Hmm. How could I make the ''large sheet of tiles before combining together''?

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!

Trying to figure out how to use the Konami SNES Compressor, can't quite get it to work.

My changes are really, really minor, and for now, just for three characters:
- For the Prince, I just want him to have white pants; on the original game, the turban and pants share the same three color palette. In my mod, the Prince looks like this:

I want him to end up looking like this:

- The Princess:
- The Queen:

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...

Hmm, I see. While I could try to figure out the latter two, I don't know how to code unfortunately (unless I follow instructions).

Pages: [1] 2