[evmatter]

That issue's fixed now. There was also a problem with the new feature not working with alternate tile sets, but that's also fixed.

Link to the fixed version: https://app.box.com/s/v6mkdz88qxa301kgeode957dvnjo2rnc

[NekoBaron]

found a problem, trying to set a warp to set object set 129 which is needed when leaving a boss area, but it keeps setting to -127, guessing its a signed/unsigned issue suddenly.

[evmatter]

It should be fixed now: https://app.box.com/s/umix40dcgjvhw9zgj3ghcu4ya3pegbos

[NekoBaron]

Turns out wario holding an enemy on a conveyor belt like the sticky block also ignores the effect of standing on the block, its really nice being able to edit the tile set and working out how the switch blocks works can do some interesting things with it, like toggle spike blocks and such.

One thing I noticed is the enemy names for the woods bee boss are switched around, basically bee hive right and boss are just reversed (Im just guessing this for the moment based on their positions in the level)

Edit: Been playing with the tileset editing more, would it be possible to have a x2 size option on the tile set edit screen to make it a lil easier to select? Also I had an idea of a button to pallet sets that makes a copy of another existing pallet based on number to make colour variations more quickly.

[evmatter]

The object naming is based on the address that the object uses in the rom. In some of the boss rooms, the addresses are switched around. Not sure why this is, but it didn't seem like too big of an issue at the time.

For tileset editing, I would probably make the "view" menu's zoom option affect the zoom of the tilesets.

Having an option to copy palette sets also sounds like a really good idea. At the moment, there isn't a good way to copy colors to other palettes. I'll definitely add this feature when I have the time.

[NekoBaron]

I tried making a new alternate tile set and horribly broke the level T_T, I'll try and work out what I did or you think there's a limit to number of alternate tilesets since I tried to make a 10th set?

[evmatter]

Did you warp to the region with the alternate tile set using the special "warp door (change tile set)" tile? Even if it displays the alternate tile set in the editor, the game only knows to change the tile set whenever it goes through that type of door.

Also, make sure to keep incremental backups of the rom. I can't 100% guarantee that the editor won't corrupt the rom after saving it. If this does happen, however, send me the ips file so that I can figure out what caused the problem and manually fix the rom.

The editor has also been updated with the features requested in the previous post:
https://app.box.com/s/lnnr2p1734otet5owaw4yvh3qg8uwey7

[NekoBaron]

Well Im currently making the 1st level for the 3rd chapter but the thing is it seem to break saving the level so like 2-3's though the level all the tiles get set like like 0, thankfully only that level gets confused but its a shame since it was turning out nice until I tried loading the rom later.

[evmatter]

I think I might know what the problem is. The tiles in levels are stored in chunks throughout the rom. Each chunk holds the tile data for about 3 to 4 levels. However, the chunk that contains the 1st level for the 3rd chapter (Maze Woods: Get to Maze Woods) contains 5 levels. This particular level is at the end of the chunk. Since the tiles are compressed, the size that the tiles take up can increase. What probably happened is that the end of the level reached out of the chunk space and into another part of the rom. The part that it reached into gets overwritten by zeros then replaced with the part of the rom that handles the placement of objects.

I'll release a new version that fixes this problem, but for now, the level is going to keep saving incorrectly.

[NekoBaron]

Thats fine, I love the tool and its great fun to use and help test it out <3, interesting it seemed to be for that level exactly but oh well, no harm done to the progress I've made with it.

[evmatter]

The problem should be fixed now. Instead of tiles being assigned to the chunk that they originally belonged in, the tiles will move on to the next chunk if it runs out of room.

Fixed version: https://app.box.com/s/itnnctk3s4o128w6m6cv4b9ejo5fryni

[NekoBaron]

Awesome <3 everything works fine again. Though it makes me wonder if I will hit a chunk limit eventually or is it designed to just move on? Just thinking since I'm making a lot of the levels take up more of the space available, though I guess the best way to find out is to keep on going.

[Dirtbag]

This is a really impressive editor., both from a technical standpoint as well as a usability perspective.  Epic job, well done 

[NekoBaron]

I'm getting an error loading the rom now, just says 'error reading file' so Im guessing I've upset it somehow since the backup I made still loads fine.

[evmatter]

Email me an ips patch of the error-producing rom so that I can figure out what the problem is.

As for the chunk limit, it will probably not be reached. I reserved 3 more chunks in the rom for any overflow. The rom is generally divided into sections that are each 0x4000 bytes long, so I call each section a chunk.

Also, thanks for the replies. The feedback is helping make this editor more powerful and bug-free. Right now, I'm working on a new part that will let you edit the graphics. Unfortunately, since the graphics are compressed, they will shift around the rom when saved causing the addresses to shift as well. Many of these addresses are used in the cutscenes, so allowing some graphics to be edited causes the cutscenes to look messed up. Until I find where the graphics are edited in the cutscenes, many of the graphics including enemy sprites will be uneditable.
For now, only some of the graphics will be allowed to be edited. This includes the subtile sets that are unused in the second megabyte of the rom. In the editor, you can see these by accessing the second half of the primary and secondary subtiles. They look like the original graphics but changed slightly. You'll also be able to edit animated subtiles since those are uncompressed. All of Wario's graphics will also be editable since I've found where they are referenced in the rom.

[Drenn]

First of all, great work with the editor so far, I like it a lot. As for editing graphics - when I first implemented sprite editing in my wl3 editor I didn't even realize they were used in cutscenes. But there are so few cutscenes in wl3 I could just hard-code those cases in. I'm not as familiar with wl2 but I'm guessing you could use a similar approach.

I also had this "misc graphics" editor which could edit basically anything after feeding it the addresses in a text file. I went crazy with my external text approach, and it's hardly necessary for such a feature, but it would be cool to see a way to edit random compressed graphics.

My input probably isn't even necessary since you seem to have everything under control, but here it is anyway. There are some people at wario forums interested in more powerful graphics editing so that's why I'm here. Best of luck with this

[evmatter]

Thanks. As you know, I got the idea to make a WL2 editor after seeing your editor. Here's the new release (version 1.2.0). Right now, only some of the graphics can be edited.
https://app.box.com/s/zmgumc6u7dxujr41dr2r2vrho4b4o2n5

The cutscenes are a bit annoying to deal with because of the address shifting with the graphics. Most of the cutscenes actually use their own graphics, but some of the graphics from tiles and objects are used in the cutscenes. Hardcoding the addresses that point to the graphics would probably be the best approach for now.

For graphics editing, I may plan to expand the amount of tile graphics that can be used in the game. Since the pointers to tile graphics use 3 bytes, it's possible to store the graphics anywhere in the rom. I'll also try to expand the amount of metatile, tile color, and tile type sets that can be added in the game. There would have to be a lot of shifting around of data in the rom for that to happen, though.

Also, out of curiosity, what was your approach to hacking the rom? I basically wrote a custom hex editor, then primarily used that to corrupt sections of the rom. Then I uncorrupted half of the corrupted section until I narrowed down which part did what. I never tried to understand the assembly code of the game, though, so I have no idea how the code of the game executes.

[Drenn]

Hmm, are tileset subtiles really compressed? Didn't expect that. An approach you could consider, is expanding the ROM to 4 megabytes, and reorganizing various things for convenience. I never did go with this approach, and decided to trust my freespace managing system instead, but it's something to consider. Either way would be a fair bit of work though, making sure nothing breaks.

As for my approach to hacking, in most cases I'd reverse-engineer the assembly code. Not always, but I'd do this to trace back data in RAM to where it was stored in ROM, and things like that. I think one of the first things I found was where the tile data was stored in RAM (or rather, SRAM). Of course, that's just RAM searching - I probably used breakable tiles to search for differences or something like that... from there, though, I put access breakpoints on the tile data which would lead me to the code which puts it there, so I could understand where and how it was stored in the ROM. I used bgb of course, all its debugging bells and whistles helped a lot. I was familiar with gameboy assembly before this from writing an emulator. I never did try the ROM corruption approach...

[evmatter]

Your approach seems a lot more advanced than the way I'm doing things. From what I've heard, corruption is more of a beginner's technique. This makes sense, though, since I'm relatively new to rom hacking. Corruption's good for finding what each section in the rom does in general, but if you try to look for something in particular it can take a long time. To help me out, I created a rom map of the data. This map is now on data crystal. http://datacrystal.romhacking.net/wiki/Wario_Land_II:ROM_map

There's a lot of extra space in the second megabyte of the rom, so storing extra graphics in that area would prevent the rom from having to expand to 4 megabytes. The one tricky part about this would be telling the editor to keep track of graphics addresses since the editor only checks certain sections of the rom for loading graphics.

So, I went ahead and hard-coded the addresses of the rom that reference graphics used in cutscenes. I've been trying to avoid hard-coding for compatibility, but this should be fine since there isn't any cutscene editing. Now, all the object/enemy graphics and the rest of the tile graphics can be edited.

Version 1.2.1
Edit: If you downloaded from this link already, there was a glitch when editing object graphics. It should be fixed now.
https://app.box.com/s/y0a2azszg1sjd8y59uqtebii2p36yl9b

[NekoBaron]

Working good so far, couple of things I can suggest if possible.

Show the current chapter/level number and name in window title bar would be useful.


Theres also a lil funny thing of if your rom is saved as .GBC (in caps) it will save it as a .GBC.gbc ,not a giant problem but a lil silly still.