Crushing Sonic to an Impossible Size - Coding Secrets!

[@thejedisonic67]

Welcome to Hydraulic Press Channel, today we have this blue hedgehog. He's got a lot of attitude and he's spiky so we must deal with it.

[@alanbareiro6806]

VAT DA FAAK?!

[@Aqua_Xenossia]

Glad I wasn’t the only one who immediately thought that upon seeing the thumbnail.

[@DehnusNorder]

Don't give Logan Paul and his KZbin overlord any ideas.

[@toyotaboyhatman]

And now.. for extra content we have these gold metal rings which are extremely dangerous

[@anidnmeno]

He is very dangerous and could attack at any time!

[@RahanPlays]

I’m always impressed by the lengths programmers had to go to save precious kilobytes back in the day. You and your team really had your work cut out for you, and always managed to ~magic it out~!

[@NoName81393]

I really wish modern devs were like this. We'd have new games compressed and optimized as far as possible. With the trend of digital downloads being at an all time high you'd this this would be priority. Who wants to download a 70GB game when it could be half that size? I'd rather have lots of compressed games than less than a dozen uncompressed ones. I'm sure Valve, Microsoft, Sony and Nintendo would love to save on server costs as well. I imagine its not cheap to allow millions of people download dozens of gigabytes simultaneously.

[@Ramkakh]

InverseCloud well the developers of this time have another challenges, I suggest to you to check ExtraCredits Channel they explain a lot of things more than the programming aspect of the games. Greets.

[@sonicmastersword8080]

InverseCloud There is still compression, as it is essential for any program. However, the age of innovative program is currently in a long hiatus. Games are just games now, baring a few exceptions of absolute masterful craftsmanship. The creativity of the first few generations of gaming , for the health of the industry, needs to return.

[@KuraIthys]

Yeah, it's quite something isn't it? Conversely when you look back at games and think about say '16 bit' vs '8 bit' games, a lot of the differences you see are arguably less to do with hardware that is more powerful in a general sense, but simply games that are larger in general, due to more storage. A great example of this contrast is the Super Mario series. Super Mario Bros is something like 32 kilobytes. Super Mario 3 is 384 kilobytes. And Super Mario World is 1 megabyte. Now think about how those games look and play, and you can probably agree that Super Mario 3 and Super Mario World have more in common than Mario 3 has with the original. So in fact, it would seem in some ways that the amount of storage space available to work with can have a bigger influence than the hardware a game runs on. At least, to a point. You also see it rather dramatically on the n64 vs the Playstation - one can trivially throw around 600 megabytes or so, the other... It cost a small fortune to have a game use 64 megabytes. The consequences of which seem pretty obvious if you think about it... Notice the n64 basically hasn't got a single RPG to it's credit? (unless you count the two Zelda titles)... It's also something you can see in reverse if you were to do homebrew development on these old systems. If you're going to build your own cartridge, you can easily use 16 megabytes on these 16 bit systems nowadays, and with a little bit of extra work, it's well within reason to use 128 megabytes or even in excess of a gigabyte or more... And if you did that on a 16 bit system you could certainly do a lot of things that would have seemed impossible at the time. (Consider Street Fighter Alpha is the first in the series to have asymmetric character designs. Why? Space of course. even the SNES version, after accounting for the dedicated compression chip, is a 96 megabit ROM, which is at least twice the size of anything else on the system.) Storage space is a major issue that is often forgotten, Yet it has major consequences on the types of games that can be made, what they look like, how they play, and so on.

[@Cyber_Akuma]

Not just Kilobytes, but even BYTES mattered, that's what impressed me, that even compressing a frame from 608 bytes to 505 bytes was considered significant. I can't imagine how limiting such constraints must have been. Also, about compression on modern games. Don't forget that modern consoles are a lot more locked-down than previous consoles where you basically has full low-level access to the hardware. You can't really just tell a specific chip to run a specific task in machine code anymore which is how many of the amazing games from older consoles pulled off some "impossible" tricks.

[@frenchyproductions9692]

A crazy amount of love and care went into these games. You guys did good work.

[@mogo9052]

I wish they would have made this a 2d game

[@sonuro6444]

Mo Go it it 2D if pixels are visible its 2D 3D is when its models with no visible pixels

[@imdone8243]

I love you default cube.

[@Lightblue2222]

@@mogo9052 Check out Sonic Blast for Master System/Game Gear .. not 3D Blast, but regular Blast.

[@thomaspleacher2735]

I thought this game was so cool as a kid in 1997. It's really fun to listen to you explain all these technical details I had no idea about 20 years ago.

[@EposVox]

I really hope someone has been working on a Genesis game and is learning from this and makes the best 2018 Genesis game ever xD

[@GalacticCuisine]

i was thinking the same thing when watching these videos lol

[@KuraIthys]

There are. I forget who. But a lot of this stuff is generally applicable to retro hardware. I've seen few techniques in these videos that are overly specific to the Genesis. Now, I do homebrew development on a variety of systems, though Mega Drive/Genesis is not currently one of them. These videos are still quite informative though. I was particularly impressed with the video compression one, but also some of the pseudo-3d effects. Despite what some would have you believe though, the majority of effects would work just as well on other 16 bit systems. Several of them would also work decently on a lot of 8 bit hardware too. Good coding is good coding after all.

[@djpain]

Honestly it's inspired me to learn how to code for a mega drive. (since I dont have a genesis)

[@KingBlonde]

djpain aren't they exactly the same? different name for different regions but the same hardware?

[@djpain]

the megadrive might be same hardware but it has a different timing than the genesis because of the power.

[@TheRanzar]

Haha nice hydraulic press thumbnail.

[@laharl2k]

Welcom to the hydrolic press channel. Today we are crushin a hedgehog.

[@blue-slushy]

Hydrolicity zone

[@LoPhatKao]

It could attack at anytime

[@SendyTheEndless]

You should have just caught his toe under a moving block, that's usually enough to crush Sonic :)

[@sonicmastersword8080]

I'm surprised you didn't use the Sonic 1 final boss as the thumbnail. That boss was made to compress Sonic into a pulp.

[@TheQuickSlash]

“I’ll STOMP YOU INTO A BLUE JELLY” -Eggman, 2011, Sonic Generations.

[@TheQuickSlash]

BFDIFan447 Oh, sorry. But how did I?

[@AAhmou]

BFDIFan447 You were close...

[@benjabby]

This series is like crack to me. I absolutely love hearing about optimization / compression tricks

[@produKtNZ]

I know exactly what you mean - I especially enjoy learning of the lengths and workarounds they had to go to just to fit a game onto a 4Mb cartridge with this video here being my all time favourite so far :3 kzbin.info/www/bejne/mV7EgqmGbKiId6s

[@digiorniboy]

benjabby don’t forget the trippy, unnerving, yet somehow addicting music.

[@SentientMeatbag]

Same. It's like a forgotten art form, running into the limits of what the hardware can do is rarely an issue now.

[@paulwebb2078]

Check out sizecoding, it's an art involving programming the smallest possible programs.

[@mafiousbj]

I love how they had to use their brains to squeeze every possible bit/byte back then. People don't give enough credit to old developers about deeply knowing how the hardware operated too and the tricks it allowed :)

[@SdudyoyO]

Game devolpers these days don't even try to compress anything. They look at their games as if they have an unlimited amount space, which makes for bigger and sometimes better games. But I'd love to see game developers work under these sorts of constraints that younger developers have never had to worry about. I wonder how many could adapt, and how many would give up?

[@Karanthaneos]

A lot of times, problems with compression and missmanagement of resourses is what makes games look or run like shit, because they literally think that the resources are unlimited. That's why we get stuff like Assassin's creed corpseface and the terrible PC ports of Batman games.

[@BonzaiThePenguin]

Sdudyoy Newton That's usually an unfortunate side effect of data streaming being faster than data decompression, it perversely results in faster loading and fewer stutters.

[@CoolJosh3k]

Good programmers still do tricks, because the better it performs means more possible customers. For example, in my game I am developing, I stop running AI code for creatures who are far enough away.

[@Professor_Utonium_]

Devs need to go back to learning to compress things well, there is no reason DOOM should take up 50 GB in my storage space.

[@donpalmera]

>Game devolpers these days don't even try to compress anything. What do you base that on? Modern games still have to workaround issues with the hardware like the maximum texture size a specific GPU supports etc.

[@that_kaleb]

As a current software developer, I absolutely love learning about these cool tricks used in older software/games. I really love this channel, keep it up!

[@cntrn-ti6xy]

You should do some tutorials videos to re-create these tricks. The homebrew scene would love it!

[@CoolJosh3k]

c3ntr0n800 I would watch these really advanced vids, but probably too much work for too small of an audience.

[@CommodoreFan64]

Cooljosh3k while I would love to watch them as well, I have to agree it would be way too much work for such a small audience. maybe if he did a once a month live stream for a few hours it could work?

[@VelvetCondoms]

I can see some other things that could be done. * Within the forward-facing animation, the last 6 frames can be achieved by mirroring the first 6. This also applies to the back-facing animation. Those two changes, collectively, could effectively eliminate 12 frames. * Because Sonic wobbles to the left and right in his running, there's some overlapping angle between each direction. Although the feet and arms are different, the head position is the same. Perhaps some sprites can be reused. * Since his hands are to the sides in the forward and back frames, and in the picture you've shown, they're internally separate sprites, perhaps mirroring could be used for the hand sprites in a few cases, eliminating another few sprites. Are there cases where, because the frames are made of multiple sprites, some sprites could be reused and/or mirrored in different frames of animation?

[@lmoore3rd]

Wow, trip down memory lane. I did a lot of 2D game console programming early in my career. Tools I developed did similar optimizations when I was working on CGB, AGB, Nitro, and dozens of those plug'n play TV Games from Jakks. Our artists were also master pixel pushers and looked for optimizations before the art made it into the content conversion pipeline. Glad to see there still in interest in the old ways. Every byte counts, every sprite counts!

[@arashikou6661]

As someone who has a favorite interview question based on Run-Length Encoding, it tickled me to see you present a practical application today. Thanks for the fun videos on the tricks programmers used to have to resort to!

[@MadmanEpic]

Something I've always wondered, why were all of the sprites so badly jacked up around the sides with the off-color pixels? It happened in DK:C as well, and I've always really hated it.

[@ejej3000]

low resolution I'd imagine

[@dan_loup]

Its the anti aliasing being roughly cut instead of blended properly. Still works fine on CRT.

[@GameHut]

It's actually because we had to anti-alias to a background that generally wasn't dark. When seen on a dark background the anti-aliasing doesn't look good, but generally in the normal gameplay it looks fine. No idea about DK:C

[@Banderpop]

These CG sprites are usually lit from the front for the sake of consistency, which means the edges of rounded body parts tend to fade into complete darkness. Although I'm sure it was avoidable.

[@KuraIthys]

I've never liked pre-rendered sprites much. Though ironically some of the first graphics I ever created for a game (roundabout 1998ish I'd guess? When I was first exploring game coding, anyway), were pre-rendered. Of course, I had the advantage that I was working on a late 90's era PC, so I could use 16 or 24 bit colour for things. Plus, my sprites had a resolution of something like 120x120 and would have been used at a 1024x768 resolution, meaning small details are less obvious. Even so one of my first lessons in doing this was that you had to turn off edge-antialiasing entirely or everything looked wrong; Anti-aliasing against the background is NOT a good idea for pre-rendered sprites, since it will look wrong in just about any situation. Lighting is also a major issue, since you have to pick an angle and stick to it. My sprites were lit from the top left, but I could get away with that for the same reason I could use 24 bit 120x120 sprites with 40 different orientations and no compression whatsoever. Even with that, pre-baked lighting means your image will only look correct under conditions that approximately match your assumptions about lighting. Which is quite limiting. Everything will look off if your environment doesn't match the lighting conditions your sprite was rendered in. Meanwhile As soon as you start to use hardware flip or rotate functions, the need for your sprite to exhibit symmetry to avoid looking really strange means you have to keep any light sources from creating asymmetric shading. If you only flip horizontally this forces lighting to be somewhere along the centreline of the sprite. (basically front or back lit only) If it also flips vertically, then your lighting can really only be from directly in front or behind. This, by the way is a rule that applies not just to sprites and backgrounds created using CGI, but also those drawn using more traditional methods. So if you've ever looked closely at 16 bit games and wondered why they rarely show any sign of pre-baked directional lighting effects, now you know why; Doing so would restrict you from being able to flip tiles... However, I assume a lot of these problems are made a lot worse when you have only 15 colours for a sprite, (and even then have to share those 15 colours with other onscreen objects) I've certainly found it extremely difficult to get a pre-rendered object to look anything other than horrible when reduced to 256 colours or less, and that's with an optimised 256 colour palette! I'm honestly amazed anyone managed to use pre-rendered graphics on hardware with such extreme colour limitations, and have it not look considerably worse than it did. Personally I'd avoid pre-rendered graphics on anything that isn't at least capable of 16 bit colour, or at the very least, I'd be extremely cautious with the use of such graphics... The results rarely look pleasing. (I for one, consider the DKC series one of the uglier games around, especially in hindsight.)

[@Icelink256]

Heh, during your explanation, I said "RLE?" to myself, a few seconds before you showed it on-screen! :P A game I'm currently developing, uses RLE compression on the in-game art, and bitplane compression for the cutscenes. There's no particular reason for the cutscenes to be compressed, but the game's total size is only 848KB at the moment. The game runs in modern Windows 10, all the way down to Windows 95, with no compatibility problems, so far.

[@SouthwesternEagle]

Icelink256 Hello :3 I subscribed to you. You're awesome!

[@MarioManTV]

Icelink256 just out of curiosity, what game engine are you using to get that level of compatibility?

[@jwhite5008]

Wow. I kinda admire your effort. Not a lot of devs put a lot of effort in this nowadays. Seeing more and more thrown together bloated unity games is just sad... However note that PNG and JPEG offer better compression and are much less of a hassle than implementing RLE by hand (unless software runs on arduino or something). IIRC, PNG was not in Windows 95 OEM by default, but is installable (probably comes with IE3.0+), and is a sane requirement. Windows 98 probably has it by default. Actually finishing game development within acceptable time (that is, not leaving it in dev hell) is just as important as makeing it great on the inside.

[@KuraIthys]

OS support for image formats isn't an advantage if it's a hand-made engine. Trust me on this, my earliest programming was custom-built engines. One of the more painful things I had to code was an image loader - and that loader was using OS calls to load uncompressed BMP's... Just the windows API calls themselves, and the conversion to a format suitable for actual use in gameplay was a fairly painful process compared to the majority of game code itself.

[@jwhite5008]

+Kuralthys I understand what you mean, but in my opinion one needs to figure out how those API work once and then just reuse the same code. There are a lot of examples and tutorials online. GDI+ APIs are kind of overcomplicated and not well documented, yes - gone through this myself, but I'd say it beats implementing (and debugging) compression by hand. If everything fails, there are a lot of free libraries for stuff like that. This was not always the case, however: before windows98 era neither all necessary APIs nor good tutorials nor a selection of free libraries existed, and decompression itself could have been too slow, and 16/256-color pallets made it even worse, so yes, that actually made sense back in the day.

[@WildNorWester]

I'd just like to say I'm really enjoying these videos. I've enjoyed these games, and it's interesting seeing the 'behind the scenes' and the challenges involved in getting the game to work as required. Some of it is ingenious.

[@PMVault]

These short sharp videos are what I miss on KZbin soo much. I subscribed n Smacked the bell to all. This content is completely underrated.

[@fredbronze]

Jon, correct me if I'm wrong, but compressing the graphics like this means you can't have the VDP pull the graphics directly from ROM using DMA, right? Did you just make the 68000 transfer the graphics to VRAM directly, or did you decompress the art to a RAM buffer first and then DMA from RAM instead?

[@GameHut]

Fred Bronze decompressed to RAM buffer and then DMA. And if I’d just done a scroll update that frame I wouldn’t decompress and DMA until next frame to load balance..,

[@fredbronze]

Interesting. Sega themselves used the RAM buffer approach for Knuckles in Sonic 2, though not for decompression purposes. Rather, Knuckles' sprites are run through a lookup table which converts them from the Sonic & Knuckles color palette to the Sonic 2 color palette.

[@The_Nametag]

Watching this series is absolutely amazing. Today we have copious amounts of memory and cycles, so a lot of the old workarounds just aren't necessary anymore. But seeing the great lengths you guys had to go through to get things to work back in the 16-bit (and earlier) era, is why those games still have a secure place in my heart. They required some real skill and dedication to try to get machines to do things they were never meant to do, with amazing results.

[@darkcoeficient]

As an mechanical engineer I really appreciate these videos. It gives an isight to the ingenuity used in software development. This is a craft and an art in itself.

[@IIIIIVEERATIIIII]

When I was a kid, I originally played a PC version of Sonic 3D Blast. It made sense to me that it would be in 3D because it was a PC game. Later I got the Sonic Mega Collection for the Gamecube and when I played Sonic 3D Blast on that, I assumed it was the PC version. I just thought it was a PC game and that was that. Learning later in my life that it was actually a 3D looking game on the Mega Drive came as a real surprise, and now this channel has been explaining so much about it. I never imagined that I would end up caring so much about this game but it feels like the biggest part of your channel and I always love learning new things about how you made it work.

[@Gecko1993HogheadIncOfficial]

Dude! I am completely enthralled by these Coding Secrets! If you could stream a webinar about 68k Assembly Language from the beginning to the most advanced of methods for game development, I would attend that!

[@FloppyDisk893]

Thanks for showing this off, this just shows the limitations that classic game developers had to deal with, and the dedication they had to fit everything into one small cartridge

[@LiamGoodison]

I adore these videos, its like looking behind the curtain at the inner workings of your childhood games

[@lunaitc]

Look, I love your work and it's absolutely fascinating how you managed to get so much out of the Genesis that shouldn't have been possible, but couldn't you have come up with literally any other name for this video? Like, one that won't haunt our recommendation lists for months to come?

[@SpunkMcKullins]

This is probably the only channel on KZbin I can enjoy without understanding a single word or detail presented.

[@Prelmable]

These videos are great! Thanks! I hope for a few Leander Amiga secrets. I liked that game very much back when I was young ;)

[@GameHammerCG]

Sir, you impress me even more with each video. The way you approach these problems is genius.

[@wolfgangfrost8043]

Glad you figured out all this cool stuff. It's crazy to think how far the Megadrive was pushed in it's lifespan. 216k is like almost half the entire ROM size of the original Sonic.

[@willrobinson7599]

Great to hear how much effort u put into maximizing what u could get out of the megadrive.

[@Dirk1Steele]

Another great video. In the era of what amounts to virtually unlimited resources, it is incredibly interesting to learn about the lengths game creators had to go through during previous generations of gaming.

[@7awliet]

Sensational. 16-bit devs were masters of computing of their time. Thanks for this video.

[@diegoantoniorosariopalomin4977]

your videos have inspired me to focus on developing and perfecting tecnqinues to increase the quality of 3d assets while consuming much less memory

[@BluecoreG]

But who made the sonic sprites and where are they now? 🤔

[@naskivik]

Welcome to the Twilight Zone.

[@KokoRicky]

*Starlight Zone

[@Spin_Music]

i think he was talking about the model too?

[@Gaia_BentosZX5]

Guys, I think the fella was referrring to the original spriter for Sonic 3D Blast.

[@PsyAlola]

It could be Jon himself.

[@grabisoft]

my favorite youtube channel lately, love this guy

[@akpokemon]

The Director's Cut was fun!! One of the VERY few games I've played all the way through in the past few years

[@brianuuuSonicReborn]

Is there a advantage/disadvantage for using larger but fewer tiles vs smaller but more tiles? Like at 2:49, let just say we ignore one of the pixels on the top right tile of the leg, it can then be represented by just 2 8x8 tiles

[@n64ra]

Awesome! Love seeing the coding secrets on Mickey Mania and Sonic 3D Blast. Would love to see one on the LEGO games too!

[@sacriptex5870]

with 7 years of age... i would never thought, that all these programming gymnastics are needed... amazing!!! video game programmers are my heros of childhood

[@ZeSonicGamer]

Man, i love these videos of coding process and the this increreble tricks to put a X object with all quality possible in a 16-bit console.

[@blackattack1840]

this is seriously giving me all new understanding of exactly why the folks who come up with these techniques get paid all the big bucks.

[@taLLdavid33]

I love to hear about all the work you guys go through to make fun gsmes for us.

[@StormcloudLive]

Always awesome to see how these games were possible on such limited hardware. Amazing.

[@whodareswhb]

So when you shifted Sonic left 1px at 2:35, I presume you needed to write something in the rendering code that move the sprite positions to cater for the non-centred images?

[@SkyCharger001]

one would assume that each sprite-set would include a zero-point definition.

[@lmoore3rd]

Yes, a similar technique we used at my studio stored offsets for the tiles from center so when the animation frame attribute data was loaded into OAM at runtime the offsets would be correct and didn't matter if our sprite chopper tool shifted the image it to optimize tiles. We also added warning logs in our sprite chopper so we could look for when this was happening and check the art manually for weirdness. That helped a lot when debugging broken art in-game.

[@ZZFilm]

Really amazing stuff! Subscribed! I'd love to one day see you pick apart some of the magic that the developers Treasure have been able to pull off back in the day. They were really wizards!

[@nullref0]

I didn't know that there could be a practical use for RLE! Very very cool video. Thanks!

[@GalacticMoblin]

The more I watch game design vids, the more I am able to picture a way to code games in my head

[@emilianojz]

its impresive the way an animation can be crush in size like that. I will like to know how do you manage to balance compression and process capacity in situations that bring that problem. I mean, who is to decide? youre a legend, thanks for sharing!

[@kevinfrazier1692]

These videos honestly make me love the game even more

[@TomTheDragon87]

Jon, your Coding Secrets videos are just amazing, i especially like how well you explain everything, so that's relatively easy to understand. I was wondering if you maybe could make a video about the Overdrive 2 demo in the future and "at least" talk some about it? That would be awesome :)

[@donkeycheese8098]

Hey gamehut,since sonic 3d blast uses prerendered sprites,is there any models for sonic,maybe even tails,knuckles, badniks?

[@chadiaffan1956]

sonc- a-donc. eh They were prerendered in now obsolete 3D rendering platform and even if they were available it would be incompatible with anywhere else

[@raiser4068]

:/

[@Everik-ct6pg]

Chadi Affan well, someone can remake the Models for us to use today

[@rubberbawlz]

Chadi Affan I wouldn't underestimate a programmer with a task. If an old defunct format is briefly 'revived' due to a realease like this, then there will always be a programmer who will write a conversion tool, just so they can use the artifact. I doubt the original was much different to an obj. There has to be data representing a point/line/face, even if it's abstracted behind nuances of the format.

[@RetroArcadeGuy]

Didn't Jon just program a viewer to look at old Saturn 3D models?

[@WakoDoodle]

Knowing this is not only interesting, but makes me wish it had a sequel; just to see how far talent like this, could take technology in video games today!

[@LateToTheBeardParty]

Game devs in the 90's were some of the best programmers in the world for figuring out wizardry like this. I wish I'd be born a decade early so I might had the opportunity to have a go at it myself during that heyday.

[@SantosRey]

I really like this videos.You take something that I will have to spend a lot of time to understand and make it easy. Good job :D

[@ezequieljimenezgarcia5081]

I'm an aspiring programmer and this is like black magic to me. Incredible.

[@SlashClawGaming]

Love this series so much, do you think someday you will talk about what it was like behind the scenes during development of this game like directions given, time constraints, stuff you wanted to add, etc.??

[@vectrex28]

Nice! I use these techniques (except the decompression) in my own games since I do homebrew NES games and the NES kinda works the same with the 8x8 sprite tiles. Great video as always Jon

[@PikaPerfect]

You wouldn’t think a video about sprite compression and space saving would be so entertaining would you? I love these videos though, they always teach me something new lol

[@theburntcrumpet8371]

You are actually a god of all software! I loved sonic 3d blast as a kid

[@bunnybismuth]

I saw the thumbnail on this and actually thought it was Hydraulic Press Channel. Not sure if I should be mad or amused.

[@ejasmith]

Watching these is like: "when will he say the line " "And then we mirror..." 🥳👏

[@daehnihc]

i lov ur videos theyre super informative and they never bore me cheers

[@flussence]

Really cool, and it highlights what a difference knowing the hardware inside-out makes. Compare this with S3&K, where they used “real” compression (some LZ variant) for the level tiles, but had to have every level trap you in loading zones dressed up as cutscenes. For a game about going fast, that's _no good_!

[@almaelma11]

Absolutely love your videos. I can't wait to see more!

[@PlayerOneStart]

Wow, another very informative video as always. Keep them coming!

[@TheFerdi265]

Recently I reverse engineered a Game Boy ROM that used the same kind of encoding to initialize its stack buffers, and stored the data inline with the instructions. Interesting to see the exact same encoding used here!

[@metametam]

Always brilliant! Great video!

[@CricetoFunni]

I know this videos pretty old, but here’s some advice I’ve learned when trying to “crush” sprites and such. 1. Copy the files to a thumb drive or same other separate storage device 2. Buy a hydraulic press 3. *You know what to do*

[@TehBurek]

I actually thought for a second that mirroring couldn't be used because of the lighting on the model, but then I looked closer and saw the light is centered, so it's still symmetrical. A wise decision indeed.

[@Phos9]

And this episode’s extra content, we have this sprite sheet, which goes in 16 directions and can fill the entire cartridge and may atahk at any time so we must deal with it.

[@camo6465]

Do you ever look back on those days where you had to go above and beyond to make a game run as amazingly as possible? It seems like it would’ve been interesting to live in that time :)

[@sonicmastersword8080]

Camo 64 Consequentially, they put more thought and effort into the design of the game and its longevity. For all the effort they put into it, they didn't want their product to be in a discount bin.

[@camo6465]

SonicMaster Sword oh don’t worry. I fully agree that gameplay is INFINITELY more important than graphics. But back in those days it would’ve gotten bonus points if it pushed a system to its limits as shown here. It’s too bad the original Genesis version of 3D Blast was subpar

[@crimson-foxtwitch2581]

Since these are also running animations, half of the walk cycle can be mirrored, bringing the total number of needed frames down to 54 and the final size to 27,270 bytes(26K)

[@SecurityDivision]

Games now - download this fancy hat skin, 20Gb added to the download queue.

[@Arphael]

Thank you. Very interesting videos! Want to see more from you.

[@FramePlay]

And yet there were still many more animations of Sonic, like halting, getting hit, jumping, etc.

[@Kazuo1G]

What you also could have done to save on space was remove that one pixel, which would remove the need for that tile entirely and add to the compression. It would not detract from the design. I've worked with tilemaps for an old game, and sometimes removing one pixel is all it takes to make space for another background decoration or floor.

[@jasperturck5628]

Your voice explaining coding is so soothing...

[@cube2fox]

Jasper Turck Could also be the music.

[@ca_lcium]

I didn't understand anything about this video but it was still quite magical to watch

[@vic123]

It must've been kinda fun making games back in those days. People really had to think outside the box to stuff things in. Nowadays, memory feels unlimited, so clever tricks like these would never be thought of these days

[@mogo9052]

Vic But he makes it sound so easy. Like, of coarse we had to reduce the bytes by doing this way and that. Duh!

[@papyrussemi2848]

Long story short, 3D Blast and Mickey Mania turned the Genesis on its head.

[@retroboy-fh1ji]

Papyrus Semi also Gunstar Heroes and Alien Soldier

[@retroboy-fh1ji]

Papyrus Semi and i forget ResQ (the 3D bonus stage still blows my mind, its like Star Fox but running on stock hardware)

[@mogo9052]

Papyrus Semi I wish more developers treated their projects with this much care.

[@solarflare9078]

And Toy Story

[@bangerbangerbro]

@@retroboy-fh1ji What do they do again?

[@SATOTEHDOOD]

Obviously. No slowdown No glitches well there is 1 bug only in sound test Memory saving techinques Creating Impressive Intro and They can fit even if they cant Good hitbox except for the rings Good cutscenes Great music Detailed sprites 16 angles to make the illusion of sonic turning Good bosses Good zones Great shadows Great 3d mechanics I ran out of ideas

[@Satoshi9801]

If you take "compressing Sonic" in a different context, you get Robotnik's fantasy.

[@brynshannon6692]

Fascinating video, as always! How much do you think modern game developers, indie or triple-A or anyone else, could learn from or make use of the knowledge you've given us with this series? In particular, I feel an indie developer who really wants to capture the authenticity of an old game could make use of all of this, but what do you think?

[@dylan8287]

These videos make me admire the old days of gaming where everything was so restricted.

[@mafiousbj]

I now know how different games with sprites of similar sizes can kill the framerate or run smoothly because of the process that goes behind with the optimization. Back then you really had to squeeze every bit you could!!

[@FullHitPoints]

One trick I noticed, but you didn't touch upon, was the fact that the up and down animations only used half the amount of frames necessary for the walk cycle, with the other half of the animation being mirrored, which slightly throws off your math when calculating how much data is needed to store the run animations. Still, it's a very highly informative video none-the-less!

[@3dmarth]

I was surprised that he didn't mention this. Unless the animation is really using 12 unique frames, but it it doesn't look that way.

[@rata536]

It is exactly the same thing I did when I started doing custom sprites, although modern tools allowed me to satter the sprites and save even more tiles. I have no compression though. Anyway, seeing that I did the same thing as you did makes me feel like a pro. XD

[@FixTheWi-Fi]

IS EVERYTHING IN THIS GAME "IMPOSSIBLE"?!...

[@RetroArcadeGuy]

Travelers Tales have done the impossible in many games... While most games boasts 2D excellence and explosions in just a 2D plane (or pretty smooth racing games like TopGear2, in example), they showed us the Genesis was way more capable of other developers were used to.

[@RussDnB]

Love how memory was managed in 8 and 16 bit machines. Very cool.

[@MarcoValeKaz]

I know this was posted ages ago, but could it be possible in the run up and run down animations to actually delete the right side, duplicate the left side and play it off sync?

[@dadangsudadang5963]

I thought this episode was about making sonic model's width and height to weird numbers, say, negatives. After watching the video, I got like OOOOOOH I GET IT

[@SkyCharger001]

it may not have helped much, but if you had checked for similar tiles, you might have reduced memory usage even more. (if tile 4 of animation 1/frame 3 equals tile 9 of animation 2/frame 7 then you only need to store one tile.) and the N/S angles can self-mirror (first six frames for left-step, last six frames are first six flipped)

[@SkyCharger001]

and the tiles don't need to have the exact same color, just the same base-pattern. (Instead of storing full colored tiles, you store indexed tiles that you color as needed, allowing you to, among other things, to use the same set of tiles for every coloration of an enemy)

[@Monacomaverick]

He lost me at the Hexidecimal bits, but it's still fascinating hearing how they made such a beautiful game fit onto a Genesis cart.

[@StuffOfSonny]

In the case of the character where you explained using long words, wouldn't it have saved space to just snip the one pixel used in that character? I wonder how many characters throughout the whole game only contain a few pixels, and thusly could be snipped without a jarring difference in visual quality.

[@Snakeshroom]

Do you have the original 3D model used for Sonic?

[@techleontius9161]

Even if he has, i think, you won't be able to open it normally with modern software.

[@Ultimatedogfan]

@@techleontius9161 right

[@bangerbangerbro]

@@techleontius9161 Then he can use old software. I'm sure its nothing obscure. Just SGI stuff probably.

[@IronMan3582]

Great thumbnail, great video content

[@jfwfreo]

Is there anything you guys didn't know about the graphics hardware on the Genesis and how to get the most out of it? Although from what you did with the Toy Story music, you seemed to know how to push the YM2162 to the limit and beyond as well... I bet there were a few guys from Sega and other developers looking at some of the effects you did in Sonic 3D, Micky Mania etc and wondered "how the hell did they do that on the Genesis?"