KawaseFan.net Forum

Main Series => Umihara Kawase => Topic started by: mfgreth on October 07, 2014, 05:43:55 AM

Title: ROM Hacking?
Post by: mfgreth on October 07, 2014, 05:43:55 AM
Has there been any effort to hacking this game in the past, outside of translating? It would be cool if someone produce a toolkit to do so, so we could produce fan-created fields/challenges. Thoughts?

(I'm not proposing to do this myself, I'm not much of a programmer, and my only experience ROM hacking was with SMW and Chrono Trigger... like everyone else basically).
Title: Re: ROM Hacking?
Post by: Nicole on October 07, 2014, 08:00:40 AM
Uhh, there were a few efforts here and there. There were a couple efforts to make a level editor, though they didn't come to pass. I dug up a Japanese field viewer at some point, which seems like it was meant to become an editor at some point, though that never happened.

There's also a level select hack I got from Electric Lady, though it's kind of buggy. I also took a small crack at reverse-engineering the game myself, though I eventually lost interest for a while since reverse-engineering assembly is rough-going. The timer routine was the main thing I figured out, in any case -- I didn't try braving the physics or map systems. I wrote some notes while doing so, but they wouldn't be very intelligible to anyone but myself as they are right now.

As for documentation regarding the internals of the game, there's a few scattered bits of information, as well as the wiki for one failed attempt at a level editor... I dunno if that's still around. Anyway, I'll try and dig up some of this stuff tomorrow.
Title: Re: ROM Hacking?
Post by: KawaseFan on October 07, 2014, 11:36:16 AM
Hopefully one day a level editor is made, that would be fantastic.
Title: Re: ROM Hacking?
Post by: Nicole on October 08, 2014, 03:12:36 AM
Here's the field select patch. (https://mega.co.nz/#!lAMQiLbL!pWNeQOVGumZFGS3Rq2pyfMl2IKFwiII97Of2Pp17-9w) This patch should be applied to a Japanese headerless ROM. It's possible that an English-patched ROM could work as well, but there's not much point since this patch breaks the replay and pause menus.

Here's the collection of Japanese resources I found. (https://mega.co.nz/#!0Bc2QIhL!r6fRtov4mPh0Y4SKL9n9YRSYr9mERCnjTYTHsFnEVWI) It includes some Japanese notes on some of the game internals, a field viewer (plus source code!), and a small, somewhat pointless patch that basically just lets you complete the game instantly (http://www.nicovideo.jp/watch/sm750814).

Here's a small linkdump of some resources I found:
http://wiki.superfamicom.org/snes/show/Umihara+Kawase (http://wiki.superfamicom.org/snes/show/Umihara+Kawase)
http://acmlm.kafuka.org/board/thread.php?id=6331 (http://acmlm.kafuka.org/board/thread.php?id=6331)
http://ndirt.com/umihara/doku.php?id=start (http://ndirt.com/umihara/doku.php?id=start)

I've got a feeling that the Japanese stuff in particular will prove useful for actually creating a level editor, but the fact that most of it's in Japanese makes things somewhat tedious.
Title: Re: ROM Hacking?
Post by: mfgreth on October 10, 2014, 01:32:32 AM
I've got a feeling that the Japanese stuff in particular will prove useful for actually creating a level editor, but the fact that most of it's in Japanese makes things somewhat tedious.

Nice finds!

It's true, it will be very tedious. But it's always worth looking into, anyways.
Title: Re: ROM Hacking?
Post by: KawaseFan on October 10, 2014, 12:50:23 PM
It's a real shame that all that research has been done with not a lot of result so far, but at least that information and code is still around for anyone who might be interested in the future.

I recognise a username from some of those links - also someone apparently involved with the wiki at ndirt.com - as someone who got to the point of actually offering to pay someone to make a level editor (http://www.smwcentral.net/?p=viewthread&t=64768), and that doesn't seem to have resulted in anything, so I don't know what it'll take for it to happen.  Maybe it's that hard to do?  Maybe €100 wasn't enough of an offer?
Title: Re: ROM Hacking?
Post by: badlose on October 10, 2014, 05:19:52 PM
I've talked a couple people throughout the years who were working on hacking SFC Umihara Kawase, they never got too far. Minor stuff like changing the timer variable, or jump height variable. I'd be most interested in the formula for calculating the line physics, as much as I'd love a level editor someday.
Title: Re: ROM Hacking?
Post by: Nicole on October 10, 2014, 08:04:32 PM
Well, I'm looking over the field viewer source code right now. Can't promise anything right now, obviously, but it does seem to me that if we can read the map data with this code, writing shouldn't be that hard, assuming there's no compression (which there doesn't seem to be). I've gotta get a handle on what the code is doing first, though.
Title: Re: ROM Hacking?
Post by: Nicole on October 10, 2014, 11:03:48 PM
Doing a little, er... experimentation.
Title: Re: ROM Hacking?
Post by: Nicole on October 11, 2014, 05:18:39 AM
Working on translating the Japanese notes, because there's a lot of information in there.

I've found out that the field data is in fact compressed, and explains what Naulahauta was seeing with seemingly random "00"s and other byte combinations sprinkled in the data--the fact that he could modify the data easily at all was because of sheer luck that the tiles he wanted to modify were uncompressed.

This doesn't mean that modifying fields is impossible or anything, but it is made somewhat more difficult by the fact that the new field data must fit in the space the original field fit in. This could possibly be sidestepped with ROM expansion, though at the moment I'm not sure how stable the ROM would be, or if some code would need to be altered.

That being said, the compression algorithm used to store the original fields doesn't seem terribly efficient, so it may be possible to squeeze altered fields in easily. It's hard to say at this stage.

EDIT: Though of course, just flat out removing all the original fields and adding in new fields would be no problem at all.
Title: Re: ROM Hacking?
Post by: badlose on October 11, 2014, 05:33:47 AM
Pretty exciting stuff. Keep us updated, or let us know if we can help in any way.
Title: Re: ROM Hacking?
Post by: Nicole on October 14, 2014, 06:51:11 AM
Code: [Select]
    Addr     FieldType No. MusicType ... HW WtrType  Time  Next
00: $98:a10e Riverside F00 Riverside     f0 01 02 e6  5:00 F01 F01 F01 F01
01: $99:b08a Riverside F01 Riverside     f0 01 02 e6  5:00 F02 F02 F02 F02
02: $97:b403 Riverside F02 Riverside     e8 01 02 e6  5:00 F03 F05 F05 F05
03: $97:d58e Seaside   F03 Seaside       f0 01 03 e6  4:00 F04 F04 F04 F04
04: $85:f000 Seaside   F04 Seaside       f0 01 03 e6  4:00 F39 F39 F39 F39
05: $93:c49c Riverside F10 Riverside     f0 01 02 e6  4:00 F09 F09 F09 F09
06: $8b:e0ff Seaside   F06 Seaside       f0 01 03 e6  4:00 F07 F07 F07 F07
07: $8a:e485 Seaside   F07 Seaside       f0 01 03 e6  6:00 F08 F08 F08 F08
08: $9b:d1e3 Riverside F08 Riverside     e8 01 02 e6  4:00 F10 F10 F10 F10
09: $9a:ad8c Riverside F11 Riverside     e8 01 02 e6  5:00 F08 F20 F12 F12
0a: $92:f0fd Seaside   F14 Seaside       e8 01 03 e6  4:00 F11 F11 F11 F11
0b: $98:908a Waterfall F15 Waterfall     f0 01 02 e6  4:00 F55 F59 F59 F59
0c: $9a:9e6e Waterfall F12 Waterfall     f0 01 02 e6  5:00 F63 F63 F63 F63
0d: $99:dfc9 Waterfall F17 Waterfall     f0 01 02 e6  5:00 F14 F28 F28 F28
0e: $99:8000 Seaside   F20 Seaside       e8 01 03 e6  5:00 F15 F15 F15 F15
0f: $9a:e6cd Seaside   F21 Seaside       e8 01 03 e6  4:00 F16 F16 F16 F16
10: $95:e923 Mt.Stream F22 Mt.Stream     f4 01 02 e6  4:00 F51 F22 F22 F22
11: $8c:f27d Seaside   F26 Seaside       e8 01 03 e6  4:00 F52 F50 F50 F50
12: $91:e749 Riverside F18 Riverside     e8 01 02 e6  4:00 F51 F51 F51 F51
13: $93:ecae Riverside F38 Riverside     e8 01 02 e6  4:00 F54 F54 F54 F54
14: $97:a2fa Seaside   F30 Seaside       f0 01 03 e6  4:00 F49 F60 F60 F60
15: $8b:f3da Seaside   F45 Seaside       e8 01 03 e6  5:00 F45 F45 F45 F45
16: $9a:cb44 Mt.Stream F24 Mt.Stream     f4 01 02 e6  5:00 F61 F43 F43 F43
17: $97:f320 Mt.Stream F35 Mt.Stream     f4 01 02 e6  5:00 End End End End
18: $92:e10e Riverside F05 Riverside     f0 01 02 e6  4:00 F06 F06 F06 F06
19: $96:f214 Wharf     F48 Wharf         e8 01 03 e6  5:00 F62 F62 F62 F62
1a: $9a:8f3a Wharf     F47 Wharf         e8 01 03 e6  5:00 F40 F40 F40 F40
1b: $99:ef2e Ocean     F52 Ocean         e8 01 03 e6  5:00 F48 F48 F48 F48
1c: $9a:d927 Mt.Stream F42 Mt.Stream     f4 01 02 e6  6:00 F18 F46 F46 F46
1d: $99:9032 Ocean     F34 Ocean         e8 01 03 e6  5:00 F38 F38 F38 F38
1e: $98:f1cd Ocean     F50 Ocean         e8 01 03 e6  5:00 F58 F58 F58 F58
1f: $99:a063 Riverside F43 Riverside     e0 01 02 e6  5:00 F60 F60 F60 F60
20: $8e:f015 Seaside   F57 Seaside       f0 01 03 e6  5:00 End End End End
21: $91:f5f3 Ocean     F55 Ocean         e8 01 03 e6  5:00 End End End End
22: $9a:bc97 Mt.Stream F33 Mt.Stream     f4 01 02 e6  5:00 F53 F53 F53 F53
23: $96:bccd Mt.Stream F31 Mt.Stream     f4 01 02 e6  8:00 F57 F57 F57 F57
24: $9a:8000 Mt.Stream F23 Mt.Stream     f4 01 02 e6  5:00 F37 F37 F37 F37
25: $98:d252 Mt.Stream F28 Mt.Stream     f4 01 02 e6  4:00 End End End End
26: $98:e293 Mt.Stream F37 Mt.Stream     f4 01 02 e6  4:00 F22 F22 F22 F22
27: $97:c4d5 Waterfall F41 Waterfall     f0 01 02 e6  5:00 F43 F43 F43 F43
28: $96:ceed Waterfall F16 Waterfall     f0 01 02 e6  5:00 F13 F13 F13 F13
29: $96:aa70 Waterfall F29 Waterfall     f0 01 02 e6  5:00 F44 F44 F44 F44
2a: $8f:ec7e Wharf     F46 Wharf         e8 01 03 e6  5:00 F41 F41 F41 F41
2b: $87:f000 Wharf     F51 Wharf         e8 01 03 e6  5:00 F62 F62 F62 F62
2c: $89:f8e8 Mt.Stream F40 Mt.Stream     f4 01 02 e6  4:00 F38 F38 F38 F38
2d: $99:c092 Riverside F49 Riverside     f0 01 02 e6  6:00 F42 F42 F42 F42
2e: $9b:994a Seaside   F25 Seaside       f0 01 03 e6  4:00 F18 F56 F56 F56
2f: $90:f69c Wharf     F56 Wharf         e8 01 03 e6  6:00 F47 F47 F47 F47
30: $9b:b9c7 Ocean     F36 Ocean         e8 01 03 e6  8:00 F42 F36 F36 F36
Doing some testing with reading data from the ROM. This is a trimmed and formatted version of the field table, which holds information like field numbers, tileset, music, and water height. As you can see, the order of these table entries doesn't really correspond to the actual field numbers, and thus probably signifies the order in which the fields were created.
Title: Re: ROM Hacking?
Post by: KawaseFan on October 15, 2014, 11:40:44 AM
Pretty interesting!

So - and I know pretty much nothing about ROM hacking, so please forgive me - but in theory the 'next' fields could be changed to lead to whichever field/s you want, or the time limits could be changed to be much quicker, and things like that, right?
Title: Re: ROM Hacking?
Post by: Nicole on October 15, 2014, 10:14:27 PM
Yep, everything in this table is very easy to modify. There's also a large amount of blank space after it, and the length of the table is not hardcoded, so adding more entries is also very easy.
Title: Re: ROM Hacking?
Post by: KawaseFan on October 17, 2014, 07:11:36 AM
That sounds pretty awesome!
Title: Re: ROM Hacking?
Post by: mfgreth on October 18, 2014, 11:10:13 PM
These are some very exciting developments, Nicole!
Title: Re: ROM Hacking?
Post by: Nicole on October 19, 2014, 08:54:28 AM
Making some progress on decompressing field data, but there seems to be some bugs in my code. Not sure if that's my fault or if the description in the notes is incorrect, but I'll look into it more. At the very least, the length of the data is coming out correctly, even if the data itself isn't, so I think I have an idea what the problem might be.
Title: Re: ROM Hacking?
Post by: Nana on October 20, 2014, 02:32:44 PM
At the very least, that sounds like making a patch where you play every level in the game consecutively would be trivial. That of course, does break the spirit of the game, but if you're already an expert, then it would be fun to go through every level in the game in one playthrough.
Title: Re: ROM Hacking?
Post by: Nicole on October 21, 2014, 12:33:08 AM
Yeah, a patch like that would be easy to make.

But actually, looking at this table a bit more... It seems I made a mistake in how this should be read. Like this line here:
Code: [Select]
    Addr     FieldType No. MusicType ... HW WtrType  Time  Next
05: $93:c49c Riverside F10 Riverside     f0 01 02 e6  4:00 F09 F09 F09 F09
F09 doesn't actually exist. In fact, what Next actually stores is the entry number in the table, not the actual field number. In this case, the ninth entry is:
Code: [Select]
09: $9a:ad8c Riverside F11 Riverside     e8 01 02 e6  5:00 F08 F20 F12 F12 And indeed, the field after F10 is F11. I'll go and fix the table in that post.

EDIT: Or... I was going to, but...
Code: [Select]
19: $96:f214 Wharf     F48 Wharf         e8 01 03 e6  5:00 3e 3e 3e 3e There is no entry 3e, but the next field should be:
Code: [Select]
2f: $90:f69c Wharf     F56 Wharf         e8 01 03 e6  6:00 2f 2f 2f 2f This is getting kinda perplexing...
Title: Re: ROM Hacking?
Post by: Nicole on October 22, 2014, 02:30:43 AM
Tracing through the assembly code to try and figure out how the Next entries work, but it seems really bizarre so far... I dunno if it has something to do with the little tutorial sequences that show up before fields or what, but I'm looking into it. So far there seems to be two other tables it consults...
Title: Re: ROM Hacking?
Post by: KawaseFan on October 22, 2014, 12:15:54 PM
That about the tutorials sounds like it would make sense.
Title: Re: ROM Hacking?
Post by: Nicole on October 28, 2014, 08:01:04 AM
Yo, just a heads-up, this topic's been at a bit of a standstill for a while, but that's because I've been caught up in some other things recently. I'll get around to working on this again, but it might be a week or two.
Title: Re: ROM Hacking?
Post by: KawaseFan on October 28, 2014, 01:28:39 PM
Not a problem at all.  The work you've already put into this is much appreciated by myself and I'm sure everyone here.
Title: Re: ROM Hacking?
Post by: mfgreth on October 29, 2014, 11:07:44 PM
Nicole, you are absolutely awesome!
Title: Re: ROM Hacking?
Post by: badlose on November 21, 2014, 07:27:38 PM
Unused/different behavior enemies from the /vr/ thread:

https://www.youtube.com/watch?v=4SLTEzKCmPs (https://www.youtube.com/watch?v=4SLTEzKCmPs)
https://www.youtube.com/watch?v=mgMI4AApyLE (https://www.youtube.com/watch?v=mgMI4AApyLE)
https://www.youtube.com/watch?v=XjPet34iXMg (https://www.youtube.com/watch?v=XjPet34iXMg)
https://www.youtube.com/watch?v=vpj3WU_Y2Pw (https://www.youtube.com/watch?v=vpj3WU_Y2Pw)
Title: Re: ROM Hacking?
Post by: KawaseFan on November 22, 2014, 04:40:48 AM
I really like the catfish in particular.  I wonder why they weren't used.
Title: Re: ROM Hacking?
Post by: Nicole on January 07, 2015, 02:16:46 PM
Oh, yeesh. I didn't realize I'd said 1-2 weeks here. Guess I was a bit too optimistic.

The motherboard on my PC ended up crapping out on me, so although I haven't lost any work or anything, I'm not quite able to work on this at the moment. Not sure when I'll be able to again, but hopefully it's not too long. At the very least I'll try to put together some documentation of the stuff I've already figured out.
Title: Re: ROM Hacking?
Post by: KawaseFan on January 07, 2015, 08:52:12 PM
Sorry to hear about your motherboard.  At least you didn't lose any data, though, that's the most important thing.
Title: Re: ROM Hacking?
Post by: Alc on May 07, 2015, 08:39:44 PM
Unused/different behavior enemies from the /vr/ thread:

https://www.youtube.com/watch?v=4SLTEzKCmPs (https://www.youtube.com/watch?v=4SLTEzKCmPs)
https://www.youtube.com/watch?v=mgMI4AApyLE (https://www.youtube.com/watch?v=mgMI4AApyLE)
https://www.youtube.com/watch?v=XjPet34iXMg (https://www.youtube.com/watch?v=XjPet34iXMg)
https://www.youtube.com/watch?v=vpj3WU_Y2Pw (https://www.youtube.com/watch?v=vpj3WU_Y2Pw)
These are fascinating. Is Verneri here? I had conversations with him about his level maps a few years back, but this is new stuff.

He also did this recently:

https://www.youtube.com/watch?v=3Z9QRSCrj0I

which is incredible. I'm guessing it must have taken some kind of emulator hack - lots of work no doubt, anyway. Well worth a look.
Title: Re: ROM Hacking?
Post by: Naulahauta on November 19, 2015, 05:35:47 AM
I had no idea this forum existed until now – I only stumbled here upon searching "Rom hacking Umihara Kawase" yesterday.
I have a lot to say. First off, Raccoon Sam, Naulahauta and vervalkon, are all the same person, which is me, Verneri Kontto. I frequent Twitter and /vr/ these days more than any forums, and you will probably find more content under the vervalkon handle these days and in the future.

My contributions include the unused enemies (https://www.youtube.com/playlist?list=PLUlpBuEOUaJ-8VCG_Qogp8__yKboSpM7J) mentioned earlier, comprehensive Sprite rips (http://www.spriters-resource.com/snes/umihara/sheet/62067/), Map rips (http://www.vgmaps.com/Atlas/SuperNES/index.htm#UmiharaKawase) and the Atlas vid (https://www.youtube.com/watch?v=3Z9QRSCrj0I). I hereby give permission for Kawasefan.net to use and host all of the media.
I also made a ROM hack that links all levels together, removes the 30-minute rule and implements the unused enemies in some levels, but I made that as a /vr/-only novelty and I no longer have the link. I never even made a patch, I simply posted the .smc. Someone might have it though.

About ROM Hacking, though – it's a more peculiar story. I posted a Help Wanted-ad on regarding the level compression in early 2013 (and indeed, later offered 100€ for someone who would create an editor) to which someone called Karethoth responded to. He made substantial work regarding the compression and created the wiki (http://ndirt.com/umihara/doku.php?id=start).

However, I got a message the 3rd of July 2013:
Quote
If you're still lost on that decompression problem, I can take a crack at it.  I'll need you to do the following:

1. Put a read breakpoint on the map data, just like you said you did in the want ad.
2. When you hit the breakpoint, hit "step out".  Write down the offset of the instruction you step out onto.
3. Reset the game and disable the first breakpoint.  Set execute breakpoints for the offset you wrote down and that offset - 2.
4. When you reach the breakpoint (even if it's before you expect it to happen), enable "trace once", "tabbed output", "squelch", and "cpu tracing".
5. Click run; you will reach the second breakpoint pretty much immediately.  Disable "cpu tracing"; there should be a text file near your rom called "name-of-rom0000000.log" or something like that.
6. Send me that file.  Any other information, e.g. notes on addresses and what they're used for, could be helpful, but if I need something I'll ask.
7. Wait.
8. ...
9. Profit!

The trick with really abstract disassembly (like compression or decompression routines) is to go through the routine and translate it instruction by instruction into a language you (and humans in general) understand better.  You don't necessarily have to finish & compile & emulate the routine (though it helps for error checking), you just come to a much better understanding of what's doing what as you translate it.  That's what I did when I was reversing decompression in Brandish 2, anyway, and apparently it worked out.

Regards,
Dave Hand
sqykly@gmail.com

To which I replied:
Quote
Thank you for your interest. Someone already dug into the routine and we've got a somewhat loose wiki under development. You can check it and probably contribute if you want to here.
We haven't done much progress. I guess the original supporter lost interest and I really can't help that much. :C
If you know a ambitious ROM hacker, I'm willing to pay 100 euros to anyone who develops a functional level editor for the game.

And our dialogue went on:
Quote
You may be in luck; I am a stupidly ambitious rom hacker drawn to seemingly lost causes, and I need money.  When you say "functional level editor", what are the qualifications?  Technically, you can edit whatever you want with a hex editor, but I'm guessing you'll want something more task specific.  Do you just need to be able to pick which tile goes where, then compress it and shove it in an IPS patch?  Or do you need other stuff like events, dialogue, some tools to see how far you can jump, etc?  Do you need to be able to load levels from the rom?  Do you need to be able to access (or at least not overwrite) existing levels from the new level in-game?

An I said:
Quote
Oh! Intriguing. And yes, there are a few key requirements for the editor.
-It must either have a separate/integrated level exporter/importer or a 'load everything on the fly'-kind of editor. Best case, both.
-A level editor, by definition must correctly display decompressed graphics, either straight from the ROM or from decompressed graphics files.
-It must have a physmap editor, a tile editor and sprite position/type editor as well as starting point and tide editor. This is a given.
-It must have a header editor for each individual level.
-The editor must be open-source.

Those are the absolute minimum requirements. Might be a tough job since to my knowledge, the wiki is incomplete and on a hiatus, so you might have to dig deeper to the compression routines yourself.
These are not required, but would be fantastic to have:
-It should be cross-platform
-It should have a credits editor
-It should have a condition editor for 'how many enemies must be killed until door opens' (if such conditions exist. I'm not sure if it's already defined in the level headers.)

Thank you for your interest. Of course, I understand if the requirements don't meet your standards but thanks so much either way!

To which he replied:
Quote
I went ahead and finished the work on the compression format; it's on the wiki.  It's actually quite similar to the compression I encountered on the Brandish 2 splash screen, though its use of intermittent callbacks like coroutines was an interesting twist.

I need to know how well the "physmap" data is understood and how much tile data is mapped out in order to decide how I'll prioritize this project.  I have a website (play5ong.com) that needs debugging work before I start collecting ad revenue from it, but if the tile data for this game, the header format, and the physmap don't need to be reversed from scratch, I can do this fast enough to not go broke and lose my server.  Otherwise, I really need to get 5ong running, and this will need to wait a bit.  Honestly, I love reversing engineering, tool-building, and the SNES, so I'd rather do this, but broke is broke =(.

Do you have a particular platform or language in mind?  I've been writing nothing but HTML5 & JS for a while, and it would really make a lot of UI stuff easy to make the level editor as a web or browser app, and that would necessarily be cross platform and open source.  It might be a little slower than a native code or java application, but it would work, and it could be done in a reasonable time frame.

I'm not going to post all the e-mails, but this is how it all started. We had now made a deal, and something incredibly ambitious, a functional level editor that works straight from the browser was under development. Not only that, but he also documented everything he found to the wiki – He even wrote a haiku (http://ndirt.com/umihara/doku.php?id=romreversing:start) for every enemy entry.

Needless to say, things looked prettty amazing. He sent me demonstrations about the user interface and we had decided upon a name, even (Kawabunga).
(http://i.imgur.com/DqXV4dm.png)


We were both sure we were nearing the release, and he sent me this the 27th of September 2013:
Quote
I just got done running some tests of the low-level modules in Node.js, and there's good news and bad news.  Good news:
- Compression & decompression work.
- At the very least, the Umihara-specific module and the IPS patch module work as browser code AND as Node modules, so if you want to make the editor a web service for whatever reason, you can put those (and probably almost everything else, but not yet tested) on the server side or the client side without any modifications.
- Both of those modules are free of egregious obvious syntax errors and crashes resulting from normal use.

The bad news is that I am going to have to do that re-allocation thing I was talking about, whether old levels need to be linked or not.  The issue is that the map data isn't contiguous in the ROM, and I have no idea what data is located in between maps, so overwriting it is fairly hazardous.  It isn't THAT big a deal, it's just another low-level thing to write and debug.  This is not at all the first time I've wished I had written the Brandish 2 editor re-allocator in JavaScript instead of Basic (actually, anything other than Basic would have been better).  So, anticipate a slight delay.

Unless of course you know something I don't about the ROM's layout, for instance one or more very large areas of totally unused space?

and soon after (emphasis mine),

Quote
Okay, re-allocation is done forever, and compression and decompression were both thoroughly tested by decompressing every map, recompressing it, decompressing it again to compare to the original decompressed version, then re-allocating all of them into the space they originally filled.  Back to the UI controller code for me.

Have you heard anything from Karethoth regarding his continued participation in the project?  I still have a couple of things it would be really cool to have tested, by someone who isn't me.


We were all super excited, knowing the release was upon us!

But... that was his last message.

I tried contacting him again and again and again, first because I was confused but later because I was worried something might've happened. I finally gave up hope in late September 2014.
To this day I still have no idea what happened. We were so close.



However, there's still hope. Someone called ellisong has started development on a tool named Riverback (https://github.com/ellisong/Riverback), and he/she seems somewhat active at GitHub. Truly, something to look forward to.

In closing, I want to inform that the level format used in the recently-released PC version is exactly the same as in the SNES/DS versions.
Title: Re: ROM Hacking?
Post by: KawaseFan on November 19, 2015, 10:45:42 AM
My contributions include the unused enemies (https://www.youtube.com/playlist?list=PLUlpBuEOUaJ-8VCG_Qogp8__yKboSpM7J) mentioned earlier, comprehensive Sprite rips (http://www.spriters-resource.com/snes/umihara/sheet/62067/), Map rips (http://www.vgmaps.com/Atlas/SuperNES/index.htm#UmiharaKawase) and the Atlas vid (https://www.youtube.com/watch?v=3Z9QRSCrj0I). I hereby give permission for Kawasefan.net to use and host all of the media.
Awesome, thank you!

Interesting to read those details about that attempt at a level editor.  It's really strange how the guy just disappeared like that after he'd made that much progress...

It'll be interesting to see how Riverback goes.
Title: Re: ROM Hacking?
Post by: Alc on November 21, 2015, 03:44:22 PM
Hi Verneri!

I also made a ROM hack that links all levels together, removes the 30-minute rule and implements the unused enemies in some levels, but I made that as a /vr/-only novelty and I no longer have the link. I never even made a patch, I simply posted the .smc. Someone might have it though.
God damn, I need this ROM. Any pointers as to who might have it or where they might be found?
Title: Re: ROM Hacking?
Post by: Naulahauta on November 21, 2015, 04:54:04 PM
I'm not sure if it's the latest version, but I sent you a PM. I can't guarantee that it's the one with unused enemies but I think this one's it.
Title: Re: ROM Hacking?
Post by: Alc on November 22, 2015, 08:04:01 PM
Much appreciated.

Can you talk a little about how you did this:
https://www.youtube.com/watch?v=3Z9QRSCrj0I
it's a fascinating video to watch.
Title: Re: ROM Hacking?
Post by: Naulahauta on November 23, 2015, 07:18:50 AM
Back when the video was made, I had recently finished the Umihara Kawase Map and Sprite rips. Around the same time I found Andy Dick's fantastic Atlas Vids (https://www.youtube.com/user/nesatlas). I knew I had to do the same for Umihara Kawase, so I asked for Andy Dick's help. The trick here was to render three separate passes of the TAS, straight from the emulator, as lossless, uncompressed videos. The first pass was the TAS but with the foreground layer visible only, then the same for sprites only and finally the HUD only. I would've done this myself but at the time I only owned a Mac and that particular BobWhoops' TAS works only on an obscure version of SNES9X for Windows.
Nevertheless, he sent me the movies and I laid the maps into my Adobe After Effects composition. After that, I put my movie on top of the composition and keyed out the background color.
The trick here is that Xkeeper had earlier helped me out with lua-scripting and had created a script that dumps given RAM addresses to a text file every single frame. I 'watched' the movie and got myself a massive text file with the RAM addresses of "screen X" and "screen Y" values on every row. I converted these hex values to decimal and added After Effects keyframe syntax to them, copied the text, and pasted it into the coordinate row of a Null object in After Effects. I then linked the movie file's coordinates to the Null Object's coordinates and tried to sync them as best as I could. The result was this:
(http://i.imgur.com/PJb5JRw.png)
As you can see, the Null Object's trajectory is pretty obvious, moving a couple of pixels every frame, and the 256x224 SNES screen is locked into it from the top left corner. When she moves one pixel to the right, the field moves a pixel to the left, and the Null Object moves a pixel to the right. It's simple really.

This video (http://webmshare.com/V6jgj) probably makes it even more obvious, as that's the first demo I showed anyone (and I hadn't removed the HUD elements yet)

However, I had to manually add sprites like the moving platforms and the tadpole. That was painful. The original plan was also to extend the levels to full HD (like I did in the last field) but I lost interest.
Title: Re: ROM Hacking?
Post by: Commando125 on November 24, 2015, 10:43:26 PM
Hey. I'm amazed my Riverback project was even found. I've been playing the Umihara Kawase games for a couple months now and a friend on some site I go to wanted me to make a level editor for the game. I've been working on figuring out the SNES game for a couple of weeks while I worked on a portfolio project at the same time. I do need some help on knowing where to go next.

I know how to decompress the level data. Some rough notes on the decompression function is posted below, which probably won't make sense to anyone except the person who wrote it (me). The decompress function was uploaded just now to my small project. I was also able to decompress some graphics with that function (some are at 0x70000, or $8E8000), it was basically the "object" tiles for the Umihara Kawase fields.

I found some information on that wiki that I have been struggling to find; and I might have notes that are not on that wiki. I'm going to try to get my notes kept together and accurate with the one from the wiki. Is the wiki active at all, or was it active until 2013?

Let me know if something is needed. I'm excited others are working on figuring this out too.

EDIT:
  I checked out the wiki. He knows more than I do currently. Wish we could get in contact with him. I never wrote the compression algorithm yet, just the decompression one. There are two places at 0x70000 and 0x68000 that have compressed graphics, and the decompression algorithm I wrote can decompress them into a format viewable by a ROM graphics editor. I was able to insert uncompressed levels into the game though by expanding the ROM, inserting "00" every 9 bytes, and changing the level header pointer. More levels can possibly be inserted to if space is found within the first bank of the ROM for the level header pointers.

  I was thinking that someone else should start the level editing project, because python and Tk might not be the best tool for this. We probably have enough data to edit the levels, but maybe not the enemies/objects. Writing the compression algorithm shouldn't be too difficult. I would love to help with the project though if someone takes over.

@Naulahauta: Do you know how to draw graphics from the ROM? I don't know how.


Code: [Select]
4096 tiles per field
Tiles are made up of 2 bytes: a 1 byte tile type and a 1 byte tile property
tile types are the tile # in the bank

The algorithm reads bytes 1 at a time.
Every read of a POS byte sets a counter equal to 8.
This counter allows to read 8 non-POS bytes before having to read another one.
The POS byte tells where the position(s) of a LZ byte(s) is/are via a bit set.
If a non-POS byte is read, the counter is decremented by 1.
EXCEPTION: if a LZ byte that is read has 0 for the left 4 bits, the counter is not decremented, and is only decremented by 1 after the next byte is read
The leftmost bit is byte 1, the rightmost bit is byte 8.
To end decompression, read #$00 four times when a POS bit is set

The LZ bytes copy data from behind it.
LZ byte: TTTTLLLL
T: total amount of bytes to place (+1)
0bTTTT + 1
If TTTT is 0, the byte after the LZ byte is how many bytes to place.
L: amount of unique bytes to copy from behind the LZ byte.
0b10000 - 0b0LLLL
Title: Re: ROM Hacking?
Post by: Naulahauta on November 25, 2015, 07:22:54 AM
Hello and welcome. I found your project by doing a simple "Kawase" query on GitHub.

The wiki is not active any more, but for the sake of preserving the knowledge it's still up. It would probably be wise to mirror it to Data Crystal or at least make a local backup.

If you read the posts earlier, you probably already know that the man behind all the info can't be reached. However, I just noticed that he's last seen on Stack Overflow a while ago (http://stackoverflow.com/users/929845/sqykly) so you might be able to get in touch with him there. I'm glad he's not dead.

I am not an expert on ROM hacking, but I know for certain that ROM images can be expanded with a tool called Lunar Expand. I don't know if it helps in this project, though, but if one could repoint the levels to the expanded areas, they would likely fit.

To be fair, the destiny is in your hands. Sqykly's gone full hermit, Karethoth's gone, and I can't program*.

What do you mean with "draw graphics from the ROM?"
I'm pretty sure I know how the sprites work – you might want to read my case study (http://www.vg-resource.com/thread-25726-post-563591.html#pid563591) (it's from the DS version but the same formats might work in the SNES version)


In closing, I can't comment on whether python and Tk are the "best tools for this" but if there's an advantage, it's cross-platform at least.

*) I have gone through the Codecademy Python course, but that's it.
Title: Re: ROM Hacking?
Post by: Alc on November 26, 2015, 02:54:18 PM
It's simple really.
It's anything but simple. Thanks for the thorough explanation, though, and for all the hard work. I would never have thought to do it that way.

Great to hear from you Commando - hope you keep working on it.
Title: Re: ROM Hacking?
Post by: Commando125 on November 30, 2015, 05:09:39 AM
After a few days of troubleshooting, I was able to decompress every graphic for the banks of the level stages/fields. Since I saw some interest on this forum for ripping media resources from Umihara Kawase games, the graphic banks are attached below  :). Two banks per field. The first 15 tiles in the bank (the ones with the same double digit) are 15 palettes for that bank. You will need a tile viewer (like Tile Molester) and the 7zip program to open them. Also note that there are some graphics that are uncompressed in the ROM (such as sprites and backgrounds).

The compression algorithm isn't done yet, but it can compress to something the game can read. It just won't compress the same way as it originally was before.
Title: Re: ROM Hacking?
Post by: Naulahauta on November 30, 2015, 11:09:06 AM
Are you sure everything's okay? I downloaded the archive but it always decompresses files with the size of 0 bytes.
Title: Re: ROM Hacking?
Post by: Alc on November 30, 2015, 11:53:19 AM
Download worked for me (160KB) and extracts ok.
Title: Re: ROM Hacking?
Post by: Commando125 on December 02, 2015, 09:47:23 PM
Progress is being made, but it can only display tiles (no objects) and I'm missing two hard-coded palettes for the tiles to select from, but I don't think they are ever used in the game for tiles. Color 0 for the palettes should probably be transparency. I'm wondering what the layout of the editor should look like. The level data and graphics are all read from the ROM itself.

EDIT: I fixed the transparency, but it isn't in these screenshots

(http://i.imgur.com/6pdmZjp.png)

(http://i.imgur.com/4HqqtaX.png)

(http://i.imgur.com/xXtLs7I.png)
Title: Re: ROM Hacking?
Post by: Naulahauta on December 02, 2015, 11:03:05 PM
Looks absolutely amazing!! Love the UI's elegance too, looks really smooth and after all, all of the levels are the same dimensions.
Title: Re: ROM Hacking?
Post by: Alc on December 03, 2015, 03:36:51 PM
So exciting to see this. Great work!
Title: Re: ROM Hacking?
Post by: Naulahauta on December 07, 2015, 12:01:10 PM
I take it there are no pre-defined palettes or formations for any tiles, and one would have to always set the "right one" to the tiles in question?
I mean, the walkable blocks look reasonable as gray or blue or light green, but the trees have to always be the tree-palette and look obviously broken if used with any other palette.

Instead of displaying the 8x8 tiles as a single-palette porridge from $000 to $1FF, would it be a good idea to include a "typical tile cluster definitions" file (an xml or something) that would include pre-built objects with their respective, real palettes? I wouldn't want to build a rock or tree formations from 8x8 blocks one by one when doing the level.
Title: Re: ROM Hacking?
Post by: Commando125 on December 09, 2015, 09:02:07 AM
Since the tiles that can be used can be easily changed per level, I can't see pre-defining palettes or formations happening. The tiles would be in a different position for every bank on every stage.

I am rewriting/porting the editor from Python to C# .NET with WPF. I think the GUI will be a lot better, along with a possible performance increase, because Python's UI options are terrible (you have to convert an image to another image to be able to display it on the UI).
Title: Re: ROM Hacking?
Post by: Naulahauta on December 09, 2015, 09:17:06 AM
Since the tiles that can be used can be easily changed per level, I can't see pre-defining palettes or formations happening. The tiles would be in a different position for every bank on every stage.
I see, sounds reasonable.

Quote
I am rewriting/porting the editor from Python to C# .NET with WPF. I think the GUI will be a lot better, along with a possible performance increase, because Python's UI options are terrible (you have to convert an image to another image to be able to display it on the UI).
While C#/.NET/WPF is inherently Windows-only, many such programs can be run on UNIX/Mac/Linux with Mono (http://www.mono-project.com/), but you probably knew this already. What I'm urging is that please refrain from using any Windows-only DLLs or obscure API calls if you can, for cross-platform compliance.

Looking forward to this!
Title: Re: ROM Hacking?
Post by: Commando125 on December 09, 2015, 12:17:34 PM
I would have to switch from WPF to support it on other operating systems, but it doesn't seem too bad to switch to Windows Forms or GTK#.
Title: Re: ROM Hacking?
Post by: Naulahauta on December 09, 2015, 01:17:42 PM
I would have to switch from WPF to support it on other operating systems, but it doesn't seem too bad to switch to Windows Forms or GTK#.
Gah, now that I looked at the WPF page (http://www.mono-project.com/docs/gui/wpf/) I see you're correct, it's not supported.
I don't want to stall your project or put any unnecessary pressure just because a handful of users might benefit from the switch from WPF to GTK, so do as you see fit.

On topic - do you have any GUI plans or wireframes?
Also what about the physical attributes of the tiles? Does one have to first draw the level and then draw the physmap?
Title: Re: ROM Hacking?
Post by: Commando125 on December 11, 2015, 07:04:52 AM
Not sure what my GUI plan is or what the physmap editor will be like. I converted the program to C# with WinForms though.

(http://i.imgur.com/0agcW6a.png)
(http://i.imgur.com/Hffz2uW.png)
Title: Re: ROM Hacking?
Post by: Naulahauta on December 11, 2015, 07:21:24 AM
Looks pretty nice! Can levels be exported/imported?

Also – someone on /vr/ said they'd be happy to contribute to the GitHub project and maybe even port it.
(http://i.imgur.com/srF58Go.png)
Title: Re: ROM Hacking?
Post by: Commando125 on December 11, 2015, 01:47:35 PM
Not yet. It shouldn't be hard to do though. I'm going to make a TODO list on what to do on the editor. I will also need more information on the objects/enemies; seems to be lacking. Will keep you updated.

(http://media.giphy.com/media/wQaM4YQbJGiiY/giphy.gif)

EDIT: Added a tile selector. Doesn't modify level yet.
(http://i.imgur.com/oEfjdaW.png)
Title: Re: ROM Hacking?
Post by: Naulahauta on December 15, 2015, 09:10:48 AM
What's the tile selector used for?
I don't think selecting a single tile for "painting" the level with is that fun because the tiles are so small. If you've tried out Lunar Magic, its multi-tile selector (select area with left mouse button, paste with the right one) is very intuitive to use, but then again these are two very different games.
Title: Re: ROM Hacking?
Post by: Commando125 on December 15, 2015, 02:56:08 PM
Super Mario World has "objects" with a length and width. Umihara Kawase doesn't have that, its two bytes per 8 pixel by 8 pixel tile. Can you tell me a bit about the multi-tile selector? Might be possible. I can probably zoom in the tile selector and level editor by 2x to fix the small tiles, but I would have to add scroll wheels on the right and bottom sides.
Title: Re: ROM Hacking?
Post by: Naulahauta on December 15, 2015, 05:24:14 PM
I know, but SMW also has "map16 blocks" which are essentially 16x16 equivalents for SMW to what these 8x8 tiles are in Umihara Kawase.

I made a quick and dirty demo in After Effects to show what I mean.
VIDEO LINK (https://dl.dropboxusercontent.com/u/152153442/demo.mp4)

The animation seems a bit fast, now that I look at it.. but ehh, you probably get the point.

• Dragging the mouse on-level shows instant preview of what it would look like if placed.
• Air tiles act as "transparent" (maybe this could be changed on context?)

Left click: select tile
Left hold: select area
Right click: paste tile/tile cluster
Right hold: "paint" with tile or tile cluster
Wheel click: de-select

This is how Lunar Magic handles its map16 tiles iirc, and it's a very robust method of making large complex shapes from smaller pieces.
Title: Re: ROM Hacking?
Post by: Commando125 on December 15, 2015, 07:26:35 PM
That was a well-made demo. After I get some free time, I will see what I can do.
Title: Re: ROM Hacking?
Post by: Commando125 on December 22, 2015, 09:37:28 PM
I got level tile pasting to work in-game, but no "map16 blocks" feature yet. Adding the map16 feature might require a small rewrite and a bit of work. Tried to reorganize the GUI a bit, but I might zoom the tileset by 2x and reorganize it back to how it looked originally (I keep clicking level by mistake instead of palette), but with the tileset zoomed in.

Next month, I might have less time on this project due to professional work.

(http://i.imgur.com/1pb6D3U.png)
(http://i.imgur.com/QKtbA8F.png)
Title: Re: ROM Hacking?
Post by: KawaseFan on December 23, 2015, 09:57:12 AM
Nice work, much appreciated that you've spent your time on this.
Title: Re: ROM Hacking?
Post by: Naulahauta on December 23, 2015, 11:08:55 AM
I'm with KawaseFan. It's fantastic to see such sporadic progress and the fact that you went the GitHub route makes the project even more appealing.

Good job! Do you have Paypal or something?
Title: Re: ROM Hacking?
Post by: badlose on December 24, 2015, 02:45:53 AM
Awesome work! CARRY ON!
Title: Re: ROM Hacking?
Post by: mfgreth on December 26, 2015, 04:22:04 PM
I've been away for so long, and I come back to all this. This thread is magic. You are all magic.
Title: Re: ROM Hacking?
Post by: Commando125 on December 31, 2015, 05:08:22 AM
I was able to add multi-tile selecting for the level tiles and tile painting for tileset tiles. I'm having issues with highlighting the selected tiles, but it seems to work non-visually.

I'm also looking for ideas on what the physmap editor should look like. I'm open to suggestions.
Title: Re: ROM Hacking?
Post by: matt on December 31, 2015, 02:34:40 PM
Awesome work so far, consider me excited and subscribed!
Title: Re: ROM Hacking?
Post by: Commando125 on January 02, 2016, 08:56:29 AM
(http://i.imgur.com/2F4v4ly.png) (http://i.imgur.com/j9HrU1b.png)

Level tile highlighting. I want to start work on the physmap editor now. I'm sure of what bits represent the physical properties of each tile, so I will have to research it.
Title: Re: ROM Hacking?
Post by: Naulahauta on January 03, 2016, 10:41:02 AM
How many different physmap attributes are there?
I can make a mockup if you can confirm the exact amount (and type) of physical tile attributes.

Right now I can only think of 16 types of walkable slopes, 1 type of solid, 2(?) types of bird landing spots, 1 type of  spawn-safe zone and 1 type of spikes and 34 different conveyor setups (16 clockwise slopes, 16 counter-clockwise slopes and solids for both directions)
Title: Re: ROM Hacking?
Post by: Commando125 on January 03, 2016, 11:23:46 AM
Here is what I have so far using my editor to read the physical properties of a selected tile. I'm starting to think that the physmap tiles can also be used to locate where doors are (there is a number 1 where you open the door), where ladders are (there is a number 1 where you can grip the ladder), where spikes are (by checking if the tile above a solid tile is a spike tile), and where objects and enemies are according to their type in the level header (I have seen tiles numbered 2 to 7 where umihara and the objects/enemies are, including a number 1 tile alongside the right of them (to determine facing?)). Use this editor link if you want to find out what tiles are what: https://www.dropbox.com/s/yavaz3uehvf0j5h/riverback_physprop.zip?dl=0.  Make a backup of your rom before using, since it auto-expands the rom on save (to fit more data). It cannot edit physmaps yet, but it can edit tilemaps and it will help display what a tile's physmap value is. If you want to edit phystiles in emulator RAM, look in $7E4000 - $7E51FF (there are four rows of tiles above and below the level). Expect bugs. Also, do not open a rom that isn't an Umihara Kawase headerless rom. If the program throws an exception, you have the wrong rom.

PHYS TILE PROPERTIES:
    $00: 0000 0000: Air
    $01: 0000 0001: Ladder (Left edge), Door?
    $02 - $07: Object placement? From enemy types in level header?
    $39: 0011 1001: Spike?
    $3A: 0011 1010: Spike?
    $40: 0100 0000: Solid
    $41: 0100 0001: Spike? Ice?
    $42: 0100 0010: Spike?
    $45: 0100 0101: Escalator left
    $47: 0100 0111: Escalator right
    $80: 1000 0000: Solid slope bottom-right: low
    $81: 1000 0001: Ice slope bottom-right: low
    $87: 1000 0111: Escalator slope bottom-right: low
    $88: 1000 1000: Solid slope bottom-right: high
    $89: 1000 1001: Ice slope bottom-right: high
    $8F: 1000 1111: Escalator slope bottom-right: high
    $90: 1001 0000: Solid slope bottom-left: low
    $91: 1001 0001: Ice slope bottom-left: low
    $98: 1001 1000: Solid slope bottom-left: high
    $99: 1001 1001: Ice slope bottom-left: high
    $A0: 1010 0000: Solid slope top-right: low
    $A8: 1010 1000: Solid slope top-right: high
    $B0: 1010 0000: Solid slope top-left: low
    $B7: 1011 0111: Escalator slope top-left: low
    $B8: 1011 1000: Solid slope top-left: high
    $BF: 1011 1111: Escalator slope top-left: high
   
    SRVH hEeI
   
    S: slope (solid if s = 1 , even if S = 0)
    R: reacts to environment? (tilemap tiles above it, or on it?) (ladder, door, spike, ice?)
    V: v-flip for slopes
    H: h-flip for slopes
    h: slope height (0 = low, 1 = high)
    E: escalator (solid if E = 1, even if S = 0)
    e: escalator direction (0 = left, 1 = right)
    I: ice? spike?
Title: Re: ROM Hacking?
Post by: Naulahauta on January 03, 2016, 08:35:51 PM
Very interesting.
I ripped ZST Save States of each level back in the day, and because ZSTs are simply a frozen piece of what's loaded to the RAM at the moment, the physmap is also there. I compared these ZST-physmaps to the physmaps that your editor shows and there's some strangeness:

The physmaps in the ZSTs are 72 rows, while your editor shows only 64 rows. Which one is correct?
(https://dl.dropboxusercontent.com/u/152153442/UmiPhys.png)
ˆ I pasted the ZST's bytes over the level map. It's almost exactly like your editor shows the bytes but, for example, your ladders are "01 00" while the ZST's ones are "01 03". Also, the trajectory of the rising platforms is a bunch of "03 03 03 03" 's in the ZST, but "07 00 03 07" and "06 00 03 07" in your editor.

Because can't trust my ZSTs, I can't just copy every byte in the physmap, paste them over the level in Photoshop and write the different Phys Props down whenever I see a new one. Although your editor displays them probably the right way, it would take forever to click on a tile, write its phys prop down, click on the next one, etc.

But anyway, once we know for certain exactly what each byte does, this should be easy. I just need a reliable way to get the raw byte dumps of the physmaps so I can make direct comparisons and figure out what tiles are what.

As for the User Interface, here's my plan. VIDEO LINK (https://dl.dropboxusercontent.com/u/152153442/RiverBack2.mp4). Again it's a bit shoddy vid at parts but you probably get the point – the physmap editor would work exactly the way the field editor does, but with its own separate annotated pictogram set with physical tile representations from $00 to $FF. In the video, it's obviously unfinished, but filling them all should prove trivial if they're bitwise anyway.
One could also be able to simultaneously edit or view the physmap and the field, or just the other.
I'm not sure how to implement it but I thought maybe adding a raw access method to the bytes could be useful too, but it's shown only briefly.
I also added a grid and a new field, the scratchpad, where the user could construct their own tile/phys arrangements for easy access and without polluting the level itself.

A couple of other suggestions, some probably already a work in progress but anyway:
• Add hotkeys to number keys 1 and 2 for previous palette and next palette.
• Add hotkeys to up/down and left/right for tile (and tile cluster too) flipping accordingly.
• Now that the air tiles are 'transparent', erasing large structures becomes a chore because I can't simply copy a cluster of 'air' and paint over stuff with it
• Add undo

Lastly, I'm sure these are probably obvious bugs/not features yet, but just to make sure these aren't Mono-specific issues:
• Nothing updates until I let go of my right/left button. When I drag the area I wish to select, I see the light box over the area only when I let go of the left button.
• When I try to paint over the level with a tile cluster selected, it only lays down it once even if I hold the right button. Continuous paint with a single tile works well though.
• When I've selected the cluster, moving around doesn't give a preview of how it will look, so I have to commit the cluster to see how it looks in all cases.
• I got a crash when I entered things I shouldn't have entered to the "Palette" field.


Otherwise a solid job – really really looking forward to this.

EDIT: wow that wasn't very coherent at all. I think I might need some sleep, but I'll get back on this later. Happy new year!
Title: Re: ROM Hacking?
Post by: Commando125 on January 04, 2016, 06:04:37 AM
Quote
The physmaps in the ZSTs are 72 rows, while your editor shows only 64 rows. Which one is correct?
The 64 rows is correct. The game adds 4 hardcoded rows on the top and bottom that mirror the top and bottom edges of the level respectively.

Quote
It's almost exactly like your editor shows the bytes but, for example, your ladders are "01 00" while the ZST's ones are "01 03". Also, the trajectory of the rising platforms is a bunch of "03 03 03 03" 's in the ZST, but "07 00 03 07" and "06 00 03 07" in your editor.
I am confident that the physmap tile values shown are correct. I have seen the game modify the tilemap tiles after the data was decompressed to RAM. It might be modifying the physmap tiles too.

Quote
I just need a reliable way to get the raw byte dumps of the physmaps so I can make direct comparisons and figure out what tiles are what.
For one reliable way, set a write breakpoint at $7E5200 and copy the tiles from $7E4000 - $7E51FF in RAM to a new file via hex editing. If you need level exporting right now, it shouldn't be much trouble to put in.

Quote
As for the User Interface, here's my plan. VIDEO LINK. Again it's a bit shoddy vid at parts but you probably get the point – the physmap editor would work exactly the way the field editor does, but with its own separate annotated pictogram set with physical tile representations from $00 to $FF.
I'm liking that interface. Well done on that video. It presents your ideas well.

Quote
I'm not sure how to implement it but I thought maybe adding a raw access method to the bytes could be useful too, but it's shown only briefly.
For tilemap editing, I see no point in raw byte access. All the tiles that can possibly be selected are in the tileset canvas. For physmap editing, I can see a use for raw byte editing, but the physmap tileset idea you had would make that use not very useful since I could select any tile I wanted from there.

Quote
I also added a grid and a new field, the scratchpad, where the user could construct their own tile/phys arrangements for easy access and without polluting the level itself.
The grid should be no trouble to add. I really want a scratchpad too, but implementing a scratch pad would take some work. I would have to treat the scratchpad, in the way I'm currently programming this, as a second level to paste tiles on. Also, the scratchpad would have to be cleared each level because each level has a different tileset arrangement.

Quote
Add hotkeys
I can do that with no problems.

Quote
Now that the air tiles are 'transparent', erasing large structures becomes a chore because I can't simply copy a cluster of 'air' and paint over stuff with it
I can either make air copyable or un-copyable. Each choice would have different strengths and weaknesses. Un-copyable air can help place structures in the level that have air around it, such as trees and ramps, but any air that you actually want there you would have to draw over by selecting the air tile in the tileset panel. Copyable air can make erasing easy, but makes it harder to place structures /w air around it because then you have to draw on the air that you don't want, which would take more work than having it transparent. I can make this option toggleable if you want.

Quote
Add undo
This is nice to have, since pasting a tile cluster that you don't want over your work can be devastating, but requires more work than you think since you have to think of every case that the user can undo from and how to store past actions from the user as well as the data from before. It isn't too high on my priority list yet.

Quote
Nothing updates until I let go of my right/left button. When I drag the area I wish to select, I see the light box over the area only when I let go of the left button.
This was intended because I am currently unsure of how to highlight tiles while the mouse cursor is being moved.

Quote
When I try to paint over the level with a tile cluster selected, it only lays down it once even if I hold the right button.
I thought about allowing this, but I can't see many use cases for it except for copying tile clusters with one tile value faster. It is too easy to accidentally drag your mouse when pasting with a cluster and then screw up your work.

Quote
When I've selected the cluster, moving around doesn't give a preview of how it will look, so I have to commit the cluster to see how it looks in all cases.
I am currently unsure of how to draw tile clusters on the level while the mouse cursor is being moved. Right now, the level editor can only redraw tiles that it has stored in the level itself. Having to draw tile clusters without modifying the level can cause some redrawing issues such as tiles being missed to redraw.

Quote
I got a crash when I entered things I shouldn't have entered to the "Palette" field.
The accepted palette value inputs are probably out of range. I will look into that.

Thanks for your input.  :) It gives me ideas on what to do with the editor. Let me know if you need something or if you find valuable information.









Title: Re: ROM Hacking?
Post by: Naulahauta on January 05, 2016, 09:54:31 AM
Thanks for the thorough replies. What I forgot to show in the video is that if you've enabled simulatenous physmap and tilemap editing and wish to work with tiles instead of tile clusters, you would have to pick both, the tile from the tileset and a pictogram from the physset. Selecting a new tile would still keep the phys prop selection, and vice-versa.

I'll look into the physmaps when I have some time. Using a breakpoint-enabled emulator is a chore because I'm on a Mac, but if I virtualise/use WINE I can probably make Geiger's SNES9X debugger work.

For the Undos, you said:
Quote
every case that the user can undo from and how to store past actions from the user as well as the data from before

Maybe I'm not thinking this through but in my opinion the only cases where the user can (or needs to) undo from are accidental tile (or tile cluster) painting operations.
Maybe the workflow could be so that every time you paint a tile or a cluster, a history state is added to an invisible "undo stack" xml file (or in the computer's RAM I guess) that stores a {old/new/how} message per row.

• If you select a 3×2 cluster from any point in the level, starting from the top left corner, that contains the tiles 00 03, 00 03, 10 03, 10 03, 00 03, 01 03 with the physprops 00, 00, 01, 01, 00, 00 and paint it over the level's coordinates x:8 y:14, the program would, before overwriting the section, store the original tiles you're destroying as variable old. Because your selection was 3×2, it would know to read three columns and two rows, from left to right (because the selection was made from the top left). If the original tiles were 20 03, 20 03, 20 03, 20 03, 20 03, 20 03 with the physprops 81, 81, 81, 40, 40, 40, the old variable would be 200320032003200320032003-818181404040. And as you click, the changes are made, the tile cluster is painted over, and the new variable is added as the undo stack's current row's other pair. The stack would have one row now, which is:
old:200320032003200320032003-818181404040\new:000300031003100300030103-000001010000\8-14-topleft-3x2

If the user were to push Undo after that, the program would paste the latest row's old bytes as a 3×2 cluster, to coordinates x:8 y:14, and row would be discarded (not deleted because Redo is cool too).
For single tile painting operations the format could be different, with simply the first variable being "what tile with what physprop" and after that, a stream of "x, y, what tile and physprop used to be here" value pairs.

Note: I am not a programmer so I don't know if this is efficient or wise or makes sense. It's just what I envisioned.
Title: Re: ROM Hacking?
Post by: Commando125 on January 05, 2016, 01:36:54 PM
Quote
What I forgot to show in the video is that if you've enabled simulatenous physmap and tilemap editing and wish to work with tiles instead of tile clusters, you would have to pick both, the tile from the tileset and a pictogram from the physset. Selecting a new tile would still keep the phys prop selection, and vice-versa.

I can make an undo for the last tile cluster pasted. Having undo for just single-tile pasting wouldn't be as painful to fix.

Quote
Using a breakpoint-enabled emulator is a chore because I'm on a Mac, but if I virtualise/use WINE I can probably make Geiger's SNES9X debugger work.

Try this one out on WINE: https://www.dropbox.com/s/2p7xtnpwpqhp0xx/bsnes-plus-r161.zip?dl=0. That is the emulator I used to reverse engineer the compression/decompression algorithm, AND it allows you to edit the RAM in-game.

I added a quick function to Riverback to save (and write the physmap to level) the physmap in the file menu: https://www.dropbox.com/s/yavaz3uehvf0j5h/riverback_physprop.zip?dl=0. Use it to help you find out what those physmap tiles mean.
Title: Re: ROM Hacking?
Post by: Naulahauta on January 06, 2016, 05:18:15 PM
Thanks, that editor is really helpful. I've done some research and here's some conclusions:

////////
Physmap bytes:
• 00: Air

• 01**: always a word where the first byte implies that an action will happen when the player pushes up and the second byte implies what the action is:
Where ** is:
00: climb a ladder
01: enter first door
02: enter second door
03: enter third door
04: enter fourth door
05-FF: the game will crash
NOTE: There can also be only one door instance (0101 or 0102 etc.) per level or the game will crash.

• 02** and 03**: always a word where the first byte implies direction and the second byte implies sprite number (up until 06).
02: sprite is facing left
03: sprite is facing right
Where ** is:
00: Player starting position (There can only be one. If there's two instances of 0200 or 0300, the game will crash)
01: sprite 1
02: sprite 2
03: sprite 3
04: sprite 4
05: sprite 5
06: sprite 6

• 03 07: Spawn-safe area. Enemies killed cannot respawn here. (special case, has nothing to do with sprites or facing left or right)

04: ?

05: If the field's sprite 05 is a bird, they can land in this spot.
06: If the field's sprite 06 is a bird, they can land in this spot.
It would be wise to remember that if you use birds in your levels, set them to slots 05 or 06. Setting them to 02 and 03 will cause a conflict and the game will crash.
////////

What bothers me, though, is the fact that in some levels 41 is a spiky solid, but in some levels it's a slippery solid. It appears that there can't be one-size-fits-all pictogram set, because the meaning of the physprops changes between levels.
It seems that conveyors and glass are exclusive.. you can't have both in the same level, at least by normal means.

There are the 14 still unknown bytes in the level headers (http://ndirt.com/umihara/doku.php?id=datastructures:start#level_header). I looked at them and they're definitely related. Fields 24, 35, 42, 33, 23 and 28 are the only ones that have glass surfaces on them. Here's their 14 unknowns:
field 24: 3C B4 5A 78 00 00 00 00 2A 00 00 0B 30 10
field 35: 3C B4 00 00 00 00 00 00 2A 00 00 00 00 10
field 42: 00 00 00 00 00 00 00 00 2A 00 00 00 00 00
field 33: 3C C8 50 8C 00 00 00 00 2A 00 00 00 00 00
field 23: 3C 78 78 3C 00 00 00 00 2A 00 00 00 00 00
field 28: 00 00 50 B4 00 00 00 00 2A 29 2B 00 00 33


These 14-byte arrays are also the only ones that contain 2A at that specific spot. I turned the 2A to 00 on field 23 and that successfully disabled the slippery surfaces and made them grabbable.

It appears that some features like spikes, conveyors, moving platforms(?) and the hanging bridges(?) must be enabled per each level by doing something to these bytes.

To reiterate, here's the unknowns of all levels with conveyor belts (emphasis added):
field 00: 3C 64 28 64 00 00 00 00 00 00 00 00 00 00
field 01: 3C 64 00 00 00 00 00 00 00 00 00 00 06 05
field 18: 3C DC 00 00 50 B4 00 00 29 00 00 00 07 05
field 43: 3C 64 28 64 00 00 00 00 00 00 00 00 00 04
field 49: 00 00 00 00 00 00 00 00 00 00 00 28 04 05


It could be that 00 sets up conveyors, maybe. Field 18 is different because it's the only level in the game that has conveyors and spikes.
Title: Re: ROM Hacking?
Post by: Commando125 on January 06, 2016, 06:06:03 PM
Great work on those finds! That really helps us with figuring this out. I was wondering if you can think of what tile should be what graphic for the physmaps? Or should they just be displayed as bytes?
Title: Re: ROM Hacking?
Post by: Naulahauta on January 06, 2016, 06:42:30 PM
I started drawing the pictograms just today, if that's what you mean. I haven't finished them yet but there's two sets, a typical 8x8 set and a higher resolution one in case a zoom function gets implemented.
(https://dl.dropboxusercontent.com/u/152153442/lo.png)
(https://dl.dropboxusercontent.com/u/152153442/hi.png)
Title: Re: ROM Hacking?
Post by: Commando125 on January 06, 2016, 07:40:43 PM
Can you draw the 8x8 one at 1x zoom and rid the grid lines? I can add the grid lines at runtime.
Title: Re: ROM Hacking?
Post by: Naulahauta on January 06, 2016, 08:16:30 PM
Sure thing. Here you go.
(https://dl.dropboxusercontent.com/u/152153442/pictograms.png)

It's still missing many pieces and I'm not sure how to represent the 01** 02** 03** parts though. I'll figure something out.
Title: Re: ROM Hacking?
Post by: Commando125 on January 06, 2016, 08:42:02 PM
Thanks. That helps a lot. I never implemented drawing from a tile graphic that's from a .PNG tileset yet. Only from SNES graphic data. It will take a while to add that in. I will start working on it after I search for a short-term lease apartment. If you want byte tiles displayed, you might want to add that too, since there are tiles missing. Make sure the font is legible. Always make byte 0 clear, not 00 like in the video. I think it's easier to see without 00 everywhere. If you don't want to do the byte tiles, I can take a shot at it.

P.S. You probably want to go with a 3x7 font for each digit if you do the byte tiles.
Title: Re: ROM Hacking?
Post by: Naulahauta on January 06, 2016, 09:40:45 PM
3x6 will give some more space. :) Here you go
(https://dl.dropboxusercontent.com/u/152153442/bytes.png)
Title: Re: ROM Hacking?
Post by: Commando125 on January 08, 2016, 06:51:53 AM
It looks like you are doing the physmap tileset in vector graphics. Make sure to save the vector file. I decided that I need a 1x (8x8) version and a 2x (16x16) version. I can probably scale the 2x version down to 1x in the editor though.
Title: Re: ROM Hacking?
Post by: Naulahauta on January 08, 2016, 07:21:39 AM
That is true, but the fine detail is lost if I simply scale down the vector version to 8x8. It is easier for me to work in a vector environment with 8x8 tiles, and scale those tiles up to 16x16 and fix some details.
I'm not home right now but I'll send the stuff over as soon as I can. However, here's a 16x16 set of the bytes.
(https://dl.dropboxusercontent.com/u/152153442/bytes2x.png)
Title: Re: ROM Hacking?
Post by: Commando125 on January 10, 2016, 07:03:45 PM
Hey. I reformatted some code around to make life easier later. I'm going to look at some apartments today, but I definitely want to work on the editor later. Work on the pictograms if you can. I would represent 1-7 as just a large bold number without the 0 digit. (make it stand out maybe from other byte numbers?).

Do you have a specific order in which you want the editor features done?
Title: Re: ROM Hacking?
Post by: Naulahauta on January 11, 2016, 07:17:51 AM
While you're right, the fact that you must always have a byte from 00 to 04 after 01, a byte from 00 to 06 after 02 or 03 (except in the special case of 0307) and that there can only be one 0200 or 0300 per level has to be emphasised strongly. This, and the fact that some unknown byte combinations can easily crash the game. This is the best I came up with:

(http://i.imgur.com/uFsQcXX.png)
While not a tileset, it's a word-set. You read two-byte columns. The first 16x8 column is empty because 00**s aren't special. The second column has representations for ladders (0100) and door exits (0101, 0102, 0103 and 0104).
The third column represents the 02** words like the starting position and the sprite numbers and their initial directions, and the fourth column, the 03**s is identical but with the added special spawn-safe pictogram for 0307.

Whenever the editor detects that there's a tile 01 02 03, it checks the byte next to it and uses this other tileset accordingly.

I wouldn't also mind a status bar/messages/console to the bottom of the editor that has warnings like "Multiple starting points detected. Expect crash" or "01FB detected at line 13. Expect crash" or something.

Quote
Do you have a specific order in which you want the editor features done?
Not really. I don't really know what's the easiest for you to implement first and I want you to be comfortable with them.

Here's the standard pictogram set with the added 01-07 as well.
(http://i.imgur.com/KbHGSSV.png)


Hope you find a nice apartment!
Title: Re: ROM Hacking?
Post by: Commando125 on January 11, 2016, 08:09:23 AM
I like that word-set idea. Would definitely help in telling what is what in the physmap editor. I'll add a status bar at the bottom, but I don't know what messages it will display yet.
Title: Re: ROM Hacking?
Post by: Naulahauta on January 11, 2016, 04:03:30 PM
That's great. Also, now that I think of it, maybe the program could even prevent you from saving if it detects two starting points (evidently a guaranteed crash)?

One last thing: for debugging purposes could you add a "export all tilemaps" and "export all physmaps" function?
Title: Re: ROM Hacking?
Post by: Commando125 on January 15, 2016, 10:27:02 PM
Here is something that you can play around with. No physmap editing/display yet. It has level export and import, grid display, and the byte checkbox does something. I did not fully test export/import, but it seems to work when I imported an exported level 4 to level 1.

https://www.dropbox.com/s/ych8gdwesv9o8xd/Riverback_LevelExportTest.zip?dl=0

For exported level offsets:
0x00: Checksum
0x0B: Header
0x30: Physmap
0x1030: Tilemap
0x3030 - 0x3031: Tile index amount
0x3032: Tile indexes
0x3132: Last 6 bytes of palette indexes
Title: Re: ROM Hacking?
Post by: Commando125 on January 16, 2016, 03:38:02 AM
Does this seem correct so far? I can always change how it displays. I also need the wordtiles updated with anything you can find out. Please number the word bytes too (00 01, 00 02, etc.), even if it doesn't represent an object.

(http://i.imgur.com/SknPCKj.png) (http://i.imgur.com/GXD1u03.png)

Edit: Made a mistake. Reuploaded new image.
Title: Re: ROM Hacking?
Post by: Commando125 on January 16, 2016, 08:55:59 AM
I made a test version that allows drawing and placing phys tiles, but there are minor graphic errors in the grid. I was able to draw a ladder and the phys props for the ladder and use it in game. I also moved a door somewhere else and it worked. There are no warnings yet when saving the ROM with bad phystiles or when opening a ROM that isn't a Umihara Kawase rom. I blame my friends playing Dragons Dogma for making me want to work on this a lot today, because I can't even run that game and they never shut up about it.

https://www.dropbox.com/s/uqs1vlto48yvz91/Riverback_phystiles_test.zip?dl=0
Title: Re: ROM Hacking?
Post by: Naulahauta on January 16, 2016, 02:25:23 PM
Thanks! I updated the wordmap and the physmap.
I still haven't figured out why some levels substitute some phystiles for others, but here's a list of conflicts (I'm talking about the numbers shown in your editor, not actual field numbers):
• Clockwise conveyors sometimes mean "Boss will start attacking you" -tiles (Level 63 and 61). A mystery in level 4.
• Ice solids sometimes mean spikes (Level 12, 15 and 20, many others)
• Ice and spikes can still coexist, like in Level 52

(https://dl.dropboxusercontent.com/u/152153442/pictograms-01.png)
(https://dl.dropboxusercontent.com/u/152153442/pictograms%402x-01.png)

(https://dl.dropboxusercontent.com/u/152153442/words.png)


The new User Interface is really sleek now! Good job.
Title: Re: ROM Hacking?
Post by: Commando125 on January 17, 2016, 12:52:42 AM
I was thinking. How are people going to figure out what makes up a word tile?

I have seen some weird things with those phystiles, such as 5 for bird spots instead of 6 and spike tiles having different values in each level. I think I'm going to make the header and tile index editors before moving onto word tiles. Maybe we can figure out what the inconsistencies mean with the header displayed per level. They are needed more than word tile displays.
Title: Re: ROM Hacking?
Post by: Naulahauta on January 17, 2016, 11:22:12 AM
A well-written readme will do. If that's not enough, I'm willing to do an annotated video tutorial on how to use the editor.

A 05 alone is always a bird landing spot if the level's sprite slot #05 is a bird.
A 06 alone is always a bird landing spot if the level's sprite slot #06 is a bird.

A 04 alone can mean a platform trajectory, but birds have to be assigned to slot #05 or #06.
A 05 alone can mean a platform trajectory, but birds have to be assigned to slot #06 (maybe #04 too).
A 06 alone can mean a platform trajectory, but birds have to be assigned to slot #05.
A 07 alone can mean a platform trajectory, but birds have to be assigned to slot #05.
Bytes 04, 05, 06, and 07 can be used all in the same level for platform trajectory assignments, but that means no birds or little fishes.
Furthermore, bytes 04, 05, 06, or 07 define the "X" sprite that appears on top of the boss door.

Title: Re: ROM Hacking?
Post by: Commando125 on January 17, 2016, 11:54:56 AM
Interesting finds. Here is something I am working on. It allows you to select what field tiles to use in the tileset. There are a couple levels that have less than 15 tiles remaining, and I originally thought the max selected tile index limit is 497 (0x1F1). I'm curious on how a couple levels (Level 22, Level 46 (the upside down field 1)) can get away with more than 0x1F1 tiles selected. I'm also wondering why byte 8 can be a bridge platform or it can be the moving small platforms into the spikes in field 15 (and other fields).

(http://i.imgur.com/z3Dsnfy.png)

(http://i.imgur.com/V9mXLYt.png)
(http://i.imgur.com/fZ7xZtL.png)
Title: Re: ROM Hacking?
Post by: Commando125 on January 18, 2016, 05:46:04 AM
The tile index editor is finished. I shifted some tile indices around and the results look like the ones in the editor. I am going to move on to the header editor.

(http://i.imgur.com/SFb7ZhK.png) (http://i.imgur.com/rt6087L.png)
Title: Re: ROM Hacking?
Post by: Commando125 on January 18, 2016, 12:50:32 PM
This version will allow you to edit parts of the level header. Let me know if you find anything out; I'm probably going to take a short break. Expect bugs.

https://www.dropbox.com/s/45e3d7s6uv57p6t/Riverback_headertest2.zip?dl=0
Title: Re: ROM Hacking?
Post by: Commando125 on January 19, 2016, 08:21:55 AM
I'm going to review the unknown header data for each level. Maybe I can figure something out. I'll just post findings in this post until you reply.

(http://i.imgur.com/O3dRbi1.png)

Findings:

Header bytes $14-$1A seem to be object types for tiles $01-$07. It seems to affect tiles $40-$47 for moving/death/ice, maybe $39-3F.

There is an inconsistency in that wiki you linked me, where $1C is water height. Water height is actually 2 bytes, from $1B to $1C. $1C is always set to 1, because if it is 0, the water takes up half the level height and disappears when you are below the wave line.

Tile 45 seems like a faster escalator than tile 47.
Title: Re: ROM Hacking?
Post by: Naulahauta on January 19, 2016, 09:35:46 AM
Header bytes $14-$1A seem to be object types for tiles $01-$07. It seems to affect tiles $40-$47 for moving/death/ice, maybe $39-3F.

DUDE

DUDE

This might be the final piece of the puzzle! It seems so obvious now.

The next few weeks are going to be somewhat busy for me but I'll try to squeeze in some time to look into these bytes too.

If we can figure out what bytes correspond to what kind of tiles, there isn't really anything stopping us from doing something that one would consider "a full hack"

A few things I've forgot to mention/ask, though:
• Do you know where the demo level data is stored and where the demo movement comes from?
• How trivial would it be to implement a title screen/game over/credits editor? I know the title screen/game over format but I don't know where the credits are...
• I have the "Starting amount of lives" and "30 minute rule on/off" -offsets written down somewhere. They would be a nice addition too, I'll let you know asap.
Title: Re: ROM Hacking?
Post by: Commando125 on January 19, 2016, 09:53:50 AM
I think the demo level is an actual level, but I'm not sure where the demo movement is.
The title screen and game over backgrounds are easy to edit and I think they are not compressed. Not sure about the giant game over fish.
Editing the credits would require finding the text of the people in the credits and changing it from there.
Starting lives are stored in $7E025A. Not sure what the 30 minute rule is.

Tiles $0C - $13 seem like 16-bit words for something. When I change it before loading a level, it seems to do nothing. Definitely seems different from the other 7 bytes.

I'm going to be starting work next week, so I might have less time, but I should get free time when at home. Finding out what each object byte is will save some work, but explaining what each one is in the editor might be an issue. If you edit the header, make sure to click "Apply Changes" before you save the level.

https://www.dropbox.com/s/b1rw7j2iwdpcrfb/Riverback_headertest3.zip?dl=0

Title: Re: ROM Hacking?
Post by: Commando125 on January 19, 2016, 03:57:32 PM
Theses are all the object values I seen in all the level headers, all in hexadecimal. The other values you shouldn't need to worry about because they are unused.

0x00, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0B, 0x0C, 0x0E, 0x0F, 0x10, 0x11, 0x18, 0x19, 0x20, 0x21, 0x22, 0x26, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B

Those 2-byte words in the header I talked about:
0x0000, 0x14FF, 0x1E96, 0x1EA0, 0x1EB4, 0x2864, 0x2896, 0x28B4, 0x3278, 0x328C, 0x32B4, 0x32DC, 0x3C64, 0x3C78, 0x3C96, 0x3CA0, 0x3CB4, 0x3CC8, 0x3CDC, 0x4650, 0x5046, 0x5050, 0x5064, 0x5078, 0x508C, 0x5096, 0x50A0, 0x50B4, 0x5A78, 0x6428, 0x6464, 0x648C, 0x783C, 0x7864, 0x7878

enemy values:
0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0D, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x1C, 0x1F, 0x21, 0x2F, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D
Title: Re: ROM Hacking?
Post by: Naulahauta on January 19, 2016, 04:30:00 PM
How are you sure those are all?
And most importantly, what do they stand for?
Title: Re: ROM Hacking?
Post by: Commando125 on January 19, 2016, 04:36:46 PM
I checked the header of each level and wrote them all down. Then I sorted the data of object values, enemy values, and 16-bit words, and sorted the lists, then removed duplicate elements.

The first set is for objects such as pillars, escalators, ice, spikes, etc. (Bottom row of 7 unknowns)

The second set I don't know. (Top row of 8 unknowns)

The third set is for enemies such as fish, bosses, salamanders, Umihara, and backpacks  (Labeled in header editor)

For object values, there are 7 spots it can go in. Each spot I think affects tiles $01-$07, $39-3F, $41-47 respectively.

I'm going to work on the enemies first.

object values:
0x00: nothing
0x04: escalator slow right. animates palette 7.
0x05: escalator slow left.
0x06: escalator fast right
0x07: causes death
0x08: rising platform series (bank 0)
0x09: falling platform series (bank 0)
0x0B: pullable/moveable wall
0x0C: door
0x0E: downward pillar
0x0F: upward pillar
0x10: pop-out ceiling tile
0x11: pop-out ground tile
0x18: bridge piece
0x19: bridge piece. collapses when touched.
0x20: single platform (bank 0, white)
0x21: single platform (bank 0, blue)
0x22: waves can push you on platform $41-$47. slippery.
0x26: rising platform series (bank 0, blue, way less frequent)
0x28: boss door barricade
0x29: causes death
0x2A: ice/glass
0x2B:
0x2C: rising platform series (bank 4)
0x2D: falling platform series (bank 4)
0x2E: rising spiked platform series (bank 4)
0x2F: falling spiked platform series (bank 4)
0x30: rising platform series (bank 2)
0x31: falling platform series (bank 2)
0x32: rising spiked platform series (bank 2)
0x33: falling spiked platform series (bank 2)
0x34: single platform (bank 1)
0x35: single platform (bank 5)
0x36: rising platform series (bank 1)
0x37: falling platform series (bank 1)
0x38: single platform (bank 6)
0x39: single spiked platform (bank 6)
0x3A: rising platform series (bank 5)
0x3B: falling platform series (bank 5)

word values:
0x0000: nothing
0x14FF:
0x1E96:
0x1EA0:
0x1EB4:
0x2864:
0x2896:
0x28B4:
0x3278:
0x328C:
0x32B4:
0x32DC:
0x3C64:
0x3C78:
0x3C96:
0x3CA0:
0x3CB4:
0x3CC8:
0x3CDC:
0x4650:
0x5046:
0x5050:
0x5064:
0x5078:
0x508C:
0x5096:
0x50A0:
0x50B4:
0x5A78:
0x6428:
0x6464:
0x648C:
0x783C:
0x7864:
0x7878:

enemy values:
0x00: nothing
0x01: "Poof"-sprite, crashes alone
0x02: "Splash"-sprite, crashes alone
0x03: net spawner (byte before this is what's dropped)
0x04: goldfish
0x05: eel
0x06: flying clam
0x07: brown snail
0x08: bucket, type 1 (byte after this is what's spouted)
0x09: bucket, type 2 (byte after this is what's spouted)
0x0A: flying fish (for bucket)
0x0B: small fish (for bucket)
0x0C: UNUSED. Puffer fish.
0x0D: blue fish
0x0E: "Poof"-sprite, crashes alone.
0x0F: red egg-laying fish
0x10: shark (byte after is what's thrown)
0x11: shark bait, also can be on ceiling
0x12: giant tuna fish
0x13: squid (horizontal) (byte after this is what's spitted)
0x14: squid (vertical) (byte before this is what's spouted)
0x15: squid ink
0x16: tiny fish in water (decorative)
0x17: brown bird
0x18: blue bird
0x19: "Poof"-sprite, crashes alone
0x1A: "Poof"-sprite, crashes alone
0x0B: "Poof"-sprite, crashes alone
0x1C: barnacle (ground) (byte after this is what's spitted)
0x1D: UNUSED. barnacle (vertical) (byte after this is what's spitted)
0x1E: UNUSED. blue barnacle, spits cannonballs
0x1F: barnacle spark
0x20: UNUSED. blue barnacle
0x21: blue snail
0x22: UNUSED. octopus (identical?)
0x23: UNUSED. catfish
0x24: "Poof"-sprite, crashes alone
0x25: "Poof"-sprite, crashes alone
0x26: "Poof"-sprite, crashes alone
0x27: "Poof"-sprite, crashes alone
0x28: "Poof"-sprite, crashes alone
0x29: "Poof"-sprite, crashes alone
0x2A: "Poof"-sprite, crashes alone
0x2B: "Poof"-sprite, crashes alone
0x2C: "Poof"-sprite, crashes alone
0x2D: "Poof"-sprite, crashes alone
0x2E: "Poof"-sprite, crashes alone
0x2F: backpack (1-up)
0x30: giant tadpole (boss) (put 0x31 and 0x36 after this)
0x31: frog (for boss)
0x32: giant seahorse (boss, enemy #3) (put 0x33 and 0x35 before this, 0x34 after this)
0x33: vertical seahorse (for boss)
0x34: small seahorse (for boss)
0x35: giant ink (for boss)
0x36: frog egg? (for boss)
0x37: giant crab (boss) (put 0x38 and 0x3D after this)
0x38: crab's bubble (for boss)
0x39: tiger flying fish (boss) (put 0x3A after this)
0x3A: tiger flying fish second formation? (boss)
0x3B: flounder flying fish (boss) (put 0x3C after this)
0x3C: flounder flying fish second formation? (boss)
0x3D: crab's platform shrapnel (for boss)
0x3E: "Poof"-sprite, crashes alone
0x3F: "Poof"-sprite, crashes alone
Title: Re: ROM Hacking?
Post by: Naulahauta on January 19, 2016, 06:01:15 PM
The enemy bytes seem to correspond to what I figured out in the Wiki page (http://ndirt.com/umihara/doku.php?id=enemytypes:start). Check it out, there's unused enemies too!
Title: Re: ROM Hacking?
Post by: Commando125 on January 20, 2016, 06:08:06 AM
Didn't know about that. Thanks. I updated the enemy byte information. It is going to take a while to figure out the objects because using the wrong bytes when spawning objects crashes the game, so I have to check them one at a time under certain conditions.
Title: Re: ROM Hacking?
Post by: Commando125 on January 21, 2016, 02:38:21 PM
I think those 16 word bytes are affecting enemy spawn rates. I'm not sure why though.
Title: Re: ROM Hacking?
Post by: Commando125 on January 21, 2016, 03:54:26 PM
Ok, those four "word" bytes are enemy spawn rates for enemy types 0 to 3. Editing the value changes how often/little it spawns. I think we have enough to consider getting a ROM hack started. At least making some of the levels. We have 48 headers and levels to play with, which should be a fine amount. I can add custom graphics in the blank spots in the compressed graphics banks, edit title screen/game over, possibly hack in more levels/headers, and maybe edit credits if I can read japanese symbols.

https://www.dropbox.com/s/ifsn6tq740g6261/Riverback_v0_1_rc0.zip?dl=0
Title: Re: ROM Hacking?
Post by: Commando125 on January 23, 2016, 02:40:49 PM
I decided that I'm going to add keyboard shortcuts to the editor before I start. Once I find some free time. If you want a certain shortcut to be a certain keypress, let me know.
Title: Re: ROM Hacking?
Post by: Commando125 on January 30, 2016, 08:31:21 PM
@Naulahauta

How did you run the editor under a Mac? I noticed some graphic issues in the screenshots.
Title: Re: ROM Hacking?
Post by: Commando125 on January 31, 2016, 05:41:59 PM
Under compiling the editor for Mono under Linux kernel, There are some severe errors with the pictureBox sizes. If you use Linux, run this program in WINE.
Title: Re: ROM Hacking?
Post by: Commando125 on February 01, 2016, 06:16:12 AM
I fixed the PictureBox size bug in Linux's Mono, fixed a severe selection bug, and added a couple keyboard shortcuts.

https://www.dropbox.com/s/m084yi541t9kxlk/Riverback_v0_1_1.zip?dl=0
Title: Re: ROM Hacking?
Post by: Devyat on February 16, 2016, 04:56:35 AM
Is this project still alive?. I can't help you guys because both my english and my programming skills are pretty bad.
However, i find what you are doing really fascinating.
Title: Re: ROM Hacking?
Post by: Commando125 on February 17, 2016, 04:35:44 AM
It's alive. I just don't have as much free time right now. And I don't know what to do next.
Title: Re: ROM Hacking?
Post by: Commando125 on February 23, 2016, 05:29:55 AM
Starting to mess around with the first level. There is a severe bug in the index tile editor, do not use the tile index editor until next release.
Title: Re: ROM Hacking?
Post by: Commando125 on March 30, 2016, 06:52:08 AM
Hey again. If you guys want to play around with a rom hack still, make sure to use this version for now: https://onedrive.live.com/redir?resid=3CD90919322C51ED!9376&authkey=!AAEsN4VHGiuc5_U&ithint=file%2czip. I added some keyboard shortcuts and made editing the levels easier by rearranging the tileset tiles to match where the index tiles are. The keyboard shortcuts are:
ctrl + left/right: Palette
left/right/up/down: Select tile next to the currently selected tile in the tileset
1/2/3/4 (not numpad): View tileset/physmap/etc.
V: vertical flip
H: horizontal flip
O: object priority
D: deselect
Tab: Switch between editing tilemap and physmap

I have another project in mind that could help a site that I participate on, so features might be frozen. If there is a serious bug, let me know.
Title: Re: ROM Hacking?
Post by: texh on April 01, 2016, 05:52:18 PM
Oh damn, it works!

Just a quick question, is there any way to select a whole tile instead of right clicking it by one one so you can copy paste the whole tree at once for example?
Title: Re: ROM Hacking?
Post by: Commando125 on April 03, 2016, 06:21:18 AM
You hold left click on the level area to select an area on the level. You hold left click and move the mouse pointer when not selecting a tile on the level area to "paint" tiles on the level.
Title: Re: ROM Hacking?
Post by: Princess Rescuer on June 21, 2016, 09:43:09 PM
Wow, this seems uh... pretty involved. Definitely not as simple as Super Mario World romhacks. Shows how exquisitely designed the game is. I'd like to see this become a thing so I can buy a flashcart and never have to buy another game again.
Title: Re: ROM Hacking?
Post by: Canvas on July 30, 2016, 09:04:09 AM
This is amazing, I will try my hand at making a small mapset and maybe a guide of some sort
Title: Re: ROM Hacking?
Post by: Canvas on August 05, 2016, 02:04:57 PM
I have spent a week learning this editor and have made a single level and plan to make more. I have also been writing down everything someone would need to know including quoting from here as a sort of manual.
http://pastebin.com/z5GQLk7S
It needs to be rewritten to be less confusing, starting with the GUI and probably ending with objects. I will very likely also make a video tutorial which will hopefully help visual learners too. I want to get a full blown romhack started so if you are interested message me and we can plan something out.

I am also making a romhack. I have only made one map (going to see some changes) which you can find in the pastebin, you will need to import it with Riverback.

Also please add some way to increase the grid size my eyes are killing me its so tiny
Title: Re: ROM Hacking?
Post by: KawaseFan on August 08, 2016, 11:44:00 AM
I like your level.  I agree with your thoughts that it may be better placed a little later in the game; maybe in the 10s or 20s.  It's not too hard, but just a bit harder than a usual early field, I think.  Then again, it might depend on how hard it is compared to all of the other fields in the finished ROM hack!

Sorry to do this, but could you possibly replace the ROM link with a link to a patch?  I appreciate that you've made only your own field playable, but the rest of the game is still buried in there, and I'd rather not have links to ROM files here, due to the legality issues.

In the next week I'll add some information to the site's Umihara Kawase page regarding the ROM hacking.  Really, I should've done that ages ago.  In the future, I'd like to have a page on the site with information on the ROM hacks people make.
Title: Re: ROM Hacking?
Post by: Alc on August 11, 2016, 05:40:26 PM
Instead of a link directly to the ROM, why not shift the link into the next pastebin? That way we don't have to worry about this site's legal responsibilities. Patches are a nuisance.

Going to check out the ROM later, thanks Canvas!
Title: Re: ROM Hacking?
Post by: Canvas on August 13, 2016, 01:28:21 AM
I went ahead and made it a patch you could import into the original ROM but that wont be how I will do the final release unless there is an easier way to import maps by then. Since it's one map though I don't think its a problem yet but hopefully I will have dozens by the end or even bigger (DREAM BIG).

Ive changed it up a good 4 times in the past 4 hours so redownload it again if you have problems. Also updated pastebin with more, and more accurate, information. Outlined three more maps, will make my own thread soon
Title: Re: ROM Hacking?
Post by: texh on August 14, 2016, 12:46:52 AM
Man that guide has been super useful!

Made this to try things out for a bit, pretty challenging one.
Title: Re: ROM Hacking?
Post by: KawaseFan on August 14, 2016, 02:37:50 PM
Made this to try things out for a bit, pretty challenging one.
Cool!  I'm not sure what you'd consider a good clear/fail ratio for this, but I failed thirteen times before clearing it.
Title: Re: ROM Hacking?
Post by: Commando125 on August 15, 2016, 03:31:31 AM
Hello again.

The editor does need rewritten. In more places than just the user interface. Looking back when working recently, I see all sorts of issues in the editor code. I probably did not think of the user enough in mind when designing the interface. Even worse that there's no documentation for it.

I'm glad someone is making a rom hack with my editor. Let me know if help is needed.

The editor expands the rom to 2048KB to have more room for levels (the levels in the original game have very compressed levels). I think the rom needs expanded to 2048KB before applying an IPS patch. UPS patch should work fine on an uncompressed rom.
Title: Re: ROM Hacking?
Post by: texh on August 15, 2016, 01:32:13 PM
Is there any way to try levels beyond the first one? Let's say I edit the second field but if I want to test it, I would have to get past the first one over and over again.

I thought about making second field as first one in different ROM and then just import it to the initial one but according to Canvas's pastebin it's not possible. The first field just gets overwritten. Maybe you know a way around this?
Quote
If you make a level and export it, then import the level, it will always replace the level it was initially on AND the current visible level.

Also I don't think this is currently possible but would make for amazing addition in the next version. If you could select area in Field Tiles (ie whole carrot or door) and paste that into Field Display it would save so much time. Honestly just copy pasting tile after tile was the most time consuming part of the "hack".


Made this to try things out for a bit, pretty challenging one.
Cool!  I'm not sure what you'd consider a good clear/fail ratio for this, but I failed thirteen times before clearing it.
Thanks for trying it out! I don't really know what kind of clear/fail ratio I'd expect but I had my brother try it out and he just ragequitted after falling off the bottom right block hh
Title: Re: ROM Hacking?
Post by: Commando125 on August 16, 2016, 05:38:11 AM
Is there any way to try levels beyond the first one? Let's say I edit the second field but if I want to test it, I would have to get past the first one over and over again.

How I test levels beyond the first is to enter the level number (in hexadecimal) at location $7E025B in ram, but most people wouldn't get how to do this. I use bsnes and its hex editor in the debugger.

I would just make the first level extremely short, with warp doors or something, and have it point to the level you want to test.

I thought about making second field as first one in different ROM and then just import it to the initial one but according to Canvas's pastebin it's not possible. The first field just gets overwritten. Maybe you know a way around this?

To make the second field the first one: Export the first (so you have a backup of the first level) and second fields to a level file. Import the second field's level on the first field.

Also I don't think this is currently possible but would make for amazing addition in the next version. If you could select area in Field Tiles (ie whole carrot or door) and paste that into Field Display it would save so much time. Honestly just copy pasting tile after tile was the most time consuming part of the "hack".

If I find time, I will consider adding that feature in. It is difficult to do with how the editor is setup.

I'll try to visit /vr/ more often.







Title: Re: ROM Hacking?
Post by: Canvas on August 16, 2016, 08:55:02 AM
I have been having a good enough time with the editor but haven't even started adding in any complex graphics. It's a pain in the ass as texh already said, I am not looking forward to it. I have been working daily on the mapset, but work is slow still as I am also trying to get into the head of the developers, figure out why they do certain things and put that knowledge to fun use. I have decided to not make a thread until it is finished, I don't know how Studio Saizensen handle modding but I don't want to figure out before it is finished

I will still update pastebin if I can, right now I am focusing on texture directions for reference and will maybe have something again soon. Until then, see ya
Title: Re: ROM Hacking?
Post by: Commando125 on August 21, 2016, 04:52:41 AM
Have you tried changing the palette numbers in the level settings? I noticed that your level had a few graphics tiles that had the wrong palette compared to the original game.
Title: Re: ROM Hacking?
Post by: Canvas on August 22, 2016, 11:02:42 AM
Yeah, when I made that I was thinking red lettuce for whatever reason, but I have noticed that isn't how it is used in the game and doesn't look enough like red lettuce either. I have just fixed it, luckily with how palettes work I don't have to fucking redraw it. Palette A is a good lettuce. Right now I am focusing on new levels though, I have created a new first boss level and it is devious
Title: Re: ROM Hacking?
Post by: texh on August 26, 2016, 07:23:54 PM
Made another one, could be better but for now I'm done with it. (that grid size holly molly)
Title: Re: ROM Hacking?
Post by: Commando125 on August 31, 2016, 07:13:01 AM
Make sure to back up your levels and rom when you use the editor. I think there is a bug in it that saves palette number indexes as 0 when exporting levels, crashing the editor.

The editor really does need a rewrite; it is rushed and not very well planned at the time.

I have attached old notes I have while making the editor and figuring out data for the game. It probably won't make sense at first since I compiled the information for myself. Maybe it will help in some way.
https://1drv.ms/u/s!Au1RLDIZCdk8g_MlxYQcnipOVb5sKg

(http://i.imgur.com/fk7xXuK.gif)

I have released a new Riverback version. The hotkeys for the show checkboxes are now bound to ctrl + 1-4. The level editor is now zoomed in 2x instead of 1x. This version contains a bugfix where unused level data from old levels (when saving your edited new levels) was not cleared out. Due to this, it is highly recommended to export and import all your levels on your current Umihara Kawase roms onto a fresh Umihara Kawase rom. Let me know if any bugs occur, especially if they differ from the previous version. Link is below.

https://1drv.ms/u/s!Au1RLDIZCdk8ySABLDeFRxornOf1
Title: Re: ROM Hacking?
Post by: Commando125 on September 01, 2016, 05:37:43 AM
If you downloaded the link in the previous post, please re-download it. The bug wasn't completely fixed. Thanks.
Title: Re: ROM Hacking?
Post by: Canvas on September 03, 2016, 08:11:34 PM
Thanks a lot this is much easier
Title: Re: ROM Hacking?
Post by: Canvas on September 05, 2016, 03:08:53 PM
Actually this gives me a different issue, I can't see from a birds eye view lmao which makes it difficult to draw new maps. I figured I could just use the old version but it is also zoomed in now, is there a config file somewhere?
Title: Re: ROM Hacking?
Post by: KawaseFan on October 18, 2016, 09:33:14 AM
I've put up a page: http://kawasefan.net/umihara-kawase-level-editing (http://kawasefan.net/umihara-kawase-level-editing)

I'm sorry that it took me until two months after "next week" to do it.

There isn't much on the page at the moment, while I figure out how much information it should have, and possibly improve the wording in some places.  I've included the Riverback download link, as well as a link back to this thread.  I intend for the page to have information on ROM hacks made with Riverback, so I'll add information on Uku when it's completed.  Feedback or suggestions regarding page content are welcome.

Commando125, again, much appreciated that you've spent your time working on Riverback.
Title: Re: ROM Hacking?
Post by: Canvas on October 19, 2016, 10:18:22 PM
The editor does need rewritten. In more places than just the user interface. Looking back when working recently, I see all sorts of issues in the editor code. I probably did not think of the user enough in mind when designing the interface. Even worse that there's no documentation for it.
I just realized you probably were referring to this post;

It needs to be rewritten to be less confusing, starting with the GUI and probably ending with objects.
I meant that I needed to rewrite the pastebin sometime to be less confusing, Riverback itself isn't that difficult to understand actually and has a very nice GUI outside the view area. Speaking of which I haven't been able to draw any new levels since it got zoomed in. Not being able to zoom out and see everything makes it much more difficult create a level based on my drawings and the limitations of the game. I really need a solution to this to even continue and I don't know where the fuck to look in the registry to find what I could only assume to be a global setting of some sort to change this setting
Title: Re: ROM Hacking?
Post by: Canvas on October 19, 2016, 10:46:13 PM
I intend for the page to have information on ROM hacks made with Riverback, so I'll add information on Uku when it's completed
I am not humble, I am already pretty proud of the 5 levels I have made and the 2 provided by texh, and you bet I am going to be boiling in ego toward the end even if nobody bothers to try Uku but I wouldn't feel comfortable with it on the level editing page. If modding explodes I want something like the Quaddicted Quake mod fansite (https://www.quaddicted.com/reviews/) but until then I wanna to stick to the forums
Title: Re: ROM Hacking?
Post by: Commando125 on October 21, 2016, 06:38:27 AM
I meant that I needed to rewrite the pastebin sometime to be less confusing, Riverback itself isn't that difficult to understand actually and has a very nice GUI outside the view area. Speaking of which I haven't been able to draw any new levels since it got zoomed in. Not being able to zoom out and see everything makes it much more difficult create a level based on my drawings and the limitations of the game. I really need a solution to this to even continue and I don't know where the fuck to look in the registry to find what I could only assume to be a global setting of some sort to change this setting

Sorry to miss your reply, I have been busy with work lately. Here's a 1x version. All I did is modify a variable from 2.0f to 1.0f and change the level's bitmap size in the GUI editor. I didn't fully test it though, so keep backups. https://www.dropbox.com/s/dh50a6erh272pzq/riverback%20-%201x.zip?dl=0

Title: Re: ROM Hacking?
Post by: Canvas on October 22, 2016, 01:29:57 PM
Thank you for the update. I have issues when I try and add solid ground. For example, selecting byte 40. Top left wont show it is selected, and if I try and draw with it I get a tinier grid. If I view maps I have already drawn with physmap shown it will show some wacky stuff as well. I will continue editing my existing maps and maybe remake an old one or two in the meantime, there is no rush so mess with it when you have time, I just needed some communication
Title: Re: ROM Hacking?
Post by: Commando125 on October 23, 2016, 02:07:41 AM
Redownload the zip file; it should be fixed.
Title: Re: ROM Hacking?
Post by: Commando125 on May 03, 2017, 11:45:34 PM
https://www.dropbox.com/s/2hk6zw6pho0r5jw/Riverback.zip?dl=0

There was an area of memory I reserved for levels that shouldn't have been reserved for levels.
Title: Re: ROM Hacking?
Post by: Canvas on August 22, 2017, 06:39:44 PM
I am not sure how helpful it will be but I said I would make it so I have, here is a video tutorial to go along with the most recent UMIPASTA.
https://www.youtube.com/watch?v=xYihG2_Ooac
https://pastebin.com/LS8tjD3v
UPDATED 02/15/2018

I have been posting the latest UMIPASTA in the Uku thread but I feel like it would be more appropriate here. Still though I have an anchor post in the Uku thread so it should remain updated
Title: Re: ROM Hacking?
Post by: Commando125 on January 17, 2018, 05:40:13 PM
This version should fix the levels being corrupted and crashing the game.

https://www.dropbox.com/s/4yud3q8albpaydd/Riverback_fix.zip?dl=0
Title: Re: ROM Hacking?
Post by: Ladida on March 03, 2018, 04:43:56 AM
hi

i had no clue there were hacking efforts for this game lol (much less an editor). either way, ive actually begun work on a complete disassembly (that can assemble properly)

what i have so far is on github: https://github.com/Matsurika/umiharakawase-dis (https://github.com/Matsurika/umiharakawase-dis)


... i guess ill look around and see what's up here
Title: Re: ROM Hacking?
Post by: Naulahauta on March 09, 2018, 09:33:22 AM
hi

i had no clue there were hacking efforts for this game lol (much less an editor). either way, ive actually begun work on a complete disassembly (that can assemble properly)

what i have so far is on github: https://github.com/Matsurika/umiharakawase-dis (https://github.com/Matsurika/umiharakawase-dis)


... i guess ill look around and see what's up here
Thank you for your efforts! If it helps, please see the disassembly notes and other useful info at the wiki (http://ndirt.com/umihara)! apparently the wiki is down. Goddamnit. There were important disassembly notes regarding the enemies there. Anyone ever take a backup?
Title: Re: ROM Hacking?
Post by: Canvas on March 09, 2018, 09:10:59 PM
I did backup something called "disassembly.txt" along with other txt files if that is what you are referring to, just in case I will link them
https://drive.google.com/open?id=1CskD7t3d-419X9yMsZId8QSmhXx796t2
Title: Re: ROM Hacking?
Post by: Ladida on March 09, 2018, 09:29:16 PM
ncie. im gonna put those in the github alongside the disassembly if thats ok (as backup and as reference)  ;D
Title: Re: ROM Hacking?
Post by: Ladida on March 22, 2018, 10:30:59 PM
forgot to mention here that i disassembled the SPC engine several days ago and filtered the music/sfx/samples

https://github.com/Matsurika/umiharakawase-dis/tree/master/SPC (https://github.com/Matsurika/umiharakawase-dis/tree/master/SPC)

the rest of the disassembly is trucking along (i had to change assemblers midway though due to complications. im in talks with the asar devs with regards to a couple things, so may switch back at some point)
Title: Re: ROM Hacking?
Post by: Naulahauta on March 23, 2018, 07:09:23 AM
I tried to compile bass on Mac and I got an executable out, but it halts on row 3 because of Error: unknown architecture wdc65816
So I ran the Windows version, bass.exe through Wine and got 海腹川背.sfc out but it halts after the title screen. Just a black screen with music playing in the background.
Are there any special prerequisites I should know?
Title: Re: ROM Hacking?
Post by: Ladida on March 23, 2018, 11:59:20 AM
for the former issue: make sure the architectures folder is located alongside bass

for the latter: nothing past the title screen is disassembled yet :P (aside from the replay menu)
Title: Re: ROM Hacking?
Post by: Naulahauta on March 23, 2018, 12:31:03 PM
Ah, I see. It works now.

What is the best way to help your quest? I like scavenging for data but I'm more of a ROM map type of guy, writing down offsets and information a la

0x1234 - $400 bytes : something something
0x1634 - $56 bytes : something something, format explained below:
// something something something


Is it redundant to do original research while  simultaneously you're doing your disassembly?
Title: Re: ROM Hacking?
Post by: Ladida on March 23, 2018, 06:17:31 PM
i mean a rom map should inevitably be done (or rather, should have been done. seems like info is just scattered randomly lol). a simple excel table converted to html should look nice; not sure if you guys have a good host aside from this website, but i can try putting it on the github alongside the disassembly (or on some other domain) if this site isnt a good option. we could also throw the ram map there and etc. basically centralizing information, which i think is important. since this site is already an umihara hub it'd be best to have it all here. basically expanding whats here: https://kawasefan.net/umihara-kawase-level-editing (https://kawasefan.net/umihara-kawase-level-editing)

doing original research concurrently with the disassembly is good and welcome because both can feed off each other. theres a couple stuff within the disassembly that ive sort of noted as maybe useful for a rom map (mainly sound effects, tiles, etc).

in terms of format, i come from the smw hacking community so im used to their rom map format (https://www.smwcentral.net/?p=nmap&m=smwrom (https://www.smwcentral.net/?p=nmap&m=smwrom)), basically address listed as a SNES address, length, type (subroutine, tilemap, etc), and the description goes more in depth on certain addresses. like for a tilemap entry, it can list a specific tile that you can change
Title: Re: ROM Hacking?
Post by: KawaseFan on March 23, 2018, 07:40:02 PM
since this site is already an umihara hub it'd be best to have it all here.

With that wiki having gone down, there certainly needs to be a new place for Umihara ROM hacking information to be stored and organised, and I'm happy to set up a section of this site for that purpose.
Title: Re: ROM Hacking?
Post by: Ladida on March 24, 2018, 03:56:23 AM
that would be stellar (though it can wait a bit; at least until a good rom/ram map is done)
Title: Re: ROM Hacking?
Post by: Naulahauta on March 24, 2018, 12:31:56 PM
Let's do it!
A ROM Hacking subpage with the disassembly (somehow), some useful Tools (I'm thinking the level editor and probably Tile Molester 0.19) and a ROM/RAM map

SMWcentral has kinda the right idea but I dunno what the best approach here would be... Maybe a simple database where anyone could add an entry, containing:
• an address (SNES or PC with easy auto-convert)
• data size
• description
• data type (graphics, music, OAM data, level data, ?????, other)
• footnotes (extra information about the data format if applicable)

Problems I can already see:
• It would probably need an automatic conflict checking system, say, if you were to add an entry that starts from 0x1234 and has a size of $100, but an entry already exists at say 0x12A8, who's in the wrong here? Data can't overlap and we have no idea who did the mistake. SMWcentral has mods to verify the addresses are correct but then again...
• well i guess that's really the only problem i can think of
Title: Re: ROM Hacking?
Post by: Naulahauta on March 24, 2018, 02:10:50 PM
I just figured out the sprite format (mostly... I think that's all there is? gonna run some tests later but I'm 95% confident)

0x4F000: Goldfish data:

20 00                           // Space reserved for palette data; $0020 bytes
00 05                           // Space reserved for 16x16 blocks; $0500 bytes.
E0 02                           // Space reserved for 8x8 tiles; $2E0 bytes.
10 42 00 00                     // $20 bytes of palette data, 15bpp BGR
0A 10 0F 0C                     // ...
34 00 D7 00
5A 01 FE 01
5F 2A 1F 33
38 25 75 4E
D8 5A 9B 52
5A 6B FF 7F

{$500 bytes of 16x16 gfx}       //  Now at 0x4F026
{$2E0 bytes of 8x8 gfx}         //  Now at 0x4F526

                                //  Now at 0x4F806 (address N):
05 00                           // Number of sprite entries, two bytes ($0005)
16 00 06 00                     // sprite #1: address N+$0016, amount $0006
3A 00 07 00                     // sprite #2: address N+$003A, amount $0007
64 00 07 00                     // sprite #3: address N+$0064, amount $0007
8E 00 07 00                     // sprite #4: address N+$008E, amount $0007
B8 00 07 00                     // sprite #5: address N+$00B8, amount $0007

                                //  Now at 0x4F81C (address N+$0016):
F3 FF F6 FF 00 20               // Tile definitions for sprite #1
03 00 F6 FF 04 20               // Format is XX xx YY yy TN tt where:
F3 FF 16 00 16 00               // XX xx = X coordinate
FB FF 16 00 15 00               // YY yy = Y coordinate
03 00 16 00 14 00               // TN = Tile Number
0B 00 16 00 13 00               // Tt = Tile type. $00 for 8x8 tile, $20 for 16x16 block.

FA FF EE FF 0E 00               // address N+$003A, tile defs for sprite #2
F2 FF F6 FF 08 20
02 00 F6 FF 0C 20
F2 FF 06 00 12 00
FA FF 06 00 11 00
02 00 06 00 10 00
0A 00 06 00 0F 00

FA FF EE FF 09 00               // address N+$0064, tile defs for sprite #3
F2 FF F6 FF 10 20
02 00 F6 FF 14 20
F2 FF 06 00 0D 00
FA FF 06 00 0C 00
02 00 06 00 0B 00
0A 00 06 00 0A 00

FA FF EE FF 04 00               // address N+$008E, tile defs for sprite #4
F2 FF F6 FF 18 20
02 00 F6 FF 1C 20
F2 FF 06 00 08 00
FA FF 06 00 07 00
02 00 06 00 06 00
0A 00 06 00 05 00

FA FF EE FF 09 00               // address N+$00B8, tile defs for sprite #5
F2 FF F6 FF 20 20
02 00 F6 FF 24 20
F2 FF 06 00 03 00
FA FF 06 00 02 00
02 00 06 00 01 00
0A 00 06 00 00 00


There are separate "banks" for 16x16 blocks and 8x8 tiles despite the graphics being a one big bunch of data so it might be hard to wrap your head around the idea but here's a visual explanation:
First, go to the graphics address 0x4F026, immediately after the palette data.
(https://i.imgur.com/9BbKHM0.png)

Now, read $500 bytes, the amount reserved for blocks.
(https://i.imgur.com/ITzzWz2.png)

If a sprite refers to a 16x16 block with Tile type attribute $20, read from this 'bank' as if they were 16x16 blocks. In this case the only Tile Numbers that really make sense are 00, 04, 08, 0C, etc...
(https://i.imgur.com/8A5MPTI.png)

The 8x8 tiles are the data that comes after the 16x16 blocks, in this case at 0x4F526. The indexing starts over from 0, too.
(https://i.imgur.com/9X1ONmx.png)



How should I write this information down in a concise manner, though? Should The ROM map read just "0x4F000: Sprite data for goldfish, see footnote" or should I explicitly list down every single offset for palette data, 16x16 graphics, 8x8 graphics, tile definitions for sprite X, etc. etc.?
I mean, the sprite format is the same for all sprites so writing all this again for every enemy seems stupid. Then again I could write a script that auto-generates all this information because after all, it only needs a beginning offset - everything else; size, offsets can be deduced from that single offset.
Title: Re: ROM Hacking?
Post by: Naulahauta on March 24, 2018, 02:48:22 PM
Sorry for the spam but here's some new exciting information:
The goldfish data was at 0x4F000, right? 0x4F000 is 89F000 when written as a SNES address. Searching for pointers to this, I found a single 00 F0 89 in the ROM, in a very suspicious array at 0xD475. Red emphasis for the golfish data pointer, but pay attention to the highlights below it.

00 00 00 00 00 00 00 33 A0 F0 CD 00 00 00 00 00 F0 86 00 D0 A0 EF D1 00 00 00 00 3E FE 87
00 54 A1 6A D4 0A 93 EC A0 12 E8 90 00 06 06 06 00 35 03 00 00 66 CF 0E CD 08 08 02 A1 9E
9B D9 A1 17 CE 6C 8B 70 9C 00 F0 89 00 0A 06 08 00 97 00 F4 FF B2 CF 23 CE 0A 08 AA 9D 9E
9B B4 A2 2F CE 6C 8B 70 9C FC C1 98 00 0A 06 04 00 96 01 E6 FF B2 CF 3B CE 10 08 AA 9D 9E
9B 3F A4 A0 CE 0A 93 70 9C 54 F8 94 00 06 06 08 00 33 01 EC FF C3 CF 0E CD 08 0A AA 9D 9E
9B F3 A6 B3 CE 0A 93 D9 A6 27 F6 8D 01 06 06 0A 00 67 00 F4 FF DB CF 0E CD 08 06 AA 9D 9E
9B 0B AA 49 CE 6C 8B 5C 9C 6B EE 9B 00 06 06 00 00 22 03 01 00 04 D0 0E CD 0A 06 FD A9 9E
9B 5B AA EC CF 6C 8B 5C 9C 6B EE 9B 00 06 06 00 00 22 03 01 00 3B D0 0E CD 0A 06 4D AA 9E
9B 28 AB B3 CE 2B 97 70 9C 52 88 9C 00 00 00 40 00 55 00 00 00 69 D4 0E CD 06 06 AA 9D B6
9B 7C AB B3 CE 48 97 73 AB 3E FC 95 00 00 00 40 00 29 00 00 00 69 D4 0E CD 06 06 AA 9D B6
9B 2B AC 49 CE 6C 8B 70 9C 00 80 9B 00 0A 06 0E 00 72 01 EA FF 68 D0 0E CD 0C 0C AA 9D 9E
9B D9 A1 17 CE 6C 8B 70 9C 8F A5 9B 00 0A 06 06 00 12 01 F0 FF B2 CF 23 CE 0A 06 AA 9D 9E
9B 99 A2 2F CE 6C 8B 70 9C 00 F0 83 00 0A 06 02 00 61 02 EE FF B2 CF 3B CE 10 06 AA 9D 9E
9B 09 A2 2F CE 6C 8B 70 9C EF E0 8C 00 0A 06 00 00 73 03 EA FF B2 CF 3B CE 10 08 AA 9D 9E
9B E8 AD 6A D4 48 97 DD AD EB FA 9B 00 00 00 40 00 24 00 00 00 73 D0 0E CD 06 06 AA 9D B6
9B EB AE 6A D4 6C 8B 5C 9C C0 F5 8A 00 0A 06 F8 FF 45 05 01 00 7C D0 0E CD 0C 0A CD AE AD
9B 21 B0 6A D4 6C 8B 5C 9C BA E0 96 00 0A 06 04 00 32 02 F0 FF 9D D0 23 CE 0C 08 B9 AF AD
9B 30 B0 6A D4 6C 8B A8 AF 92 B1 98 00 0A 06 04 00 32 02 F0 FF B8 D0 23 CE 0A 06 C0 AF AD
9B B7 B2 6A D4 48 97 70 9C F3 B0 9B 00 00 00 00 00 00 00 00 00 69 D4 0E CD 0A 0A AA 9D 87
B2 33 A0 6A D4 48 97 70 9C 30 FF 83 00 00 00 40 00 01 00 00 00 69 D1 33 A0 6A D4 48 97 70



Checking out those green ones and they're definitely pointers to other sprites. The second row, FC C1 98 (0xC41FC) is the eel enemy you meet in the second level.

I don't know what the other number represent though, but I'm looking into them now. If you replace the Golfish's row with the Eel row, all goldfishes in the game will transform into eels, graphics, behaviour and all.
Title: Re: ROM Hacking?
Post by: Ladida on March 24, 2018, 04:13:23 PM
lol, ironically i just hit upon that table in the disassembly. the sprite pointers are at $81D3E9 (aka 0xD3E9), theyre 16bit though. the first entry is sprite 0 (aka null/skipped), next is the poof, then the splash (these 2 have minimal data), then the net sprite, goldfish, etc. good stuff

Quote
How should I write this information down in a concise manner, though? Should The ROM map read just "0x4F000: Sprite data for goldfish, see footnote" or should I explicitly list down every single offset for palette data, 16x16 graphics, 8x8 graphics, tile definitions for sprite X, etc. etc.?
I mean, the sprite format is the same for all sprites so writing all this again for every enemy seems stupid.
you can just do "0x4F000: Sprite data for goldfish", and then the entry for "data type" can detail the general format when expanded, since its the same for all of em
Title: Re: ROM Hacking?
Post by: Commando125 on March 25, 2018, 07:03:20 AM
All the graphics for the level tiles are compressed the same way as the level data themselves, so maybe a separate tool or script can easily be made to decompress and compress the graphics into the ROM. The graphics for the backgrounds are not compressed.

I did have to decompress the level tile graphic data with Riverback to read it into the editor. See link: https://github.com/ellisong/Riverback/blob/master/Riverback/LevelEditor.cs#L40 (https://github.com/ellisong/Riverback/blob/master/Riverback/LevelEditor.cs#L40). The decompress and compress algorithms I wrote seem horribly coded (because I can't read assembly worth a damn), but they are working. Compress/decompress algorithms are at https://github.com/ellisong/Riverback/blob/master/Riverback/DataCompressor.cs (https://github.com/ellisong/Riverback/blob/master/Riverback/DataCompressor.cs).

The script in the following topic post lets you decompress the .arc file for the PC versions of the Umihara Kawase games: https://kawasefan.net/forum/index.php?topic=43.msg535#msg535. I am unsure how to compress the .arc file back in a non-destructive way (where you decompress and compress the original data resulting in the same original data back). If I remember right, I think the ROM is compressed in the .arc file inside the original Umihara Kawase PC game. It may be possible to use Riverback to read/write that file.

Attached is old notes while creating the editor. I have no clear recollection of what is inside and some of it is gathered/copied from other peoples' notes.
Title: Re: ROM Hacking?
Post by: Ladida on March 25, 2018, 06:20:11 PM
The decompress and compress algorithms I wrote seem horribly coded (because I can't read assembly worth a damn), but they are working. Compress/decompress algorithms are at https://github.com/ellisong/Riverback/blob/master/Riverback/DataCompressor.cs (https://github.com/ellisong/Riverback/blob/master/Riverback/DataCompressor.cs).
assembly is all i know. we make a good team lol

anyways a quick glance at your decompressor and some searching tells me that the compression format is probably LZSS or some variant, because apparently that was a common format for post-NES games. could be wrong though


also, i have those notes backed up on the github already, but thanks anyways!
Title: Re: ROM Hacking?
Post by: Naulahauta on March 26, 2018, 07:02:14 AM
I wrote a Sprite Exporter to test out if my docs were right – they weren't.
• I accounted for Tile Type attributes of $00 and $20 only, turns out there's more. The byte is actually a set of flags that not only determine the tile size (8x8 or 16x16) but also palettes and possible vertical/horizontal flips
• In my original post, I said that the Sprite Entries list a 2-byte relative Address and a 2-byte Amount. Turns out It's actually 2-byte relative Address, 1-byte Amount and 1 unknown byte.

Otherwise the exporter's output is 100% correct so that's great.

Making a Sprite editor couldn't be too hard but I don't think making a standalone tool right now is wise. I'd much rather write a specification for a Sprite format and have the separate sprite files as binaries in the disassembly. That way if a sprite editor gets made, one wouldn't have to think about pointer math or size limitations.

EDIT: Adding to this - there's definitely a Hitbox pointer and a Behaviour pointer somewhere in the "Enemy Headers" I (incorrectly) listed in my last post.
Title: Re: ROM Hacking?
Post by: KawaseFan on April 13, 2018, 02:59:08 PM
Let's do it!
A ROM Hacking subpage with the disassembly (somehow), some useful Tools (I'm thinking the level editor and probably Tile Molester 0.19) and a ROM/RAM map

SMWcentral has kinda the right idea but I dunno what the best approach here would be... Maybe a simple database where anyone could add an entry, containing:
• an address (SNES or PC with easy auto-convert)
• data size
• description
• data type (graphics, music, OAM data, level data, ?????, other)
• footnotes (extra information about the data format if applicable)

Problems I can already see:
• It would probably need an automatic conflict checking system, say, if you were to add an entry that starts from 0x1234 and has a size of $100, but an entry already exists at say 0x12A8, who's in the wrong here? Data can't overlap and we have no idea who did the mistake. SMWcentral has mods to verify the addresses are correct but then again...
• well i guess that's really the only problem i can think of

I'm imagining a system that records conflicting submissions in a separate table (along with a record of which entries they conflict with) for checking.  Whether the table of conflicts is available for all to view and comment or only a select few to investigate, I'll leave that up for discussion, but in any case, a select few people would have the ability to accept or reject the submission.