Secrets of Sonic 3D's "Impossible" scrolling 

"In the end the game couldn't reach the speed of Sonic 1" I think moving any faster than what was already possible in S3DB would've been too fast. In the game you only have a limited area of view and being able to run any faster probably would've just ended in frustration because the player would run into things too often.

The graphics are rather impressive for the Genesis, and on top of that you still stuck the FMV at the beginning of the game. It may not have been the best game on the console but it was a technically impressive one.

Oh John, talk dirty to me about memory.

I never felt 3D Blast was too slow as a kid, even seeing it today I think it's fine.

Scientists: Humans cannot physically travel at the speed of light. They'd burn up Jon: So here's how I used compression to make it work

An improvement for the "feeling" of this being a slow game could have been a few high speed sections strewn inside the level which use more traditional less detailed and repeating tiles confined within that part of the stage, while going back to tile streaming when the section is over.

Jon: "Theoretically, this should be impossible to do" Also Jon: "Yeah lol so here's how I did it anyway"

Ah, THAT'S why the floor looks so simple compared to everything else. I thought it's just to clean the visuals because Sonic 3D Blast is a fast game and fast games require clean visuals to be playable.

I like how at the end you ask if we know cheaper ways of putting graphics on the genesis like we fully understood anything you just said.

Serious limitations: *Exist* Coding Secrets: *Oh No!* 2 seconds later... Coding Secrets: *Anyway*

It never fails to impress me when people manage to do incredible feats on limited hardware and RAM. I've always been a down-to-basics kind of programmer. I guess it's a byproduct of being raised coding on the Spectrum and Acorn Electron (Basic) where you have to get creative to squeeze more out of less. These days everything has crazy RAM and these kinds of hardware-level tricks are seen less and less, even on consoles.

Lovely. Have you ever had to program for the Genesis's Addons, like the 32X?

I love how an Englishman is behind some of the biggest Japanese games of the last century!

Also titled "How we built a Frame-buffer on a Sega Genesis". That's amazingly interesting and shines a different like to me regarding 3D Blast, the amount of work and coordination for everything to work correctly, as the game design needed to be in point with the limitations of the VRAM is amazing. I think that 3D Blast has had it's bad points over the years, the platforming in 3D sucks, but as a side-game it's pretty fun, the music is also great and the bosses were pretty interesting ideas. Sure it always felt too "Western" compared to the original games, but still.

Great Vid! Sonic 3D Blast is such an underrated game.

I love how John can be so introspective and self critical about the methods used. This dude should be teaching architecture and game design at some university.

This is actually so interesting to see how this effect was pulled off!

You should break down why Sonic Spinball has such a low framerate, and maybe try to optimize it.

Hi Mr. Burton! After roughly 26 years, I've finally finished Sonic 3D Blast on Genesis. And with all emeralds! I wanted to let you know I enjoyed the game and that your videos helped me appreciate all the work that went into it. Thank you to you and the team for everything y'all did!

You should review The Adventures of Batman and Robin for the Sega Genesis, due to each level having it's own groundbreaking technology (sprite rotating, 3D like scrolling, etc.) I would like to see how it worked and how they were even able to fit it onto the cartridge.

the highest-value coding channel on the planet. Nice one, Squire.

"Theoretically, this should be impossible to do" Jon: I'm going to do what's called a Pro-Gamer move

**COD Warzone sweats nervously**

The only improvement I can think of would be to have some extra RAM in the cartridge and use that to store the uncompressed tiles, instead of storing them in ROM. This way you could store the tiles compressed in ROM and then decompress them to the extra RAM when the level loads. Although this would've probably necessitated some kind of elaborate ROM bank switching to get the data in and out of the extra RAM and I'm not even sure if the Genesis could even support external RAM like this.

I wonder if this rendering system is any different on the Saturn version.

"Do you know any better, cheaper ways" .......I barely just understood this way, let alone recreate it and further less know of any better ways.

I was actually really impressed with the tilesets in Sonic 3D Blast. Some of those tile pieces are fairly high detail for a late release 16bit game. I didn't mind Sonic 3D Blast being a slower game. Isometric games are a bit unwieldly when they move fast.

Honestly it feels less like Sonic is slow and more like his animation is. The top speed felt fine, it's definitely the extent in which you can reasonable expect to be able to control Sonic, it's just that with 3D models, you didn't really have much of an opportunity for animation smears or squash and stretch techniques back then like you did with 2D sprites. I see plenty of games suffering from this even now.

Hi

Can you explain how the physics work, how sonic detects where he is...

Did you have any input on the saturn port of sonic 3d?

One option would have been to somehow include more VRAM in the cartridge, kind of similar to what the SNES with the super FX chip

Jon: "...and Sonic was all about going fast". Oh dear. This is the only thing that I have a gripe with. So many people say this, and they couldn't be more wrong. I never had an issue with the speed in this game. Perspective in making jumps? Maybe. But the speed was never an issue. At least I know why the number of objects on screen was kept to a minimum. Interesting stuff.

I seem to recall you did a direct code port for the Saturn version - I assume the CD-ROM wasn't nearly quick enough to stream the tiles, so how did you get around this? Was there enough RAM to load all the assets to memory and stream them from there?

I feel like the max speed in Sonic 3D is just right, honestly. I've never once thought Sonic was going too slow when playing the game. That honour goes another isometric Sonic game.

8:20 Feels like those time you ask something on Stack Overflow and you are indeed the first one to encounter that problem. All you can do is just working on the solution. So, this is basically an unanswered question from the '90s. Do you want to set a bounty on that? XD

This game always makes me motion sick for some reason 😂

Ooh, I like that the tilemap is slightly bigger than the screen! On the original NES, you got two whole screens' worth of tiles arranged in a row, which gave you smooth scrolling along only one axis--with way more tiles than you needed to do it. If you wanted 2-axis simultaneous scrolling, there would be artifacts along the edge of the screen (like in Mario 3). I have no idea if the SNES was set up more like its predecessor or the Genesis in that regard.

This guy is a master at coding, i would even compare him to John Carmack.

Naive question: wouldn't RLE helped both the throughput and storage pressure on ROM? I've recently ported some of my code (that uses RLE) to the Amiga 500 and it worked fine (not blazing fast, but I'm only using C and no special chip...yet). Maybe there is some drawback I'm not taking into account?

I'm not a programmer, but man I love hearing you break all of this down. Keep up the amazing work. Would love to see you break down some of your favorite viewpoints/graphical approaches to camera placement in Genesis/Mega drive games. For example, you spoke about the Isometric view here in 3d Blast and others like Spot goes to Hollywood. What are other games that you appreciate in achieving such a unique look? Maybe also examples that worked to achieve something so technically jarring in theory. Some stand outs to me are like the Mickey Mania/Lion King Stampede/Moose sequences (saw your videos on those and they are great) or Vectorman - Day 2: Metalhead stage.

Even as a kid, I thought that 3D Blast captured the feeling of Sonic very well, fast or not. The level geometry with slopes that affect your momentum in a realistic way really helps. I think isometric adventure games just never get a good critical reception, even if they’re amazing. They had such a brief historical window, during which they were unintuitive to those used to 2d, and then immediately afterward 3d made people regard them as obsolete.There’s another isometric game for the Mega Drive, Spot Goes To Hollywood, that I maintain also holds up well, but it’s a hard sell

"Do you know of any better cheaper ways to achieve the same thing? If so, please let me know 25 years ago."

This is one of my favourite RU-vid channels, keep it up!

Can you please do a video on how they coded the entering painting animations for each unique painting in super Mario 64 - when you enter the painting it has a cool liquid wave effect, how is that programmed?

Sonic is about momentum management 😌

I feel like Sonic not being faster in 3D Blast isn't the problem, if anything, Sonic's running speed should've accelerated slower so you feel the sense of speed when Sonic would've finally hit his max speed, perhaps indicated with an actual running animation instead of him jogging at all times.

A. You're a genius coder. B. Sonic 3D is already too fast so it shouldn't be any faster. It tends to cause me nausea. Not your fault -- most 90's 3D games did. It wasn't until the Halo era where it finally +started+ to get comfortable for me, but old games can still make me a little green to this day.

I would have been here in Sega dev studios in the 1990s to see the fascinated face of early Sonic Team when they see for the first time the incredible Sonic speed rendering without any lag they had obtained on Genesis. After the release, this fascination became viral on all 1990s kids which played for first time.

So you're saying that sonic 3D had 4k textures all the way back then? Modern devs are playing us for fools with 4K gaming!

God I would love to see a new genesis game made by this man..... come on buddy..... new side scrolling shooter,,,, maybe a doom port for genesis.... your a amazing programmer

I guess the same technic were used in the isometric Super Mario RPG. Because it's a turn based RPG, it's generally not so fast (but it has some fast scenes as well!), but additional effects, like some parallax scrolling and scaling/rotation (mode7) were added.

So I got a question; were these techniques used on the Sega Saturn/PC port of Sonic 3D Blast? I'd imagine the stronger hardware would allow for better graphics, but the two versions look more or less identical imo

So, that's probably why Megaman X acts the way it does with the widescreen hd branch of bsnes.

Hey how much involvement did you have with the Saturn version of Sonic 3D? Any plans to release a Director's Cut of that version? I'd love to see Super Sonic, time attack, toggle-able soundtrack, tighter controls. Etc.

I Don't think the game would become unplayable at double speed you would just need to design controls with more friction.

coding secrets titles : IMPOSSIBLE the video: its fucking simple

Wow your not even political and RU-vid unsubscribed me from your channel without my permission.

Might have tried using staggered tile loading for axis speeds lower than 8px/s - put all the bandwidth towards loading the fast axis and partially load the slow axis with what's left (screen edge tiles loaded last), it's not gonna be needed on the same frame anyway. You could angle the camera such that loading bandwidth between going vertically and going horizontally is the same. Worst case scenario would be going diagonally which will take 1.4x more total bandwidth than going in cardinal directions at the same speed, but also each axis would only be 0.7x as fast so they both can be loaded in staggered fashion. The levels could be designed to have mostly horizontal or vertical high speed segments, which would actually help with going too fast in an overhead view game. Finally, maybe you could cram in some basic compression that would activate if bandwidth was lacking, such as skip every other byte when reading from ROM and duplicate it when writing to VRAM and use that for screen edge tiles, and use normal loading algorithm for the center tiles, maybe store the indices of half-loaded tiles and revisit them once bandwidth becomes available (player stops moving).

It's insane to me that you could plan a tile map and use this "visual noise" to make good looking graphics. How do you ever got in to this. How did you learn to think with tile maps o.O ? This is the definition of not intuitive xD.

Sonic 3d is just such a technical marvel. This game just shouldnt be able to work on the genesis, but somehow you guys did it anyway!

Weren’t all Sonic games developed by the Japanese Sonic team? You are not Japanese, are you??

So if this was such a problem, how come the game wasn't made for the Saturn first? That version of the game I assume has none of those bottlenecks but inherits their symptoms anyway by dint of being an enhanced port. I believe you've said in the past that the Saturn version was done by SEGA and perhaps another contracted studio and functionally runs the Genesis code you wrote through a layer of obfuscation that also adds the extra fancier graphics and substitutes the sound assets? But I suppose what I'm asking is if they were going to make a Saturn version, why not have you make that version instead of the kneecapped Genesis version to begin with? I already suspect it might have to do with X-Treme not being considered truly sunk until you were nearly done with the Genesis version, come to think of it, but hoooo golly...

it was a cool game and all. but if you was doing an overhead view you should have made a sonic RPG with it like mario RPG on snes. it would have fit better than an action game.

Most people may not agree. But I think that Sonic 3D was an awesome game and these coding secrets make it even cooler and impressive.

John: So, this is what I wanna do Genesis: Lol, no chance mate, not gonna happen John: And now it's done, didn't even bother with compression Genesis: 😐

I don't have any idea why but the intro/background music used in these videos triggers my anxiety really badly LOL

I don't think it ruined the game, I remember playing it as a kid (long after it had come out) and it seemed pretty fast.

Would love to know how you got the diagonal scrolling so smooth in this game. Working on my own isometric game at the moment and get some amazing staircasing effects. >.>

i am not sure if it was a thing you could do but some cartrages could "upgrade" the console by including extra hardware. it would be intresting to use one of those to add better sprite rendering to the sega hardware. in that case you could have brand new tricks to get even better 3d effects. you could basically rotate or scale sprites inside the cartrage and send them as regular sprites to the console for the final image.

I'm so jealous of your expriences with genesis development

To be honest, I've never felt the game being slow. It runs pretty smoothly. It for sure is a technical miracle on the Genesis. I also like the soundtrack, but unfortunately the gameplay was never my cup of tea.

Clever using separate layers for the same background.

Very impressive. I know all about tricks to conserve memory. I spent 3 years designing a huge game on RPG Maker 2 and I wound up scripting things the developers never even considered. That game is called Runewind Saga, and might still be available on RPG Maker Pavillion, but I never finished the second part, and due to a series of tragic events involving losing my girlfriend and home, the project was abandoned.

Jon, I don't understand any of this, but your channel is always so nice to listen to.

Well done! Nice, creative solution to the problem, and I'm confident you picked the right way to go about it. In the 8-bit days (1980), I worked on a hospital inventory system in which the hardware had only 48K of RAM, so we had to code it in 8080 assembly and each code module had to fit in 3K. We managed to do a lot with a little. Thank God it was text only! All good wishes.

The biggest problem programmers had then is graphical limitations, the biggest problem today is game sizes, no one really want to use any ways to downgrade the game size, you have your PS4/5 with 500Gb HDD/SSD and you can install 2,5 Red Dead Redemptions here, when you should be able to have at least 20 games at the same time, but very small amount of devs cares. i swear many games can use 5-10 times less Gbs if this wasn't a case.

love these videos more than you could ever possibly imagine. thank you for taking the time to put them together, you do such a great job with them.

So effectively, asset streaming was shoehorned onto a Sega Genesis. I thought the streaming used in Soul Reaver on PS1 was impressive. 😳

What if you didn't actually use the whole screen for visual updates? Rather than 320x244, do 260x200? That would allow temporary faster than 8px/frame

There are a lot of ways to optimize how quickly data can be sent, using trickery with the VDP registers. This article can be very helpful, I'd suggest giving it a read! www.plutiedev.com/mirror/kabuto-hardware-notes

I find it so fascinating the lengths you went to create something different. 99% of gamers dont realise the skill needed to create these effects. The likes of teirtex and other poor teams never spent any time to get the best out of the megadrive . Well done to you and travellers tails team

Sounds kind of similar to John Carmack's adaptive tile refresh. Except, on an actual console.

Just wanted to say thanks for what you have done. I'm glad I get to see this video series.

It’s mad the things you was able to accomplish 👍👍

I always appreciate that hopeful, "if you can think of a better way, let me know in the comments" you put at the end of each video. You have too high an opinion of us. X)

I'm glad you covered this, I always wondered about the cost of uploading new graphics from the ROM vs the traditional way of keeping the same tileset for a given level. I think it's a neat trick and I'm not quite sure you could have done it any other way without compromising on graphic variety and other factors? Great video!

Man, I Love these Videos, I had the Saturn Version of this, Was that also yours ? with Regards to the speed, for Me, Sonic was Fast enough in S3D, and played fine.

Damn! I misread the title. I thought it said Sonic *C*D

Fantastic video, very interesting how much effort went into these games! Thanks for sharing!

I forgot about this game. I loved this game as a kid

These games are still some of the greatest. I like the way that, as a player, you just turned it on and played. Games now take an hour just to get started, and by then I'm like "forget it".

Ok if the genesis draws tiles ahead of the visible screen wouldn’t that mean that it would be super easy to make it widescreen you’d just have to extend the view to that extra space that people don’t see and maybe make it so enamys and sprites don’t pop in

A lot of people in the homebrew community have explained this to me. It's nice to finally hear about the design decisions directly from you Jon 👍

I really don’t dislike the scrolling, it feels really fast to me and maybe even faster than the original sonic.

Does anyone else get motion sickness from this game?

Thanks fo another great video! I wonder what sort of graphics we would get if this level of optimimization was still applied to modern games (is it even possible/feasible?)

I'll NEVER forget me and my cousin's reaction when i first rented this game at a blockbuster back in '96 the intro alone was so epic you should definitely do a video on that alone. It's such a gorgeous epic intro...

Love these deep dives. As a game dev (and a gamer, too), these vids just make me love the Genesis/MD all the more.

Great video. Thanks!