SonLVL

I'm horribly looking forward to the S3K one, however I reckon a complete disassembly is going to be needed first. :P (Unless there is one. In which case I'm slooooow.)

 

There is a Sonic and Knuckles disassembly , but I don't know of a complete one.

 

Best new app beside the Special Stage editor, fo sho.

 

looks nice so far. Too bad I tried to open up the S1 level editor and it crashed

 

popped up a message box.
I can't remember the message, but I remember it was caused when I tried to remove or add a new chunk

 

ow no idea then...I just remember clicking on some chunk and then the message appeared. Ill try looking at it again soon

 

Here is a very experimental Mac OS X port if anyone wants it. (Requires OS 10.6 or higher)

You can load data, but you can't save. (I've only re-written the decompression parts of the Windows COM DLL's into .NET, not the compression parts yet.) Fairly useless, but you can use it to export level maps at least. It's also very unstable.

This was mostly an experiment to see how quickly I could decompile someone else's code and get it to build again. (About 2 hours, minus the effort to rewrite the decompression routines from the DLL's) If there is any interest, I can continue working on this port until it's usable. Or I can at least provide native .NET (de)compression DLL's if MM wants them, so that it would be possible to make it work anywhere Mono can run.

 

*flails arms*
Mac ports make me feel happy. I must try and report back. *teleports off with a copy of the programme*

INB4 .NET

 

FYI, I found a small bug in my Nemesis decompressor for the case of mode 1 decompression. I still haven't updated SVN with it, but the changes are as follows:

Code (Text):

1. Index: src/lib/nemesis.cc
2. ===================================================================
3. --- src/lib/nemesis.cc    (revision 28)
4. +++ src/lib/nemesis.cc    (working copy)
5. @@ -406,13 +406,11 @@
6.      {
7.          // For alternating decoding, we must now incrementally XOR and output
8.          // the lines.
9. -        dst.seekg(0, std::ios::end);
10. -        std::streampos sz = dst.tellg();
11.          dst.seekg(0);
12.          dst.clear();
13.          unsigned long in = LittleEndian::Read4(dst);
14.          LittleEndian::Write4(Dst, in);
15. -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while (dst.tellg() < sz)
16. +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while (dst.tellg() < rtiles << 5)
17.  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
18.  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in ^= LittleEndian::Read4(dst);
19.  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LittleEndian::Write4(Dst, in);

To avoid being completely off-topic, I have a suggestion for handling HTZ, WFZ and DEZ zone tiles (and maybe levels in other Sonic games that work similar to these). These levels work by patching the art of another level with zone-specific tiles. So what you need to do is support some form of art patching that works (schematically) like this (using HTZ as example):

Code (Text):

1. VRAM tile:&nbsp;&nbsp;$0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $01FC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $037E&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $0393
2. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v
3. Buffer 1:&nbsp;&nbsp;&nbsp;&nbsp; <----------------------- EHZ tiles ----------------------->
4. Buffer 2:&nbsp;&nbsp;&nbsp;&nbsp; <--- passthrough ---><-- HTZ tiles --><--- passthrough --->

Here, the passthrough regions simply forward the tile requested to the EHZ tile buffer, while the HTZ tiles are used instead of the EHZ ones in those regions. This allows editing of EHZ and HTZ tiles and allows them to be saved independently on changes to either, without the HTZ tiles gaining duplicate copies of all EHZ tiles and without the EHZ tiles being overwritten by HTZ tiles. (by the way, Rexon uses tiles starting from $037E, so you may want to keep this indirection further along).

 

Any idea why it's chucking this at me?

And yes the file is there.

EDIT I'm on XP BTW, 32 bit, SP2.

 

Because he spelled "Kosinski" wrong in his INI files.
The split disassembly produces a kosinski folder, while his INI file expects 'kozinski'
You can fix this by opening the INI file in Notepad and fixing it.

 

well mine says kosinski too.

just one of those weird things I could've sworn I checked, lol

EDIT:
nope, renamed and it still chucks the error.

 

The copy I grabbed from the wiki just last week has kosinski, so I assume it's correct.

I ported from the original C code to C#. Wasn't aware there was a C++ port. And this is exactly why I released as soon as I had it far enough along to work, instead of finishing it first. Because this is the 2nd time I've posted something that someone else was working on but didn't bother to post it in a public place where I can read it. It only took about an hour to do each of the decompressors, it should be feasible for me to do the compression this weekend if there's still a reason for me to do so.