SC4ED - Super Castlevania 4 Editor

[RedGuy]

Short Answer: Yes, I'm planning to have a way to change the level design.

Long Answer: Redoing each existing 256x256 pixel scene with different tiles is possible with some minor changes to what I already have.  Collisions seem to be coupled with the tile maps like they are in mmx so placing the tile map and its associated tiles would get you new stairs/walls/slopes/etc depending on the map you use.  So ya, you could take an existing scene and add stairs and walls to change it to a vertical/climbing type.  The more difficult thing is events (enemies, candles/upgrades, camera locks, level segment end, etc) and how they work.  I know where the initial camera lock is for the level, but I have not looked at any event code to see how events work.  And I still don't understand how level segment bounds works.  So I'm not sure how to change a 12x1 scene level segment into a 1x12 scene level segment, yet.

mmx had a sparse event data structure with triggers on block (32x32 pixel) boundaries and the events could call into custom code that could update tiles, palettes, spawn enemies, or do pretty much anything to the state of the game.  Hopefully Castlevania is simpler - it took a while to code up events in the mmx editor and it's still far from perfect.

[MathUser2929]

I'm looking forward to whatever you can do. Uncompressing the rom sounds like a really good idea. We can use our own graphic editors to change the graphics that way.

[Vanya]

Castlevania games in general have notoriously... unfriendly level data formats on the NES. Hopefully this won't be as much of a pain in the ass. Good luck!

[Bregalad]

Castlevania games in general have notoriously... unfriendly level data formats on the NES. Hopefully this won't be as much of a pain in the ass. Good luck!

Would you care to explain what is so unfriendly ? I am interested and you hit my curiosity here.

[Vanya]

They aren't tidy and thus easy to edit.
All 3 games have editors, but the best they can do is edit tiles and meta-tiles/TSA.
Actually changing how and where a level segment transitions to the next doesn't seem to be included in the level data itself.
For example, you can place a set of stairs anywhere in the first room of stage 1 of CV1 and when you go up passed the top of the screen it'll lead you to another room of garbage data. So there has to be something pointing to the right data somewhere, but I've never been able to figure out exactly where. I'm not even sure if it's a table or if it's part of the code for the stairs themselves.
CV3 is no better, and CV2 seems much more limited.

I'd love for someone with much greater ASM knowledge to try tackling these games and share their findings.
That brings to mind that hack of CV3 that was being worked on by Dr.Mario & Optomon, I think. Cadence of Agony, IIRC.
They scrapped the level format altogether and made one from scratch. It was coming along nicely, too.

[MathUser2929]

They dreamed too big and were overwhelmed by the amount of work in making a non-linear game.

[RedGuy]

I created a ROM that includes decompressed data for most (not all) of the levels and puts it in the 1MB-2MB space in the file.  I played through half the game and didn't notice any graphics problems.  The tiles show up in tile layer pro now.

With some minor changes to the decompression algorithm there's only one control byte every $400 bytes instead of every $1F bytes.  I can get the tile data for the start of an uncompressed region to begin on a $20 byte aligned address, but every $400 bytes it will get offset by 1 byte.  If it helps, I can try removing the offset.  Since people are going to edit tiles outside of the editor is it important that they always align to a $20 byte aligned address?

[ShadowOne333]

I created a ROM that includes decompressed data for most (not all) of the levels and puts it in the 1MB-2MB space in the file.  I played through half the game and didn't notice any graphics problems.  The tiles show up in tile layer pro now.

With some minor changes to the decompression algorithm there's only one control byte every $400 bytes instead of every $1F bytes.  I can get the tile data for the start of an uncompressed region to begin on a $20 byte aligned address, but every $400 bytes it will get offset by 1 byte.  If it helps, I can try removing the offset.  Since people are going to edit tiles outside of the editor is it important that they always align to a $20 byte aligned address?

Having the ROM with the uncompressed data would be such a miracle gift!
Would sprite editing For characters/enemies be possible with the uncompressed data now viewable?

[RedGuy]

Wasn't sure if enemies were being decompressed, but I see them in the modified ROM.  Since I only look at the levels right now the character data doesn't show up.  I can try to decompress those.

The hand, leaf-thing, bird, and other enemy tiles can be seen here:

[MathUser2929]

Wow, nice.

[ShadowOne333]

Wasn't sure if enemies were being decompressed, but I see them in the modified ROM.  Since I only look at the levels right now the character data doesn't show up.  I can try to decompress those.

The hand, leaf-thing, bird, and other enemy tiles can be seen here:

Woa awesome!
Will you release the patch that converts the original SC4 ROM into an expanded one with the uncompressed data in it?

[MathUser2929]

Maybe it'd be better to let him finish the level editor first. Especially since he's moving pointers around and stuff like that still. No point releasing a expanded rom patch if it's incompatible with the level editor when it's released.

Edit: I see that little Spiny enemy. Woot!

[RedGuy]

My plan is by this weekend to provide a basic editor that let's people:
- View the level BG0 data (many of them don't display correctly).
- Expand the ROM.
- Save the ROM.
- An internal emulator that let's you play the game inside the editor.

Expanding the ROM decompresses most (but not all) compressed regions, rewrites the pointers in the game to point at that uncompressed data, and then changes the decompression routine in the ROM to support the new format that only has one control byte at the beginning of each uncompressed region.  I pad all regions to be $20 byte aligned and a multiple of $20 bytes so they are easy to view and modify in a tile editor.  You can see a bunch of tiles in the viewer that are green with colors at the end.  This is $20 bytes worth of 29 $FF bytes, a 2B size and, a 1B control for the decompression routine followed by the aligned uncompressed region.  The code in the ROM still breaks regions into $400 byte chunks for DMA across multiple frames.

This new format for a region probably won't change, but what will change is never versions of the editor may move the decompressed regions around when expanding.  So the editor should always be able to open up an expanded ROM since it just follows the pointers and understands the new format (which doesn't change), but you won't be able to re-expand an already expanded ROM.  And the tiles may not be in the same spot when expanding in different versions of the editor.

So treat these early versions of the editor as a way to try editing the tiles and see the changes in the game, but not necessarily as the base for a big modification.

[MathUser2929]

Well, I look forward to the first version of the editor then. I hope you continue making progress on it too.

[SunGodPortal]

Yeah, I can't wait for this either. I've been standing outside the gates of this one forever waiting for someone to open it up.

[MasterGrand]

Nice job man,Keep up !

What about edit sprite ?

[RedGuy]

Editing sprites with assembly information is a lot of work.  Not sure if I'll ever get to that.  But if you want to change just the tiles that should be doable with a tile editor and an expanded ROM.

Here's the current version.  It's a huge hack right now so I disabled a lot of things.  Ignore all the random megaman stuff which I haven't converted to castlevania stuff like the icons.

- File -> Open to open the ROM.  You can scroll through the level segments with page-up and page-down.  Many of the levels have graphics errors in the editor.
- File -> Expand ROM will try to expand the ROM.  It will tell you if it succeeds.  It's expanded from 1MB to 2MB.
- File -> Save/Save AS will save it.  Make sure to save after expanding if you want to try the ROM.

There's also a button to start an external emulator and a menu item for an internal emulator.  The internal emulator has a lot of bugs (sometimes the screen moves off the map temporarily, it shakes right now when walking).  Make sure to setup your joystick or key settings if you want to try the internal emulator.  F1-F10 load state, Shift+F1-F10 save state, space = pause, F12 = start emulator, Escape = stop emulator.

All the decompressed stuff is dumped to $100000 (1MB) and above.  I forced all the tiles to be aligned to $20 byte addresses so they should be easy to view and edit in a tile editor.  Simon, items, and weapons are still compressed right now.  I'll figure out where they are located and decompress them in a future version.

If someone is bored I would appreciate you trying to go through the whole game on an expanded ROM to make it sure it works.  I played about halfway through without seeing any graphics glitches or having it hang.

https://drive.google.com/file/d/0Bx9gzQZCkH8qTXVOQ2h0bm44MVk/view?usp=sharing

[ShadowOne333]

@RedGuy:

I just did a playthrough from start to finish of the game with the expanded ROM to 2MB without any issues.
I didn't see anything out of place nor anything odd at all.

I ace'd it.

[RedGuy]

Thanks.

I'll add some more things to the uncompressed section of the ROM for people to view/edit and then continue working on the level editor.

[ShadowOne333]

Thanks.

I'll add some more things to the uncompressed section of the ROM for people to view/edit and then continue working on the level editor.

Thank you for your wonderful work!