Discussion in 'Engineering & Reverse Engineering' started by Devon, Jul 11, 2022.
I find it difficult to believe they couldn't get all 4 time zones onto a single 256kB file.
Considering that they use unique tile/block/chunk data per time zone? I believe it. Also the fact that chunks are uncompressed and hardcoded to be referenced at address $210000 does not help, and they use so many chunk IDs that they can't just be compressed and decompressed into a buffer easily. Palmtree Panic Act 1 Present (US region) alone only has $3B2 bytes of free space, and the chunk data uncompressed is $F200 bytes long! Trying to decompress that into Genesis work RAM would destroy it.
Not saying that optimizations can't be made, but I really don't think it would be easy without redoing things in the core engine...
What I really wonder is if, by removing the CD tracks, there would be a way to make this a "base MD only" game. I mean, if you don't have to load the whole game as many times as levels are, if the code's so shitty cleaning it would actually reduce it even more, if you don't have absurd loading times for stuff base MD does fine... Probably the real question is who would be so nuts to try.
The SSF2 mapper might still need usage, but that entirely depends on how well the game is optimized. My concern is less with the code and moreso the sheer amount of data and how that data is used. There's also DA Garden, the special stages, and title screen's usage of the graphics processor, but it's been very well proven that they can be replicated with clever programming.
The regular stages by themselves can run on the base MD hardware just fine, though.
I've even ported R11A to a standalone Genesis ROM one:
I have also at one point even ported all of R1, but that was hackishly put together by hex editing out the Sub CPU command function in each MMD and using the SSF2 mapper to swap them out at ROM address $200000 (which is where Word RAM is located at in CD Mode 2).
I've seen this exact topic of discussion come up no less than four times, and still it hasn't been done.
In fact, I think it's quite possible.
In terms of optimization, you just need to remove excess garbage, like mode 7 on the title screen, a ramp from PPz1, possibly D.A. Garden, a warp screensaver.. well, naturally optimize the level chunks themselves.
In the end, there is the above Devon hack, there is a CD art test, and there is a demonstration of special stages in Sonic 1. The only question is how to write all this music so that it sounds decent (ideally with at least a couple of unique samples per track)
Who knows, maybe one day it will happen?
There's also this, but apparently it eats up a lot of ROM space:
Yeah, without bankswitching (or some extreme compression format), you'd basically be forced to replace the CD Special Stages with something smaller.
For this, there is Mode 1 (which allows the game to be played from cartridge while the Sega CD plays CD audio from a disc), however most emulators don't emulate DMAing correctly when it's activated; another concern would be the PCM tracks, which would have to be standard Redbook audio as well, but would have a chance of surpassing the CD size limit (700 MB).
I mean the Genesis adaptations..
You know, 16 bit.. defelemask..
But your variants are interesting too. Port Sonic CD to SMD, and add MSU-MD support for using CD audio from Sega CD for game ported from Sega CD to Sega MD.. lmao.
But jokes aside, now I really want to see this game on MD. But you have to be a real psycho to take on such a thing..
That's only really Kega that does it. What happens on that is that it still treat DMA source addresses as if it's in mode 2, so for example, $200000 would still point to Word RAM, and not the 2nd half of ROM space. Genesis Plus GX's implementation isn't broken, though.
Or, because I'm apparently obsessed with solving this:
These disappearing platforms - use this triangle pattern as a placeholder for any art that hasn't been decompressed, and it'll almost fit in with the aesthetic! ...
... or you'd trigger seizures. Putting the "panic" in Palmtree Panic.
Though I guess as far as sub-optimised code goes, addressing general slowdown across the board would be preferable - you seemingly don't need to do much in Sonic CD to drop below 60FPS. I half expected people on Retro to start back-porting fixes introduced with 2011 remake of the game, but to date I've only seen the "Sonic 2-style" spindash - not even Tails, and you wouldn't have to make the sprites anymore.
One of the biggest factors of slow down in general actually has to do with graphics decompression. Again, it uses Nemesis, which is known to be slow. Not only is it used when starting the level, but the game also has a feature to swap out graphics mid-level. You can easily see this when you launch out of the roll tunnel towards the start of Palmtree Panic Act 1, as that's an area where it swaps out graphics.
There's another video of my optimized time warp that's in that area, and with the graphics decompression algorithm swapped out for Kosinski Moduled, the lag is gone:
This is an earlier video, before I fixed the issue of it flashing black for a split second. Although, that's when you can tell the file is fully loaded and running and when graphics decompression begins.
Related to this, someone on Twitter a good while ago made a thread wondering why the time warp seemed to last longer in the 2011 remake. As it turned out, they were testing it in this same area, and they were able to land on the ground before they could time travel. The thing is... there was no lag in the remake in that area, for obvious reasons. In the original, the time warp timer ticks down, even during lag frames, so because of the lag in that area due to the graphics decompression, it merelt appears to run shorter.
To prove my point in response to that a while back, I made a quick hack that made it so that the time warp timer didn't tick down on lag frames, and sure enough, it was basically the same results as what that person had in the 2011 remake:
Is it just me, or does the game lag quite frequently when the warp trail shows up?
I actually have wondered about the feasibility of a Mode 1 port of Sonic CD using this approach. Specifically, the CD-DA audio and FMVs would still be loaded from disc, but everything else, including all executable code and PCM music, loaded from cartridge.
With that kind of approach, you could actually compress the chunks and other data that's on the cartridge and decompress them into Word RAM.
If I'm understanding correctly, assuming no data transfers need to be made between the two units, as it seems to be in ordinary levels, you could just set the word RAM to 2M mode and get a extra 256KB of RAM to use for the chunk table?
In the original game, level MMDs are loaded into Word RAM in 2M mode, which obviously means that it's set to be accessed by the Genesis. So, yes, indeed, that is true.
Wait. I'm baffled. How did you manage to do this without any of the provided hardware sprite scaling that the Sega CD offers?
I do see that it appears to be a lower resolution that the CD version - but I'm absolutely into the nerdy details, so please do tell me your magick!
MarkeyJester made that and it's all just a matter of clever software rendering and dumping into VRAM. I did also post the updated version he did that actually renders in the "proper" resolution, and that's still without the MCD.
Separate names with a comma.