I would expand that statement to any triple A game developer actually, no matter the time frame. The extreme optimization of this era is absolutely fascinating stuff but I'm sure programmers nowadays must also use some clever tricks to come up with such complex game mechanics, graphic details and online multiplayer gaming.
I highly suggest you watch interviews of how uncharted games were made. Specifically the train and boat. Absolute genius programmer's of the modern day
Any chance of an updated video where that process is updated? I've read through a few comments and it seems like there's some neat things going on there that would be interesting to see explained!
Hey, I was wondering... Do you think you could do a video where you look at how developers would use 2D sprites within 3D environments? You know, something like the tires in Crash Team Racing or several background/hazard elements in Pac-Man World. Just putting an idea out there. You can reject if you don't think it's interesting.
Sonic 2's source wasn't reverse engineered entirely until long after it was widely pirated. I mean, people were hacking it specifically because of the emulation scene long before even that.
As a kid i thought: well ok, this cant be 3D - it must be a very small animation scaled up to fill the screen. But i couldnt imagine that cartridge space was so scarce back then, that even this was impossible to do as the only trick to achieve this! Unbelievable what coders did back then! Kudos!
I still think they over-programmed it a bit, due to how much of the screen they can fill with solid colored 8x8 tiles, but it could be that that was how it was intended to work but still ran into memory issues even with that scheme.
There's a really weird crash in Sonic 2 in Hilltop zone where if you hit one of the Rexon's at full speed vertically it crashes the console. It has always been a nagging mystery to me as to why in this particular instance out of the whole game there is a crash, there is assembly documentation as to what happens but its beyond my understanding as I am not familiar with the console. I would love to see you do a breakdown of what causes the crash. Not sure that's something that would peak your interest, but anyway as always I love your content!
Not trying to be a grammar nazi, but it's 'pique' instead of peak. You seem smart and articulate, so I thought you'd want to know. Feel free to correct any errors I may have made. 😄👍
Ashley Coleman Acually It was in the first revision the bug exist. If you jumps and breaks a stone and after at the Rexor so it start points to final boss sprite and crashes.
Oh, wow: this is one of the rare cases where you are wrong about something: the Sonic 2 Special Stages do not use horizontal interrupts at all. Most of your analysis is correct regarding the "stretched" nature of the tile graphics in video RAM; but the method by which they take these graphics and merge them together into one image is wrong. What they actually do is use a 128x32 cell pattern name table with specially prepared per-line horizontal scroll table. For scroll B (the background), the pattern names are just repeated every 32x32 cells, and the horizontal scroll is set to create the parallax effect as you describe. For scroll A (the foreground), the horizontal scroll table is set up so that each pair of lines on screen come from a separate 32x32 cell segment of the pattern name table. The first two lines comes from cells 0-31, the next pair of lines comes from 32-63, and so forth, looping back to 0-31 after 8 lines. They also use double-buffering by swapping between two different base addresses for the foreground pattern name table. The decompressor decodes 8 rows of cells and sends them by DMA to the VDP to the inactive pattern name table; along with the game logic, these 8 rows take 2 NTSC frames. After the whole screen is decoded, there is one additional logic update and the pattern name tables are flipped to "draw" the animation frame. This makes it 20/3 frames per second (60/9). One more nitpick, they do not use mirroring on the straight frames of animation; if you look closely, the balls are not symmetric. However, they *do* use whole-screen mirroring for the left/right turns; the decompressor used can do that flipping if needed. One more note, the art is also stored only one row per cell in ROM (and compressed); each row is copied 8 times to the VDP.
As for the compression scheme, it is somewhat simple: It has two data streams: one with pairs of bits of descriptor data; and the other with the compressed data blocks. The 4 different descriptors are basically number of bits (6, 7, 6, and 10 bits) that make up an index into one of 4 lookup tables in ROM. The first two are RLE pairs (pattern name + number of repeats), while the last two have single pattern name tables. The decompressor code, however, is a giant mess of jump tables, and is probably some 5 times slower than it could be.
Out of interest, any idea which way would be more memory efficient? I.e. the way used by Sega or the way in the video? Seems the end result would be the same.
@@chrisdakers3688They would both use the same amount of VRAM; and most likely for ROM as well, but it is harder to be sure due to possibly different compression schemes.
Huh. I had guessed at some of how this worked, but the reality is more complex than I had really considered. Surprisingly, the method in use here is similar to several conceptual methods I came up with for the SNES but never tested. These methods were related to making it easier to draw 3d geometry, and some tricks to make it possible to show a lot more onscreen colours simultaneously by exploiting the weirdness of the SNES high colour mode. High colour mode is 255/256 colours per tile - but if you then also switch it to 'direct colour' mode, you get RGB 332 encoding for the pixels, but can then use what would normally be the 'palette' bits of the tilemap to instead specify the low order 3 bits. This essentially gives 11 bit colour. Still, since we actually have a second layer which is free to use the re and can do additive colour blending, an additional 16 tiles gives the final 4 possible bits. - this works because the second layer is a more typical 8 palette with 15/16 colours per tile mode. Since 'direct colour' doesn't use the hardware palettes at all, we can in fact specify an additional 120/128 colours specific to this layer. Just one problem, 3 bits of colour information are only stored once per 8x8 block, and the extra 4 bits we get from the second layer are also only specified for however many tile patterns we choose to make for the second layer. That means while we do indeed get full 15 bit colour, we only have proper control over it in an 8x8 block of pixels. However, an obvious workaround presents itself. We can use HDMA and change the scrolling offsets (and if nessesary the tilemap base address in VRAM) and actually gain more vertical colour control. Down to the level of individual scanlines in fact. Thus, that gives us 15 bit colour at the level of an 8x1 block, at the expense of some HDMA logic and potentially extra memory to store up to 8 times the usual number of tilemaps. (a tilemap is 2 kilobytes, so 8 of them is 16 kilobytes) There are other possible uses of this, especially in combination with various pixel patterns. One trick that's related but somewhat different is actually demonstrated by a relatively well known Mega Drive tech demo. But, due to it's nature it should actually work better on the SNES. It involves loading a pattern into video memory that consists of every length of line from a single pixel to the entire screen. You need this in every possible colour combination you'd like to use. But really you only need to have a suitable tilemap and a diagonal tile that covers the colour transition you want, plus the solid colours. This lets you quickly draw horizontal lines of arbitrary lengths, though you can only have one such line for each background layer you have to work with. The horizontal scrolling value specifies where on the screen the line begins, and the vertical scrolling value is used to specify how long the line needs to be. This lets you draw arbitrary solid colour patterns. Or, with multiple layers and colour combinations, simple 3d geometry. (flat shaded, though textured is possible if you're very careful) But the cost is that you have to adjust the scrolling registers every scanline. On the Mega Drive I don't know exactly if there's any tools to help with this, or if you have to use a CPU interrupt. But on SNES you have HDMA which is purpose-built for this exact kind of task. furthermore, since you're really only doing single-colour graphics on each layer, you can use mode 0, which has 4 background layers. Then you can use the two 'windows' to specify where a line begins and ends as well, which lets you draw as many as many as 7 distinct lines per scanline, (I think. It's been a while since I checked the logic on this), to the Mega Drive really only letting you do 2. (or was it 3? In reality the last 'line' drawn is also drawing the 'blank' masking to the end of the line on the Mega Drive - on the SNES the windowing hardware can do that instead.) The shapes you can draw with this have some weird restrictions, but in theory some fairly complex 3d geometry could be displayed with little CPU involvement... It's certainly the kind of effect you don't generally think about, but it has some interesting implications. Another SNES specific example is that if you adjust scrolling parameters each scanline on a mode 7 display you've effectively created a 1 dimensional texture lookup. This is tricky to work with, but amongst other things it has the correct properties to run a raycasting engine with texture-mapped walls (with as added bonus you can scale the texture using mode 7 hardware alone). The caveat being that the image has to consist of horizontal 'wall' segments, whereas raycasting based games tend to use vertical segments. (for the obvious reason that with vertical segments it's as though you're rotating in place while standing on a floor and looking at walls, while the rotation with horizontal segments is vertical and there's fewer situations where that makes sense...) Per scanline effects can do some really interesting things if you are willing to think outside the box a little...
These are always fantastic! I’d love to see one about the S3&K Blue Spheres special stage! Just like Sonic 2, I have some ideas how it was done, but I always enjoy your explanations. 🤗
It's not quite as complex, it uses palette swapping. Stealth goes into some detail in his proof of concept for a Sonic 3 port hcstealth.tumblr.com/post/100311283757/sonic-3-knuckles-20th-anniversary
That one is mostly palette swapping, like what was done in mickey mania. There are animation frames for rotating the screen but since everything is moved by 90 degrees, it can be mirrored. Spheres are given a couple of sizes too.
S3 used a simpler tecnique using fast palette color swaps, everything else is just different sized sprites with different palletes and the same chaos gem with different colors and 4 different sprites. Wich is also loaded once the stage is finished (that's why the orbs dissapear, to free space for the gem sprites. It's simpler but makes for a more fun bonus stage
The only thing I could think of was RLE, given the tiles being basically just large areas of solid color. It's a great demonstration, though, of one of my "rules": restriction breeds creativity. Part of while I feel so fortunate to have begun programming in the 8-bit era, and on devices running PalmOS (m68k and eventually ARM processors, 4 or 8MB total storage). My competitor's backup software came in at ~2.3MB (on a device with 8MB of storage) because they utilized C++ and the C++ STL… on an embedded device… while mine was plain C coming in at ~21KB. In one "demo competition" for the full color m505 Palm handheld, I wrote a 1KB Mandelbrot fractal renderer, explorer, with palette animation. I couldn't use the ROM floating point routines, a long jump to a long jump was too slow due to ROM indirection, so I had to write my own IEEE 754 implementation… and still fit in 1024 bytes. Those were the days!
it was actually quite normal in those days.. to script kiddies is might sound awesome, but you wouldn't believe the tricks we pulled in those days. Like self-adapting code and such, just to save on jump instructions, realtime tricks with the electron beam, changing screen resolution in the middle of the screen (on Amiga), etc. Nowadays, these tricks are less needed, but if you still have them under your belt, guess what you can do on modern hardware.
Pretty mind-blowing for its time for sure. I've still a love-hate relationship with this special stage, though; it's the only one where I need save states to beat. Harumph. :c
I directly thought of colour cycling, like used for the Sega logo animation in another of your videos and that I first saw in deluxe paint on an Amiga 1000 bank in the mid 80s
AS far as I can tell, this is literally how modern compression works! The tiles represent all groups of values being used (AKA a word list) and the screen layout uses indexes (AKA tokens), and then you say this is compressed as well, which I'm guessing is run-length encoding. Also, this kind of reminds me of how JPEG compression works, except that JPEG's use a standard look-up table containing blocks of patterns instead of this, which uses a specialized look-up table containing strips of patterns. In other words, JPEG's use 2-dimensional patterns, while this uses 1-dimensional patterns.
This is incredible stuff as always - it’s amazing how ingenious programmers had to be with such limited resources, making the consoles of the time do things that on the surface they shouldn’t be able to. I’m glad that game making is so open to all just now with Unity and so on, but we’re taught to get in the habit of just stretching our legs out and taking all the memory we need :)
This is the kind of thing that both amazes and terrifies me and my life project of developing a Mega Drive game. The fact that this kind of strategy for memory management due to how limited it was, and the code written in Assembler (or something alike) are just... woah.
This is a fantastic video! I find it super interesting how they achieved this using the different palette blocks instead of individual frames of animation. Also. I would love to maybe see a video on the game Star Cruiser one day, as its graphics are incredible for the mega drive.
Hi, cool video takes me back to when I programmed games for the Amstrad CPC464. If you're interested, the CPC was an 8bit Z80 based machine with 3 video modes 2colour, 4colour and 16colour. We used the Z80's screen refresh interrupts to be able to change modes and colour palettes enabling multiple video modes to be displayed on each single frame. As the CPC range did not have C64 style hardware sprites, all graphical rendering had to made by the Z80, so in order to speed up graphic writing to screen memory we had to point the stack pointer to the required graphic memory and "push" the graphics thus saving valuable clock cycles. This also meant graphics had to be stored in reverse! Cheers.
Back then, Sonic games were made by the best programmers in the industry. Nowadays, Sonic games are made by the best programmers of the FAN COMMUNITY (Sonic Mania).
Wow, this is nuts...another thing that always got me in these bonus stages is the huge sprites. Sonic and Tales were giant for their day. It's something you didn't see very often back then. When you did it was generally for bad games like China Warrior (TG-16) or Sword of Sodan (GEN) that centered around huge characters while everything else suffered...or it was a quick gimick like some of Castlevania VI's (Snes) bosses. In Castlevania's case the boss would shrink the second you hit him. In Sonic The Hedgehog 2's case both characters run around the play field as giant sprites throughout the duration of the stage. The rings are large and numerous as is the bombs.
I have no experience actually doing code, but i've tried to learn as much as i can about it casually. Your videos have been the best for that, as they show me whats possible with just a little bit of creativity. It makes me want to study the various compression and memory saving techniques from both 2D and 3d games
I've been playing and replaying Sonic 2 for no joke the last 20 years of my life and I have never, ever noticed that there are checkpoints of different colour in the special stages. Videos like these are the most interesting, just seeing the different tricks programmers used to get a particular thing to work in their game with limited hardware.
Developers in the old days were freaking coding magicians. Achieving so much with so very little of ressources. I really enjoyed it, how in the 3DS port of the game, they seemed to have re-created this special stage with actual 3D graphics and actual depth, while perfectly keeping the original look.
@@Rokabur Sadly, this is very true. Today developers don't even optimize their games anymore, often being programmed very sluggish, since they have so many ressources to waste.......
Thank you for making Coding Secrets its own channel. Super fascinating stuff. The video you did on how Sonic R's fading effect was programmed has turned out to be a serious resource for Saturn homebrewers. As for new videos, you could look at all the crazy things going on in VectorMan and VectorMan 2. Or if you're willing to share some more of your Sega Saturn knowledge, analyze some of Sega's fighting games, like Fighting Vipers or Last Bronx.
I really love your videos man. You explain things so good and with examples of my childhood. Now, years later, I create mods, learn to write code a bit which amazes me even more to picture the whole thing. And I really love the background music. In combination with your smooth voice its just perfect. Thanks man! Keep it up!
This was so cool to see, I have always wanted to know how this effect was pulled off! I'm also curious as to how this compares to effects used in Adventures of Batman and Robin (particularly the Mad Hatter Boss).
Hello, i like your videos. Your voice, the music and really well done presentation is really relaxing. I say this in a good way that i often rewatch these videos when i try to get sleep. :)
Awesome video mate I've caught up on all your coding secret videos now lol, I'm not even a programmer or anything but find these videos really interesting and intelligent some of the tricks you've mentioned is genius, keep up the good work
I figured out the checkpoints were ring graphics ages ago when I lost rings just before a checkpoint. All the rings I lost started to flash different colors as the palette cycled for the checkpoint!
I was subscribed to this channel, why it unsubscribed me? I'm glad that you're still making these; I was a tad worried that i haven't seen a video on quite a while
Excellent explanation as usual. Since Knuckles' Chaotix uses a similar special stage design, I would presume that some of the same techniques would be employed there too, and that one would be interesting to hear an explanation of
Excellent video as always! Now please do one on sonic 3's as clearly it has to be generated because of the blue spheres mode. Sonic 3's special stage always amazed me as a kid. Well, that and the toy story 3d level you already covered.
Insane the amount of tricks they did to get visuals down to the KB's to save cartridge space. Meanwhile, today we're going to render a video that's GB's large and upload it to TH-cam like it's nothing.
Game developers are seriously magicians. I love that they always manage to give us graphics and effects that are actually beyond a consoles capabilities :)
I really wonder how they figured out the block combinations to use. Probably some brute force algorithm to check each rendered frame? In any case, fascinated as always about this tech. Great video and thank you!
I think the only way they could have achieved a smoother and higher-resolution version of the special stage without using too much memory would be with elaborate color palette changing, like in the special stages of Sonic 3 or the moose chase stage in Mickey Mania. A basic version of this would have to leave out any turns or hills in the halfpipe, but perhaps they could add a few frames for these that also utilize constant color palette changing.
If you ever find time you should check out the Pico-8. It's a software fantasy 8-bit console written in LUA. You've got something like 2 million CPU cycles per second to work with, a tiny drop of RAM, and it uses all the classic 2D systems like sprites and background layers. People have already made some 3D stuff in it including a flight sim. As a bonus you can look at the code, graphics, and audio of any game. Games can be completely created on the Pico-8.
Though some of this is outside my knowledge and understanding, it shows me one thing: like the visual effects teams and cell animation teams of the era, the work that these game designers did required a different kind of ingenuity. They did their very best (depending on the how good the team is and the demands of the game) to get the very most out of the medium they worked with. Thanks for sharing this analysis.
This is amazing! Interesting how special stages in main sonic games were so unique. What puzzles me more in classic sonic games is other stuff. In sonic 3 (or it was sonic 2?) there is a unused object in debug mode, a sphere made of spheres, rotating and zooming, and this effect usually put the framerates very low, so it was cool but too taxing on performance
Pretty sure that was from Sonic 3 and was a leftover from testing the spherical special stages, rather then something designed to be used in normal levels.
It's crazy to think a whole game that was programmed with all the ingenuity was contained in just 700KB....blows my mind, that would be like a single blade of grass asset in a modern triple A title.
Considering the horizontal rows are blocks and blocks of solid color it would seem to suggest investigating some sort of run length encoding. Heck, since the colors always follow the same pattern, I doubt you would even have to add colors, just a fixed number of columns. Toss in some pre-calculated huffman encoding for lengths and you could likely really shave down the size. While best for pixel mapping, it might still have a benefit with tile maps.
If you modify your Mega Drive with a 68010 CPU swap, the special stage speeds up slightly, increasing difficulty. I would not recommend doing this hardware mod to your main console, as there can be unwanted behavior in some games, including crashes (Sonic 3 doesn't even get past the title screen), but for other games it can significantly improve performance.
"However, the track obviously isn't drawn in real-time 3D, as the machine doesn't really have the power to do that" But it does have the power to do this: th-cam.com/video/LcT1XIrklhQ/w-d-xo.html Of course I'm aware that running an actual video game is very different than running a demo, but you'd think there'd be a way to make it work, if only for show.
Demos are nowhere near as complex as games as they do not contain the gameplay logic that will gobble up cycles. When he says "The machine doesn't really have the power to do that" he is obviously speaking within the context of a game with thousands of lines of logic code. They are completely different uses of the technology.
It could technically be possible using precalculated lookup tables so the CPU can find the answer to trigonometric equations instead of having to do the calculations itself, saving on cycles, the downside being the table itself will take up a fair amount of ROM and requires an extreme level of foresight from the developer to predict all the calculations the engine will attempt, because the Titan demo is on rails I could imagine this is the method they went with (though I haven't looked at the source code if it's available so I can't say for sure) as they know already what's going to be rendered. I must state that the Motorola 68000 is no slouch, compared to the Ricoh 5A22 of its competitor its night and day (I'm restraining myself from going too in-depth or this comment will be novel-length), it can certainly handle calculating 3D worlds, but not exactly at reasonable framerates, look at LHX Attack Chopper for example, it's impressive but on the border of what some people deem playable, and apparently the developers leveraged the Z80 sound controller for extra support in calculations, though that may only be a rumor.
The game Another World (or the game Flashback) have even more impressive intros, given the hardware limitations but the problem lies more in the realm of memory limitations than anything else. I think they didn't repeat it in Sonic 3 just to make more variations, so it wasn't always the same, I wonder if some md programmes could do a better sonic 2 bonus stage demo fully payable...🤔
The NGPC's native resolution is only 160x152, and SPA's version of the special stage uses even fewer colors for the tube (I count 5), so it might actually have been easier to do than on the Genesis.
@@abraveastronaut The NGPC can handle less colors per tile, but it also has less VRAM than the Mega Drive. The Mega Drive special stage tube graphics are actually 128x112, you can see Sonic, Tails and the BG have twice the resolution. That alone makes the NGPC version higher res. The NGPC also doesn't have separate layers for foreground and background so the blue gradient is fused with the tube tiles. It's not as easy as it seems.
I feel they went overcomplicated for that thing... Wouldnt it be more efficient in size to have the frames compressed as RLE (Run Length Encoding) for the track and just use sprites for the arcs over it? The architecture is probably fast enough to do it... Red Zone intro cutscene was able to cram that in two colors... for far more frames that this special stage...
The problem is not so much the speed of the hardware, but the bandwidth to VRAM. Ir was high, but not high enough to do a full screen art update like you describe. And it would still take obscene amounts of ROM space like that.
I was always very impressed by the Sonic 2 Special Stage back in the day. To me they should have expandad it somehow in the sequels instead of repeating the sonic 3 bonus stage from them on. i love this kind of video thank you
Yeah, considering there are so few colors you could use a static image and generate "movement" by animating the palette, like LCD animation. You could actually use a lot of color and texture with this method if you can manipulate palettes mid-frame. Turns and ramps would have to be real frames though.
I think it was overly complicated. Those animations were simple with low color count and most of the time there were very few changes between frames. it should be possible to simply store just key-frames as 8x8 pixel chunks, where a lot of them would repeat. Then store what changed in next frame, which would update just 10-40% of 8x8 chunks. Anyway as for retro programming goes, I'm most familiar with MS-DOS PCs, where redrawing whole screen was costly, but CPUs were fast, there was a lot of RAM and games weren't that constrained in size. 4-12 MB was the usual size of floppy based games.
My first impression was that it was done with careful palette animations for all the looping parts and a few unique frames to get in and out of transition views. I bet you could get a lot out of normal planar perspective math and then just distort the image into the U shape with horizontal interrupts, but that would make certain parts of the stage that they shipped with much harder to draw.
My big brother had a Mega-CD and when he played this level the first time I vividly remember how *totally blown away* I was We've come an insane way since then.. its actually unbelievable what a home machine is capable of today
This was always my favourite Sonic Special Stage. While it looks bad these days (unless you have nostalgia glasses on), at the time this blew me away with how I thought it looked 3D
I always wanted to know how they achieved the 3D slopes on such a "weak" hardware and very little available memory. As it turns out, the answer seems to involve a good amount of planning ahead. The use of foreground tiles here is pretty interesting. Thank you for sharing your insight.
This LUT with all the possible pixel combinations being used to create this level bg sound very similar to what Jan Sloot's compression method was supposed to be
Programmers during the 8 and 16-Bit golden age were superhuman. All of this is next level innovation to me, and it's almost 30 years old.
Same.
Pretty sure there was something in their coffee.
I would expand that statement to any triple A game developer actually, no matter the time frame. The extreme optimization of this era is absolutely fascinating stuff but I'm sure programmers nowadays must also use some clever tricks to come up with such complex game mechanics, graphic details and online multiplayer gaming.
I highly suggest you watch interviews of how uncharted games were made. Specifically the train and boat. Absolute genius programmer's of the modern day
Restriction breeds creativity
So apparently, it doesn't use horizontal interrupts to squash the screen, but horizontal scroll registers instead. Approx the same result.
Any chance of an updated video where that process is updated? I've read through a few comments and it seems like there's some neat things going on there that would be interesting to see explained!
Every Nth video (every 8th video maybe?) just issue a bugfix video :P
Hey, I was wondering...
Do you think you could do a video where you look at how developers would use 2D sprites within 3D environments?
You know, something like the tires in Crash Team Racing or several background/hazard elements in Pac-Man World.
Just putting an idea out there. You can reject if you don't think it's interesting.
When the two smartest kids in class have differents answers^^
Its a pity you didn't work on N64, you would've performed miracles on a tiny 8MB cartridge.
Game companies: "Damn, our source code has been leaked. Now anybody can pirate our games!"
Programmers: "Oh, nice, new literature."
Sonic 2's source wasn't reverse engineered entirely until long after it was widely pirated. I mean, people were hacking it specifically because of the emulation scene long before even that.
Nintendo right now*
@@mechashadow correct
mechashadow Yeah.. but Sm64 wasn’t Leaked fully just some useless files
As a kid i thought: well ok, this cant be 3D - it must be a very small animation scaled up to fill the screen. But i couldnt imagine that cartridge space was so scarce back then, that even this was impossible to do as the only trick to achieve this! Unbelievable what coders did back then! Kudos!
I still think they over-programmed it a bit, due to how much of the screen they can fill with solid colored 8x8 tiles, but it could be that that was how it was intended to work but still ran into memory issues even with that scheme.
Programmer Naka is a legend
There's a really weird crash in Sonic 2 in Hilltop zone where if you hit one of the Rexon's at full speed vertically it crashes the console. It has always been a nagging mystery to me as to why in this particular instance out of the whole game there is a crash, there is assembly documentation as to what happens but its beyond my understanding as I am not familiar with the console. I would love to see you do a breakdown of what causes the crash.
Not sure that's something that would peak your interest, but anyway as always I love your content!
Not trying to be a grammar nazi, but it's 'pique' instead of peak. You seem smart and articulate, so I thought you'd want to know. Feel free to correct any errors I may have made. 😄👍
Thank you for pointing this out! This is why I am a computer science teacher and not an English one!
@@Killadey English is my first language and I didn't even know that, thanks!
@@Killadey this is the most diplomatically phrased correction I've ever seen. 10/10
Ashley Coleman Acually It was in the first revision the bug exist. If you jumps and breaks a stone and after at the Rexor so it start points to final boss sprite and crashes.
I laughed out loud when you said SEGA used compression methods and showed Sonic in a hydraulic press.
I was waiting to see this video, it was in private this morning!
Right, I was very confused
I saw it tomorrow, I clicked, it was private.
The same thing for me
Patreon Exclusive I guess
@@finalityfran8759 he'd set it to unlisted in that case though
Oh, wow: this is one of the rare cases where you are wrong about something: the Sonic 2 Special Stages do not use horizontal interrupts at all. Most of your analysis is correct regarding the "stretched" nature of the tile graphics in video RAM; but the method by which they take these graphics and merge them together into one image is wrong.
What they actually do is use a 128x32 cell pattern name table with specially prepared per-line horizontal scroll table.
For scroll B (the background), the pattern names are just repeated every 32x32 cells, and the horizontal scroll is set to create the parallax effect as you describe.
For scroll A (the foreground), the horizontal scroll table is set up so that each pair of lines on screen come from a separate 32x32 cell segment of the pattern name table. The first two lines comes from cells 0-31, the next pair of lines comes from 32-63, and so forth, looping back to 0-31 after 8 lines.
They also use double-buffering by swapping between two different base addresses for the foreground pattern name table. The decompressor decodes 8 rows of cells and sends them by DMA to the VDP to the inactive pattern name table; along with the game logic, these 8 rows take 2 NTSC frames. After the whole screen is decoded, there is one additional logic update and the pattern name tables are flipped to "draw" the animation frame. This makes it 20/3 frames per second (60/9).
One more nitpick, they do not use mirroring on the straight frames of animation; if you look closely, the balls are not symmetric. However, they *do* use whole-screen mirroring
for the left/right turns; the decompressor used can do that flipping if needed.
One more note, the art is also stored only one row per cell in ROM (and compressed); each row is copied 8 times to the VDP.
As for the compression scheme, it is somewhat simple: It has two data streams: one with pairs of bits of descriptor data; and the other with the compressed data blocks. The 4 different descriptors are basically number of bits (6, 7, 6, and 10 bits) that make up an index into one of 4 lookup tables in ROM. The first two are RLE pairs (pattern name + number of repeats), while the last two have single pattern name tables.
The decompressor code, however, is a giant mess of jump tables, and is probably some 5 times slower than it could be.
Thanks for the correction!
Out of interest, any idea which way would be more memory efficient? I.e. the way used by Sega or the way in the video? Seems the end result would be the same.
@@chrisdakers3688They would both use the same amount of VRAM; and most likely for ROM as well, but it is harder to be sure due to possibly different compression schemes.
Reeeeeeeeeeeeeee
Huh. I had guessed at some of how this worked, but the reality is more complex than I had really considered.
Surprisingly, the method in use here is similar to several conceptual methods I came up with for the SNES but never tested.
These methods were related to making it easier to draw 3d geometry, and some tricks to make it possible to show a lot more onscreen colours simultaneously by exploiting the weirdness of the SNES high colour mode.
High colour mode is 255/256 colours per tile - but if you then also switch it to 'direct colour' mode, you get RGB 332 encoding for the pixels, but can then use what would normally be the 'palette' bits of the tilemap to instead specify the low order 3 bits.
This essentially gives 11 bit colour.
Still, since we actually have a second layer which is free to use the re and can do additive colour blending, an additional 16 tiles gives the final 4 possible bits. - this works because the second layer is a more typical 8 palette with 15/16 colours per tile mode.
Since 'direct colour' doesn't use the hardware palettes at all, we can in fact specify an additional 120/128 colours specific to this layer.
Just one problem, 3 bits of colour information are only stored once per 8x8 block, and the extra 4 bits we get from the second layer are also only specified for however many tile patterns we choose to make for the second layer.
That means while we do indeed get full 15 bit colour, we only have proper control over it in an 8x8 block of pixels.
However, an obvious workaround presents itself.
We can use HDMA and change the scrolling offsets (and if nessesary the tilemap base address in VRAM) and actually gain more vertical colour control.
Down to the level of individual scanlines in fact.
Thus, that gives us 15 bit colour at the level of an 8x1 block, at the expense of some HDMA logic and potentially extra memory to store up to 8 times the usual number of tilemaps. (a tilemap is 2 kilobytes, so 8 of them is 16 kilobytes)
There are other possible uses of this, especially in combination with various pixel patterns.
One trick that's related but somewhat different is actually demonstrated by a relatively well known Mega Drive tech demo.
But, due to it's nature it should actually work better on the SNES.
It involves loading a pattern into video memory that consists of every length of line from a single pixel to the entire screen.
You need this in every possible colour combination you'd like to use.
But really you only need to have a suitable tilemap and a diagonal tile that covers the colour transition you want, plus the solid colours.
This lets you quickly draw horizontal lines of arbitrary lengths, though you can only have one such line for each background layer you have to work with.
The horizontal scrolling value specifies where on the screen the line begins, and the vertical scrolling value is used to specify how long the line needs to be.
This lets you draw arbitrary solid colour patterns.
Or, with multiple layers and colour combinations, simple 3d geometry. (flat shaded, though textured is possible if you're very careful)
But the cost is that you have to adjust the scrolling registers every scanline.
On the Mega Drive I don't know exactly if there's any tools to help with this, or if you have to use a CPU interrupt.
But on SNES you have HDMA which is purpose-built for this exact kind of task.
furthermore, since you're really only doing single-colour graphics on each layer, you can use mode 0, which has 4 background layers.
Then you can use the two 'windows' to specify where a line begins and ends as well, which lets you draw as many as many as 7 distinct lines per scanline, (I think. It's been a while since I checked the logic on this), to the Mega Drive really only letting you do 2. (or was it 3? In reality the last 'line' drawn is also drawing the 'blank' masking to the end of the line on the Mega Drive - on the SNES the windowing hardware can do that instead.)
The shapes you can draw with this have some weird restrictions, but in theory some fairly complex 3d geometry could be displayed with little CPU involvement...
It's certainly the kind of effect you don't generally think about, but it has some interesting implications.
Another SNES specific example is that if you adjust scrolling parameters each scanline on a mode 7 display you've effectively created a 1 dimensional texture lookup.
This is tricky to work with, but amongst other things it has the correct properties to run a raycasting engine with texture-mapped walls (with as added bonus you can scale the texture using mode 7 hardware alone).
The caveat being that the image has to consist of horizontal 'wall' segments, whereas raycasting based games tend to use vertical segments. (for the obvious reason that with vertical segments it's as though you're rotating in place while standing on a floor and looking at walls, while the rotation with horizontal segments is vertical and there's fewer situations where that makes sense...)
Per scanline effects can do some really interesting things if you are willing to think outside the box a little...
These are always fantastic! I’d love to see one about the S3&K Blue Spheres special stage! Just like Sonic 2, I have some ideas how it was done, but I always enjoy your explanations. 🤗
palette
It's not quite as complex, it uses palette swapping. Stealth goes into some detail in his proof of concept for a Sonic 3 port hcstealth.tumblr.com/post/100311283757/sonic-3-knuckles-20th-anniversary
That one is mostly palette swapping, like what was done in mickey mania. There are animation frames for rotating the screen but since everything is moved by 90 degrees, it can be mirrored. Spheres are given a couple of sizes too.
S3 used a simpler tecnique using fast palette color swaps, everything else is just different sized sprites with different palletes and the same chaos gem with different colors and 4 different sprites. Wich is also loaded once the stage is finished (that's why the orbs dissapear, to free space for the gem sprites. It's simpler but makes for a more fun bonus stage
I always wondered how they pulled of such feats with such tiny cartridges... these videos never cease to amaze me.
This is some insanely smart programming. I chuckled at bit when you asked if we have a better way of doing this. I certainly don't.
The only thing I could think of was RLE, given the tiles being basically just large areas of solid color. It's a great demonstration, though, of one of my "rules": restriction breeds creativity. Part of while I feel so fortunate to have begun programming in the 8-bit era, and on devices running PalmOS (m68k and eventually ARM processors, 4 or 8MB total storage).
My competitor's backup software came in at ~2.3MB (on a device with 8MB of storage) because they utilized C++ and the C++ STL… on an embedded device… while mine was plain C coming in at ~21KB. In one "demo competition" for the full color m505 Palm handheld, I wrote a 1KB Mandelbrot fractal renderer, explorer, with palette animation. I couldn't use the ROM floating point routines, a long jump to a long jump was too slow due to ROM indirection, so I had to write my own IEEE 754 implementation… and still fit in 1024 bytes.
Those were the days!
@@GothAlice Cool story. I also grew up with 8-bit computers (mainly my Commodore 64).
it was actually quite normal in those days.. to script kiddies is might sound awesome, but you wouldn't believe the tricks we pulled in those days. Like self-adapting code and such, just to save on jump instructions, realtime tricks with the electron beam, changing screen resolution in the middle of the screen (on Amiga), etc. Nowadays, these tricks are less needed, but if you still have them under your belt, guess what you can do on modern hardware.
Pretty mind-blowing for its time for sure. I've still a love-hate relationship with this special stage, though; it's the only one where I need save states to beat.
Harumph. :c
I always found pausing the game on and off really helped, albeit was a cheap move.
FX chip: I'm best known for 3d on 16 bit consoles
Sonic 2: hold my 3d
I directly thought of colour cycling, like used for the Sega logo animation in another of your videos and that I first saw in deluxe paint on an Amiga 1000 bank in the mid 80s
Yes, I think you could get a similar effect from some sort of colour cycling for some of it for sure
AS far as I can tell, this is literally how modern compression works! The tiles represent all groups of values being used (AKA a word list) and the screen layout uses indexes (AKA tokens), and then you say this is compressed as well, which I'm guessing is run-length encoding.
Also, this kind of reminds me of how JPEG compression works, except that JPEG's use a standard look-up table containing blocks of patterns instead of this, which uses a specialized look-up table containing strips of patterns. In other words, JPEG's use 2-dimensional patterns, while this uses 1-dimensional patterns.
This is incredible stuff as always - it’s amazing how ingenious programmers had to be with such limited resources, making the consoles of the time do things that on the surface they shouldn’t be able to. I’m glad that game making is so open to all just now with Unity and so on, but we’re taught to get in the habit of just stretching our legs out and taking all the memory we need :)
It'd be quite interesting to know in details how the Phantasy Star 3D labyrinth ( Master System) was done...
I recently played it for the first time and was very impressed by it. It's simple, but stunning, and definitely gorgeous for the time (and system).
This is some insane thinking process going on. So fascinating seeing how games I enjoy were made and the breakdown of them. That's just awesome.
This is the kind of thing that both amazes and terrifies me and my life project of developing a Mega Drive game.
The fact that this kind of strategy for memory management due to how limited it was, and the code written in Assembler (or something alike) are just... woah.
You put your own BGM in the video, but it didn't stop my brain from blasting the music over it when watching the footage hahaha
This is a fantastic video! I find it super interesting how they achieved this using the different palette blocks instead of individual frames of animation.
Also. I would love to maybe see a video on the game Star Cruiser one day, as its graphics are incredible for the mega drive.
This level absolutely charmed me as a kid. It felt so immersive. Baffling to have that known in kb.
I got crazy when I saw the Bonus Stage for first time as a kid... I instantly knew I had the best console in my hands! :D
That is ingenious. To think of it for a star, and then be able to actually do it with the limitations of the hardware. Amazing.
I had no idea how they did this until now tbh. It's insane that they pulled this off on the Genesis.
The Sonic 3 & Knuckles ring stages make me wonder whether an effect like this would be possible using palette cycling...
I always thought it was palette cycling until I saw this explanation.
It has most of the hallmarks of a palette cycling based animation...
ah well. XD
Hi, cool video takes me back to when I programmed games for the Amstrad CPC464. If you're interested, the CPC was an 8bit Z80 based machine with 3 video modes 2colour, 4colour and 16colour. We used the Z80's screen refresh interrupts to be able to change modes and colour palettes enabling multiple video modes to be displayed on each single frame. As the CPC range did not have C64 style hardware sprites, all graphical rendering had to made by the Z80, so in order to speed up graphic writing to screen memory we had to point the stack pointer to the required graphic memory and "push" the graphics thus saving valuable clock cycles. This also meant graphics had to be stored in reverse! Cheers.
Back then, Sonic games were made by the best programmers in the industry. Nowadays, Sonic games are made by the best programmers of the FAN COMMUNITY (Sonic Mania).
Wow, this is nuts...another thing that always got me in these bonus stages is the huge sprites. Sonic and Tales were giant for their day. It's something you didn't see very often back then. When you did it was generally for bad games like China Warrior (TG-16) or Sword of Sodan (GEN) that centered around huge characters while everything else suffered...or it was a quick gimick like some of Castlevania VI's (Snes) bosses. In Castlevania's case the boss would shrink the second you hit him. In Sonic The Hedgehog 2's case both characters run around the play field as giant sprites throughout the duration of the stage. The rings are large and numerous as is the bombs.
July 24th, 2020: Coding Secrets has 22.1K subscribers.
Don't mind me! Just making my mark before he hits a few hundred thousand!
I have no experience actually doing code, but i've tried to learn as much as i can about it casually. Your videos have been the best for that, as they show me whats possible with just a little bit of creativity.
It makes me want to study the various compression and memory saving techniques from both 2D and 3d games
Weird that after seeing all the releases I never saw/was recommended a video with new content. Great video!
I've been playing and replaying Sonic 2 for no joke the last 20 years of my life and I have never, ever noticed that there are checkpoints of different colour in the special stages.
Videos like these are the most interesting, just seeing the different tricks programmers used to get a particular thing to work in their game with limited hardware.
I can not imagine thinking in such a way that you could dream this up. It's insane.
This was really impressive to watch, actually.
Can't wait to see what you bring up next!
I have this game in a original cartidge. I thought it's various backgrounds added to the screen to make the animetion. But THIS, is EVEN BETTER. WOOOW
This special stage was my absolute favorite! I was obsessed with finding those giant rings just to play!
Developers in the old days were freaking coding magicians. Achieving so much with so very little of ressources.
I really enjoyed it, how in the 3DS port of the game, they seemed to have re-created this special stage with actual 3D graphics and actual depth, while perfectly keeping the original look.
Limitation breeds inspiration. Having limits will encourage you to get creative to maximize what you can do.
@@Rokabur Sadly, this is very true. Today developers don't even optimize their games anymore, often being programmed very sluggish, since they have so many ressources to waste.......
Thank you for making Coding Secrets its own channel. Super fascinating stuff. The video you did on how Sonic R's fading effect was programmed has turned out to be a serious resource for Saturn homebrewers.
As for new videos, you could look at all the crazy things going on in VectorMan and VectorMan 2.
Or if you're willing to share some more of your Sega Saturn knowledge, analyze some of Sega's fighting games, like Fighting Vipers or Last Bronx.
I really love your videos man. You explain things so good and with examples of my childhood. Now, years later, I create mods, learn to write code a bit which amazes me even more to picture the whole thing. And I really love the background music. In combination with your smooth voice its just perfect. Thanks man! Keep it up!
This was so cool to see, I have always wanted to know how this effect was pulled off!
I'm also curious as to how this compares to effects used in Adventures of Batman and Robin (particularly the Mad Hatter Boss).
I’d love to see the coding secrets behind Flashback. This was such a smoothly animated game on the Mega Drive, I was blown away.
Except the small video clips when picking up certain items, during important plot/story telling and such. They ran at like 3-5 fps....
I’m fascinated with solutions like these. You never know how much you can achieve by the use of optimization
I always noticed they were scaled up... but never knew how they did it.
Great explanation!
Really interesting video! Would have been nice to learn how they made Sonic and Tails look 3D. That was absolute insanity for video games back then.
great video. Would love more Sonic 2 stuff!
Hello, i like your videos. Your voice, the music and really well done presentation is really relaxing. I say this in a good way that i often rewatch these videos when i try to get sleep. :)
Awesome video mate I've caught up on all your coding secret videos now lol, I'm not even a programmer or anything but find these videos really interesting and intelligent some of the tricks you've mentioned is genius, keep up the good work
0:39 omg they forgot to flip one of the ring frames so the rings are wiggling instead of spinning.
Well seen.
I figured out the checkpoints were ring graphics ages ago when I lost rings just before a checkpoint. All the rings I lost started to flash different colors as the palette cycled for the checkpoint!
I was subscribed to this channel, why it unsubscribed me? I'm glad that you're still making these; I was a tad worried that i haven't seen a video on quite a while
I used to wonder why the background of that stage looked so odd. Damn satisfying to have the answers :)
Excellent explanation as usual. Since Knuckles' Chaotix uses a similar special stage design, I would presume that some of the same techniques would be employed there too, and that one would be interesting to hear an explanation of
Chaotix uses the 32X to draw polygons.
Excellent video as always! Now please do one on sonic 3's as clearly it has to be generated because of the blue spheres mode. Sonic 3's special stage always amazed me as a kid. Well, that and the toy story 3d level you already covered.
My favourite special stage in any Sonic game. Still blows me away today from a technical standpoint and is really fun to play.
Insane the amount of tricks they did to get visuals down to the KB's to save cartridge space.
Meanwhile, today we're going to render a video that's GB's large and upload it to TH-cam like it's nothing.
I am very happy to have stumbled upon this video, as I've always wondered how they made this special stage possible on the Sega Genesis.
Palette swapping was such a brilliant trick, I never quite mastered the art of it beyond simple tricks like a line of water moving back and forth.
Game developers are seriously magicians. I love that they always manage to give us graphics and effects that are actually beyond a consoles capabilities :)
I really wonder how they figured out the block combinations to use. Probably some brute force algorithm to check each rendered frame?
In any case, fascinated as always about this tech. Great video and thank you!
Maybe! I wonder if they could tell the artists what colours could be next to others, so they could avoid some colour combinations that way
I didn't understand most of what you explained but all I know is that it's really cool what Sega did.
The original developers at Sonic Team were really efficient in the way they managed to solve problems pertaining to using space on the Genesis.
I think the only way they could have achieved a smoother and higher-resolution version of the special stage without using too much memory would be with elaborate color palette changing, like in the special stages of Sonic 3 or the moose chase stage in Mickey Mania. A basic version of this would have to leave out any turns or hills in the halfpipe, but perhaps they could add a few frames for these that also utilize constant color palette changing.
If you ever find time you should check out the Pico-8. It's a software fantasy 8-bit console written in LUA. You've got something like 2 million CPU cycles per second to work with, a tiny drop of RAM, and it uses all the classic 2D systems like sprites and background layers. People have already made some 3D stuff in it including a flight sim. As a bonus you can look at the code, graphics, and audio of any game. Games can be completely created on the Pico-8.
Sonic 2 was the first game I ever played. This special stage was always my favourite of the series too!
Oh man I have so many videos to catch up on! I thought you stopped making videos completely after not seeing anything on the GameHut Channel.
I wouldn't be able to tell you other ways. I'm just here because I find it interesting to see how they _(may have)_ did it.
Though some of this is outside my knowledge and understanding, it shows me one thing: like the visual effects teams and cell animation teams of the era, the work that these game designers did required a different kind of ingenuity. They did their very best (depending on the how good the team is and the demands of the game) to get the very most out of the medium they worked with. Thanks for sharing this analysis.
I am always amazed by your content. Keep it up!
I love what YT brought to me today, new sub!
Saga is really good at making pixels look like animations. Very impressive.
I was unsubscribed from you it seems. Love this stuff! Those guys were wizards!
I bet this guy is gonna blow like tech rules
I absolutely love seeing this kind of thing, this is exactly why I subscribed and shared your videos to some friends.
So good I watched it twice
So great to have you making new breakdowns
Coding Secrets - Contra: Hard Corps (USA)/Contra: The Hardcore (魂斗羅ザ・ハードコア, Japan)/Probotector (Europe, Australia)?
This is amazing! Interesting how special stages in main sonic games were so unique.
What puzzles me more in classic sonic games is other stuff. In sonic 3 (or it was sonic 2?) there is a unused object in debug mode, a sphere made of spheres, rotating and zooming, and this effect usually put the framerates very low, so it was cool but too taxing on performance
Pretty sure that was from Sonic 3 and was a leftover from testing the spherical special stages, rather then something designed to be used in normal levels.
Thanks for the tip! I found the video of the spheres ... wacky!
th-cam.com/video/pnZEdZRXz_g/w-d-xo.html
It's crazy to think a whole game that was programmed with all the ingenuity was contained in just 700KB....blows my mind, that would be like a single blade of grass asset in a modern triple A title.
I love channels like this. I myself am going into game developing, and this is just cool. I subscribed.
Im Glad this came through my news feed... This is very interesting.....
Considering the horizontal rows are blocks and blocks of solid color it would seem to suggest investigating some sort of run length encoding. Heck, since the colors always follow the same pattern, I doubt you would even have to add colors, just a fixed number of columns. Toss in some pre-calculated huffman encoding for lengths and you could likely really shave down the size. While best for pixel mapping, it might still have a benefit with tile maps.
This is just mind-blowing. I've always wondered how they pulled that off.
If you modify your Mega Drive with a 68010 CPU swap, the special stage speeds up slightly, increasing difficulty.
I would not recommend doing this hardware mod to your main console, as there can be unwanted behavior in some games, including crashes (Sonic 3 doesn't even get past the title screen), but for other games it can significantly improve performance.
You mean the game was lagging the whole time in the special stages?
"However, the track obviously isn't drawn in real-time 3D, as the machine doesn't really have the power to do that"
But it does have the power to do this: th-cam.com/video/LcT1XIrklhQ/w-d-xo.html
Of course I'm aware that running an actual video game is very different than running a demo, but you'd think there'd be a way to make it work, if only for show.
Demos are nowhere near as complex as games as they do not contain the gameplay logic that will gobble up cycles. When he says "The machine doesn't really have the power to do that" he is obviously speaking within the context of a game with thousands of lines of logic code. They are completely different uses of the technology.
It could technically be possible using precalculated lookup tables so the CPU can find the answer to trigonometric equations instead of having to do the calculations itself, saving on cycles, the downside being the table itself will take up a fair amount of ROM and requires an extreme level of foresight from the developer to predict all the calculations the engine will attempt, because the Titan demo is on rails I could imagine this is the method they went with (though I haven't looked at the source code if it's available so I can't say for sure) as they know already what's going to be rendered.
I must state that the Motorola 68000 is no slouch, compared to the Ricoh 5A22 of its competitor its night and day (I'm restraining myself from going too in-depth or this comment will be novel-length), it can certainly handle calculating 3D worlds, but not exactly at reasonable framerates, look at LHX Attack Chopper for example, it's impressive but on the border of what some people deem playable, and apparently the developers leveraged the Z80 sound controller for extra support in calculations, though that may only be a rumor.
The game Another World (or the game Flashback) have even more impressive intros, given the hardware limitations but the problem lies more in the realm of memory limitations than anything else. I think they didn't repeat it in Sonic 3 just to make more variations, so it wasn't always the same, I wonder if some md programmes could do a better sonic 2 bonus stage demo fully payable...🤔
amazing effects, but virtua racing (genesis version not 32x version) uses an extra chip in the cartridge to show real 3d enviroments.
_Race Drivin'_ would beg to differ.
10 FPS, yes, but it _is_ a fully-3D environment of sorts.
These videos are great! I get ideas on how to save memory sometimes in web applications from watching these. Thank you!
I wonder how they managed to port this special stage to the Neo Geo Pocket for Sonic Pocket Adventure.
The NGPC's native resolution is only 160x152, and SPA's version of the special stage uses even fewer colors for the tube (I count 5), so it might actually have been easier to do than on the Genesis.
@@abraveastronaut The NGPC can handle less colors per tile, but it also has less VRAM than the Mega Drive. The Mega Drive special stage tube graphics are actually 128x112, you can see Sonic, Tails and the BG have twice the resolution. That alone makes the NGPC version higher res.
The NGPC also doesn't have separate layers for foreground and background so the blue gradient is fused with the tube tiles. It's not as easy as it seems.
I feel they went overcomplicated for that thing... Wouldnt it be more efficient in size to have the frames compressed as RLE (Run Length Encoding) for the track and just use sprites for the arcs over it? The architecture is probably fast enough to do it... Red Zone intro cutscene was able to cram that in two colors... for far more frames that this special stage...
The problem is not so much the speed of the hardware, but the bandwidth to VRAM. Ir was high, but not high enough to do a full screen art update like you describe. And it would still take obscene amounts of ROM space like that.
Sonic 2 was my introduction to Genesis. These special stages impressed me GREATLY.
Back then anything that seemed 3D blew my mind.
I hope you do S3&K :p
Been a fan since the first video on the channel
I was always very impressed by the Sonic 2 Special Stage back in the day. To me they should have expandad it somehow in the sequels instead of repeating the sonic 3 bonus stage from them on.
i love this kind of video thank you
Yeah, considering there are so few colors you could use a static image and generate "movement" by animating the palette, like LCD animation. You could actually use a lot of color and texture with this method if you can manipulate palettes mid-frame. Turns and ramps would have to be real frames though.
I think it was overly complicated. Those animations were simple with low color count and most of the time there were very few changes between frames. it should be possible to simply store just key-frames as 8x8 pixel chunks, where a lot of them would repeat. Then store what changed in next frame, which would update just 10-40% of 8x8 chunks.
Anyway as for retro programming goes, I'm most familiar with MS-DOS PCs, where redrawing whole screen was costly, but CPUs were fast, there was a lot of RAM and games weren't that constrained in size. 4-12 MB was the usual size of floppy based games.
Brilliant. Keep them coming!
My first impression was that it was done with careful palette animations for all the looping parts and a few unique frames to get in and out of transition views. I bet you could get a lot out of normal planar perspective math and then just distort the image into the U shape with horizontal interrupts, but that would make certain parts of the stage that they shipped with much harder to draw.
Even after you explain it to me, I have to wonder how they were able to pull this off back then.
because they were extremely dedicated
My big brother had a Mega-CD and when he played this level the first time I vividly remember how *totally blown away* I was
We've come an insane way since then.. its actually unbelievable what a home machine is capable of today
This was always my favourite Sonic Special Stage. While it looks bad these days (unless you have nostalgia glasses on), at the time this blew me away with how I thought it looked 3D
I always wanted to know how they achieved the 3D slopes on such a "weak" hardware and very little available memory.
As it turns out, the answer seems to involve a good amount of planning ahead. The use of foreground tiles here is pretty interesting.
Thank you for sharing your insight.
This LUT with all the possible pixel combinations being used to create this level bg sound very similar to what Jan Sloot's compression method was supposed to be