Compression Problems

I'm not usually one for help topics, but this particular problem has me completely stumped and it's starting to piss me off.

I have created a basic art file for a font and I'm trying to compress it in Nemesis format for use. I've never had any problem compressing things in the past, but this particular art file is throwing up problems. Viewing the uncompressed art in TLP or in SonMapEd shows it to be fine, perfectly readable and usable. As soon as I compress it in Nemesis, using either the Sega Data Compresser or SonMapEd, it throws out complete garbage. A decompression afterwards confirmed that the art has been heavily corrupted during the process. I've attached pics below for reference. I've tried compressing other files today and they work just fine, so does anyone have an idea on what's causing this?



Art before compression



Art after compression (decompressed again)

 

Feel free to tell me if I sound like an idiot here, but I think that maybe, just maybe, if the file extension of your art file is .asm, that could potentially be the problem. I might be wrong, but if I'm thinking correctly (and you can tell me if I'm wrong), an art file with the file extension .asm can't be compressed to any format. However, I'm just starting out with figuring out these kinds of problems, so the information I just gave might or might not be useful. I do hope it is useful to you.

 

You're right, that did sound stupid. I've been hacking for 12 years, when it comes to this kind of thing I know what flies and what doesn't, and I always work on art files in binary. I don't see why anyone would want to have art files in asm format. I have sort of fixed the problem, although I would like an explanation on why this is happening. I added a further 5 blank tiles to the end of the art file, and now suddenly all is fine. If I add any less than that to the end, it goes to shit. It's not really a problem coz I can just overwrite the blank tiles again in VRAM, but it is an inconvenience. Explanations anyone?

 

I know for sure the nemesis compression is glitchy in sonmaped, as I had a problem with it myself some time ago (trying to compress a given 1 tile art file was crashing the editor, with an additional tile it was fine). The sonic compression tool is using the same dlls and has the same problem, kensharp however doesn't and compressed such files properly. 

So in my opinion, in this case it's probably an error in the dll of the nemesis compression, although I have no further details on the matter.

 

What is this Kensharp you referred to and where would I go about getting it? A google search just returned a lot of results about someone called Ken Sharp XD

 

If I may ask, what's the size of your file?

 

Uncompressed (without additional 5 tiles) - 640 bytes

Compressed (which ends up garbage) - 198 bytes

EDIT: Also tried the Nemesis MD Programs from Retro, which are executables that don't appear to use the KENS DLLs and they also give out the same shit as SonMapEd and Sega Data Compresser.

 

Here it is, sorry for the wrong name, it's kenssharp, with 2 s.

http://segaretro.org/KENSSharp

But anyway, after your tests you can now be perfectly sure it's something wrong with the compression algorithm used by those programs, which is definitely a good thing to know.

 

Worked perfectly, thanks for the help, much appreciated.

 

SonLVL uses KENSSharp for its compression (it was actually made for SonLVL), and I highly recommend it. If you do manage to find a bug, you can give FraGag on Retro an example file, and he will fix the bug (amazing!). It can also run on Linux and Mac with the Mono framework so that's nice.

 

It was just one of those things I found to be very strange. In 12 years of hacking I'd never had the problem before, so I was convinced I was doing something wrong. Nice to hear that modern tools are using the correct codec DLL files, hopefully this topic will raise awareness about the issue and some of the older programs can be updated to work with them.