ROM Hacking?

[Commando125]

I think those 16 word bytes are affecting enemy spawn rates. I'm not sure why though.

[Commando125]

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

[Commando125]

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.

[Commando125]

@Naulahauta

How did you run the editor under a Mac? I noticed some graphic issues in the screenshots.

[Commando125]

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.

[Commando125]

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

[Devyat]

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.

[Commando125]

It's alive. I just don't have as much free time right now. And I don't know what to do next.

[Commando125]

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.

[Commando125]

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.

[texh]

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?

[Commando125]

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.

[Princess Rescuer]

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.

[Canvas]

This is amazing, I will try my hand at making a small mapset and maybe a guide of some sort

[Canvas]

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

[KawaseFan]

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.

[Alc]

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!

[Canvas]

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

[texh]

Man that guide has been super useful!

Made this to try things out for a bit, pretty challenging one.

[KawaseFan]

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.

[Commando125]

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.

[texh]

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?

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

[Commando125]

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.

[Canvas]

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

[Commando125]

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.

[Canvas]

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

[texh]

Made another one, could be better but for now I'm done with it. (that grid size holly molly)

[Commando125]

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

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

[Commando125]

If you downloaded the link in the previous post, please re-download it. The bug wasn't completely fixed. Thanks.

[Canvas]

Thanks a lot this is much easier

[Canvas]

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?

[KawaseFan]

I've put up a page: 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.

[Canvas]

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

[Canvas]

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 but until then I wanna to stick to the forums

[Commando125]

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

[Canvas]

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

[Commando125]

Redownload the zip file; it should be fixed.

[Commando125]

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.

[Canvas]

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

[Commando125]

This version should fix the levels being corrupted and crashing the game.

https://www.dropbox.com/s/4yud3q8albpaydd/Riverback_fix.zip?dl=0

[Ladida]

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


... i guess ill look around and see what's up here

[Naulahauta]

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


... 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! apparently the wiki is down. Goddamnit. There were important disassembly notes regarding the enemies there. Anyone ever take a backup?

[Canvas]

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

[Ladida]

ncie. im gonna put those in the github alongside the disassembly if thats ok (as backup and as reference) 

[Ladida]

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

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)

[Naulahauta]

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?

[Ladida]

for the former issue: make sure the architectures folder is located alongside bass

for the latter: nothing past the title screen is disassembled yet (aside from the replay menu)

[Naulahauta]

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?

[Ladida]

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

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

[KawaseFan]

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.

[Ladida]

that would be stellar (though it can wait a bit; at least until a good rom/ram map is done)

[Naulahauta]

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

[Naulahauta]

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.


Now, read $500 bytes, the amount reserved for blocks.


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


The 8x8 tiles are the data that comes after the 16x16 blocks, in this case at 0x4F526. The indexing starts over from 0, too.




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.

[Naulahauta]

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.

[Ladida]

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

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

[Commando125]

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

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.

[Ladida]

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.

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!

[Naulahauta]

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.

[KawaseFan]

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.