Join us on Discord!
Started by mfgreth, October 07, 2014, 05:43:55 AM
Quote from: texh on August 14, 2016, 12:46:52 AMMade this to try things out for a bit, pretty challenging one.
QuoteIf 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.
Quote from: KawaseFan on August 14, 2016, 02:37:50 PMQuote from: texh on August 14, 2016, 12:46:52 AMMade 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.
Quote from: texh on August 15, 2016, 01:32:13 PMIs 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.
Quote from: texh on August 15, 2016, 01:32:13 PMI 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 from: texh on August 15, 2016, 01:32:13 PMAlso 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".
Quote from: Commando125 on August 29, 2016, 02:42:19 AMMake 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
Quote from: Commando125 on August 15, 2016, 03:31:31 AMThe 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.
Quote from: Canvas on August 05, 2016, 02:04:57 PMIt needs to be rewritten to be less confusing, starting with the GUI and probably ending with objects.
Quote from: KawaseFan on October 18, 2016, 09:33:14 AMI intend for the page to have information on ROM hacks made with Riverback, so I'll add information on Uku when it's completed
Quote from: Canvas on August 05, 2016, 02:04:57 PMI 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
Quote from: Ladida on March 03, 2018, 04:43:56 AMhii 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
Quote from: Ladida on March 23, 2018, 06:17:31 PMsince this site is already an umihara hub it'd be best to have it all here.
QuoteHow 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.
Quote from: Commando125 on March 25, 2018, 07:03:20 AMThe 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.
Quote from: Naulahauta on March 24, 2018, 12:31:56 PMLet'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 mapSMWcentral 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