Bubsy (SNES version) TAD - extreme speeds craze (full) скачать в хорошем качестве

Bubsy (SNES version) TAD - extreme speeds craze (full)

  / ulillillia   --- This video has 2 variants: full and truncated. This is the full, uncut version. It shows the full scope of what it takes to reach these extreme speeds. As a child, I discovered the "glide hop" on various objects to reach untold heights, such as cheese wheels, hot dogs, eggs, frogs, and UFOs (among others). I'd often play level 4 and chain glide hops on the eggs, the only way to achieve record speed. My best speeds with normal, unboosted play are about 43 with level 4, 37 on 13, 30 on the train, and 28 with the village. No eggs exist in the river-themed setting, my musical favorite. I'd often miss the collision with the eggs or I'd get the timing of full acceleration usage wrong, losing speed. Well, there was a time where I achieved 91.5 px/fr, but it required leaving the system on for 3 days and never letting go of glide unless I paused the game. I even put duct tape on the power LED and color it in permanent marker black so my parents didn't turn the system off or ground me for playing games when I was supposed to be sleeping. I never understood why the screen instantly jumped to the bottom or why certain things were the way they are. I also wondered why the background had a flickering effect (mainly in the Genesis version, the one I grew up with, but also the SNES version when paused) and why the level had odd parts missing or duplicated when going beyond 32 px/fr or falling through the ground when beyond 16 px/fr. I knew of the pixel counts because I move the character one pixel at a time and counted them. To get those answers, it would take until I got into game programming, which started in 2003 or so. And, 30 years after first playing this game, I dove very deep into the game's mechanics, doing RAM searches. From game design experience, I figured that, for example, speed data would have the X and Y values consecutive in RAM, as they're stored in structs which tend to be consecutive in RAM. Finding the fractional part of the current position took a lot more effort because I was anticipating either a 16-bit value or a 32-bit value (variable sizes are powers of 2, for what I've seen). I never heard of 24-bit variables until I overflowed the score in Pipe Dream at an unexpected 8,388,607. Through searching for these, and knowing how variables worked, I finally got answers to those childhood questions. Wanting a video to show off the stunt of not only just reaching that original 91.5 px/fr max speed (doing so with the forest area rather than the carnival area), but also something I only ever got through using debug mode (available on SNES version only): falling through the ground and actually reaching the true speed cap of 128 px/fr. I can't do that with normal play because it requires absurd levels of precision or needing several hours of consecutive play of just holding glide. Consider the collision zone for the eggs being from 1000 to 1016, being at 980 and falling at 48 px/fr. 980+48 is 1028, which is outside the collision bounds, so no collision occurs. I would not hit them and with normal play, there's no redo short of starting all over again with the first bop at 19 px/fr. Enter the TAD (Tool-Assisted Demonstration). With the ability to set the controls on a frame-by-frame basis and to go back and make changes to always guarantee hitting the eggs to keep building up speed, plus the RAM searches so I can see the exact speed, I could push for extreme speed and reach it in record time. Not only that, but I could also guarantee falling through not only the track, but also the bottom ground, so I could reach the true max speed. I also wanted to set up the max speed to occur while Bubsy is visible and most of the way down, to see the 32-scale background move a whopping 4 pixels per frame. The desert is my number 1 most loved background of all 2D games, but only the train has usable eggs. The constantly moving background and lack of any foreground references makes it impossible to line up every time; with seeing the position and the frame-by-frame control inputs, I was able to uncover something silly that I was suspecting would happen but was unsure of the scope. Taking this special video even further is also including the actual controller inputs for each frame, along with showing the values shown in the RAM search. I wrote a program to use the video frames from a screen capture of the playback to display the controller inputs and the key variables. I modified the appearance to compact the data as much as possible and improve the readability, such as adding a decimal for the fractional parts. I've also included vocal commentary to further enhance the video, to better explain some things and the commentary explains everything else.