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). ruclips.net/video/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.
@@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.
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.
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...
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.
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.
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?
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.
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.
This video is AMAZING. Please do more. I love seeing these tricks for creating effects, they really show how clever the programmers were just to make something that today seems so simple. Especially interesting to see you talking about other creators games, and it really shows your incredible knowledge and skill.
I love your channel. Really highlights the logistics and difficulty of coding and developing video games. Also thank you for your contribution to my childhood with some of the games you worked on, I thoroughly enjoyed them!
Sonic the Hedgehog was my first game ever, back when I was in the single digits! As a computer science student these days, its awesome to see what went into that part of my childhood. Great content!
Love the premise. I don't know assembly type code well, and it is very illuminating to see someone who knows it break it down, regardless if you wrote it or not.
Ogni volta che guardo il Bonus Stage di Sonic the Hedgehog, penso a quanto sarebbe stato bello avere un gioco come Sonic Drift con la stessa tecnica... STUPENDO
as a hardware engineer, I too can be sometimes fascinated by stuff people did back in the day when they were seriously limited in what they could work with
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.
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
Really interesting video, congrats for all the hard work you made on it buddy! Checking again the video in slow motion, I have the impression they have actually 4 layers (2 backgrounds, 1 foreground and 1 sprite layer): - Background 1 - as the one you show - Background 2 - containing most of the parts at foreground square) - Foreground layer - just a few objects that appears in front of sonic (like some coconut trees at the beginning of video 0:14 that appears in front of sonic, while others stay behind him)
Very cool explanation of those coding secrets! I'd love to see an explanation on the coding secrets used in Mega Turrican, which is loaded with real time sprite scaling and sprite rotation! So amazing!
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 👍
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.
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): ruclips.net/video/DFq3iQ6wNrQ/видео.html
Had to watch it a second time, but that optimization to use a single sprint instead of the full list of 16 frames makes total sense now that you point it out!
I wonder if the Genesis could rotate 1 tile in real time at any angle instead of using tables, it may be possible given the low resolution (A 16x16 tile would need a 24x24 area to rotate into, that's only 9 tiles for the CPU to rotate) The Amiga could do full screen CPU based image rotations using special lower resolution screen modes like 160x128.
Would like to see you look at Pokemon Gold and Silver, specifically at the compression they used that went from them not able to even fit Johto on the cartridge to suddenly having enough room to include a cut down Kanto, too
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..
I'd love more dives into unique software solutions, it's always fun to see how different people work around a given hardware's limitations. I unfortunately never had a Sega console so I can't request a particular game, but I'm honestly fine with anything you would care to cover.
There was a line of code added in to make the special stage move the way it does. It originally moved smooth, and with some slight editing can be made to move smooth again.
Honestly it's fascinating how different some aspects are compared to the SNES like not using color math or not using mode 7 background transformations for rotation. It's just interesting to see how different things were implemented.
[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.
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.
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.
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
I'd love to see a breakdown of Streets of Rage 2. The "impact" pauses when you hit someone has always fascinated me, and how those massive sprites are handled on the Megadrive at such speed would be very interesting to tear down, as would how you do instances of the same enemy. Something on the enemy A.I. too, becasue how they prowl and move around you seems really hard to code.
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!
1:52 - That's not just shadow object, but a collision wall sprite. It is used occasionally when same level chunk used for various level areas. In some cases it has to be open section where collapsable ledge attaches to. Green Hill has mostly FLOOR collision, with very few wall collision, opposed to later levels.
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?
Love these videos, I have great respect for coders, not sure i could ever be one, since I'm horrible, and I mean HORRIBLE at math, but these videos are fun, its cool to get a feel of the science behind this great art form.
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
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 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. ;)
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.
People actually have found ways to make the special stages spin smoother. There's a few lines of code that have to be changed, which can be accomplished with a game genie or similar device. While it does make the screen spin at a much higher framerate, it doesn't add in any extra frames of animation to the blocks. This gives the effect of misaligned blocks between animation changes. Regardless, it's still way better than the original speed.
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?
these kinda vids are always interesting to me, I love seeing the 'behind the scenes' kinda stuff in old skool video games. would you maybe do Super Metroid for one of these plz? :)
I wish somebody would hack the rom to demonstrate that super smooth special stage technique you talk about, would love to see that and have it running on my mega SG
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?
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.
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.
@@Domarius64 Frame rate drop is very common on any console! Perhaps that video glitch is related to the video recording!
Clint Hobson thanks! i thought it really looked bad and didn't understand what's special about it
I didn't even realize my videos were not running at 1080p until I read this. Thanks.
@@Berserkr01 This guy literally just said why it happens lol
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). ruclips.net/video/DFq3iQ6wNrQ/видео.html
@@RG7621 The Christian Whitehead remake of the game doesn't run on original hardware
Remove one line of code and boom, smooth rotation in special stages.
yup, the code is all there for it, it’s just “disabled” by a single line of code
theres a hack if sonic 1 that rotates the special stages smoothly in real hardware...
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 understood that reference
GO OOOOOON
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.
That and Road Rash are on my "Coding Secrets" wishlist
I like how the spike bridge is actually a model scrolling to give a 3D effect
No, it's not...? Without a special chip in the cartridge of virtua racer, you can only use sprites.
@@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
@@Roach1 Ooohhh, right. Yeah, my mistake.
Oh shoot. Looks like we are caught up now. Hope the updates keep coming anyway.
Though this isn't counting the Sonic coding tutorials which I am wondering if those get an upload here or if that is more for the other channel.
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.
ruclips.net/video/DFq3iQ6wNrQ/видео.html
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.
@@ginky. coulda fooled me. Its maybe not perfectly smooth but seems to be at least triple the frames of animation
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.
Agreed. That batman game is one of my fav titles on genesis yet i never beat it
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...
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.
There's already a video of that on YT somewhere. It's just palette swaps and a single animation of 90 degree rotation.
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.
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?
I'd love to see your take on Astrix and Oblix xxl for the gba. I personally find it the most impressive 3D gba game
It is impressive but damn the sacrifices in terms of perspective and warping
What happened to the És?
Astérix and Obélix
Yup I agree
its fun too
Asterix always had the best graphics even on the Master System.
I'm liking this new channel. Thanks for the insights!
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.
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.
This video is AMAZING. Please do more. I love seeing these tricks for creating effects, they really show how clever the programmers were just to make something that today seems so simple. Especially interesting to see you talking about other creators games, and it really shows your incredible knowledge and skill.
I love your channel. Really highlights the logistics and difficulty of coding and developing video games. Also thank you for your contribution to my childhood with some of the games you worked on, I thoroughly enjoyed them!
For just a moment, based on the thumbnail, I thought we were going to get some coding secrets regarding the film, like a VFX breakdown or something 😂
How to fit Sonic the Movie onto the Genesis.
I'd love to see you unravel Red Zone for the Megadrive! That game was nuts.
Thank you for this video. Sonic 1 was the first game I ever played; it's extremely neat to see it broken down in-depth.
I love these teardown videos! The insight you give into how the games work, through great illustrations, sates many years of curiosity.
Sonic the Hedgehog was my first game ever, back when I was in the single digits! As a computer science student these days, its awesome to see what went into that part of my childhood. Great content!
Love the premise. I don't know assembly type code well, and it is very illuminating to see someone who knows it break it down, regardless if you wrote it or not.
These were always my favorite game hut videos. Glad you are expanding and focusing on a second channel!
Would love to see NiGHTS into Dreams pulled apart
I noticed your channel yesterday, great videos. Also the music was great, hope to see more videos because they are very interesting.
Ogni volta che guardo il Bonus Stage di Sonic the Hedgehog, penso a quanto sarebbe stato bello avere un gioco come Sonic Drift con la stessa tecnica...
STUPENDO
as a hardware engineer, I too can be sometimes fascinated by stuff people did back in the day when they were seriously limited in what they could work with
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.
Such analysis is invaluable. Please continue.
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
Really interesting video, congrats for all the hard work you made on it buddy!
Checking again the video in slow motion, I have the impression they have actually 4 layers (2 backgrounds, 1 foreground and 1 sprite layer):
- Background 1 - as the one you show
- Background 2 - containing most of the parts at foreground square)
- Foreground layer - just a few objects that appears in front of sonic (like some coconut trees at the beginning of video 0:14 that appears in front of sonic, while others stay behind him)
Very cool explanation of those coding secrets! I'd love to see an explanation on the coding secrets used in Mega Turrican, which is loaded with real time sprite scaling and sprite rotation! So amazing!
This is really neat. I love these kinds of videos. Keep 'em coming!
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 👍
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!
Yuji Naka said he was getting sick from smooth special stages, so he added a line which makes it slower.
@@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.
Yeah, there's a simple Game Genie code you can put in to enable the smooth special stages.
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): ruclips.net/video/DFq3iQ6wNrQ/видео.html
these videos are great - I have always wanted to code but never seemed to get my head around it - these are really interesting
Paralax scrolling !! Detail like this is mind blowing and must take the patience of a saint
The video editing is superb, excellent.
I love your vids especially on other programs/games!
Had to watch it a second time, but that optimization to use a single sprint instead of the full list of 16 frames makes total sense now that you point it out!
I wonder if the Genesis could rotate 1 tile in real time at any angle instead of using tables, it may be possible given the low resolution (A 16x16 tile would need a 24x24 area to rotate into, that's only 9 tiles for the CPU to rotate)
The Amiga could do full screen CPU based image rotations using special lower resolution screen modes like 160x128.
Loved this! Would love to see you breaking down more games like this! :D
"Please consider the like, subscribe, bell ringing action every RUclipsr pleads for."
Already enjoying this
I clicked like not only because I really enjoy your videos but also becuase I'm trying to make myself believe I understand what you are saying.
awesome background music and narration too!
Would like to see you look at Pokemon Gold and Silver, specifically at the compression they used that went from them not able to even fit Johto on the cartridge to suddenly having enough room to include a cut down Kanto, too
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..
Fascinating how the hardware limitations of these consoles shaped game design.
I'd love more dives into unique software solutions, it's always fun to see how different people work around a given hardware's limitations. I unfortunately never had a Sega console so I can't request a particular game, but I'm honestly fine with anything you would care to cover.
There was a line of code added in to make the special stage move the way it does. It originally moved smooth, and with some slight editing can be made to move smooth again.
This channel really needs to take off. Very good content
I would love to see a video about maverick chips on the SNES. Especially the CX4 chip that Capcom used in Mega Man X2 and Mega Man X3.
"maverick chips"
"Mega Man X"
i c wut u did ther
Honestly it's fascinating how different some aspects are compared to the SNES like not using color math or not using mode 7 background transformations for rotation.
It's just interesting to see how different things were implemented.
[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.
Just found your channel today, and love what I'm seeing. Subbed. :)
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.
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.
Loved it. Snes doom source code just came out, maybe that one has some interesting quirks no?
Teach me more, can't get enough of this!
Liked and subbed the whooole shabang.
People like you are awesome and i need this sort of therapy in my life.
Meanwhile, Electron Developers:
It takes 15 seconds to load the loading bar, how can we cut this down to just 10 seconds?
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
I'd love to see a breakdown of Streets of Rage 2. The "impact" pauses when you hit someone has always fascinated me, and how those massive sprites are handled on the Megadrive at such speed would be very interesting to tear down, as would how you do instances of the same enemy. Something on the enemy A.I. too, becasue how they prowl and move around you seems really hard to code.
RedZone please Jon! particularly in the context of what achievements they boasted about on the opening screen
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!
1:52 - That's not just shadow object, but a collision wall sprite. It is used occasionally when same level chunk used for various level areas. In some cases it has to be open section where collapsable ledge attaches to. Green Hill has mostly FLOOR collision, with very few wall collision, opposed to later levels.
Yes absolutely more plz plz plz. Love these vids... and triply so when it's about Sonic :)
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?
I'd like to see you do a smooth special stage hack with the amount of knowledge you have about this game and the hardware.
I would love to know more about "Rocket Knight Adventures". There are a lot of incredible effects in there.
Love these videos, I have great respect for coders, not sure i could ever be one, since I'm horrible, and I mean HORRIBLE at math, but these videos are fun, its cool to get a feel of the science behind this great art form.
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
Would love to see more coding secrets for any genesis game plus 32x if you know anything about that. Love your channel
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 would like to see other games produced by others analyzed and explained
Love these videos
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. ;)
Yeah I'd love to see you tackle the hair/animation climbing of shadow of the colossus
Brilliant explanation of brilliant game.
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.
I always wondered how the special stages were even possible.
Watching him play the special stage made me feel physically uncomfortable
Atleast this version of the video's thumbnail doesn't clickbait with movie Sonic...
People actually have found ways to make the special stages spin smoother. There's a few lines of code that have to be changed, which can be accomplished with a game genie or similar device. While it does make the screen spin at a much higher framerate, it doesn't add in any extra frames of animation to the blocks. This gives the effect of misaligned blocks between animation changes. Regardless, it's still way better than the original speed.
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?
ruclips.net/video/zjQik7uwLIQ/видео.html
This might scratch that itch in the meantime
He doesn’t know the SNES as well as the Genesis code.
Check out Retro Game Mechanics Explained
Watch around 4:00 in speed x2 to really see the effect NOT working :P
Dats because the video skipps every other frame and it only draws once every other frame so youre only seeing one side
Or you can see it in 480p
A game like Lords of Thunder on the PC Engine would be interesting to look at in comparison to the Megadrive version.
these kinda vids are always interesting to me, I love seeing the 'behind the scenes' kinda stuff in old skool video games. would you maybe do Super Metroid for one of these plz? :)
I wish somebody would hack the rom to demonstrate that super smooth special stage technique you talk about, would love to see that and have it running on my mega SG
Oh god that special stage still gives me nightmares
I’d love to see if there are any secrets to some of the rendering engines or secrets (if any) behind Vectorman or Gunstar Heroes.
Man, do anything, just keep up the great work
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?
Yugi Naka did some amazing programming for Phantasy Star on the master system, would love to see a video on it
Green hill zone bg is the most beatiful thing
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.
3:54 You could say that it's CLEARLY useful.