OK, so we know that in Sonic 1-3, jumping under a monitor bounces it to the floor, whereas in Sonic & Knuckles this was completely changed so that monitors smash from any direction. Right? This isn't hacked in any way - it's vanilla S3&K. It's often been thought that the monitor drop code may have been changed because they couldn't get it to work in reverse gravity. Well, in reverse turns out to be the only direction where it IS enabled. (You can actually see elements of this as you progress through Death Egg 2 - note that upside-down monitors can't be jumped straight into from the side in the same way as the rest of the game.) The code to make this work is very close to being correct, but there is one mistake. When you bounce a monitor down, it is supposed to bounce up briefly before it travels down. This bounce up hasn't been reversed correctly, so the bounced upside-down monitor begins hurtling towards you pretty quickly rather than going the other way first. As a consequence, it's very difficult to actually bounce it down without it falling straight into a rolling Sonic and breaking anyway - but you can at least see it's moved a few pixels before that happens. That's why I did a hyper transformation first in the video - so Sonic wouldn't be rolling and couldn't break it. The code to make this happen for right-way up monitors is all still there - it's branches of the same code, but there's a branch at the beginning that skips it all if the monitor is the right way up. I find it hard to imagine why this is. Perhaps they gave up on fixing the upside-down behaviour and decided to give normal monitors a similar effect to match (seems unnecessary, since I don't remember any monitors in DEZ2 you can actually make fall in reverse, so the normal behaviour wouldn't really seem noticably abnormal - in fact there is more visible difference between their behaviour because of the change!) Perhaps they meant to dummy out the incorrect upside-down behaviour and got the condition backwards (I've seen this elsewhere, but I don't really buy it for this, since it's a pretty fundamental interaction and it behaves this way in every S3C and S&K beta we have over a couple of months, IIRC.) What happens if you reverse gravity while a monitor is falling, and all that sort of thing? Nothing special. Whether a monitor falls up or down, and which side of it makes it fall, is entirely determined by the monitor's vertical orientation. This sort of makes sense - it seems logical to be able to smash an upside-down monitor on the ceiling rather than making it fall, and the gravity swap objects always seem to affect only Sonic and nothing around him - why should monitors be any different?
Ah, the very wonders of the Sonic Engine! When I was working with the S2HD TD, and was double checking the reverse gravity code against S&K, I decided to search for other objects acting upon the reverse gravity flag. The object next to the players that had the most reverse gravity interactions were the monitor object. I thought there was something big about it, because you don't make so much changes in an object unless it is important. Well, turned out later when Sonic Retro reminded me S&K monitors don't fall down when knocked from below. And as you point out, monitors are placed upside down to react upside down, and not because of reverse gravity. There is of course the velocity with gravity functions where reverse gravity plays a part. My guess is they had alot of their minds, and it turned out they had to disable the whole thing. But was it because of a bug? Such thing can be tested by re-enabling the code, right? I think it was disabled just to prevent future changes to bug out, as they probably felt it was a waste of time to add reverse gravity support when there was no place in game where it could be used (like an upside-down palmtree, which doesn't really fit Death Egg Zone). But my research didn't end there. We need to know what behaviour a monitor should have in a reverse gravity environment (one act in S&K doesn't cover it all)! And the two other games supporting reverse gravity (very well I must add) are Sonic Advance and Sonic Advance 2. I have spent many hours with them, for research. Looking beyond their issues which pretty much never would be accepted if the game was named Sonic 3, they still tell the story about the overall design of a 2D Sonic game. So in Egg Rocket Zone Act 1, at the very top (too bad you have to play there and it takes ages), it is one of the best level designs in the Advance series for sure, when you cross path up to the end. I LOVE IT! Anyway, somewhere at that end, there is a little bit of a reverse gravity section, and in that section, there is a monitor resting in the air! That means you can touch it from underneath. But it isn't easy. And I don't remember the action! It was back in 2008, and I got one lucky hit, but I am not sure if it was a perfect hit, so I don't want to just call it at this moment. But I played it on the real hardware, so there was pretty much one chance of test per life. S&K set the standard, that reverse gravity is part of original Sonic design. Even if it was added for just one act, it would have been perfectly balanced for the next Sonic game, for sure! Too bad it was 1994, and the end of our lives as we knew it.
This is what I just don't understand. From having hacked around and done some testing, as far as I can deduce, there are only two things that stop the code from working 100% correctly in both directions: The upward bounce on first hit doesn't work right when upside-down. This is what causes the upside-down monitors to normally get broken while falling, as I explained above. This was a two second fix once I saw it. There's a branch to ignore the dropping code completely, which is followed only for monitors that are the right way up. This is easily skippable, again, after working out what it's doing to begin with. So there's completely working code for normally-orientated monitors, which is deliberately ignored, and slightly broken code for monitors orientated in reverse, which is actually used. If this were a last minute change I'd think for sure that someone got that branch condition backwards. Your scenario makes sense, but my conclusion from it would be to disable the buggy upside-down drop code, not the bit that still works! In any case, the the next Sonic 3 Complete release will have monitor dropping enabled for both directions with those issues fixed, so that will give an opportunity to highlight any further issues. And I should really make time to have a go at Sonic Advance sometime.
Perhaps they disabled that behavior from the normal monitors to maintain consistency between them? I mean, since they couldn't get the upside-down ones to behave correctly. Looking forward to the mandatory "fix upside down monitors and restore the Sonic 3 behavior" tutorial in the bugfix section of the wiki.
You're probably right, but why go to the trouble of making a whole conditional branch for normal monitors rather than just jumping over the lot (which I've tested and does work more consistently)? I guess we'll never know. There are probably a few bits and pieces like this I should tutorialise, now there's a nice disassembly to refer to. I'll try to give some time to that in the summer perhaps.
Just like you, I need the monitor to work in reverse gravity as well, so I have made a few tests. In Sonic 1, the monitor's solid box code is different from the solid box code that crushes you from beneath, so that the monitor can't crush you when it falls down. But because of that, when the monitor is falling, Sonic can't ride it at all. The test I made was placing Sonic on top of the monitor, and changed the monitor's state to be knocked and fall down. Sonic just stood in the air, completely failed. It was an impossible situation to begin with. Sonic can't be below it at the same time as being on top of it. In Sonic 2, Tails was added. That means Tails can ride the monitor when Sonic knocks it from beneath. When I was supposed to test Sonic, I didn't even have to change the state of the monitor, as CPU Tails knocked it down for me: However, with this new interaction level, the monitor acts as a normal solid box, and crushes you! Tails is dead in the picture above, but it could have been Sonic knocking the monitor over himself. In Sonic 3, the same applies just as Sonic 2. Sonic is killed by the monitor he just knocked, and Tails can ride that same monitor while falling both upwards and downwards perfectly. Death to a falling monitor is kinda evil? Yes. It is the first time I knew it myself. I just pictured the Sonic 1 behaviour when I think about a monitor falling down over you. So in Sonic Advance 1, the Sonic 1 rule applies. The monitor falls down and doesn't crush you. You don't even want to know what happens if CPU Tails is activated through the cheat code, as it is Sonic Advance and Dimps we are talking about here. And the multiplayer modes really show some horrible results on interactions. But it has reverse gravity, and in Egg Rocket, at the end, there is a monitor placed, but you can't jump underneath it as it is resting on the ceiling (acting as ground in reverse gravity). This monitor looks just like it was placed normally though, as its graphic isn't upside-down. When you break it, the icon will move upwards too (normal behaviour), which confirms it is just placed normally. But when you jump on it, you jump onto its bottom, and it will break. The hit direction is reverse in reverse gravity, so if you hit it from the top, you will trigger its falling, which is in normal gravity (this could only be triggered through hacking). So why did they disable this in S&K? As Tiddles pointed out, even the S&K betas the monitor falling was disabled. You probably have the answer in the Solid Box code, where alot of reverse gravity had to be applied for S&K at a late stage. Just a perfect place to screw up the game! And since the monitor is resting on the Solid Box code (like thousands of solid boxes, moving or not), it must have given bugs at an early stage of reverse gravity implementation. A typical example would be that when they first added reverse gravity, they quickly tried to make the Solid Box code work, and it seemed to work fine in Death Egg Act 2, but Sonic might have died all the time when he touched the monitor. So they placed that branch temporarly. Then later, they found more bugs in the Solid Box code, and decided to fix it completely, or maybe they even got an angry Naka off the Knuckles in Sonic 2 project to help them. And after that, they just decided to leave the monitor code unchanged, as you don't want to find bugs in the Solid Box code again. That was just a simple example of what could have happened.
Not to go off topic too much, but I always thought the reason they disabled the falling code from between Sonic 3 and S3K was because of a weird collision glitch with Tails flying into the underside of a monitor. If you do this at the end of AIZ2 with the fire shield just before the last checkpoint, you can, with the shield pushing you, go through the floor and get stuck. You can also sort of juggle the monitor in the air while flying, which is rather weird. This can also happen on CNZ1 with a few monitors hanging in a secret room, if you fly and knock them down from underneath.
Good point! A falling monitor has many problems. Even if you disable the bottom collision (to not allow crushing), the side collision can still squeeze you through an angled floor, or wall. The only fix is to have monitos on places where they won't cause such problems, or disable monitor falling.
Perhaps that's ultimately why it was changed. Personally, considering that this is a game where you might find yourself in a wall just from moving briskly anyway, I'd rather have the more interesting behaviour and take the odd bit of lousy collision (but the beauty of patch options leaves everyone else free to make up their own mind!) I'm still resistant to the argument that it was taken out because of upside-down glitches, because as I said, all their work on upside-down behaviour, buggy and broken as it is, is still enabled. They failed to make that work right, and then took out the bit that did work right, and left in the bit they messed up. The rightside-up code is completely unaffected by it too, if you take out the branch to avoid it - it works just as well as it did (albeit with the same bugs) if you bring it back. There is one other bizarre monitor behaviour I've found testing this, which I suspect is somewhat academic given that AFAIK it never appears in any of the original level designs. Nevertheless, here it is: rolling along the ground at an upwards angle and colliding with a monitor doesn't work sensibly at all. In Sonic 2 and onwards, you'll just sail straight through it. Sonic 1 is different but at least as bizarre (only tested on REV01) - Sonic will bounce back off it without it breaking, and lose his rolling animation, but will still have rolling physics and may regain the visible rolling status (it seems like that happens if you push a direction that causes a speed gain). I haven't had time to test it yet, but I wonder if this could cause some odd effects in Lava Reef with its wobbly floors.
Yep, Sonic is an expert of running through walls at high speeds. I have seen the bounce bug before. And as much as we can call it a bug, it is not possible to correct this thing. Please do check Lava Reef (and other levels that might bug out), when you have reenabled the monitor falling code. I'll find it very interesting!
Seeing as your on the subject of high speeds, I've always wondered why the screen can't keep up when your running really fast. Is it just a case of the hardware unable to draw fast enough or is it a case of lazy programming again? It's just that I've seen a video of Sonic 4 and he can still outrun the screen a bit.
The video hardware is only able to hold a small portion of the level at any given time. As the camera moves, the portions that leave the screen are overwritten with new data that will soon scroll into view from the opposite side. The system that performs these updates has limitations imposed by their design, not necessarily by the hardware. The amount of memory and processing time the programmer decided to dedicate to this system will dictate how much it can update every frame, and if the player moves faster than that limit the camera has no choice but to lag behind. I wouldn't say this is "lazy programming", it's more like careful allocation of resources. They could even have made the scrolling system able to update larger areas every frame, but the resources this would require could end up compromising other aspects of the engine. I also wouldn't say that "the hardware is unable to draw fast enough", because it is, maybe just not when it's also doing all the other things the engine needs. Maybe they just limited the camera's speed on purpose to emulate the effect. It seems a lot of people find it cool that Sonic can outrun the camera.
It was pretty much Naka not wanting to make the code draw more than one row/column of 16x16 tiles at the same time (and it'd had probably made the code much more complex, so I can see why). That said, this limit only kicks in when Sonic is moving at faster than 3 screens per second, so by this point you may as well argue the camera lags behind because Sonic is simply too fast to be outpaced by anything - even the game itself =P
It is more of an optimation, and far from lazy. Sonic 1 was actually too heavy, so Naka had to cut the upper screen's scrolling in water levels. That's why Labyrinth Zone doesn't have any fast slopes you can roll in. In Sonic 2, much was optimized, and the music driver was moved to the z80, which I believe helped alot, so split screen gameplay could be used, and by that I think the water levels also worked. [Sonic 1] When the water surface is too high on the screen (technically, the hblank begins before vblank has ended, because Naka is still drawing tiles in the vblank), and you scroll so there is a tile update, you will see the cut. It starts bleeding (if it was human flesh). Sonic however has no limits to his rolling speed, and if you are inhumanly quick (like making a TAS) you can break the game (run out of the level boundaries, through walls, breaking sequence), where other games would still never break playing like that. So what happens if you constrict Sonic's speed? I have tried it, but from testing, I feel that Sonic needs to be free. It is one important part of the game. I have to look at it the same way Goku saw his chances with using Kaio-ken x20. As of Sonic 4, it is a Dimps game, so read my response below about the Sonic Advance series. It was the way to scroll backgrounds back then. It was used for most games. Super Mario Bros still uses it today. The best way to see how this works is to play some Mario scroller game in a Gameboy Advance emulator (VisualBoyAdvance), and watch the background update as you go through a stage. Sonic Advance series just draws the whole screen every time, which is the easy way of doing it, and it also allows Sonic Advance 2 camera style scrolling.
I think you a may be over thinking about the whole monitor drop thing... Maybe it was just disabled to allow side jump monitor breaking..?
I thought this, actually. Because in the between-level cutscenes the character is programmed to instantly jump when next to a monitor if they walk into it. For example, if you use the signpost to reveal a monitor at the end of Sandopolis 1, and you are to the left of it when the points tally, Sonic/Tails/Knuckles will walk right (as usual) afterward but when getting to the monitor they jump and smash it, acquiring its contents. I always presumed this was the reason behind the change in their behaviour.
Now I am interested (like I wasn't before, lol). Can this be demonstrated in a video for all of us to see? Also, is this triggered by monitors only, or will the demo moving player jump over any obstacle that is placed in the way (like any other Solid Boxes, or just a wall like a staircase (wall-floor combination) that is at the end of Lava Reef Act 2). I think you are getting close to the truth here (I can only think of Sandopolis Act 1 (hidden monitors), Muchroom Hill Act 2, and Flying Battery Act 2 having to deal with such behaviour, and all of them are in S&K, any other places where this might happen? Maybe Death Egg Act 1 (are there any monitors there?)).
