Having played this game countless times, I had never noticed the screen was mirrored. To me, that is the best trick in this bag full of tricks. Would love to see sister episodes for stuff like the special stages in Sonic 3D and the rotating tower in Mickey Mania.
Yeah, someone made a game for Macintosh (I forget which) and they used the same technique there. They mirrored the top/bottom of the rooms, and then drew the game objects over everything as another layer.
Not only that, the alien sprite is also completely horizontal and floating halfway between the floor and ceiling. So in this case, everything on-screen is still 100% mirrored horizontally.
Zack, you're talking about a different thing than James and Karanthaneos. At 6:11 there's the potentially mirrored spinning thing. But at 6:07 there is a non-mirrored thing that looks like it could have been a wall texture, but wasn't.
While assembly code is a bit beyond me, I loved the breakdown of how it was coded, and how it was optimized for the hardware. A very well put together video. Please do more!
Definitely wasn't expecting you to follow this video up with a literal tutorial on how to do raycasting on a Sega Genesis. This video is as impressive as the graphical effects it covers. Also, only 6 and a half minutes it took for you to explain these things too. That is awesome, man. Thank you for this :)
I miss the days where programmers had a responsibility to ensure that their code ran at a decent framerate. Nowadays it's just "Our game runs at 10fps? It's clearly your fault for not having a ten thousand dollar computer."
+Retro Frontier I only have the utmost respect for programmers who dealt with those limitations, but I wouldn't belittle the achievements of modern programmers to that degree. The hardware may have gotten considerably more powerful but what players demand of their games have also skyrocketed. Plus you mention Game Maker, a program I feel I'm an expert at but not one I'd consider myself a programmer from. GML isn't C++, which is actually used in nearly every modern video game. They share some similarities and lord knows both are easier than assembly, but pretending they are on the same difficulty level would be quite misleading. And even then while a terrible programmer could make a game in a few hours with Game Maker, an expert of the program could pull off things in the same amount of time that the other programmer wouldn't think Game Maker was even capable of. Also if you're aware of lower level modern programming languages like C and C++, you'll know that there are still many problems like the ones seen in these videos you still have to contend with. The ease of tackling them may be mitigated and the amount of memory you have to work with may sometimes seem infinite, but that doesn't mean having issues where you have to count specific numbers of bytes don't happen.
If you look at Nintendo, you'll see this spirit is not gone. Just look at MK8 and BOTW on the Wii U. Nintendo always saves a buck on the hardware and spends it on making the software that much more efficient for their consoles!
This is only the case in PC land. Console developers still have a responsibility to make sure their code runs at a decent framerate on the platform they're developing for. And, just like in the old days, they meet that challenge with varying diligence and success.
I was really hyped for LEGO Worlds when I saw TT developed it. I'm not sure where it stands in technical achievement, but the usability and controls were very underwhelming. Company names stay, but the developers change.
@ I don't really know what's the power of any iPhone, but the better ventilation that the switch has allows it to work a lot harder. Although this may not be an objective observation; personally I don't find TT's LEGO-themed games all that complicated. Surely there's some serious math involved in optimizing which pieces need to get rendered, but it's rather simple compared to other AAA games, and the hardware is much more forgiving for various small inefficiencies that they could make. The only company that really amazed me lately for its runtime efficiency is Id. And again, as a PC user I was let-down by the controls and contents rather than image quality (graphics weren't that marvelous, but I don't care much for that - LEGO is all blocky anyway). Maybe I grew cynical of good-old companies after observing some of them going down dark paths. Maybe TT has incredibly talented programmers. For now I just think that their products are barely worth mentioning in conversations with my friends.
What a fascinating video! I love seeing behind the scenes stuff like this! When you mentioned that the screen was mirrored, i had a jaw-dropping "OH MY GOD" moment! I had no idea, it didn't look mirrored and i never would have noticed had you not pointed it out!
Wow, this was awesome! Great work, Jon. So glad you're sharing these super cool and innovative old tricks that were used on those old systems. Keep it up, sir. Great work. Would love to see more of this in the future. :)
More! That was fabulous. I'm a 38 year old engineer, so I'm old enough to remember playing, and now smart enough to understand it - it's like the Goldilocks zone for enjoyment of this stuff. :)
"Write in the comments if you want more or less of this kind of thing." Who would want less? These videos are fantastic. Wow at the tricks you used to get this demo to run up to 58.4 fps! Especially that macro trick. Really would like to see more on Genesis Toy story if possible. The game is a technical marvel on the Genesis. You guys did some neat audio mixing tricks with that game too.
Amazing video and it's super informative, absolutely if you get enough requests other than myself please publish more of these, the scene really needs more ppl like you my friend.
I don't pretend to understand all of this but please do more stuff like this. Anything is nice, but this is great. Also if you have anything on Toy Story 2 you'd be pressing some of my oldest gaming nostalgia buttons. And if not, thanks anyway just for being part of the company that made it.
Gotta love unrolling loops. A friend made a generator, which generated 68k source files containing huge unrolled loops, to render each scanline of a scaled image at any scale factor (imperfectly, there were a few bugs), and I created the code that will scale vertically by skipping or repeating some lines, and it turns out, I can scale 4 images simultaneously where 1 image is generally large and 1 is very small, and DMA all the art in 30fps! And on top of that, because it was for a menu, and the code was just small enough, I was able to Kosinski compress the code (Actually, I also wonder what Kosinski compression would have been called back in the day?). It did create for some very awesome effect, and again show how much a beefy CPU can do. Also, really liked the high production value of the video, keep it up! More technical effect videos would be cool to see.
Yeah, when writing shaders, I often unroll my loops and I remember when I started in scratch (many years ago) we would manually unroll loops for faster 3D rendering (though it was very primitive).
Looking back into this, this is probably the best Coding Secrets video I have ever saw. The music, length, and best of all, the Lego HUD all combine to make this the most detailed and beautiful video on your channel! I would LOVE to see more of this editing (whenever possible)
1:31 - Ultima Underworld did it first (in fact, John Carmack has mentioned that Wolfenstein 3D was inspired by an Ultima Underworld demo), although they didn't simplify it quite so much (it supported other types of deformation).
This channel is gold. You're a genius, Jon! Often times for me, lack of funds for certain projects calls me to be more creative, but in this case, hardware limitations really pushed you guys to push the boundaries and create something amazing from very little. Very very impressed!
This is absolutely fascinating. I'm a developer in another industry and I find tales of 16-bit development to be interesting and actually... inspirational. You guys (the people that coded the games of my youth) are actual heroes to me.
I really like how writing a huge amount of code instead of a loop, WAS the solution back then, as cartridge space and cycle times were much more important to consider. Now-a-days it's perfectly fine for code readability to cause a slight "performance" hit at run-time. Just goes to show how platform limitations really have an impact, and that modern clock speeds and memory are insanely higher now. Really enjoyed the video, would love to see some more of this "breakdown" type of video.
4:30 Wow, actually I hadn't even noticed that it was mirrored. That is such a simple yet clever trick. But then there's still a non-symmetrical wall at 6:07 ..
this stuff is just facinating!!! you sir are responsible for many of my favorite childhood games. I'm so glad you're willing to share this incredible insight into what you were thinking!
It seems so simple when explained that way, but someone had to look at the issues they were facing and come up with all of these solutions. This is pretty crazy, I love how this channel presents its content.
Have to say, amazing videos. Cannot believe I've not seen anything else like this before on youtube. I find it incredibly interesting, especially with the limitations of the technology at the time and you are very articulate and explain things so well. I haven't the foggiest how to write or understand code by I fully understand what you are doing and trying to achieve with your videos. Great work!
Loved this. Always wondered how tricks like this were pulled off on 16-bit hardware. Blown away at how clever it all was. I don’t know any code, but his explained it in a way I could understand, so thank you!
I LOVE this kind of thing!!!! I do like how some of your later videos break things down in a way that is easier to understand for non-programmers, but as a programmer this stuff just speaks to me in a wonderful way - these days, it's always about writing the least number of lines of code to accomplish things for ease of maintenance (It is for me, at least!) but it's fascinating to see how things used to be, when space and runtime were both extremely important and had to be managed when writing this stuff.
I'm discovering your channel and as a younger developer but raised by an Amiga 600, I'm craving these first-hand stories of 16-bit game development. Thanks a lot for sharing, hoping to see more!
I'm currently learning Python as my first programming language, and although the code in this was at a much lower level it helped me understand why code is programmed a certain way at a higher level. This is brilliant stuff, thanks.
Woooow! So the screen was mirrored! Mindblow!!!! I loved so much this game as a kid! And I still do!! I always bring Toy Story when i'm talking about Genesis vs. Snes! Also, that mod player is amazing too! AMAZING video! I would love to see more about the development of this game! Subscribed!
Oh god this is just brilliant! Early 3D was so tricky to implement that it wasn't possible without all sorts of hacking around. Even for PC during the years when Megadrive was around, Doom and System Shock were about as much as you could ever get, for 16-bit consoles it was even stricter. Also awesome job with revealing the trickery of game engines. There will always be interest in that kinda stuff just like people still keep releasing Megardive demos (Overdrive and others). And since code breakdowns of old games are so rare (I can only remember 1 dev for megadrive ever sharing his code - Chris Shrigley), such content is always unique and insanely valuable among us enthusiasts. There are also emulator developers who are always interested in insider info, so don't be afraid to dive as deep into code geek stuff as you can or wish, there will always be interest! Thanks for your channel, keep on kicking ass!
More! I don't know about the technical side of games but watching your videos over and over helps me to understand more and more, a "byte" at a time, lol.😃
I love your videos. I'm not saying modern games don't use any kind of trickery to make things work, but you all had to be so much more inventive with such intense constraints. Nowdays a lot of publishers don't even require devs to compress the file size for digital downloads of console games. It's fascinating how much engineering goes into some effects we took for granted as just technological evolution as if it's something people didn't work on.
You're like the Vsauce equivalent within gaming science, showing and telling in such a way that a lot of people understand the concept of what you're talking about. love your content, keep it up :)
I like to speed up the video to 2x during the code segment, because it already makes no sense to me, and hearing it make no sense at double the speed is very funny to me
this is the gaming stuff i really enjoy. it would be cool if you did some videos just rambling about your experience making a particular game, and any memorable coding challenges or other notable stuffs. like your opinion on Sonic 3D and if you think criticism is just misunderstanding the game or etc not too many (i've seen nobody else) genesis devs are on youtube, so this is a great channel you got going indeed
I agree, there is a video of Genesis Aladdin developer playing his game while commenting all sorts of stuff about it, and a similar one with Symphony of the Night. It is always very enjoyable to watch such stuff.
Wow! It only took me 22 years to get to know how some parts of the Toy Story game were made :D. I must say that the first time I saw that level I was very confused of what to do, nothing in that level made sense to me for a while. What great memories this brings :D Thanks for sharing, please do more :)
A sincere thanks for choosing to share Your knowledge, and taking the effort to make these videos in order i to do so. And I personally appreciate how You "get to the gist" and present the general principles in an easy and relatable way, it almost feels as if You could have figured it out Yourself ;)... Best regards
Incredibly interesting. Please share more of these types of videos. Back in the day, there was certainly a bit of an obsession with games players about the special effects seen in games from yourselves, Treasure, Konami and other great coding houses that seemed to border almost on witch craft compared to what most developers put out.
This is what games in the 8bit/16bit era so much fun. The developers were always facing hardware limitations and had to come with hacks or other ingenious ways to overcome them. This led to great games, as the effort would really shine through.
This kind of stuff is so amazing and interesting to me. I know nothing about coding but I feel like you wouldn't see things like this anymore with modern games because machines are so much more powerful and memory space isn't so low. Awesome to see the tricks in the background to make these techincal scenes with such limited technology of the time.
God, i love good ideas. I think all programmers can appreciate the mind fuck moments you have when idea like mirroring the image comes into play. Great video.
Being a fresher programmer, I'd like to see more of this sort of thing. It always boggles my mind watching the coding of far more limited systems than the luxurious ones we have these days.
That is insane, I had somewhat of an idea how the old 3D games used to work but I never knew each pixel was being manipulated individually and then it's mirrored too >.< . Mind blown.
Not only do I want more, I'd love it if you did a tutorial series on 6800 assembly, so we'd learn to make a simple game along with you from start to finish
I find it far more interesting watching analyses of how developers managed to squeeze incredible visuals out of the 16-bit consoles than any "behind the scenes" of modern games.
This was so cool! I feel like ASM makes a tad more sense to me now than it did before, haha. Definitely appreciate the rundown! Would love more techy stuff like this in the future!
I'd be curious to understand how the "mirroring" was achieved. Presumably the CPU still has to program the DMA to perform the copy? Certainly a lot less CPU intensive than rendering the full screen.
I'm not one to argue much with your code, since you've made more of a career out of it than I have. But why did you not use the auto-increment with (a0)/(a1), I know the instances where you have to skip over pixels you couldn't, but for many instances you could've done, and as a result, you could've removed the add.l in majority of the cases. Additionally, you could've added "words" rather than "longs", since address registers sign extend the word to long-word on addition. It could've been faster, and the code could've been smaller =S The indexed version on the right at 5:05 could've been a series of (a0)+, since it's always incrementing by 1. Why did you guys not use auto incrementing?
Markey Jester to make it more understandable I pretended that the screen was only 1 pixel wide. In reality it would have been 256 pixels wide so to get to the next line down you would have to skip 256 pixels, not just 1 so (a0)+ wouldn't help. But mostly it's because it's easier to follow for people who don't know specific 68000 assembler. Good ideas though with that specific code.
By all means, I don't just have an understanding of 68k, I have a thorough understanding of the Mega Drive's VDP too. I was led to believe the same though, that you dumbed down the logic just to help explain it, in fact, I was told by a friend that this may be the case, in the end, she encouraged me to disassemble Toy Story to varify. Unfortunately, indeed, you could've optimised: ...etc... ROM:003E403E move.b 0(a0),0(a1) ROM:003E4044 move.b 1(a0),4(a1) ROM:003E404A move.b 2(a0),8(a1) ROM:003E4050 move.b 3(a0),$C(a1) ROM:003E4056 move.b 4(a0),$10(a1) ROM:003E405C move.b 5(a0),$14(a1) ROM:003E4062 move.b 6(a0),$18(a1) ROM:003E4068 move.b 7(a0),$1C(a1) ROM:003E406E move.b 8(a0),$20(a1) ROM:003E4074 move.b 9(a0),$24(a1) ...etc... This is related to the wall rendering, of which could've been auto-incremented, but wasn't. There was a copy of this below which did have the auto-increment, but the CPU ran through this code and other non-auto increments. I would like to apologise though, I didn't mean to come off so negative in my response, nor did I mean to put any negative impact to the work you guys put in, you did an outstanding job! Truely wonderful work, I was just quite shocked and taken off guard, I honestly didn't expect a lack of auto-increment in your code. That's all. I hope I haven't offended anyone, and if so, my apologies entirely...
Markey Jester hey no problem. I'm guessing that is from the code that was macro generated. So it will have been a generalised macro to deal with any step-rate through the texture and screen to generate all the code. I guess we didn't optimise for the few single step cases, or it was too hard to code into the macro back then. I can't actually find the code that generated the macros so I can't see what it did. It would have never helped with the screen side of things, but with the texture side it would have. I'll have to go back and recode it now - it can be faster still!
GameHut this is killing my brain and here I thought the genisis was simple or at least simpler no it's a fucking mess and a mad house also you guys did a great job on sonic r and I feel you don't get told that enough
"here i thought the genisis was simple or at least simpler no it's a fucking mess and a mad house" This is assembly code. Every single CPU in existance uses some form of assembly code. If you think THIS is a "mad house", then everything else is as well. it's not just the genesis
"If you look, the screen is mirrored, which gives us double the frame rate"
Absolute filth, I love it
Having played this game countless times, I had never noticed the screen was mirrored. To me, that is the best trick in this bag full of tricks.
Would love to see sister episodes for stuff like the special stages in Sonic 3D and the rotating tower in Mickey Mania.
Yeah, someone made a game for Macintosh (I forget which) and they used the same technique there. They mirrored the top/bottom of the rooms, and then drew the game objects over everything as another layer.
It looks like there's at least some custom exceptions to the mirroring - towards the end of the video we see a wall texture with the alien toy on it
James Stocks that's not a texture on a wall thats a sprite that just scales up and down depending on distance. And its always facing the player
Not only that, the alien sprite is also completely horizontal and floating halfway between the floor and ceiling. So in this case, everything on-screen is still 100% mirrored horizontally.
Zack, you're talking about a different thing than James and Karanthaneos. At 6:11 there's the potentially mirrored spinning thing. But at 6:07 there is a non-mirrored thing that looks like it could have been a wall texture, but wasn't.
While assembly code is a bit beyond me, I loved the breakdown of how it was coded, and how it was optimized for the hardware. A very well put together video. Please do more!
BlobVanDam holy shit! You're that LEGO Doctor Who guy! I love your stuff!
BlobVanDam what the hell you're that guy who made that Sonic 3 3D video 7 years ago
Riain, thanks! I don't expect to get recognized. :D
SonicPigeon, have you had that video pop up in your recommendations lately like apparently everyone else? lol
BlobVanDam no actually it was already a few years ago, but somehow it's a really memorable video
Definitely wasn't expecting you to follow this video up with a literal tutorial on how to do raycasting on a Sega Genesis. This video is as impressive as the graphical effects it covers. Also, only 6 and a half minutes it took for you to explain these things too. That is awesome, man. Thank you for this :)
gm112 The Genesis would take forever to do anything resembling raycasting. This is unlit 3D the likes of DOS and 16-bit Windows.
@@3lH4ck3rC0mf0r7 He said raycasting, not raytracing.
I miss the days where programmers had a responsibility to ensure that their code ran at a decent framerate. Nowadays it's just "Our game runs at 10fps? It's clearly your fault for not having a ten thousand dollar computer."
Yeah, I'm pretty sure most of the games nowadays can be optimized to run much faster than they do.
In those days you built a game to run on a certain config. Now there are hundreds of thousands of confide that games have to work on
+Retro Frontier I only have the utmost respect for programmers who dealt with those limitations, but I wouldn't belittle the achievements of modern programmers to that degree. The hardware may have gotten considerably more powerful but what players demand of their games have also skyrocketed.
Plus you mention Game Maker, a program I feel I'm an expert at but not one I'd consider myself a programmer from. GML isn't C++, which is actually used in nearly every modern video game. They share some similarities and lord knows both are easier than assembly, but pretending they are on the same difficulty level would be quite misleading. And even then while a terrible programmer could make a game in a few hours with Game Maker, an expert of the program could pull off things in the same amount of time that the other programmer wouldn't think Game Maker was even capable of.
Also if you're aware of lower level modern programming languages like C and C++, you'll know that there are still many problems like the ones seen in these videos you still have to contend with. The ease of tackling them may be mitigated and the amount of memory you have to work with may sometimes seem infinite, but that doesn't mean having issues where you have to count specific numbers of bytes don't happen.
If you look at Nintendo, you'll see this spirit is not gone. Just look at MK8 and BOTW on the Wii U. Nintendo always saves a buck on the hardware and spends it on making the software that much more efficient for their consoles!
This is only the case in PC land. Console developers still have a responsibility to make sure their code runs at a decent framerate on the platform they're developing for. And, just like in the old days, they meet that challenge with varying diligence and success.
Traveler's Tales truly is one of my favorite game companies just because of the stupid stuff they could do with the hardware
I was really hyped for LEGO Worlds when I saw TT developed it.
I'm not sure where it stands in technical achievement, but the usability and controls were very underwhelming. Company names stay, but the developers change.
@
I don't really know what's the power of any iPhone, but the better ventilation that the switch has allows it to work a lot harder.
Although this may not be an objective observation; personally I don't find TT's LEGO-themed games all that complicated. Surely there's some serious math involved in optimizing which pieces need to get rendered, but it's rather simple compared to other AAA games, and the hardware is much more forgiving for various small inefficiencies that they could make. The only company that really amazed me lately for its runtime efficiency is Id.
And again, as a PC user I was let-down by the controls and contents rather than image quality (graphics weren't that marvelous, but I don't care much for that - LEGO is all blocky anyway).
Maybe I grew cynical of good-old companies after observing some of them going down dark paths. Maybe TT has incredibly talented programmers. For now I just think that their products are barely worth mentioning in conversations with my friends.
more more!
Thats Awesome!
"Isso é muito AWESOME!"
Que vídeo sensacional mano! Foda demais! Nunca tinha reparado que era espelhado a tela, eu sempre fale desse game em discussões de mega vs. Snes.
Senhor virso. O senhor por aqui.
Stop speaking Spanish
Pacheko Spanish?? WTF
What a fascinating video! I love seeing behind the scenes stuff like this! When you mentioned that the screen was mirrored, i had a jaw-dropping "OH MY GOD" moment! I had no idea, it didn't look mirrored and i never would have noticed had you not pointed it out!
IKR. We have just lost cabin pressure. =)
Ah, same here.
Ah, same here.
Wow, this was awesome! Great work, Jon. So glad you're sharing these super cool and innovative old tricks that were used on those old systems. Keep it up, sir. Great work. Would love to see more of this in the future. :)
More! That was fabulous. I'm a 38 year old engineer, so I'm old enough to remember playing, and now smart enough to understand it - it's like the Goldilocks zone for enjoyment of this stuff. :)
Currently blowing my mind
Woah
3:57 *franticly points* LEGO Star Wars UI Reference!
JaCoB'S cLuB Glad I wasn't the only one who noticed it!
JaCoB'S cLuB Now we just need someone to make the Gamehut logo a Lego figure
"Write in the comments if you want more or less of this kind of thing."
Who would want less? These videos are fantastic. Wow at the tricks you used to get this demo to run up to 58.4 fps! Especially that macro trick.
Really would like to see more on Genesis Toy story if possible. The game is a technical marvel on the Genesis. You guys did some neat audio mixing tricks with that game too.
Amazing video and it's super informative, absolutely if you get enough requests other than myself please publish more of these, the scene really needs more ppl like you my friend.
I don't pretend to understand all of this but please do more stuff like this. Anything is nice, but this is great. Also if you have anything on Toy Story 2 you'd be pressing some of my oldest gaming nostalgia buttons. And if not, thanks anyway just for being part of the company that made it.
FUCK YES I WANT TOY STORY 2 CONTENT.
Me three. I want to know if there's some kind of story behind buzz losing his mind in the demo mode on Dreamcast.
@@GoldenGrenadier What? What happened on the demo mode?
@@sparkside217 On one of the demos, Buzz will Start running into a wall and the rest of the demo won't sync up.
Gotta love unrolling loops. A friend made a generator, which generated 68k source files containing huge unrolled loops, to render each scanline of a scaled image at any scale factor (imperfectly, there were a few bugs), and I created the code that will scale vertically by skipping or repeating some lines, and it turns out, I can scale 4 images simultaneously where 1 image is generally large and 1 is very small, and DMA all the art in 30fps! And on top of that, because it was for a menu, and the code was just small enough, I was able to Kosinski compress the code (Actually, I also wonder what Kosinski compression would have been called back in the day?). It did create for some very awesome effect, and again show how much a beefy CPU can do.
Also, really liked the high production value of the video, keep it up! More technical effect videos would be cool to see.
Yeah, when writing shaders, I often unroll my loops and I remember when I started in scratch (many years ago) we would manually unroll loops for faster 3D rendering (though it was very primitive).
@@TheSpace928 imagine if Sega used a 680020 processor this game would have looked even better
Looking back into this, this is probably the best Coding Secrets video I have ever saw. The music, length, and best of all, the Lego HUD all combine to make this the most detailed and beautiful video on your channel! I would LOVE to see more of this editing (whenever possible)
1:31 - Ultima Underworld did it first (in fact, John Carmack has mentioned that Wolfenstein 3D was inspired by an Ultima Underworld demo), although they didn't simplify it quite so much (it supported other types of deformation).
This channel is gold. You're a genius, Jon! Often times for me, lack of funds for certain projects calls me to be more creative, but in this case, hardware limitations really pushed you guys to push the boundaries and create something amazing from very little. Very very impressed!
Love the HUD that appears Jon :D
This is a great video and can't wait to see more like it.
More of this kind of content please. Great use of visuals to explain complex ideas simply. Well done.
I really enjoyed this video. It makes me so happy to see in-depth content from the people who worked on these games.
More of this would be really cool. Idk what exactly I want explained, but seeing this was really neat
This is absolutely fascinating. I'm a developer in another industry and I find tales of 16-bit development to be interesting and actually... inspirational. You guys (the people that coded the games of my youth) are actual heroes to me.
I really like how writing a huge amount of code instead of a loop, WAS the solution back then, as cartridge space and cycle times were much more important to consider. Now-a-days it's perfectly fine for code readability to cause a slight "performance" hit at run-time.
Just goes to show how platform limitations really have an impact, and that modern clock speeds and memory are insanely higher now.
Really enjoyed the video, would love to see some more of this "breakdown" type of video.
4:30 Wow, actually I hadn't even noticed that it was mirrored. That is such a simple yet clever trick.
But then there's still a non-symmetrical wall at 6:07 ..
BdR76 The non-mirrored wall is not a wall, these toys are on the background layer
it's just 1 wall that gets to draw its full texture
wouldn't slowdown so much
It still seems more impressive than the SNES version of the 3D section
this stuff is just facinating!!! you sir are responsible for many of my favorite childhood games. I'm so glad you're willing to share this incredible insight into what you were thinking!
Yo, this channel is THE hidden gem of TH-cam. Love these videos. Please keep it up!
Fascinating video, please keep producing more. Really enjoy hearing about how effects were made and then optimised for older systems.
It seems so simple when explained that way, but someone had to look at the issues they were facing and come up with all of these solutions. This is pretty crazy, I love how this channel presents its content.
Have to say, amazing videos. Cannot believe I've not seen anything else like this before on youtube.
I find it incredibly interesting, especially with the limitations of the technology at the time and you are very articulate and explain things so well. I haven't the foggiest how to write or understand code by I fully understand what you are doing and trying to achieve with your videos.
Great work!
PLEASE DO MORE! This is great at teaching valuable coding and logic usage! Keep up the Awesome work!
Loved this. Always wondered how tricks like this were pulled off on 16-bit hardware. Blown away at how clever it all was. I don’t know any code, but his explained it in a way I could understand, so thank you!
Super cool to have first-hand comments on programming techniques of that era ^_^
Please keep up !_!
It was one of my childhood favorites.
That mirroring trick was AWSOME.
Please, more of this!
I LOVE this kind of thing!!!! I do like how some of your later videos break things down in a way that is easier to understand for non-programmers, but as a programmer this stuff just speaks to me in a wonderful way - these days, it's always about writing the least number of lines of code to accomplish things for ease of maintenance (It is for me, at least!) but it's fascinating to see how things used to be, when space and runtime were both extremely important and had to be managed when writing this stuff.
This is getting better! Assembly code is something beyond my understanding but I love the secrets to achieve the desired effect.
I'm discovering your channel and as a younger developer but raised by an Amiga 600, I'm craving these first-hand stories of 16-bit game development. Thanks a lot for sharing, hoping to see more!
I'm currently learning Python as my first programming language, and although the code in this was at a much lower level it helped me understand why code is programmed a certain way at a higher level. This is brilliant stuff, thanks.
I actually really enjoy these dedicated code walks. Assembly isn't something I use a whole lot of today, but it's always fascinating to learn about.
It was one of the best fps sequences because the smooth moves and detail. Nice to see this!
Woooow! So the screen was mirrored! Mindblow!!!!
I loved so much this game as a kid! And I still do!! I always bring Toy Story when i'm talking about Genesis vs. Snes! Also, that mod player is amazing too! AMAZING video! I would love to see more about the development of this game! Subscribed!
Oh god this is just brilliant!
Early 3D was so tricky to implement that it wasn't possible without all sorts of hacking around. Even for PC during the years when Megadrive was around, Doom and System Shock were about as much as you could ever get, for 16-bit consoles it was even stricter.
Also awesome job with revealing the trickery of game engines. There will always be interest in that kinda stuff just like people still keep releasing Megardive demos (Overdrive and others). And since code breakdowns of old games are so rare (I can only remember 1 dev for megadrive ever sharing his code - Chris Shrigley), such content is always unique and insanely valuable among us enthusiasts.
There are also emulator developers who are always interested in insider info, so don't be afraid to dive as deep into code geek stuff as you can or wish, there will always be interest!
Thanks for your channel, keep on kicking ass!
WOW! Just discovered Coding Secrets, and I can't stop watching! Definitely please make more, it's so interesting to see this type of gaming history
This throws me back sooooo many years. Thanks a lot, Jon. Please, if you have more of this, by all means post it! Cheers and thanks a lot!
I actually never noticed that half of the screen is mirrored in order to save space, that IS pretty clever.
More, please! As an IT student, it's really interesting to see what advanced code looks like, and what the reasoning behind it is.
Definitely more of this please! I love this sort of thing along with all your other videos. Keep up the great work!
More! I don't know about the technical side of games but watching your videos over and over helps me to understand more and more, a "byte" at a time, lol.😃
As a programmer, I enjoy learning about how the games of my childhood actually worked under the hood. Thank you for sharing this.
I love your videos. I'm not saying modern games don't use any kind of trickery to make things work, but you all had to be so much more inventive with such intense constraints. Nowdays a lot of publishers don't even require devs to compress the file size for digital downloads of console games. It's fascinating how much engineering goes into some effects we took for granted as just technological evolution as if it's something people didn't work on.
You're like the Vsauce equivalent within gaming science, showing and telling in such a way that a lot of people understand the concept of what you're talking about. love your content, keep it up :)
I like to speed up the video to 2x during the code segment, because it already makes no sense to me, and hearing it make no sense at double the speed is very funny to me
this is the gaming stuff i really enjoy. it would be cool if you did some videos just rambling about your experience making a particular game, and any memorable coding challenges or other notable stuffs. like your opinion on Sonic 3D and if you think criticism is just misunderstanding the game or etc
not too many (i've seen nobody else) genesis devs are on youtube, so this is a great channel you got going indeed
I agree, there is a video of Genesis Aladdin developer playing his game while commenting all sorts of stuff about it, and a similar one with Symphony of the Night. It is always very enjoyable to watch such stuff.
Agreed. The entire Dev Plays series by Double Fine is worth watching.
Man, I take memory for granted on all my projects. This really gives some perspective.
Holy hell I love that breakdown of optimization, really neat to hear about. Would love too see more practical stuff like this to spark the imagination
More, definitely more of this. I'm loving the behind the scenes looks!
Such a cool video. The part about the macro that generates thousands of lines of code just to bypass the cost of looping was crazy.
i love this channel answering all my childhood wonders.
this is great! very informative - always wondered how Toy Story pulled off so many graphical tricks that I had never seen on a Genesis before!
Wow! It only took me 22 years to get to know how some parts of the Toy Story game were made :D. I must say that the first time I saw that level I was very confused of what to do, nothing in that level made sense to me for a while. What great memories this brings :D Thanks for sharing, please do more :)
I remember seeing this when you'd first got it up and running, but that version hilariously had Mickey Mouse hands holding a minigun.
I love that you show the assembly, this is really good information.
I love it! It's very illuminating, seeing the actual assembly code! Super interesting!
A sincere thanks for choosing to share Your knowledge, and taking the effort to make these videos in order i to do so.
And I personally appreciate how You "get to the gist" and present the general principles in an easy and relatable way, it almost feels as if You could have figured it out Yourself ;)...
Best regards
Incredibly interesting. Please share more of these types of videos. Back in the day, there was certainly a bit of an obsession with games players about the special effects seen in games from yourselves, Treasure, Konami and other great coding houses that seemed to border almost on witch craft compared to what most developers put out.
And that's when assembly is at its best. Good job man. Really impressive
Please do more videos like this, it was very interesting!
Amazing channel. I wish there were more 16 bit vets like you who did this kind of thing.
Just found this channel out and I am loving it!
Gosh it just incredible how yourself and other got around some of the hardware limitations of the time. It's remarkable
This is what games in the 8bit/16bit era so much fun. The developers were always facing hardware limitations and had to come with hacks or other ingenious ways to overcome them. This led to great games, as the effort would really shine through.
I'm loving this CODING SECRETS series!
This channel is amazing, definitely going to help me! Thank you for the time to share your wisdom!
More of this kind of thing. Love these videos!
This was super interesting, I'd love to see more about this kind of stuff
This kind of stuff is so amazing and interesting to me. I know nothing about coding but I feel like you wouldn't see things like this anymore with modern games because machines are so much more powerful and memory space isn't so low. Awesome to see the tricks in the background to make these techincal scenes with such limited technology of the time.
This is really friggin awesome!! Love these vids since I had all these games and really enjoyed them. :)
God, i love good ideas. I think all programmers can appreciate the mind fuck moments you have when idea like mirroring the image comes into play. Great video.
I love your videos. So much. Crazy things don't seem so mystical anymore.
Being a fresher programmer, I'd like to see more of this sort of thing. It always boggles my mind watching the coding of far more limited systems than the luxurious ones we have these days.
That is insane, I had somewhat of an idea how the old 3D games used to work but I never knew each pixel was being manipulated individually and then it's mirrored too >.< . Mind blown.
I loved this. I am a huge fan of the mega drive and seeing this is just mesmerising. Thanks so much.
ABSOLUTELY MORE
You break everything down nicely, please be as technical as you wish. This stuff is incredibly fascinating.
Not only do I want more, I'd love it if you did a tutorial series on 6800 assembly, so we'd learn to make a simple game along with you from start to finish
This is incredibly fascinating! Thank you for sharing.
This kinda stuff makes you appreciate old school coders
I find it far more interesting watching analyses of how developers managed to squeeze incredible visuals out of the 16-bit consoles than any "behind the scenes" of modern games.
Subbed. It amazes me how you guys tweaked everything to push hardware to its limits when space and CUP cycles were at a premium.
Holy crap, that was very interesting, and you explained it quite well. Well done!
This was so cool! I feel like ASM makes a tad more sense to me now than it did before, haha. Definitely appreciate the rundown! Would love more techy stuff like this in the future!
I'd be curious to understand how the "mirroring" was achieved. Presumably the CPU still has to program the DMA to perform the copy? Certainly a lot less CPU intensive than rendering the full screen.
Mirroring was effectively free as the hardware allowed mirroring of any graphics already in VRAM
Are we talking DMA VRAM copy? Using the source/destination address to implement the mirroring?
LOve the break downs. Def do more. Informative, demystifying and interesting!
I'm not one to argue much with your code, since you've made more of a career out of it than I have. But why did you not use the auto-increment with (a0)/(a1), I know the instances where you have to skip over pixels you couldn't, but for many instances you could've done, and as a result, you could've removed the add.l in majority of the cases. Additionally, you could've added "words" rather than "longs", since address registers sign extend the word to long-word on addition. It could've been faster, and the code could've been smaller =S
The indexed version on the right at 5:05 could've been a series of (a0)+, since it's always incrementing by 1.
Why did you guys not use auto incrementing?
Markey Jester to make it more understandable I pretended that the screen was only 1 pixel wide. In reality it would have been 256 pixels wide so to get to the next line down you would have to skip 256 pixels, not just 1 so (a0)+ wouldn't help. But mostly it's because it's easier to follow for people who don't know specific 68000 assembler. Good ideas though with that specific code.
By all means, I don't just have an understanding of 68k, I have a thorough understanding of the Mega Drive's VDP too. I was led to believe the same though, that you dumbed down the logic just to help explain it, in fact, I was told by a friend that this may be the case, in the end, she encouraged me to disassemble Toy Story to varify.
Unfortunately, indeed, you could've optimised:
...etc...
ROM:003E403E move.b 0(a0),0(a1)
ROM:003E4044 move.b 1(a0),4(a1)
ROM:003E404A move.b 2(a0),8(a1)
ROM:003E4050 move.b 3(a0),$C(a1)
ROM:003E4056 move.b 4(a0),$10(a1)
ROM:003E405C move.b 5(a0),$14(a1)
ROM:003E4062 move.b 6(a0),$18(a1)
ROM:003E4068 move.b 7(a0),$1C(a1)
ROM:003E406E move.b 8(a0),$20(a1)
ROM:003E4074 move.b 9(a0),$24(a1)
...etc...
This is related to the wall rendering, of which could've been auto-incremented, but wasn't. There was a copy of this below which did have the auto-increment, but the CPU ran through this code and other non-auto increments.
I would like to apologise though, I didn't mean to come off so negative in my response, nor did I mean to put any negative impact to the work you guys put in, you did an outstanding job! Truely wonderful work, I was just quite shocked and taken off guard, I honestly didn't expect a lack of auto-increment in your code. That's all. I hope I haven't offended anyone, and if so, my apologies entirely...
Markey Jester hey no problem. I'm guessing that is from the code that was macro generated. So it will have been a generalised macro to deal with any step-rate through the texture and screen to generate all the code. I guess we didn't optimise for the few single step cases, or it was too hard to code into the macro back then. I can't actually find the code that generated the macros so I can't see what it did. It would have never helped with the screen side of things, but with the texture side it would have. I'll have to go back and recode it now - it can be faster still!
GameHut this is killing my brain and here I thought the genisis was simple or at least simpler no it's a fucking mess and a mad house
also you guys did a great job on sonic r and I feel you don't get told that enough
"here i thought the genisis was simple or at least simpler no it's a fucking mess and a mad house"
This is assembly code. Every single CPU in existance uses some form of assembly code. If you think THIS is a "mad house", then everything else is as well. it's not just the genesis
Mind blown. More of this content please. Best TH-cam follow in a while. Keep it up GH!
I just loved this video! All these small details... wish I had programmed games that time...
Love this video! A novice-level tutorial series on Genesis programming would be very appreciated!
more of this kind of thing. this is neat!