Sonic Mega Collection/Sonic Gems Collection

I felt this thread was relevant

http://forums.sonicretro.org/index.php?showtopic=13514

So to answer your question, the games are likely emulated with the ROMs being compressed and/or encrypted, now, having never tampered with any version except the PC, one thing I did find, was that changing the actual ROM names around (I.e. swapping Sonic 1 with Sonic 2) didn't have much of an effect, but removing the actual files or replacing them with something different caused the game to crash upon selecting the ROM, in which case I'd make the assumption that the game checks through the ROMs to find the correct one internally inside the ROMs themselves.

I'm only speculating though, I don't claim to know the inner workings, but it looks like changing the ROMs is a no go for now until someone thoroughly examines the compression/encryption format, and finds a way.

 

I believe the genesis games are just slightly encrypted regular .BIN roms... someone extracted the one for Sonic 1 and that's how we got Rev 1.3 or something like that.
Sonic CD is a port of the old 1994 PC version, R is a port of the PC version, and Fighters I dunno. Might be an emulator, I feel like I remember people ripping broken models for Honey and a couple other characters with Pro Action Replay codes...

 

That would have been the arcade version as the Game Cube version was missing Honey all together

 

It wasn't necessarily missing, it just crashed the game. After all, it was discovered first in the gamecube version.

Sonic the Fighters was probably a port, given that there were actual data files instead of roms. On the other hand, it was very unusual for a gamecube game because all of the in-memory stuff was mapped to virtual addresses outside of what the Action Replay supported. You couldn't hack codes for it using normal means, because everything moved around constantly. I had to use my own tool that I wrote instead of GCNrd UI because it couldn't search outside of 'normal' memory regions. I don't remember what the correct term for what it did was called, but only 1 or 2 other games ever did that. Maybe it was simulating some kind of copy protection on the arcade hardware? It still seems more likely to be a port though, because it's unlikely that Sega would want to emulate Model 2 hardware for a single game.

The virtual memory region thing is also the reason that no official codes were ever released for it, outside of the ones I hacked for the US version. The "master code" for Sonic the Fighters used a custom code type that the author of the GCNrd UI created specifically for this problem, and it basically hacked the Action Replay's code handler into supporting the rest of the codes.

 

Not completely accurate.

Sonic the Fighters was comprised of two .cvm images. One contained all the game's data, the other contained .adx versions of the music.

Here is a snip of data from the Sonic the Fighters rom:



And one from the Gem's file ROM_CODE1.CMP



The whole makeup of the Gem's data is very similar to the arcade counterpart bitwise, but there is obviously some odd corruption of areas of data that aren't particularly used.

 

Interestingly enough, the drx Mega Collection prototype for Gamecube gives a little bit of insight on that MD/GEN emulator's overall progress.

If you open it up in GCTool, you will see a 'sonic3.bin' in the main root of the directory. This can be extracted and run in any typical Genesis emulator. If anyone can confirm that Sonic 3 runs in this prototype of Mega Collection, then we might be able to try rom swapping it with something else.

Overall, both collections have a very similar architecture.

.BNR is used for the title screen graphics, while
.ADX is used for all background music
.SFD files are used for video playback (whether it's for the title screen or even something more remote like Sonic CD cutscenes)
.TPL is for all the various graphics files that make up the menus

Gems Sonic CD is simply the PC version compressed: http://forums.sonicretro.org/index.php?showtopic=27737&st=0&p=658412&#entry658412

Sonic R is simply the PC Version, never did any research on that.

Sonic the Fighters is interesting. It's all CMP and FTS files. The more important chunks of the source code seem to be CMP. I'm guessing they either slightly altered the source code and did a direct port or did some sort of partial Model 2 emulation.

(EDIT: Hey, 600 posts! ...How did I get 600 posts here? o_0 I haven't logged in for months!)

 

According to Sonic-CulT, the reason it wouldn't load was because it was missing
http://sonic-cult.org/dispart.php?catid=4&gameid=2&subid=1&artid=6

The retro article backs this up.
http://info.sonicretro.org/Game_Secrets:Sonic_the_Fighters

 

That doesn't look like corruption to me, it looks very much like compression. The "look" of the ASCII you pasted resembles what usually happens with ASCII in PRS files, although I doubt it's PRS compressed. The .cmp extension makes it even more obvious that it's compressed.

The extremely unusual memory management the game used definitely makes it seem like emulation, but I'm still not entirely convinced about that. I just don't think they would write a Model 2 emulator for a single game. It might have been easier for them to port the game but read all of the data from the ROM. That would explain why certain things don't work. I'll pull my equipment out of storage and get to the bottom of this.

Edit: Okay, I looked. I'm not really sure what they did here. The ROM data is not unused, but all of the stage and character data that has been broken up into the filesystem is also not unused. Honey is only referenced once in the gamecube executable, (with the rest of the character names) but she doesn't have her character data broken out like everyone else. Everyone else's files are referenced but since there are no files for Honey, I guess I'll agree that she wasn't included. The game doesn't depend solely on the ROM files, which tells me it's not emulated. But the fact that it uses them at all is odd too.

I can't really give a good analysis, as it turns out that the drive tray on my Gamecube seems to have stopped working properly after sitting in a box for 6 years. I managed to get the drive door open eventually, but for some reason I can't get it StF to load in the debugger anymore without freezing. I guess I should've taken better notes the last time I did this.

 

1. All the Sonic the Fighters pages on CulT were written by me, and the information there is dated from January 2nd 2007. The section needs to be revamped.
2. The Retro page was updated with info from that page and other sources.
3. This particular information regarding Honey in Gems was taken from this quote from over 7 years ago from sonicblur "The character doesn't have a model, and the game will crash if you try to load a fight with it."

sonicblur, we should really get together and take another look at StF for PC. I'd like to make move-swapping possible to view possible unused moves as well as animations and change the pointer order in the test menu, where debug mode resides.

 

As you say, the Retro page is updated. but it still says

As far as I know, no one has shown that Honey's model is in Gems Collection to disprove that statement.

 

Resurrecting this topic as I have actually new, relevant info to this discussion.

As sonicblur pointed out years ago, it is some form of compression. Specifically, the header data states that it's "CRICMP 2.10", but this may not mean it's an official CRI middleware format. Digging back into this file format I decided to broaden my horizons and look at other similar Sega games produced around the same time. To do this I took a look at the programming credits for Sonic the Fighters in the staff.xml file for Gems and found that programmers who worked on StF also worked on Fighting Vipers (the Model2b game StF was molded from) and Virtua Fighter 4 - Evolution, both for PS2.

FUNNILY ENOUGH, both FV and VF4E both use the CVM images for binary and audio to run and BOTH contain CMP files with the same header information. For some unknown reason, probably to make the game files seem bigger on the disc than they really were, the copy of Fighting Vipers contains BOTH the compressed and uncompressed binary files! Comparing the two types of files, I have found some of the necessary header information to decompress the contents of the CMP files, which uses some sort of LZ77 compression, but I just haven't figured out one 4 byte array and how it relates to the decompression.