SC4ED - Super Castlevania 4 Editor

[RedGuy]

What was supposed to be a two day break from the mmx editor turned into a week long hack to start a Super Castlevania 4 editor.  It's not much right now, but there's enough to display one (hardcoded) level segment.  It also only loads BG0.  Since I borrowed the mmx editor code the emulator works as-is and you can see a paused screen in the picture below.

A lot of data in the ROM is compressed.  Much more than mmx which only really compressed tiles.  It has a decompression routine that looks at control words in the stream to: (a) decompress LZ, (b) copy the input stream, (c) zero extend 8b to 16b, (d) decompress RLE using a byte in the input stream, or (e) decompress RLE using 0.  This wasn't too difficult to understand and code up.  I haven't coded a compressor, but that shouldn't be too bad.

I couldn't find any previous work on SC4 and had to look through traces to figure most of it out.  If anyone knows of some documentation on the ROM/RAM layout or really anything about the game I would appreciate a link.

[SunGodPortal]

Oh shit. This is awesome. I'm a Castlevania freak so let me know when and if you need somebody to test this sucker out. Will there be a graphics editor? I've wanted to work on this game before but writing programs and cracking compression is a little beyond my level of dedication.

[Rodimus Primal]

If just to restore the censored stuff this is awesome indeed.

[Vanya]

Sweet Jeebus This is one of the holy grails right here!
I don't think there really is much documentation on this game at all, so you're probably going to be the first.
I wish you all the luck in the world

On a side note, I was just wondering how big of a ROM would be needed to convert SCV4 into a full uncompressed version of itself?
Also, would it be a huge task to create such a version of the game?

[MathUser2929]

Wow, never thought I'd see the day. I hope you finish your editor. Graphics and pallette editor would be nice.

Also you should consider a option to map the hold button to L. You can hold your character in place by holding jump when you hit the ground after jumping. From there you can whip diagnolly. It would be better if you could hold your position with L without having to jump first.

[ShadowOne333]

YES!
Uncensored Super Castlevani IV here we go!

[SCD]

This is really cool, we'll finally have a uncensored version of Super Castlevania IV in the near future.

[MathUser2929]

I never had a problem playing the Japanese version of CV IV. Just a couple storyline screens are japanese. You don't need to know japanese to play it. You could be playing uncensored the entire time.

[Morinis]

Damn, this looks very promising.  Other people have said already before me though I'll add onto the hype.  I hope there is a graphic editor in the future once you unlock the process on how to read such things.



Hope your work bears a lot of fruit in this endeavor.  My hat is tipped to you sir.

[RedGuy]

Graphics editing - I'd like to get a basic background tile editor working.  Something similar to the mmx editor where there's a tile editor, map editor, block (?) editor, and scene editor.  Sprite editing is more difficult and I don't have time to spend on it right now.  I'd like to display enemy/object sprites on the map and allow for moving, adding, and removing them, but probably no editing.

Palette editor - This is straightforward to do for at least the background tiles.  Most of the palettes are not compressed.

Uncompressed size - I haven't looked at how well the compression works.  My guess is that the average compression ratio is not better than 2x (uncompressed to compressed ratio) so it would be < 3MB (1MB original ROM + 2MB uncompressed data) total in size as a worst case.  I wouldn't be surprised if the actual ratio is closer to 1.3x and not all of the ROM is compressed so it may be less than 2 MB total.  Someone could probably dump uncompressed data in the 1+ MB area of the ROM and branch before the decompression code to a MVN.

The editor probably won't be capable of any actual editing for a while.  I need to figure out the various graphics mode code (mode 7 levels crash right now) and get more of the levels displayed correctly.  Collisions, events, sprite display, more details on the level segments are constructed .... there's a lot of stuff that is still a mystery.

EDIT: Has anyone worked with mode 7 before?  I read up on it and the non-extended version of it has just one 256 color background.  But when I go into snes9x and toggle on/off the backgrounds it still behaves like there are 3 (foreground tiles, background tiles, status bar) like it does in mode 1.  An example of this is the very first level segment in SC4 where you jump on the drawbridge which rotates up.  Maybe that's just a trick based on how they prioritize tiles and snes9x is aware of which tiles it needs to enable/disable?

[Vanya]

They might have some good info on Mode7 over Super Mario World Central. There has been some futzing around with it there.

[Tenkarider]

Perhaps you can find some info about mode7 even in FF6hacking.com docs

[mrrichard999]

Nice!

[RedGuy]

I got all of the level (segments) to load, but several of them have mild to moderate graphics corruption.  I included some pics from some of the better looking ones.  I'm having a hard time finding the bounds of the level in the ROM so I ended up using the first camera lock that gets loaded.  Unfortunately, that doesn't always show the whole level so I hard coded several of the dimensions of the levels into the editor for now.

It may end up easier to decompress all the background components and write a new ROM that's > 1MB to simplify the editor.  Otherwise, I'll have to record all the original compressed sizes to add checks to make sure the edited compressed sizes fit into that same space.  There are some ways to make things fit (e.g. sorting tiles), but given that not just the tiles are compressed I don't really want to save 500+ sizes and add checks for them.

[MathUser2929]

Whatever it takes to make it work I guess. I really hope to see some CV IV hacks come of this. It's a great game and it's great that it may finally get fresh levels.

Have you given any thought to adding a button to hold your place so you can whip diagnolly without moving or jumping first? I tried requesting that from a few people but noone took it up.

[Vanya]

Awesome. If you can convert the game into an uncompressed form that would be fantastic.
It would definitely make it much easier to do certain things under those circumstances.

Another thing I'd like to see implemented in the future is the ability to change the order of the levels.
And I know it would probably be way off in the future, but the ability to change the layout of the level segments would be awesome too.

[dACE]

Have you given any thought to adding a button to hold your place so you can whip diagnolly without moving or jumping first? I tried requesting that from a few people but noone took it up.

So what's stopping you from taking it up?

(If you have better things to do - chances are, so have other people.)

/dACE

[MathUser2929]

I don't know how to do it.

In b4 learn and never bring it up again.

[RedGuy]

I was able to create a file with tile maps, tiles, and some other compressed data stored as uncompressed in the 1MB+ region.  I modified the bank:offset addresses in the ROM to point at the uncompressed data.  As a workaround to not modifying any of the code I had to insert control words before every 31 Bytes since that's what the decompression function assumes for uncompressed data.  It seems to work for the few levels I tested.  People will probably want to modify tiles using tile viewers so this isn't a long term solution - more of a test to make sure the decompression and relocation code works.

One thing I still haven't decided on is how to pack the uncompressed data.  I'd like to keep the ROM under 4MB to avoid using the extended addressing modes and potential compatibility issues with that.  A brute force way is to give every level segment ($44 in total) its own 64KB region (representing WRAM), but unfortunately that's more than the available 3MB.  Another way is to allocate the memory in some fixed size chunks (e.g. $400) which allows for some growth and packs better.  It's also possible to pack like types together (e.g. tile maps with other tile maps) for better packing.  Not having to support data that crosses a page boundary would also be nice.

After how to store the decompressed data is decided and any remaining bugs in the decompression code are fixed I'm going to figure out what remaining data is still compressed (e.g. sprites) and include that.  Then I'll give out an editor executable for people to try out.

[Vanya]

Cool. I look forward to taking it for a spin.
Out of curiosity, now that you're seen the map data, how flexible is it to work with?
Will we eventually be able to go as far as making a horizontal area vertical, for example?