They just exist to extend the floor collision. The crusher works just fine without those invisible blocks.
A more detailed look on the unused swinging platform object in Sonic CD v0.02 (object 0x29): While not placed in the stage, its graphics are loaded in act 2 around the area in which a swing is placed in the final. The number of chain links it spawns is determined by the lower 4 bits of its subtype value (0 = underflow, 1 = 0 links, 2 = 1 link, etc.). The upper 4 bits determine how it moves. There are 8 unique movement types: 0x - Moves in a circular motion clockwise. 1x - Moves in a circular motion counter-clockwise. 2x - Moves 180 degrees downwards. 3x - Moves 180 degrees upwards. 4x - Moves 540 degrees, starts facing west. 5x - Moves 540 degrees, starts facing north. 6x - Moves 90 degrees downwards. 7x - Moves in a circular motion counter-clockwise, and also spawns object 0x13, which is a Mosqui in Salad Plain. It is unknown what the object was intended to be (maybe a switch?). It was speculated before that it was meant for Tidal Tempest, but the fact that the graphics do load here say otherwise. In fact, the final swing object in Palmtree Panic also features 8 different movement modes, while the one in Tidal Tempest only has 2 movement modes, both moving in circular motions. Really, the idea of remnant objects from other zones in v0.02's R1 doesn't really work out when you realize that Sonic's movement code references the Collision Chaos pinball flippers by object ID, yet the actual object is not found in the v0.02 build. Also, the Collision Chaos remnants in v0.02 are all within Sonic's object code, which makes sense, since it's shared between stages. Also, in v0.02, a pre-v0.02 FM sound driver can be found in the stage files, and they contain an even earlier version of the time warp sound.
I've received a few comments on Twitter that compared it to Sonic Spinball among those commenting on how dreadful it sounded, so you're not alone there.
The flowers throughout the game have a small bug that I don't think has been documented anywhere (probably because it is only noticeable when moving very slowly). When moving horizontally, they disappear way too early (as in, they vanish the moment they are more than halfway off the left and right sides of the screen). This seems to be the result of the fact that they never bother to set their width: Code (ASM): .TouchDown: move.b #4,oRoutine(a0) ; Set routine to animate move.b #1,oAnim(a0) ; Set animation to seed planted animation move.b #$30,oYRadius(a0) ; Set Y radius ; oWidth ($18 pixels) should be set here, but it isn't... bra.w ObjFlower_Animate ; Continue to animate sprite With no width set, DrawObject culls them the moment they are more than halfway off the screen. As far as I can tell, this should be a single-line fix with "move.b #$18,oWidth(a0)".
I would like to make a correction, as these are incorrect, actually. The track structure address is actually incremented before calling the update function, and on top of that, each song adds in a dummy slot for the removed rhythm channel, so things are actually kept aligned properly. My apologies!
I've got some quirks about the PC/PS2 port that Devon encouraged me to post. In DIRCOL.C, there is a function called swap: Code (Text): unsigned int swap(int lSrc) { unsigned short iHi = (-1 & lSrc) >> 16; unsigned short iLow = lSrc; return (iHi << 16) | iLow; } Presumably, this is supposed to swap the two lower bytes of the integer with the two upper bytes. However, reading the code, you'll find that it doesn't do any swapping! It just takes the two parts, and puts them back together in the same order. I've re-read the assembly multiple times to be sure, and Ghidra optimises this functioin as just: Code (Text): return lSrc; Next, here's a part of function ReadScrolMap, found in LOADER2.C: Code (Text): p = pmapwk; for (i = 0; i < 128; ++i) { sMemSet(pmapwk, 0, 512); p += 256; } From what I understand, pmapwk points to the start of an array of shorts that contains map data, and this for loop is supposed to set all of the array's values to zero, 512 bytes (256 shorts) at a time, in preparation of reading the map data from a file. The problem is that sMemSet is always given pmapwk instead of p, so only the first 512 bytes are ever set to zero. Finally, in FCOL.C, we have the following code: Code (Text): iXposi += iOffset; iScd = scdchk2_r(pActwk, iXposi, iYposi, iBlkMsk, iRideon, cpDirstk); iXposi -= iOffset; While not harmful, restoring function parameter iXposi to the original value is pointless because both times it's at the end of the function, when it'll go out of scope. This is likely to be a literal transcription of the original 68000 assembly, where iXposi was contained in a register, which is shared across all blocks of code.
So, I've been learning how to use After Effects, and I came up with this demonstration on how the Sega CD is used to render a special stage. This example demonstrates how the Sega CD renders a special stage. The way scaling and rotation works on the Sega CD is that it uses a table of values to dictate how to scan a source image. For each row in the rendered image, it takes an entry from the table. Each table entry consists of a starting coordinate and delta values. It plots the scanner at the starting coordinate, and for each pixel in the rendered row, it moves the scanner by the amount set in the delta values. In this specific example, the first 3 rows are effectively nulled out due to rendering errors caused by the fact that it's rendering so far away for those rows (although, the 4th row is also erroneous, although it doesn't seem like it was noticeable enough for the developers).
It still gets to me, how little Sonic CD uses the Mega CD's extra features and is a really poor showcase for the ASIC and PCM chips, when the game really needed to be a showcase for the system, even the FMV was a letdown with a small window and terrible jerky FMV (even by Mega CD standards) Good work mind Devon
To be fair, judging from Devon's notes it seems like even the programmer(s) had little clue what to actually do with the CD. Remember that 510 demo message?
This is the work from one of SEGA's Japan top consumer teams and yet they couldn't use the Mega CD in a way that showed it off like a tiny UK British studio like CORE Design could? I like Sonic CD but it should and could have been such a better showcase for the ASIC chip and the PCM chip. It's sad when the most impressive use of the ASIC chips is for the clouds on the title screen or with the scaling in D.A Garden For me, every Boss battle should have been a showcase for the ASIC chip, a little like how many Mari IV boss battles used Mode 7 and the bonus round should have been more like that from Sonic 2 just with loads of scaling sprites like those seen in the 3D sections Cliffhanger or Batman Returns on the Mega CD
This is a thread for discoveries and neat bits of trivia, not a thread for complaining about what we wish Sonic CD did differently
We've already had this discussion before in this exact thread a while ago. IMO it would be best to make a separate thread about that sort of stuff if you really want to discuss it. Anyways, here's an extra tidbit with this The past is also affected by this: And, of course, if we look back at 510, we have a match:
The points chaining system in the 2011 remake of Sonic CD is bugged. This is due to the fact that the chain doesn't get updated until a points object disappears, causing an inconsistent points chain if you rack them up too quickly. This is the code responsible for it. Object[26] is what keeps track of the chain. As you can see, it doesn't get updated until the points object has despawned, causing the issue shown above. The way the chain gets reset if the player lands on the ground or on top of an object is also weird. When a points object despawns, the chain counter is set to a "gravity" value depending if the player is grounded or not, and then checks if it changed in the next frame. For instance, if you start a chain by hitting a badnik, landing on the ground and jumping before the points despawns, and then hitting another enemy after it despawns, the chain will continue. Here, a spring was added to easily demonstrate this. It also creates inaccurate behavior where, unlike the original Sega CD version (by extension, Sonic 1), you cannot continue a chain if you roll into an enemy and then jump into another. For reference, here's the original's behavior.
I doubt that it's strictly speaking related, but there's a similar issue where the successive multiplier for the values of ring UFOs in the remake doesn't match the original. If you hit all the ring-generating UFOs in sequence without hitting a different one, I believe you're supposed to get 160 rings (20, 20x2, 20x4, 20x8) the Sega CD version, but in the remake I don't think it gets that high.
