As a diehard Saturn fan, it's great to have had devs like you developing for the system, devs who didn't see the Saturn's weirdness as an obstacle but as a challenge to be overcome. It's an even greater blessing to have you making videos so many years later so that all this knowledge can fall into the hands of the people! If only there were more Jon Burtons in the world, we would have seen more devs push the Saturn hardware to its limits and more great games made for this criminally underrated system.
I'm a big Saturn fan myself, but don't let your fandom blind you. There is nothing wrong with the way developers thought of the Saturn. The console was just notoriously difficult to develop for, and I would imagine that few developers were probably both smart and talented enough to utilize the Saturn to it's full potential. Just so nobody misunderstands what I just said, I'm *not* saying that they weren't smart and talented, I'm simply saying that you would have had to be *exceptionally* smart and talented to get the most out of the console. A lot of patience was probably required as well. The fact is that the PS1 was just so easy to develop for and that's why most developers didn't even bother with the Saturn. Can you really blame them? The N64 is also said to have been difficult to develop for, but it was more worth developing for because the console was far more successful then the Saturn. Unfortunately, the Saturn was really only a big hit in Japan. On a side note, I've always thought that the Saturn was by FAR the best console of it's generation when it comes to the transition from 2D to 3D. It was the ultimate 2D gaming console, yet it was perfectly capable of 3D games as well. While both the PS1 and N64 were capable of 2D games, they were definitely made with 3D games in mind and not 2D games at all. From what I've heard, the Saturn could also apparently do some cool effects in 2D games that the PS1 could not (although the PS1 could apparently do effects in 3D games that Saturn couldn't.) Also, while the PS1 did have a handful of 2D games on it (Edit: after posting and thinking about it a little, I realized that there are far more then just a handful), Sony did not like seeing 2D games on the PS1 at all. I'm pretty sure Nintendo had no problem with it, but again, the N64 was not made with 2D gaming in mind either and actually had even fewer 2D games on it then the PS1 did.
I saw no clickbait in this video's title. He even cared to put the right quotes around 'impossible' so to say that accomplishment was never indeed impossible but still hard to do, hence deemed impossible by some people not knowledgeable enough to pull that out. So no clickbait here, just informations about something hard to accomplish by programming Saturn's hardware, it just happened that he was the talented programmer to do that, right?
It's amazing how we take these things for granted nowadays, when programmers used to get crafty in order to pull off effects like these. I'm glad developers today have access to easier tools such as Unity and UE4, but it's still really cool what you guys were capable of back in the day.
The work they're doing today is far more amazing than anything that was done in the 90s. The brainpower that goes into a modern bleeding edge game engine today is humbling. Game dev used to be completely hacky dog shit. Games weren't even designed to run at variable refresh rates, resolutions or aspect ratios. It was nothing but global variables, hacks, special cases, and glitchy ass looking workarounds like the one described in this video (whose end result didn't even look that good when the game originally shipped, IMO).
Big Blue Frontend Is that why all the major engines (Unreal, idTech, CryEngine) had their roots in the 1990s and were all expanded upon by people for years down the line? That's right, nothing today is special. Making games now all requires that you use someone else's tools refined through the decades and add some scripts here and there to make a new game out of an existing framework. If anything, being a lazy hack is the current norm.
Game sack!?!? Looks likes Joe's in the house, Sega fans rejoice. How about a TT feature some day, or something hardware orientated with John ? Hardware pushers don't even start to describe this teams talents. PS. Long time viewer, thanks for all the good videos you and Dave have done over the years. :)
I say the same! I have also always find TT games way impressive! Such a great opportunity to finally see how those classics were coded by the creators themselves. BTW, I love Game Sack!
2 great videos from my 2 fave channels on same day, Although... I think I used the wrong grit sandpaper on my MegaDrive cart. Greendog still plays like shit.
Wow! One thing I keep finding incredible during these coding secrets videos is that Sega (the manufacturers of the hardware) did not (or could not) find a way to do this themselves. But instead a 3rd party developer finds a way. Really cool as always.
the same happened with Naughty Dog when they developed Crash Bandicoot. ND completely destroyed Sony's internal team when they attempted to challenge the Bandicoot by making their own shitty in-house platformer, failing to get anything even close to looking as good. This is nothing compared to the lengths that Andy Gavin and the other folks went to make Crash Bandicoot possible, completely hacking the PSX in the process and crossing lots of boundaries they weren't supposed to. Just storing the levels required they write their own tool which had a sort of adaptive compression, meaning it would compress completely differently if they moved even just one polygon. Some time, they got the level to compress under the size limit, but then they could never get a compression as good after making changes, meaning they had to alter the level over and over again until the algorithm finally managed to get it down again. You can read Gavin's blog posts about the development of Crash Bandicoot to learn more. Pure intellectual brilliance in every department over at Naughty Dog during these years, whether it be programmers or artists.
Maybe just because they created the console doesn't mean they were imaginative enough to exploit all its capabilities. I don't know what led Sega to include all those tools and functions on the console that made the fading effect of this game possible, but I really doubt it was specifically to accomplish said effect given how complicated the whole process is and that it seems like only TT Games managed to pull it off, and that was after taking a very deep look into what the console was capable of. Maybe Sega of Japan (or any of their internal divisions) also looked at these functions and didn't think much of them, but TT Games not only took them into consideration, but combined them together (sprite color calculation ratio and the Saturn's shading effects) to accomplish something apparently the console wasn't designed to be capable of.
The Saturn wasn't even designed to be a 3D machine. It was just so good at manipulating sprites Sega was able to cobble together something after seeing the Playstation and filling their trousers in horror.
Sega never worked out how to do fades on their system. If you look at their final games, they just used a mesh for anything supposed to be translucent.
Blank Blank: because Larry watches these videos about retro stuff, and likes to comment on them. And you likely subscribe to Larry or at least watch his videos. So the UA-cam algorithm shows you his posts.
As someone who’s working on home brew for Saturn when you got to showing the mountain frame by frame and then for lack of a better word “showed your work” my brain melted. I know that you guys definitely didn’t get enough credit for these impossible things you pulled off throughout the years.
The other, equally insane way to do transparency was the _Burning Rangers_ method: DMA objects to a tile layer, use the transparency functions of VDP-2 (the "background" graphics co-processor) and then copy them back to the sprite layer. The catch: your game runs like dogshit because you bottleneck the entire system. No wonder everyone else just gave up and used the dithered effect.
It's important to remember that VDP1 ships its data to VDP2 regardless, but I agree, the approach was novel, if somewhat flawed - the fires had to be rendered in half-resolution to keep performance up, and there was a ton of glitching. NiGHTS may not have been as adventurous but the results were better.
DMA does not cause much more bottlenecks than memory controller itself, (if CPU shares same bus to DMA and Memory Controller). Bottleneck would be copying insane ammounts of memory between CPU/RAM directly on timing critical events (such as horizontal blank or graphics engine bus access), not to mention the graphic corruption it would cause. This is where I see Nintendo virtuosity by enabling OAM access during hblank so you can do neat special effects without copying back the same line. But that requires a different hardware engineering approach. Well, programmers back then learnt the hard way and knew porting code would be "you either prove it or you suck"
You made me so proud to be a Saturn owner Christmas 1997, =)....and still to this day even. Sonic R is brilliant, and I've always wanted to know how this was done, =D.
Back in the day, whenever I saw Travellers Tales I knew it was a quality title. I stopped gaming regularly in the late 90s so I don't know much of their work after the 16-bit era, but I'm glad there's such interesting content on UA-cam passionately made by one of their members.
Hello Mr. Burton. I just finished playing your Director's Cut of 3D Blast and it was amazing. All new features were great, but maybe I liked old chaos emeralds system better and also time challenges are very hard, but that's to be expected. Overall great re-release and I love your content. Greetings from Poland.
Watching these videos always makes me feel a little ashamed of my own coding. I rarely think about the hardware beyond the very general sense. Another fine coding secret there, sir!
It's crazy that back in the day, the developers also had to be hardware experts in order to realise the ideas they had. I can't imagine this is the case now.
@@mrcyberpunk I see you were more a fan of the more serious animated series. The "Scratch & Grounder" series was good for a laid back laugh, but I preferred the other version in the 90s. Loved the opening theme song too.
I don’t know much about how video games are made, but Sonic R was one of my favourite games as a kid. I have fond memories of getting it to run on my dad’s shitty old PC at 6yrs old. Fantastic to see a channel from someone who worked on it. We still remember and appreciate all the hard work you guys did all those years ago.
BlueSatoshi I believe the Saturn was originally developed with the aim of creating the ultimate 2D graphics machine and its 3D rendering capability was a bit of an afterthought.
My guess is that until the PlayStation was revealed, Sega expected the typical 32-bit home console game to use an engine similar to Outrun or Space Harrier rather than Daytona USA; the Saturn approach would be more performative for this.
Great video as always Jon! Can you do a video explainin how Radiant Emerald has transparency effects galore, in addition to the fading effect? That would be pretty awesome! :D
This is amazing. I had no idea Saturn games could gouraud shade / light the entire scene. I thought gouraud shading was pretty well limited to objects and character models and that's about it outside of the Slave Driver engine games. This is amazing. Also, to the distorted sprite comments (the video was accurate). Quads and Triangles are both polygons, and the PS1 and Saturn both rasterize their polygons in 2D in a very similar fashion, as the video displays. Folks ought to try not to fall in to the "Saturn was hard to code for" internet hype. Saturn had more processors to optimize for. Saturn was NOT a traditional 3D renderer by any standard. There WAS NO STANDARD at the time. The choice at the time was triangles with affine texture mapping glitches and polys that literally pop out of place every few frames, or "distorted sprites" before 3D acceleration became consumer priced.
PS1 scan converted polygons instead of building them using lines, so the PS1 could do some basic transparency without overdrawing and messing it up. I heard from people that worked on the Saturn that it was hard, no internet 2nd hand stories here.
Sometimes i think people just follow me around the Internet. It's like it's made of these inescapable paths, even though hypothetically, anyone can go anywhere anytime.
And then Playstation 2 came along, which was more conventional, but not necessarily easier, lots and lots of quirks, just little bouts of weirdness and a high errata density.
With the Dreamcast giving up the ghost, and the Xbox and Gamecube a year away though, the PS2 had the console market to itself for a year, so it made sense for developers to focus on PS2 besides all the hype.
I really don't like the mentality that you have to be a "genius" to program. It's just something you get good at, like writing, drawing, composing, any regular skill.
Me saying "genius", is just a way to say that he was really clever with this. In all of their games, Traveller's Tales studyied the hardware they were working on to make the best out of it, and Sonic R is an awesome example of that.
Such dedication to perfecting your art! I have so much appreciation for what you did to push Sega's hardware! Thanks for the videos! I love hearing your insights, and you break it down so well for us who aren't coders.
Yep! I feel that if Sega had made it easier to program for, it would have seen better success. Maybe not enough to beat the Playstation, but still better than it ended up doing.
Isn't it also true that part of it was because a lot of the Saturn's best games didn't get released in the US because that a-hole Bernie Stolar kept them from being so because they were 2d and "nobody wants 2d games anymore"?
This is an amazing video, very well put together! Especially the quad overdraw explanation. Been wondering about Sonic R's fade effect for a while. Until this video, my best guess was maybe the hardware had built in some kind of early Direct3D8-like fog effect but the reality is so much more impressive! This series as well as the megadrive coding secrets means a lot to me. I'm so grateful you put in all this effort and look forward to future videos.
As a chance to geek out for a moment, thank you for these insightful videos on your past work as I grow a better appreciation for game development and the minds behind the projects, but also thank you so much for being a part of Sonic R. That game shaped me and my families' childhood in so many great ways, most of it for me was the soundtrack, but the game itself kept us coming back for more. Again, thank you so very much!
I love this. This shows why for me, the magic has gone with the modern machines. Now, with machines virtually limitless (in comparison to the 80s and 90s), it's childs play to do something like display a true-colour bitmap, or playback some music while also playing appropriate sound effects. I read something the other day that sums it up nicely for me - limitations breed creativity. So trying to achieve an effect like this, or showing plenty of colours on an earlier machine, is far more interesting to me. And yes, I know there are still limitations these days, but they're not as limiting, if you get what I mean?
Ok, but look at the new more advanced techniques we use to push hardware further, like light prepass, indirect rendering, screenspace reflections, etc. Light prepass/deferred rendering alone is already really interesting to study. The concept is simple, but implementation details to get good performance are not as trivial. Such as accurately compressing the normals down to 2 values in screen space and reconstructing them later, or how to reconstruct both diffuse and specular lights from just 4 float values, rather than waste a whole 3 channels on specular highlights. It may not require as much low level coding expertise, but makes up for it in programming and mathematical technique.
Try making a beautiful game, by today's standards, that runs well. Trust me, it's not easy, and there is still magic being created every day in the industry.
Lassi Kinnunen you could not be more wrong! A huge portion of the budget is dedicated to graphics! It has become a sort of arms race. And engines constantly push graphics technology further. Have a look at unreal, they keep,adding new graphics features all the time. Most recently they added some very cool volumetric light probes, and distance field shadows. Very cool stuff. Speaking of elite, have you heard of elite dangerous? Its running on the cobra engine, a custom bespoke engine by frontier, which does still push technology further. Getting all these procedural assets to run smoothly is no small feat! To think that studios no longer squeeze as much performance as they can is incredibly naive. What sells games these days are graphics, (hence all the impossibly good looking demos at E3, and the push for 4k in the console space).
I love so soo much what you are doing with your channel, any chances to have more details on an old interview you gave to Sega Saturn Magazine: What special effects and techniques are you most proud of in the Sonic R engine and why? You replied: The cross fading "misting" effect, the reflective water, and the compression technique used to calculate visible polygons. Can we have information about the compression used to calculate visible polygons ? Did the cross fading was a huge deal compared to what the Saturn offered in other games ? Can you explain why ? :D
According to Retro Gamer's "The Making of Sonic R" article, Burton said he was most pleased with the reflective surfaces, because the Saturn simply doesn't support them.
This is a rare peek into hardware specific coding which never really gets talked about. It's also a really good reminder of how easier amateurs like myself have it these days. Stories like this are the reason I look up to older devs with so much respect. Any way thanks for all the great insight about tricks you've pulled off over the years. I can only hope to have stories like this to tell some day.
Excellent explanation, but there's one thing I don't understand. To the best of my knowledge, the VDP2 color calculation only works with Palette sprites, not RGB ones, since RGB sprites don't have enough bits to store any color calculation data (RGB being 15bit colour and 1bit to select RGB). So you have to use palette sprites to do the background fade. But you also do a transparent shield, which HAS to be RGB, because polygon transparency only worked in RGB sprites... on paletted ones, it would corrupt the palette index. So what is going on there? Extreme micromanagement to draw each sprite a different way depending on distance?
Also, when a shield is drawn over a far-away, half faded polygon, the shield completely draws over it, with no transparency. Is that normal for an rgb pixel with semitransparency on, to overwrite a palette index pixel underneath it?
Wow, that must've been hell to micromanage given that you have to upload all the palettes in advance to the VDP2.Also, you didn't mention it in the video, but you used transparent quads for the rainbow trail on the speed booster. Non-textured, single colour polygons with gouraud shading, to keep the speed up. You can actually see the transparent pixel overdraw bug on those, but only if you pause the game since it is so fast.
zyrobs yeah, the emulator I used to capture footage drew them as non-transparent so I didn’t bother explaining them, but in short, the transparent corruption is avoided due to the orientation they are drawn at to avoid the overdraw corruption (apart from the join)
I've seen a trend on YT of developers giving concise and meaningful insights into how computers perform the apparent miracles they do. It is good. You're on the forefront. Carry on.
You (and your colleagues I'm sure) seem to have some fantastic ways to think outside the box and use logic to get great results. Thanks very much for sharing.
Yes, yes it was. To give you an idea how much, think that the Saturn's 3D capabilities were better than those of the PlayStation. But 3D games on the Saturn still looked like shit (most of them anyways) compared to those of Sony's console because programming anything 3D on it was that difficult. And well, you know, Sega killed the console before developers could get used to its hardware, and what was left gave the Saturn the reputation of being "that console that couldn't compete with the PlayStation because it had some shitty 3D". Sad, very sad...
Jorge Enrique Riera Saturn’s 3D capabilities were always worse than PS1. Bad transparency (usable only for special cases), slower drawing, being limited to quads even if you want triangles, wasteful redrawing of the same pixels, inefficient use of video memory due to framebuffers being fixed size, lack of uw-mapping (shown by Gamehut in another video). Only minor feature that saved it sometimes was support of 2D mode7-like effects that complemented real polygons on some games, typically used for drawing ground and/or sky.
If you look at theoretical specs and numbers, the Saturn has a HIGHER polygon per second count than the PlayStation. For example, check out this article www.racketboy.com/journal/ps1-strength-and-weaknesses-vs-n64-sega-saturn
N64 is also difficult to program, but the outcome is not as bad as Saturn. N64 uses triangle to draw polygons like PlayStation, so it also capable of 3D.
I don't think comparing a late Saturn game with an N64 launch title (a legendary launch title but a launch title nonetheless) is a fair comparison but ok.
Jorge Enrique Riera u could also say he's comparing Sonic R to the best N64 had to offer graphically. None of the later N64 games progressed further than Super Mario 64 visually, so his point is still very valid 😊
"None of the later N64 games progesses futher than Super Mario 64 visually" Emmmm... no? If by "not progressing visually" you mean things like low-re textures, fog and other stuff like that that's more due to limitations of the system because of the cartridge format. And even with those limitations, visual progress can be noticed. Jet Force Gemini, Donkey Kong 64, the two Banjo games, the two Zelda games, and of course Conker's Bad Fur Day, you can't compare any of those games (and many others I'm not remembering right now) with SM64 and say there wasn't any visual progress at all. That's like saying Final Fantasy IX and Chrono Cross, which are some of the best looking games on the PS1, are visually on the same level as Final Fantasy VII.
Conker is ages ahead in the graphic aspect. There's no fog, a massive draw-distance, big textures, dinamic shadows, and there's the fact that the whole game has voice in the dialogues.
Yeah, but would you believe me if I told you that I once heard someone say that any average PS1 game already looks better than Conker? I also heard someone say that most N64 games have a framerate so low they're barely playable... What can I say? The internet sure is a weird place sometimes.
whenever they talk about sonic r graphics, i remember a magazine article from that time saying "graphics look more like what you can see on the nintendo 64 than the saturn". it hyped me so much but it was already too late.
This channel is entirely "hello! Today I want to talk to you about how every single aspect of sonic R is impossible for the hardware to support and was far ahead of its time" Awesome stuff
FINALLY! Someone explains the difference in the Saturn and PlayStation's ways of rendering 3D in a way that I can understand! Excellent video. I actually was never curious about the fading backgrounds until now. Somehow I never really noticed it in relation to most other Saturn games like Daytona USA. It's amazing you had such a rich understanding of how to work with the Sega Saturn.
This is a great video. I'm curious, as somebody who was an insider at the time, do you feel there was any merit to Sega's decision to go with the quad-based rendering model they chose (beyond perhaps expediency in the Saturn's dev process)? We've seen a lot of videos from you about some of the challenges it creates. I can imagine the reasons that might have motivated them, but were there practical _advantages_ from your perspective?
I'm always blown away by the ideas that game programmers and artist come up with to make something work.And from what I've heard making a Saturn game was really hard.I wish I had the brain to program but the tricks to overcome challenges like this really just make my head spin
Hi, I've been doing some hacking around with the PC version of Sonic R. one of my goals was to try and get Network Multi-player working again, however in the version that people use it was removed and the patches are no longer compatible. I was wondering if you might be able to go into why it even existed in the first place (if that was something you worked on). it just seems like a rather obscure thing to add to a PC port of a Saturn Game. Thanks, CnG
No one You know - Patches that are meant for a specific build (or range of builds) can fail if the internal code is significantly different in subsequent builds, especially if the patches are based on changing code in specific locations within the program's files, which was often the case. It was good for earlier systems that had a limited amount of storage space and/or network bandwidth for distributing the patches. Most newer patching techniques replace entire files, meaning the patches are going to be bigger, but not as reliant on what version is already in place.
Not sure if this is exactly how they did it, but Virtua Fighter used same quad-based technology to display first truly textured 3D graphics on arcade machines (and Saturn/32X). IIRC they had to rewrite code for PC port as it did not supported quads.
If you have triangle based hardware, you can just render two triangles with UV coordnates of 0/1 according to which quad corner, and it's done. If the hardware is affine, it will distort more than quad affine hardware, but it'll still work. If the hardware is perspective and you manage to retain Z/W through the pipeline, everything is going to look fine. If you have quad based hardware and are trying to render triangle based models which use UV coordinates for texture placement, give up, there's nothing you can do, you need to remodel all of your assets in quads and with exactly one texture spanning each quad corner to corner.
There were apparently two versions of PC Virtua Fighter. As the game was released before PC 3D had standardized, a company manufactured a quad-based PC card, and it came with Virtua Fighter. A quick Google search finds the NV1, apparently Nvidia's first graphics card, based on Saturn hardware (even including a Saturn controller port). A handful of Saturn games were ported for this PC hardware. Some years afterward, a friend of mind gave me his graphics card and the accompanying copy of VF, thinking I could use it as a passable upgrade for my old PC. Unfortunately, the card was effectively useless by that point. PC had quickly standardized to using triangles for 3D, and DirectX was created. Nvidia apparently tried releasing DirectX compatible drivers for the card, but it didn't really work.
BainesMkII, the NV1 is even more unusual than the Saturn; and it really has no Saturn compatible hardware except for the actually quite trivial game ports and the SEGA partnership to provide a batch of ported software. It's more unusual in the way that it doesn't render quadrilaterals like the Saturn, it renders quadratic surfaces, which are smooth, imagine each surface as being defined by 9 points in space, and imagine being able to represent a very close approximation of a sphere with just 6 surface primitives. However, no software except some tech demo that i have never seen in person and can no longer find, used the feature, the Saturn games used degenerated quadratics into 4-point quadrilaterals, effectively rendering same as Saturn.
I've never been a big fan of Sonic Rs gameplay but your videos really show what a technical marvel it was. Still possibly the smoothest looking game on the system.
Absolutely brilliant work explaining not only how you done this work, but why it was a challenge in the first place. What gets me though is that people say the Saturn cant do transparency with 2D sprites, but if its "polygons" are just sprites that are morphed and what not. Why couldnt devs use this technique to make full transparent sprites in 2d games.
I love watching these videos to see how programs and designers had to get around the limitations of hardware to create such amazing feats. Thanks for showing how this was done!
I just want to congratulate you on this channel. I got lead here by UA-cam as I'm interested in Sonic and have been following you for a while now. Even though I don't have the means to create games, the way you describe and explain is so easy to understand and isn't condescending. I want to thank you. I hope your channel continues to grow! ♥
Why so much storage overhead? A shift and a mask will conveniently divide all 3 or 4 colour components in half or a quarter... it will fade to black but it means you just have to work with subtractive colour, so you just subtract the last step from 1...
Makes the code more efficient, and I don't think the algorithm actually just did quarters. I used that in the video for simplicity but I think the actual colour calculation algorithm was more complex in reality.
processing power was certainly a more valuable commodity than storage space. remember, we has just left the cartridge generation where 2mb was a lot to this new cd gen with as much as 650mb available to play with. storage wasn't a bottleneck.
But these systems don't exactly have an overabundance of RAM either for what they're trying to accomplish. Well, the hardware limitations play out differently for different projects, so if some RAM is left over, no reason not to spend it.
GameHut I'm just wondering what TT did for the SNES ports of its games, like Toy Story and Mickey Mania. How did you recreate the "3D" effects of the Genesis version on SNES, and if you even did?
being a hardware engineer feels like living in the 50's again (since reinventing everything). I think programmers back then had to adapt to non standard ways of achievements, so they had become hardware engineers in the process. lol
I mean, yeah, but let's say a character is made with 500 polygons, or "sprites". You would have to write one line of code for each and every sprite on a model, rather than just being able to write one line of code for the model.
That's not really how programming works. Even on older machines with hardware sprites, like the Mega Drive or the NES, you still have to draw the entire screen, including all the sprites, for every frame. So every frame there would be some code going through all the things to be drawn, and drawing all those things on the screen. That's not really any different from how we use modern GPUs, we've just invented more efficient ways of getting all of those polygons onto the screen. (and modifying what they look like) Whether you call them "sprites" or "polygons" doesn't really have any effect on how to draw them onto the screen.
The fact that you still remember these coding tricks you did years ago is impressive enough. I have friends that work at InfinityWard that can't recall how they coded some of the older Tony Hawk games
These stories are such an inspiration for me as a programmer. You old school devs must feel really damn proud. Doing stuff back then really was an art.
Amazing. It's really nice to hear about programming and coding on the Saturn. The software based rendering has always fascinated me and seeing these tricks done with the limitations is something else.
God I love your videos. They are very in depth yet simple to follow. I grew up with Nintendo consoles but always had a thing for sega and I still do to this day. It clearly shows that you loved doing your job and I admire you for that.
This is the only channel where I have to watch every video twice because all this info flies by me the first time, but the second or even third watch I finally start to understand.
Fascinating, thanks for producing these videos - love to hear about the problem solving that went into creating these games - limitations really do fuel creativity.
This is so good keep doing this, you are one of the few with actual good content even though I don’t really know what you are talking about half the time
That's hilarious, I literally played this game like 2 days ago and was thinking, gee, I wonder how they accomplished the transparency in the fading. Very interesting! I love these coding secrets episodes!
Amazing. Explained the limitations of the saturn that i had no explanation for other than "it had too many processors" all in one video! You should crowdfund a documentary where you explore the world of videogame graphics from origin to today. Would be amazing to see
Every time. EVERY TIME. That I watch one of your videos, I come away a literal whiz at computer coding. THIS STUFF IS AWESOME!!!! And I don't throw that out there lightly. THIS IS SICK.
As a diehard Saturn fan, it's great to have had devs like you developing for the system, devs who didn't see the Saturn's weirdness as an obstacle but as a challenge to be overcome. It's an even greater blessing to have you making videos so many years later so that all this knowledge can fall into the hands of the people! If only there were more Jon Burtons in the world, we would have seen more devs push the Saturn hardware to its limits and more great games made for this criminally underrated system.
I'm a big Saturn fan myself, but don't let your fandom blind you. There is nothing wrong with the way developers thought of the Saturn. The console was just notoriously difficult to develop for, and I would imagine that few developers were probably both smart and talented enough to utilize the Saturn to it's full potential. Just so nobody misunderstands what I just said, I'm *not* saying that they weren't smart and talented, I'm simply saying that you would have had to be *exceptionally* smart and talented to get the most out of the console. A lot of patience was probably required as well. The fact is that the PS1 was just so easy to develop for and that's why most developers didn't even bother with the Saturn. Can you really blame them? The N64 is also said to have been difficult to develop for, but it was more worth developing for because the console was far more successful then the Saturn. Unfortunately, the Saturn was really only a big hit in Japan.
On a side note, I've always thought that the Saturn was by FAR the best console of it's generation when it comes to the transition from 2D to 3D. It was the ultimate 2D gaming console, yet it was perfectly capable of 3D games as well. While both the PS1 and N64 were capable of 2D games, they were definitely made with 3D games in mind and not 2D games at all. From what I've heard, the Saturn could also apparently do some cool effects in 2D games that the PS1 could not (although the PS1 could apparently do effects in 3D games that Saturn couldn't.) Also, while the PS1 did have a handful of 2D games on it (Edit: after posting and thinking about it a little, I realized that there are far more then just a handful), Sony did not like seeing 2D games on the PS1 at all. I'm pretty sure Nintendo had no problem with it, but again, the N64 was not made with 2D gaming in mind either and actually had even fewer 2D games on it then the PS1 did.
This is such good content that you don't even mind the clickbait-quality memes, that's how good these videos are.
+elPatrixF Yep, much better without them. I definitely agree with you! : - )
I think his click-baity sensational thumbnails kinda cheapen his amazing content honestly... but if he likes them, I won't complain :)
That’s something I noticed too. The videos are great, but the titles are so clickbaity..
How is that clickbait
I saw no clickbait in this video's title. He even cared to put the right quotes around 'impossible' so to say that accomplishment was never indeed impossible but still hard to do, hence deemed impossible by some people not knowledgeable enough to pull that out. So no clickbait here, just informations about something hard to accomplish by programming Saturn's hardware, it just happened that he was the talented programmer to do that, right?
It's amazing how we take these things for granted nowadays, when programmers used to get crafty in order to pull off effects like these. I'm glad developers today have access to easier tools such as Unity and UE4, but it's still really cool what you guys were capable of back in the day.
The work they're doing today is far more amazing than anything that was done in the 90s. The brainpower that goes into a modern bleeding edge game engine today is humbling.
Game dev used to be completely hacky dog shit. Games weren't even designed to run at variable refresh rates, resolutions or aspect ratios. It was nothing but global variables, hacks, special cases, and glitchy ass looking workarounds like the one described in this video (whose end result didn't even look that good when the game originally shipped, IMO).
Big Blue Frontend Is that why all the major engines (Unreal, idTech, CryEngine) had their roots in the 1990s and were all expanded upon by people for years down the line? That's right, nothing today is special. Making games now all requires that you use someone else's tools refined through the decades and add some scripts here and there to make a new game out of an existing framework. If anything, being a lazy hack is the current norm.
Banzeken there can still be amazing games out there
Amazing video! I have wondered about this since the 90s. Thank you so much for explaining this!!
Game sack!?!?
Looks likes Joe's in the house, Sega fans rejoice.
How about a TT feature some day, or something hardware orientated with John ?
Hardware pushers don't even start to describe this teams talents.
PS. Long time viewer, thanks for all the good videos you and Dave have done over the years. :)
I say the same! I have also always find TT games way impressive! Such a great opportunity to finally see how those classics were coded by the creators themselves. BTW, I love Game Sack!
2 great videos from my 2 fave channels on same day, Although... I think I used the wrong grit sandpaper on my MegaDrive cart. Greendog still plays like shit.
Sup Game Sack!
i knew if i looked down in the comments id see this goofy ass
You are the best on UA-cam at explaining complicated graphical properties in a well worded and simple visual way that anyone can follow.
exceptional mad language skillz people can teach anything language related.
But what's with all these "impossibles"? Was anything possible on these consoles? Do any of these games even actually exist? 🤔
nothing is real, existence is impossible
Do we even exist?!
Half life is possible on Saturn!
Nothing is impossible !
When two youtubers with excellent thematics works together,this always lead to an unexpected but great result.
From my understanding of old PC and console games, it's a miracle if you got the game to display anything other than error text.
Wow! One thing I keep finding incredible during these coding secrets videos is that Sega (the manufacturers of the hardware) did not (or could not) find a way to do this themselves. But instead a 3rd party developer finds a way. Really cool as always.
After sonic and knuckles sega lost a few brain cells.
the same happened with Naughty Dog when they developed Crash Bandicoot. ND completely destroyed Sony's internal team when they attempted to challenge the Bandicoot by making their own shitty in-house platformer, failing to get anything even close to looking as good. This is nothing compared to the lengths that Andy Gavin and the other folks went to make Crash Bandicoot possible, completely hacking the PSX in the process and crossing lots of boundaries they weren't supposed to. Just storing the levels required they write their own tool which had a sort of adaptive compression, meaning it would compress completely differently if they moved even just one polygon. Some time, they got the level to compress under the size limit, but then they could never get a compression as good after making changes, meaning they had to alter the level over and over again until the algorithm finally managed to get it down again. You can read Gavin's blog posts about the development of Crash Bandicoot to learn more. Pure intellectual brilliance in every department over at Naughty Dog during these years, whether it be programmers or artists.
Sega did manage transparencies in the likes of burning rangers and panzer dragoon Saga. Still, Sonic R is on another level with how impressive it is.
Maybe just because they created the console doesn't mean they were imaginative enough to exploit all its capabilities. I don't know what led Sega to include all those tools and functions on the console that made the fading effect of this game possible, but I really doubt it was specifically to accomplish said effect given how complicated the whole process is and that it seems like only TT Games managed to pull it off, and that was after taking a very deep look into what the console was capable of. Maybe Sega of Japan (or any of their internal divisions) also looked at these functions and didn't think much of them, but TT Games not only took them into consideration, but combined them together (sprite color calculation ratio and the Saturn's shading effects) to accomplish something apparently the console wasn't designed to be capable of.
@@bigblue344 be quiet
Damn, hearing about that the Saturn actually renders distorted sprites is new to me! Learning something new everyday...
The Saturn wasn't even designed to be a 3D machine. It was just so good at manipulating sprites Sega was able to cobble together something after seeing the Playstation and filling their trousers in horror.
Big Blue Frontend that’s amazing
@@youtubesuresuckscock This is an urban legend that has been plenty busted.
Sega never worked out how to do fades on their system. If you look at their final games, they just used a mesh for anything supposed to be translucent.
Larry Bundy Jr why do I always see you on these videos?
Larry Bundy Jr not in burning rangers.
Blank Blank: because Larry watches these videos about retro stuff, and likes to comment on them. And you likely subscribe to Larry or at least watch his videos. So the UA-cam algorithm shows you his posts.
It's weird, because I don't nor do I know anyone that watches his videos yet I still see him everywhere
panzer dragoon 2 did had transparent enemy bullets tough, one that i remenber of the top of my head are the last boss green round bullets
*_Mr. Naka I don't feel so good..._*
I Dunno...
Burning rangers was quite the technical feat
Mike Contra with graphics that wouldnt be a problem for Playstation at all.
beaten to the punch
"That's Iwata-san, you rude rodent!"
That pfp is a mood
As someone who’s working on home brew for Saturn when you got to showing the mountain frame by frame and then for lack of a better word “showed your work” my brain melted. I know that you guys definitely didn’t get enough credit for these impossible things you pulled off throughout the years.
The other, equally insane way to do transparency was the _Burning Rangers_ method: DMA objects to a tile layer, use the transparency functions of VDP-2 (the "background" graphics co-processor) and then copy them back to the sprite layer. The catch: your game runs like dogshit because you bottleneck the entire system. No wonder everyone else just gave up and used the dithered effect.
It's important to remember that VDP1 ships its data to VDP2 regardless, but I agree, the approach was novel, if somewhat flawed - the fires had to be rendered in half-resolution to keep performance up, and there was a ton of glitching. NiGHTS may not have been as adventurous but the results were better.
DMA does not cause much more bottlenecks than memory controller itself, (if CPU shares same bus to DMA and Memory Controller). Bottleneck would be copying insane ammounts of memory between CPU/RAM directly on timing critical events (such as horizontal blank or graphics engine bus access), not to mention the graphic corruption it would cause. This is where I see Nintendo virtuosity by enabling OAM access during hblank so you can do neat special effects without copying back the same line. But that requires a different hardware engineering approach. Well, programmers back then learnt the hard way and knew porting code would be "you either prove it or you suck"
You made me so proud to be a Saturn owner Christmas 1997, =)....and still to this day even. Sonic R is brilliant, and I've always wanted to know how this was done, =D.
Back in the day, whenever I saw Travellers Tales I knew it was a quality title. I stopped gaming regularly in the late 90s so I don't know much of their work after the 16-bit era, but I'm glad there's such interesting content on UA-cam passionately made by one of their members.
Hello Mr. Burton. I just finished playing your Director's Cut of 3D Blast and it was amazing. All new features were great, but maybe I liked old chaos emeralds system better and also time challenges are very hard, but that's to be expected. Overall great re-release and I love your content. Greetings from Poland.
Watching these videos always makes me feel a little ashamed of my own coding. I rarely think about the hardware beyond the very general sense. Another fine coding secret there, sir!
The thumbnails are always great for this channel
It's crazy that back in the day, the developers also had to be hardware experts in order to realise the ideas they had. I can't imagine this is the case now.
Robotnik: "And when I'm done, half of the Animals will still exist."
Sally, Bunny, Rotor! No Come Back... "Hi I'm Shadow" "and I'm Big the Cat.. FROGGEH!!" NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!
"Half" the animals? OH SNAP!
@@mrcyberpunk I see you were more a fan of the more serious animated series. The "Scratch & Grounder" series was good for a laid back laugh, but I preferred the other version in the 90s. Loved the opening theme song too.
@@Mastermind8908 Satam was always the superior. But everyone can agree Undreground was the weakest series.
@@mrcyberpunk Yeah, I tried but just couldn't get into Underground. Three Sonics saving music? This isn't Footloose people.
I don’t know much about how video games are made, but Sonic R was one of my favourite games as a kid. I have fond memories of getting it to run on my dad’s shitty old PC at 6yrs old. Fantastic to see a channel from someone who worked on it.
We still remember and appreciate all the hard work you guys did all those years ago.
Well, that explains why the Saturn used quads.
Still, that 12 layer method's amazing!
BlueSatoshi I believe the Saturn was originally developed with the aim of creating the ultimate 2D graphics machine and its 3D rendering capability was a bit of an afterthought.
My guess is that until the PlayStation was revealed, Sega expected the typical 32-bit home console game to use an engine similar to Outrun or Space Harrier rather than Daytona USA; the Saturn approach would be more performative for this.
1:48 Best description I've seen of the Saturn's 3D transparency issue.
Great video as always Jon! Can you do a video explainin how Radiant Emerald has transparency effects galore, in addition to the fading effect? That would be pretty awesome! :D
The whole track was drawn using one mix mode of 50%. Same technique as the video explains
What I love about your videos: even with limited knowledge about computers, you have absolutely no problem following your explanation.
This is amazing. I had no idea Saturn games could gouraud shade / light the entire scene. I thought gouraud shading was pretty well limited to objects and character models and that's about it outside of the Slave Driver engine games. This is amazing.
Also, to the distorted sprite comments (the video was accurate). Quads and Triangles are both polygons, and the PS1 and Saturn both rasterize their polygons in 2D in a very similar fashion, as the video displays.
Folks ought to try not to fall in to the "Saturn was hard to code for" internet hype. Saturn had more processors to optimize for. Saturn was NOT a traditional 3D renderer by any standard. There WAS NO STANDARD at the time. The choice at the time was triangles with affine texture mapping glitches and polys that literally pop out of place every few frames, or "distorted sprites" before 3D acceleration became consumer priced.
PS1 scan converted polygons instead of building them using lines, so the PS1 could do some basic transparency without overdrawing and messing it up. I heard from people that worked on the Saturn that it was hard, no internet 2nd hand stories here.
I do a lot of programming myself and I just gotta say your bag of tricks is pretty damn impressive. I love these coding secrets videos.
Retro Game Mechanics Explained and Game Hut need to have a chat.
Fascinating to finally understand why the shading suddenly pops into the scene. Very clever.
Woah. Good stuff.
Sometimes i think people just follow me around the Internet. It's like it's made of these inescapable paths, even though hypothetically, anyone can go anywhere anytime.
I love sonic r because of all the impossible effects you pulled off. I played it a lot when I was just a child.
Programming on the Saturn seemed like the hardest thing ever! You guys were absolute geniuses!
I think programming in general was the hardest thing ever. There was no GameMaker Studio or Unity. Just lots and lots of hard work.
And then Playstation 2 came along, which was more conventional, but not necessarily easier, lots and lots of quirks, just little bouts of weirdness and a high errata density.
With the Dreamcast giving up the ghost, and the Xbox and Gamecube a year away though, the PS2 had the console market to itself for a year, so it made sense for developers to focus on PS2 besides all the hype.
I really don't like the mentality that you have to be a "genius" to program. It's just something you get good at, like writing, drawing, composing, any regular skill.
Me saying "genius", is just a way to say that he was really clever with this. In all of their games, Traveller's Tales studyied the hardware they were working on to make the best out of it, and Sonic R is an awesome example of that.
Such dedication to perfecting your art! I have so much appreciation for what you did to push Sega's hardware! Thanks for the videos! I love hearing your insights, and you break it down so well for us who aren't coders.
You're a freakin wizard at this stuff wow
I call this former sega dev "old school programmer". ps: emu author here
Coding Secrets is maybe the best thing I've seen on UA-cam. Keep up the great work!
Yes! Saturn seems quite different from the PlayStation.
Yep! I feel that if Sega had made it easier to program for, it would have seen better success. Maybe not enough to beat the Playstation, but still better than it ended up doing.
Player One Start I thought Sonic Xtreme not being released is what killed the Saturn
True dat!
Yeah, that definitely did not help.
Isn't it also true that part of it was because a lot of the Saturn's best games didn't get released in the US because that a-hole Bernie Stolar kept them from being so because they were 2d and "nobody wants 2d games anymore"?
This is an amazing video, very well put together! Especially the quad overdraw explanation. Been wondering about Sonic R's fade effect for a while. Until this video, my best guess was maybe the hardware had built in some kind of early Direct3D8-like fog effect but the reality is so much more impressive!
This series as well as the megadrive coding secrets means a lot to me. I'm so grateful you put in all this effort and look forward to future videos.
I don't want to go, Mr. Burton
As a chance to geek out for a moment, thank you for these insightful videos on your past work as I grow a better appreciation for game development and the minds behind the projects, but also thank you so much for being a part of Sonic R. That game shaped me and my families' childhood in so many great ways, most of it for me was the soundtrack, but the game itself kept us coming back for more. Again, thank you so very much!
I love this. This shows why for me, the magic has gone with the modern machines. Now, with machines virtually limitless (in comparison to the 80s and 90s), it's childs play to do something like display a true-colour bitmap, or playback some music while also playing appropriate sound effects. I read something the other day that sums it up nicely for me - limitations breed creativity. So trying to achieve an effect like this, or showing plenty of colours on an earlier machine, is far more interesting to me. And yes, I know there are still limitations these days, but they're not as limiting, if you get what I mean?
Right on. Like, spot on! ^^d
Ok, but look at the new more advanced techniques we use to push hardware further, like light prepass, indirect rendering, screenspace reflections, etc.
Light prepass/deferred rendering alone is already really interesting to study. The concept is simple, but implementation details to get good performance are not as trivial. Such as accurately compressing the normals down to 2 values in screen space and reconstructing them later, or how to reconstruct both diffuse and specular lights from just 4 float values, rather than waste a whole 3 channels on specular highlights.
It may not require as much low level coding expertise, but makes up for it in programming and mathematical technique.
And yet games like PUBG still look like ass.
Try making a beautiful game, by today's standards, that runs well. Trust me, it's not easy, and there is still magic being created every day in the industry.
Lassi Kinnunen you could not be more wrong! A huge portion of the budget is dedicated to graphics! It has become a sort of arms race. And engines constantly push graphics technology further. Have a look at unreal, they keep,adding new graphics features all the time. Most recently they added some very cool volumetric light probes, and distance field shadows. Very cool stuff.
Speaking of elite, have you heard of elite dangerous? Its running on the cobra engine, a custom bespoke engine by frontier, which does still push technology further. Getting all these procedural assets to run smoothly is no small feat!
To think that studios no longer squeeze as much performance as they can is incredibly naive. What sells games these days are graphics, (hence all the impossibly good looking demos at E3, and the push for 4k in the console space).
I love your Saturn coding tricks! That console was such a goofball. Amazed how you still remember it in such detail!
TT + SS = God Coding activated.
GH just shows the amazing capability's of the SS when the human brain is used :)
For the peasants:
SS= Sega Saturn
TT= Traveller's Tales
GH= Game Hut
ty ty
peasant her
My new secretary :)
The brilliance of these videos is in how succinctly they summarize.
Thank you soooo much, dunno if you read my request on last video but this is exactly what I wanted to know :D
yep!
I love so soo much what you are doing with your channel, any chances to have more details on an old interview you gave to Sega Saturn Magazine: What special effects and techniques are you most proud of in the Sonic R engine and why?
You replied: The cross fading "misting" effect, the reflective water, and the compression technique used to calculate visible polygons.
Can we have information about the compression used to calculate visible polygons ? Did the cross fading was a huge deal compared to what the Saturn offered in other games ? Can you explain why ? :D
According to Retro Gamer's "The Making of Sonic R" article, Burton said he was most pleased with the reflective surfaces, because the Saturn simply doesn't support them.
This very video explains why the cross fading was a huge deal...
GameHut oh sorry i didn’t understand it was the same stuff. Thanks again 😇
This is a rare peek into hardware specific coding which never really gets talked about. It's also a really good reminder of how easier amateurs like myself have it these days. Stories like this are the reason I look up to older devs with so much respect.
Any way thanks for all the great insight about tricks you've pulled off over the years. I can only hope to have stories like this to tell some day.
Excellent explanation, but there's one thing I don't understand. To the best of my knowledge, the VDP2 color calculation only works with Palette sprites, not RGB ones, since RGB sprites don't have enough bits to store any color calculation data (RGB being 15bit colour and 1bit to select RGB). So you have to use palette sprites to do the background fade. But you also do a transparent shield, which HAS to be RGB, because polygon transparency only worked in RGB sprites... on paletted ones, it would corrupt the palette index. So what is going on there? Extreme micromanagement to draw each sprite a different way depending on distance?
Also, when a shield is drawn over a far-away, half faded polygon, the shield completely draws over it, with no transparency. Is that normal for an rgb pixel with semitransparency on, to overwrite a palette index pixel underneath it?
Transparent shield was RGB. Palette sprites for background fade. Two different draw routines.
Wow, that must've been hell to micromanage given that you have to upload all the palettes in advance to the VDP2.Also, you didn't mention it in the video, but you used transparent quads for the rainbow trail on the speed booster. Non-textured, single colour polygons with gouraud shading, to keep the speed up. You can actually see the transparent pixel overdraw bug on those, but only if you pause the game since it is so fast.
zyrobs yeah, the emulator I used to capture footage drew them as non-transparent so I didn’t bother explaining them, but in short, the transparent corruption is avoided due to the orientation they are drawn at to avoid the overdraw corruption (apart from the join)
Your Coding Secrets videos are some of the most fascinating videos on the Net! Thanks!
Great video & thumbnail 👍
I've seen a trend on YT of developers giving concise and meaningful insights into how computers perform the apparent miracles they do. It is good. You're on the forefront. Carry on.
Sega i dont feel so good
You (and your colleagues I'm sure) seem to have some fantastic ways to think outside the box and use logic to get great results. Thanks very much for sharing.
Was the Saturn as difficult to code for as people say it was?
Yes, yes it was. To give you an idea how much, think that the Saturn's 3D capabilities were better than those of the PlayStation. But 3D games on the Saturn still looked like shit (most of them anyways) compared to those of Sony's console because programming anything 3D on it was that difficult. And well, you know, Sega killed the console before developers could get used to its hardware, and what was left gave the Saturn the reputation of being "that console that couldn't compete with the PlayStation because it had some shitty 3D".
Sad, very sad...
Jorge Enrique Riera Saturn’s 3D capabilities were always worse than PS1. Bad transparency (usable only for special cases), slower drawing, being limited to quads even if you want triangles, wasteful redrawing of the same pixels, inefficient use of video memory due to framebuffers being fixed size, lack of uw-mapping (shown by Gamehut in another video). Only minor feature that saved it sometimes was support of 2D mode7-like effects that complemented real polygons on some games, typically used for drawing ground and/or sky.
If you look at theoretical specs and numbers, the Saturn has a HIGHER polygon per second count than the PlayStation. For example, check out this article www.racketboy.com/journal/ps1-strength-and-weaknesses-vs-n64-sega-saturn
"saturn had perspective corrected texture mapping"
no it didn't...
N64 is also difficult to program, but the outcome is not as bad as Saturn. N64 uses triangle to draw polygons like PlayStation, so it also capable of 3D.
Another fantastic video. Thanks for sharing the behind the scenes of 90s game development. It's fascinating
Cool, Sonic R did something better than Mario 64.
I don't think comparing a late Saturn game with an N64 launch title (a legendary launch title but a launch title nonetheless) is a fair comparison but ok.
Jorge Enrique Riera u could also say he's comparing Sonic R to the best N64 had to offer graphically. None of the later N64 games progressed further than Super Mario 64 visually, so his point is still very valid 😊
"None of the later N64 games progesses futher than Super Mario 64 visually"
Emmmm... no?
If by "not progressing visually" you mean things like low-re textures, fog and other stuff like that that's more due to limitations of the system because of the cartridge format. And even with those limitations, visual progress can be noticed. Jet Force Gemini, Donkey Kong 64, the two Banjo games, the two Zelda games, and of course Conker's Bad Fur Day, you can't compare any of those games (and many others I'm not remembering right now) with SM64 and say there wasn't any visual progress at all.
That's like saying Final Fantasy IX and Chrono Cross, which are some of the best looking games on the PS1, are visually on the same level as Final Fantasy VII.
Conker is ages ahead in the graphic aspect. There's no fog, a massive draw-distance, big textures, dinamic shadows, and there's the fact that the whole game has voice in the dialogues.
Yeah, but would you believe me if I told you that I once heard someone say that any average PS1 game already looks better than Conker?
I also heard someone say that most N64 games have a framerate so low they're barely playable...
What can I say? The internet sure is a weird place sometimes.
whenever they talk about sonic r graphics, i remember a magazine article from that time saying "graphics look more like what you can see on the nintendo 64 than the saturn".
it hyped me so much but it was already too late.
This channel is entirely "hello! Today I want to talk to you about how every single aspect of sonic R is impossible for the hardware to support and was far ahead of its time"
Awesome stuff
FINALLY! Someone explains the difference in the Saturn and PlayStation's ways of rendering 3D in a way that I can understand! Excellent video. I actually was never curious about the fading backgrounds until now. Somehow I never really noticed it in relation to most other Saturn games like Daytona USA. It's amazing you had such a rich understanding of how to work with the Sega Saturn.
This is a great video. I'm curious, as somebody who was an insider at the time, do you feel there was any merit to Sega's decision to go with the quad-based rendering model they chose (beyond perhaps expediency in the Saturn's dev process)? We've seen a lot of videos from you about some of the challenges it creates. I can imagine the reasons that might have motivated them, but were there practical _advantages_ from your perspective?
I love ur vids. Reminds me of how much love was put back in the days and how close to the hardware you worked.
I love coding secrets!
I know nothing about this stuff. But the way you explain and present them, I find it entertaining, informative, and I actually learn what you explain.
NO! NOT THE MEMES!
IT'S IN MY EYES! IT'S IN MY EEEEEYES!
I'm always blown away by the ideas that game programmers and artist come up with to make something work.And from what I've heard making a Saturn game was really hard.I wish I had the brain to program but the tricks to overcome challenges like this really just make my head spin
Hi, I've been doing some hacking around with the PC version of Sonic R. one of my goals was to try and get Network Multi-player working again, however in the version that people use it was removed and the patches are no longer compatible. I was wondering if you might be able to go into why it even existed in the first place (if that was something you worked on). it just seems like a rather obscure thing to add to a PC port of a Saturn Game. Thanks, CnG
CodenameGamma I don't think he had any involvement in the PC version. Patches? How would patches not be compatible now if they were compatible before?
No one You know - Patches that are meant for a specific build (or range of builds) can fail if the internal code is significantly different in subsequent builds, especially if the patches are based on changing code in specific locations within the program's files, which was often the case. It was good for earlier systems that had a limited amount of storage space and/or network bandwidth for distributing the patches. Most newer patching techniques replace entire files, meaning the patches are going to be bigger, but not as reliant on what version is already in place.
Wow, this blew my mind! I've always wondered how Sonic R did that, absolutely crazy coding wizardry from back in the day. Keep up the good work!
3D was'nt made of triangle but sprite on genesis
MIND
BLOWN
Harmonie Duquesne on the saturn*
Not sure if this is exactly how they did it, but Virtua Fighter used same quad-based technology to display first truly textured 3D graphics on arcade machines (and Saturn/32X).
IIRC they had to rewrite code for PC port as it did not supported quads.
If you have triangle based hardware, you can just render two triangles with UV coordnates of 0/1 according to which quad corner, and it's done. If the hardware is affine, it will distort more than quad affine hardware, but it'll still work. If the hardware is perspective and you manage to retain Z/W through the pipeline, everything is going to look fine.
If you have quad based hardware and are trying to render triangle based models which use UV coordinates for texture placement, give up, there's nothing you can do, you need to remodel all of your assets in quads and with exactly one texture spanning each quad corner to corner.
There were apparently two versions of PC Virtua Fighter. As the game was released before PC 3D had standardized, a company manufactured a quad-based PC card, and it came with Virtua Fighter. A quick Google search finds the NV1, apparently Nvidia's first graphics card, based on Saturn hardware (even including a Saturn controller port). A handful of Saturn games were ported for this PC hardware.
Some years afterward, a friend of mind gave me his graphics card and the accompanying copy of VF, thinking I could use it as a passable upgrade for my old PC. Unfortunately, the card was effectively useless by that point. PC had quickly standardized to using triangles for 3D, and DirectX was created. Nvidia apparently tried releasing DirectX compatible drivers for the card, but it didn't really work.
BainesMkII, the NV1 is even more unusual than the Saturn; and it really has no Saturn compatible hardware except for the actually quite trivial game ports and the SEGA partnership to provide a batch of ported software. It's more unusual in the way that it doesn't render quadrilaterals like the Saturn, it renders quadratic surfaces, which are smooth, imagine each surface as being defined by 9 points in space, and imagine being able to represent a very close approximation of a sphere with just 6 surface primitives. However, no software except some tech demo that i have never seen in person and can no longer find, used the feature, the Saturn games used degenerated quadratics into 4-point quadrilaterals, effectively rendering same as Saturn.
I've never been a big fan of Sonic Rs gameplay but your videos really show what a technical marvel it was. Still possibly the smoothest looking game on the system.
You're a genius.
Absolutely brilliant work explaining not only how you done this work, but why it was a challenge in the first place.
What gets me though is that people say the Saturn cant do transparency with 2D sprites, but if its "polygons" are just sprites that are morphed and what not.
Why couldnt devs use this technique to make full transparent sprites in 2d games.
Hi Jon bit of a weird question but I have always wondered, is Dave Burton a relation to you?
Yep, brother
Ahh! thanks for the reply!
What about Richard Burton? ;)
I love watching these videos to see how programs and designers had to get around the limitations of hardware to create such amazing feats. Thanks for showing how this was done!
I din't feel fell so good Mr. Strak.
I just want to congratulate you on this channel. I got lead here by UA-cam as I'm interested in Sonic and have been following you for a while now.
Even though I don't have the means to create games, the way you describe and explain is so easy to understand and isn't condescending. I want to thank you. I hope your channel continues to grow! ♥
Why so much storage overhead? A shift and a mask will conveniently divide all 3 or 4 colour components in half or a quarter... it will fade to black but it means you just have to work with subtractive colour, so you just subtract the last step from 1...
Makes the code more efficient, and I don't think the algorithm actually just did quarters. I used that in the video for simplicity but I think the actual colour calculation algorithm was more complex in reality.
processing power was certainly a more valuable commodity than storage space. remember, we has just left the cartridge generation where 2mb was a lot to this new cd gen with as much as 650mb available to play with. storage wasn't a bottleneck.
But these systems don't exactly have an overabundance of RAM either for what they're trying to accomplish. Well, the hardware limitations play out differently for different projects, so if some RAM is left over, no reason not to spend it.
Eh, 2 MiB of RAM and 1.54 MiB of video RAM isn't all too shoddy for 1995.
Another great video. Man, I love Coding Secrets... Back in the day you were always doing things that seemed impossible on the hardware you worked on.
why does 3D blast have moral support in the credits???
Making games is hard. Helps having an understanding girlfriend
GameHut I'm just wondering what TT did for the SNES ports of its games, like Toy Story and Mickey Mania. How did you recreate the "3D" effects of the Genesis version on SNES, and if you even did?
The absolute chad.
being a hardware engineer feels like living in the 50's again (since reinventing everything). I think programmers back then had to adapt to non standard ways of achievements, so they had become hardware engineers in the process. lol
I love how devs always found a way to work around these restrictions on older hardware, awe inspiring work sir! Thanks for explaining it.
wait, so you are saying that each polygon in the game is actually a sprite that you had to move one by one? That seems EXTREMELY tedious
Shouldn't be that much different if it's still possible to use all of the standard cool matrix operations we use with triangles.
I mean, yeah, but let's say a character is made with 500 polygons, or "sprites". You would have to write one line of code for each and every sprite on a model, rather than just being able to write one line of code for the model.
I'm assuming you mean for rendering? No you wouldn't, that's what loops are for and it's no different that tris.
That's not really how programming works. Even on older machines with hardware sprites, like the Mega Drive or the NES, you still have to draw the entire screen, including all the sprites, for every frame. So every frame there would be some code going through all the things to be drawn, and drawing all those things on the screen. That's not really any different from how we use modern GPUs, we've just invented more efficient ways of getting all of those polygons onto the screen. (and modifying what they look like) Whether you call them "sprites" or "polygons" doesn't really have any effect on how to draw them onto the screen.
NOW I understand, thanks.
The fact that you still remember these coding tricks you did years ago is impressive enough. I have friends that work at InfinityWard that can't recall how they coded some of the older Tony Hawk games
These stories are such an inspiration for me as a programmer. You old school devs must feel really damn proud. Doing stuff back then really was an art.
Casually shows documents with a huge "SEGA Confidential" watermark over it. Love this channel
So that's where Saturn's unique look comes from! I will be on the lookout for disappearing gourad lighting now! Thank you for the awesome info.
Amazing. It's really nice to hear about programming and coding on the Saturn. The software based rendering has always fascinated me and seeing these tricks done with the limitations is something else.
God I love your videos. They are very in depth yet simple to follow. I grew up with Nintendo consoles but always had a thing for sega and I still do to this day. It clearly shows that you loved doing your job and I admire you for that.
This is the only channel where I have to watch every video twice because all this info flies by me the first time, but the second or even third watch I finally start to understand.
All these coding secrets videos are great. Please keep them coming.
Fascinating, thanks for producing these videos - love to hear about the problem solving that went into creating these games - limitations really do fuel creativity.
I love this, really cool and clever. The saturn seems like it was a really fun challenge to program on.
There's an added bonus in that fading in the lighting on visible objects creates a sort of atmospheric perspective too!
This is so good keep doing this, you are one of the few with actual good content even though I don’t really know what you are talking about half the time
thank you so much for making these. It's like getting to explore my childhood wonder^^
Every time I think you must be out of material, you come up with some other bit of wizardry. Cool stuff as ever.
That's hilarious, I literally played this game like 2 days ago and was thinking, gee, I wonder how they accomplished the transparency in the fading. Very interesting! I love these coding secrets episodes!
I find these videos really fascinating. Keep up the great work!
It's remarkable the amount of ingenuity put into programming these games.
Amazing. Explained the limitations of the saturn that i had no explanation for other than "it had too many processors" all in one video!
You should crowdfund a documentary where you explore the world of videogame graphics from origin to today. Would be amazing to see
Man, programming games for the saturn must have been a NIGHTMARE, but thank you for games I grew up with so much.
How amazing you worked on this!
Aah, that's nice! It's great how that works so well. I wouldn't expect it to, when first hearing the issues, and the method used to get around them.
A truly amazing youtube channel man. Every video I watch of yours is so clever
Every time. EVERY TIME. That I watch one of your videos, I come away a literal whiz at computer coding. THIS STUFF IS AWESOME!!!! And I don't throw that out there lightly. THIS IS SICK.