The water effect starting from 3:03 only really works when viewing the video in 60fps, otherwise the video always shows every other sprite causing the effect to not be visible. So check it on 1080p60 or 720p60 in comparison to any other resolution when whatching that part of the video.
Ah thanks. Was wondering about this. Most people will be confused I think. Makes you really appreciate that all our old games ran a silky smooth 60fps.
Would be really interesting if Jon went back and made a proof of concept of a smoother rotating special stage like he talks about at the end of the video
The game has (disabled) code for smoother rotation, but because of the limitated number of animation frames it makes it look like the blocks move about a bit (relative to each other). ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-DFq3iQ6wNrQ.html
Sonic Fans: "Green Hill! Green Hill! We've had enough of Green Hill, and we don't want to see any more Green Hill!" Jon: "But have you looked at the coding secrets within?" Everyone: "...proceed."
I'd love to see Toe Jam And Earl have a coding secrets dedicated to it. That game had so many layers of random, I'd be interested how the hardware managed to pull it all off.
Yes, please take a look at The Adventures of Batman and Robin + Contra Hardcorps for the Genesis. Those games a full of epic effects and the Batman one even has some next-level demoscene music in it.
@@bonniethehedgefox9139 i think he meant a pre-rendered sprite from a model, but i'm pretty sure that isn't the case, and it was just a talented artist that made it look 3d
Fun fact. The Sonic 1 special stage actually rotates smoothly with a game genie code. Showing what the hardware is really capable of! The issue is that it effects the gameplay physics negatively, so I assumed that's why they took it out of the game. It's not because of data limitations since it's already able to rotate smoothly with only a game genie tweeking the code.
If you look closely at the special stage with this code active, you can see that the sprites for the squares do not rotate smoothly, they are still rotated according to the individual frames stored in VRAM. The hardware just plain can't do it any other way. All the code does is make the sprites *translate* on screen more smoothly.
I'd love to see a breakdown of how the Blue Sphere bonus stage works in Sonic 3. Bonus points for the Sonic 2 3D special stage too. Lots of fun tricks in those.
Interesting thing about the special stages, there's actually a much smoother implementation of the special stage rotation in the cart! There is a romhack available that unlocks this mode, that can be realized on unmodified hardware using Game Genie codes. More information: www.sega-16.com/forum/showthread.php?31767-Sonic-1-Special-stage-Smooth-Rotation-patch. Here are the Game Genie codes in action (skip about 1:40 in to get right to the effect): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-DFq3iQ6wNrQ.html
I have a suggestion for a game I would love to see some coding info about: Earthbound (or "Mother 2" in JP) I have seen many many youtube videos and gaming articles mention the code in Earthbound as some kind of impossibly complex myth able to do many things other games on SNES/Super Famicon couldn't, and that very few people understand the coding language itself today. This is always mentioned in passing, and never any specific detail, and I would love somebody with your insight, who was working during the era, to go into greater detail about this or perhaps share any possible insider knowledge or findings about it you could dig up - or at the very least an explanation from your experience and background. Is it that complex/mysterious?
Please continue making these videos. I usually don’t comment but I’ve watched every video you’ve made. Your talent of explaining things without completely oversimplifying or over complicating the topic is amazing. Irregardless of whether you made the games or someone else had, no one can match your talent of making high quality content while explaining these interesting concepts you and other game developers used when working with old hardware.
"Irregardless" is not a thing. Since this is the first time you're caught and it's a minor offense, I'll let you off with just a warning. Please be careful next time. - Grammar Police.
@@GraveUypo That is not a grammatical error, it is vocabulary error - pedantry police. Also, since language is not a formally structured thing, but something which develops organically, sufficient incorrect usage, or made up words, over a sufficient amount of time will cause the language to change. A dictionary is descriptive, not prescriptive. And irregardless is a fairly old and relatively widespread form of word abuse at this point. Old enough in fact to qualify as an actual word by now.
I love how programmers of classic games deal with the system's limitations. I'm impressed in cases like the parallax effects in 8bit machines, like in the title screen of Castle of Illusion for Master System or the terrain during the intro cutscene of Ninja Gaiden for NES, or even the cloud moving in the backgroung in the last segment of the Craggy Cliff stage in Land of Illusion for Master System. I'm also impressed with the 3D special stage in Sonic 3 (& Knuckles), where the moving ground is just color palette changing, like the Sonic 1's waterfalls Jon cited in this video. Please Jon, share more about these things. It's very interesting...
It fascinates me how various relatively complex tricks from older hardware became standard features of newer ones. For instance, parallax scrolling by scrolling a single image at different speeds was a technique seen on a decent number of 8 bit systems, but it required careful timing. On some systems you'd literally have to count out CPU cycles to know when to change values. Then you got scanline interrupts that made it a lot easier. Meanwhile the Mega Drive has a dedicated hardware feature for it that can specify a list of scanlines on which to change the scrolling register, and what to change it to. At first glance the SNES doesn't appear to have such functionality... But in actuality it has a far more general system for implementing such effects; HDMA. HDMA takes a list in memory of which scanlines it should trigger on, a set of values, and a set of memory locations to write those values to. Thus, while there are a limited number of bytes you can write in one go, (8 hdma channels which can write either 1 or two bytes each using several techniques, if I remember correctly. So you can write to up to 8 memory locations and either write 8 or 16 bit values to those locations), you can pretty much write to ANY graphics register... Meaning you can apply any arbitrary effect that can be accomplished by changing 8 or less graphics registers on each scanline, using an entirely automated system. For an 8 bit system that would have seemed insane. Yet by the 16 bit era such automation of special effects tricks from the 8 bit era was quite common. (the amiga has the same general idea as H-DMA but taken to it's logical extreme; The Copper list; Instead of having a list of data that gets written once per scanline, the amiga copper list specifies a register to write to, a value to write, and how many pixels before the next instruction in the list - as long as there is at least a minimum number of pixels between each operation on the list, you can do stuff like this all over the screen, not just on a line by line basis.) Meanwhile if you go back in the other direction, while no doubt someone would have figured them out eventually anyway, a lot of these effects owe their existence to the Atari 2600. Why? Because the Atari 2600 was built when memory was extremely expensive. And in order to cut the memory used to a bare minimum, it doesn't have a video chip capable of displaying an entire screen of graphics. Rather, it has a video chip which can display one line of graphics. And if you want anything more complicated than that? The CPU has to do it by adjusting what the graphics chip draws every single scanline. So to make anything at all, you're forced to learn to cope with the concept of changing your graphics data every scanline. A technique later systems didn't require, but which, it turns out, could still be used to create special effects above and beyond what the system was seemingly capable of normally...
Yeah, he started out by reuploading all of his Coding Secrets videos from the GameHut channel. He intends on making new Coding Secrets videos from here on out.
c -up, c- down, c - left, c-right hold right hit all 6 abc and 123 buttons together then hit start will unlock a secret menu to custom build all levels add rings ect everywhere select any level the possibilities are endless
Man, I had an Amiga at the time, and that machine had only 8 sprites with a bunch of annoying limitations with regards to sprite reuse and palettes. I always wondered why MegaDrive/Genesis games were so fluid. That system is a real beast when it comes to its sprite capabilities.
@B3ro1080 Yeah, something like that. But doing that is a pain in the ass to code vs just having more sprites. You get the same thing with the NES and Commodore 64. C64 has 8 sprites, but with clever coding people have displayed as many as 40 of them. The NES simply offers the ability to draw 64 sprites. That works out about the same when the programmers are good at what they do... But when the programmers are less capable, the system with more sprites just plain wins out. And yeah, the Mega Drive's sprite hardware is pretty impressive. On paper the SNES seems superficially better. But once you see the list of restrictions the SNES forces on you, the Mega Drive wins hands down. (at sprites at least). Of course, neither compares to a Neo Geo. Neo Geo can draw 384 sprites. These sprites can be anything from 16x16 to 16x512. It can draw 96 sprites on a single scanline. It can scale sprites independently in the x and y dimensions. (it only scales down, but it can scale arbitrarily within that) And it has this lovely feature where you can set a flag in a higher numbered sprite and if it's adjacent to a lower numbered sprite, both sprites will move if you change the position of the lower numbered sprite. In fact the Neo Geo is so good at sprites, that it doesn't bother with traditional background layers. the background layers are also sprites. If you work it out, being able to draw 96 sprites on a line, which are 16 pixels wide each, that's 1536 pixels of sprite data per scanline. for a screen width of just 320 pixels; That means you can cover the screen in sprites 4.8 times, which is useful if your backgrounds are also sprites. By contrast the Mega Drive can draw up to 20 sprites on a scanline, and regardless of how big those sprites are, it can draw only 40 tiles worth of sprites on a scanline. (8x8 tiles - 320 pixels. Exactly matching the screen resolution). The SNES can draw 32 sprites on one scanline, or 34 tiles (again, 8x8 tiles. - 272 pixels. However the SNES only has a 256 pixel resolution. In this case the SNES has just enough overlap so that if sprites are off the edge of the screen it can still show the partial sprites.) One slight weakness of the mega drive, which is why sprite glitches are somewhat more common - besides there being no spare ability to draw sprites on a line if they go of the edge of the screen... On Mega Drive sprites that are completely invisible off the edge of the screen still count as being on the scanline in question. While on the SNES (aside from a weird bug with a specific horizontal position value), if a sprite isn't visible onscreen it doesn't count towards the limit... Of course, the Neo Geo is at heart an Arcade machine. And the home system is rare, expensive and obscure... So it's not the fairest of comparisons... Still, if I could have the 'ultimate' 16 bit system I'd take the background generating hardware of a SNES, Amiga's COPPER, and the Neo Geo's sprite engine, and mash it all together... xD
1:50 As mentioned on the original video, the sprite likely also gives side collision to that wall. 6:24 As also mentioned on the original video, smooth rotation without hindering VRAM seems to have been implemented, but later scrapped. The special stages are already dizzying; having constant rotation wouldn't help. I do appreciate the look into the other games you didn't make, and I can't wait to see what you dig up on the later games in the series!
@@PilaCiu No he did not, it's Chinese whispers (telephone for you US folk). He said something in relation to "motion sickness" (exact words) and it got misconstrued as being "the special stage" that was the cause.
The licensing lockout on later model Mega Drive consoles will always display a certain splashscreen. This system is called TMSS. The Genesis game "BattleTech" will actually produce this splash screen even on earlier models that didn't have it. How does it do that?
2:23 I noticed there are a lot of cases in Sonic 3 where a lot of background elements overlap each other (Carnival Night and Launch Base are good examples). Can you explain how they did this?
Hi Jon - I've always wanted an in-depth into how the Foreground sprites (characters) are collision mapped so that the character is animated on the surface of said foreground (or background sprite) and not falling through the level - To put it more simply (hard to explain in text), how does sonic run on a surface? and what elements of the game are changed when a ledge crumbles away?
From what I've discovered online, the solidity is attached to tiles. How it works in Sonic is greatly detailed here: info.sonicretro.org/SPG:Solid_Tiles I'm also guessing that the "weird" shadow tiles mentioned in the video are there for this exact same reason. The base tile behind the "shadow effect" has no solidity information as it is repeated a lot in the level without being solid, so they needed to put additional solid tiles on top to avoid Sonic running through those sections.
Now that we're up-to-date on Coding Secrets, could you explain Castle of Illusion's 2nd stage section where it has this map flippin' effect when touching a box? There's also an improved version of this effect on Dynamite Headdy's 8-4 Vice Versa level
I was just about to type the same thing. Decided to search for it and it seems it's a re-upload from their GameHut channel: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Br5NfeQsLQo.html
Apologies, I missed the "Future of GameHut" video so I thought you had stopped posting for a while. Running across all the videos from this wonderful, new channel I was thrilled to see it coming back! I'll not lie, I don't understand coding, nor why it has to be so impossibly hard to get into, but I am in awe of the things I see and hear from people such as yourself, John Carmack and others. The Sonic R video, I knew was going to be mind bending, but I cannot believe how complicated the Sonic 2 bonus stages were! They look so simplistic, from a graphical standpoint, but to hear about the tech that went into making them work is just incredible! In terms of other games that I'd love to hear code breakdowns on would be 1) Red Zone(of course), 2) the bike driving stages in Jurassic Park: Lost World, 3) how the Sega CD's extra ram allowed for extra animation in games like Samurai Shodown and ET:CftDS, 4) How the Sega CD's hardware scaling was used in any given game, 5) The 32X's unseen potential, 6) How Sega pulled off Panzer Dragoon on Game Gear(there is talk about using two different screen refresh rates to pull this off), 7) Sonic CD, it looks amazing, is it something that could have been done on the Genesis, assuming cart space wasn't an issue, or did the SCD hardware play a part, 8) The Genesis, and end to the rumours: Can it do 64 or 66 colors at a time(without tricks), 9) Hard Driven', how did Tengen pull off this polygon-based game so early(and why do I still laugh when hitting the cow!?), 10) (mercifully, the last one)What do you feel is the most technically impressive game on the Genesis, and why?
The video I love to see you doing is a doom Saturn,, what went wrong,,, and how you could have improved the game.... it would be awesome....maybe some info on the 32x port,,, maybe through in something on the wolfenstien 3D port on the genesis..... I’m rambling,, but it would be amazing to hear your perspective on this... with gifts like yours and the knowledge you have.... it would be spectacular..
hey I like the sonic movie's sonic cameos but can you also add elements related to the game in the episode? just the movie sonic doesn't really convey what the episode is about!
Can you look at The Adventures of Batman and Robin game? (The Genesis version or SNES version, although they're completely different games) The Genesis one has such an impressive intro that there has to be some coding secrets in there, and the SNES one's roller coaster fight seems to use similar graphic techniques to the moose chase on Mickey Mania.
SNES's roller coaster fight when Joker is throwing bombs is Mode 7 with perspective by HDMA. Sometimes just Mode 7 alone when the screen rotates. I think that one of the best tricks of the game is the 3D building when you're falling with catwoman. Looks like polygons, but is some windowing effects.
Great video! You mentioned water transparency-I came across another RU-vid video which was discussing the "console vs. emulator" debate, and the presenter pointed out how the foreground waterfalls in this game (and/or Sonic 2?) used an alternating horizontal pixel pattern such that when viewed on a composite monitor/TV, the chroma artifacting and dithering would cause a perceptually clean "transparent" effect, whilst viewing the same effect with an RGB monitor/emulator would merely result in sharp vertical lines. It's similar to the dithering you used in the Sonic 3D intro, correct? And if so, did you explicitly anticipate the use of composite video dithering, or was it incidental?
1) Please unpack Road Rash 3! Although the framerate isn't very high, it has layered background scrolling and a lot of other impressive effects, possibly even software-coded sprite scaling (they could just be incremental sprite variants, but it really doesn't seem like it in action) 2) The Special Stage in Sonic 1 can actually rotate much more smoothly with just a couple simple Game Genie/PAR codes. It probably doesn't increase the actual sprite frames, but the whole movement is as smooth as butter. There's also a bug in the Sonic 1 special stage; Sonic's jump height is always maximum, but it was supposed to be variable just like when you're in the normal stages.
6:36 In fact, rom hackers already did that. For example, in a rom hack "Sonic: The Ring Ride 4" the special stages are actually smooth. There are also some other romhacks which does have smoother squares, but I don't quite remember which else, sorry...
I love seeing how programmers trick hardware into doing what seems impossible. Newer systems are inherently capable of so much, it's almost boring, even if they look objectively better.
So is this channel exclusively for the coding secrets stuff? It was confusing seeing this video when you already uploaded it 4 months prior on the game hut
3D Games and Big LED TV's where a step back for those pieces of Art. That is why i will never play my good old Console Games on Modern TV's. And that 30fps Horror until now with PS5 was... it was Horror! I am mostly play on PC and my Good Old Consoles. For Modern 3D Games 144Hz Freesync! i will never ever go back! Thank you very much Sir! Sonic is and will always be a Big part of my Gaming Legacy. S E G A !!!!!!!
Love these vids! It's probably just as rare of a talent to break these sorts of technical things down as it was for the original developers to be so clever with the hardware they were working with at the time.
Hey, Jon, there a semi-known game I'd like you to examine, if you still maintain this series: do you know Brian the Lion on the Amiga? It managed to pull so very nice "console" tricks on the OCS hardware such as a fully rotating intro screen, a "tube background" level with big chunks of rotating scenery (in bonus stages), and probably far more colours than the 3+3 bitplanes allowed.
Sonic 1 sprite code is fun to play with . At "SEGA" screen press Up , C , Down , C , Left , C , Right , C , hold A , press start . If you hear a bell it worked (CONTINUE HOLDING (A) until the game begins !!!). You can now change sonic into different sprites and place them onscreen . Also pause hold (A) and play in slo-mo . Or reset game by pausing and tapping (A)(start) repeatedly
Game requests: Basically anything where really clever use of memory to save resource and clever game optimisation to run on slow hardware such as portable. Tetris, All Sonic & Mario 2D games, Crash Bandicoot, The Last Of Us, Daxter PSP, Tekken 6 port on PSP.
I would love to see more of everything! As far as to the what...name the game from then to now and I'll love it. Gunstar Heroes, Lunar Silver Star Story, Phantasy Star 1-4, Streets of Rage 1-3, Street Fighter 2, Metal Slug, Metal Gear (Nes), Strider (Gen), Ghouls N' Ghosts...I can do this forever. ;)
1:50 from what I've heard this wall is a sprite, because the background layer is using a chunk that on its own has no collision on either of the sides, so this sprite wall was added to prevent Sonic from falling down into the lower section of the level, so it's more than just aesthetic purposes they probably could make another chunk for this section, but got a little lazy I guess 😅😅
It's a longshot, but Ultima Underworld deserves a thorough analysis, inspiring Wolfenstein 3D and Doom. (Carmack saw UW and thought to himself, "That's terrible. The performance is sh*t. I can do better." and worked out BSP map traversal to make it so-not worrying about things you can't see is a great speed boost.) Doom is a great FPS, but Ultima Underworld already had multiple/variable light sources, variable map geometry (destructible mining surfaces), true 3D objects in-world, in-world simulated physics, RPG inventory interacted with by dragging world objects, dialog trees, running/jumping and physical puzzles, looking up and down, true projectile/missile weapons v. ray-cast hitscan guns… I'm starting to sound like a playthrough of Game Developer Tycoon. Its engine also later went on to serve for System Shock. ❤️ Looking Glass Studios.
I think the special stage rotated like it did to make it doable for the player. It can go faster, there's a Game Genie code to smooth it out and it also accelerates when you grab the emerald or hit a goal block.
Could you do a video explaining the details of how you programmed the movement in Sonic 3D? I've always had trouble doing isometric ramps, how do you calculate the players depth position when he's going up or down a ramp that is occluded? I've never been able to figure out how you do that without a full 3d engine. Surely there's some trickery that I'm missing. Even Marble Madness I can't figure out the trick. They managed to pull it off on C64 and Spectrum games too so I'm missing something obvious I think!
I don't understand between 1/3-1/2 of what you are saying but it's really interesting! I remember noticing the effects you are talking about but didn't/don't have the language to explore/explain what I was/am looking at. Good work 👍
Question about the special stage rotation. There is a small hack you can do to the game which involves removing one line during the special stage rendering loop. When this line is removed, the special stage moves very smoothly and fluidly. Wouldn't there have to be more sprites for these extra rotations? If you're curious, you can use this cheat code on a US Rev 00 version of Sonic the Hedgehog to activate this effect: ATBT-AA32 RG2T-C6XA RG2T-C6XC Or, in a Sonic 1 dissasembly, going to "SS_ShowLayout" and removing this: andi.b #$FC,d0 I don't know exactly what this operator does, but I'm guessing that it could be an angle comparison, in order to make the stages less likely to cause nausea while playing. I would love your insight into this though
Now you say it, I remember reading about the same parallax scrolling in a a book on AMOS for the Amiga. Where, with clever artistic tricks, you don't let them overlap. Subtle genius.
4:00 the flickering water would probably, given the low refresh rate of TV phosphors (ala "ghosting"), look fairly solid transparent (and pulsing) instead of flickering on and off. This random YT video recommended to me shows ghosting (it would be less pronounced on a proper TV): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-P013sPRPSvw.html
[1:49] The reason for Sonic Team using sprites and not the background graphics for some of the terrain was because each act is made up of a limited set of "meta-tiles". Even 16-bit consoles can only hold so much, so to save memory, you'd naturally want meta-tiles to be the building block for the levels, saving memory as well as, potentially, time, since it's much quicker to build levels out of huge chunks of terrain than out of separate 8x8 tiles, especially large levels.
Something i found while messing with debug mode is the following: Moving extremely, *EXTREMELY* fast makes the level data get loaded too slow, causing it to just pull from memory outside of the level data. I think this is only possible in special stages, but since some tiles can be interacted with, you could technically modify memory, possibly triggering things like the credits sequence? To prove it, look at the blocks when you fall into memory. They flash colors extremely randomly, some of them have no collision, and sometimes other tiles don't behave correctly. That's proof that it is an area in memory. Entering debug mode while inside of memory seems to refresh everything and/or put you a little bit outside of the usual level borders. oh cool you read the whole essay, congratz
Interestingly, the remastered version of Sonic 1 on mobile and in Sonic Origins has smooth rotating for the special stages. It sounds like an upgrade on paper, but it completely changes the timings for how they're played. For example: In the original, you can get away with not inputting anything at all until you reach the room with the Chaos Emerald, but in the remaster you'll just fall into the exit if you try to cheese it like that.
Have you heard of the MSX computer? Or the Commodore 64 some demos for them do full screen rotation at high speed, could you possibly explain how this is done, I just subscribed to your channel, I’m a programmer and I liked the explanation you give
There is a video on YT where someone changed one line of code in the Sonic ROM and the special stage rotated at 60fps but because of the limited number of animation frames, the blocks jiggle about a bit. Would love to see real hardware doing this with more frames now you’ve said it’s possible. As for future videos, I’d like to know how tile based consoles like the MD achieved pseudo 3D Racing games.
There’s a romhack out there where the coder removed one line of code from sonic 1 and the jerky special stage became butter smooth. It definitely works!
I would like an explanation of how levels such as Underwater Labyrinth (and later Sandopolis Zone, in Sonic & Knuckles) allow for infinite water (or sand) sliding, as in, Sonic might fall into a water slide (which he man exit by jumping, provided that he lands on a "dry" platform) which drops him into another water slide and so on ad nauseam.
You're half right at 1:40 but that sprite also acts as a solid barrier object. The higher section on the left is actually a separate 256x256 level chunk, and some other chunk flow into it at the same level, where as this on is lower. Without that highlight object, you'd run straight through that wall. It's hard to explain, but hopefully you know what I mean.
Genesis games, especially outside Sonic titles, are so neglected by modern game culture. It's awesome to see more content about them, much less from someone who has professional experience with the system. I'd love to see more videos about games you admired or found professionally inspirational from that era and what makes them tick. I always enjoy hearing shop talk, especially "oh dang, that's cool!" moments about technically impressive things that might not be obvious to players.
I have an alternative answer for why they didn't make the shading blocks part of the background layer, or why they didn't use a decompression routine to make the rotation in the second stage smoother: time. These both seem like the kind of "make it work" solutions that tend to stick around when a deadline shows up. That's probably a (slightly nerdy) video suggestion: your least favourite "make-it-work" solutions that used a bunch of processing time, but nonetheless made it onto the final master.
A question that has come to my mind... how would Sega go to do the seemingly 3 planes scroll in Sonic3? In Sonic3 there are many levels where it looks like there are more than the usual foreground and background, and would look those aren't sprites with different priority either. Keep it up! 😃
I recommend Mortal Kombat 3 for the Genesis. I’m interested in that one because of how well Sculpted Software was able to achieve much better results than Probe Softwares butchered ports of MK 1& 2 which were very disappointing. I’d like to see how Sculptured Software was able to pull off the things that Probe couldn’t.
I'd actually really like to see someone replicate this on SNES (maybe add it into that brilliant SNES Sonic demo that already exists). I initially thought it would be hard, but then I remembered the SNES can actually put 128 16x16 sprites on screen at once, which 48 more than Genesis, as well as doing 2 background layers with ease, so it should be pretty easy. I even think some of the static block could be put on a third background layer if necessary, which again, the SNES does 3 background layers as standard, so it should be able to take advantage of that here too. As long as the SNES can do this stuff without slowdown, which might be the only snag here, I think it could not only do this bonus stage as it but actually make it look even better too, with more colours and proper transparency and that like. And, given that the stage blocks are all done with sprites, the SNES could even do some sneaky background switches into Mode 7 and sometimes have the entire background layer warp and sway and zoom in and out for a very cool additional effect, before switching back to the normal layers again. Edit: In fact, it could even switch all the blocks out for a Mode 7 background version of the same effect at times, switching the colour palette so the blocks on the Mode 7 layer change colour as per normal, and then it could use all those now free sprites to do whatever other impressive effect, and then switch back to normal again a bit later. And so on. So, yeah, I'd really love to see what someone could do with this bonus stage concept on SNES.
I find these so fascinating because I grew up with liking Sonic more than Mario, didn’t know why other than I thought it looked better. Not too long ago I watched how Crash Bandicoot was made as well. It’s amazing what coding tricks had to be done to make these video games so awesome back in the day. Truly genius.
Great video mate👍 didn't they also do some amazing trickery with 'borrowing' of animation frames from the 3D SEGA logo to create the 3D clip of Sonic and Knuckles running in 3D through the stage at the load up?
I asked this on the original post on GameHut, but I never got a response on it... What systems are you willing to cover for games to add to this series? Because if it's Genesis only, then I've got nothing. (I can do PS1, though.)
Please explain how sound compression worked backed then? whenever SEGA did voices in their genesis games they always sounded significantly better then when other games did it.
If modern games squeezed performance and visual quality out of hardware as efficiently as games like this one, modern games would look much, much better than they already do.
I looooove this kind of stuff!!! I would love ot see a video technical comparison between an early sega genesis game (soon to its release date) and one that was much more advance later in its lifetime... like Toy Story's 3D segment for example.
