Is Pixel Perfect Collision Impossible? - CODING SECRETS

[@scotts918]

Programmers - if you tell them something can't be done, even if you're the developer of the hardware.... They. Will. Find. A. Way.

[@pumpkin6429]

Scott S 👏 👏 👏 👏 👏

[@imdone8243]

I'm still trying to figure out how to be happy. Scuffs

[@alakani]

​@@imdone8243 We could use CRISPR/Cas12a to make you happy, but being happy all the time would actually be pretty antisocial. I suspect you would automatically be happy without any personal code changes, if the genes responsible for narcissism were supressed in the general population, but the resulting loss of genetic diversity might lead to the extinction of our species if the environment changes too rapidly.

[@CrossoverGameReviews]

Just like players playing your game. "I've tested this for bugs and exploits. You can't cheat your way out." But they always find an exploit.

[@decrodedart2688]

yeah bro haha its probably a good reverse psychology trick! haha

[@NoahNCopeland]

It amazes me the ingenuity you guys had back in the day.

[@ficolas2]

Noah Copeland indeed, nowadays something like that is as simple as a broadphase and then checking for sprite collision. Even possible for 3d meshes

[@ficolas2]

Big part of game developement nowadays is code monkeying.

[@bangerbangerbro]

ficolas2 How do you just "check" for a sprite collision when most modern hardware are blitter systems. The only thing the hardware really does on its own is draw images and distort them in different ways.

[@ficolas2]

No one You know cpu, not gpu. Thats the thing, with a broadphase checking boundix box collisions and calculating the collision areas, modern CPUs are capable of doing this. Ofc it depends on how many collisions will have to be checked.

[@VulpisFoxfire]

Yeah...devs are relatively lazy these days, since they generally have processing and storage to spare instead of having to cram it all into very small parameters like they did on older machines.

[@matt4193]

Working with limited hardware and space sure made things tricky and at times almost infuriating, but man, do we get some amazing dev diaries explaining their struggle and clever ways to get even further than what the machines were capable of.

[@jc_dogen]

Matt using features built into the hardware isn't exactly exceeding the capabilities of the machine

[@digiorniboy]

Matt *than what we thought the machines were capable of

[@riddleiddle]

Sometimes I think their limitations sparked their creativity and brought us the best aspects in gaming.

[@johneygd]

Math Helper i guess those hardware limitations did not only sparket creativity but it may also have sparked the idea to produce systems more economically. For example if my first revision of a speak & spell gedjet contains a 1bit DAC for voices,,, but once i will descover that it is also possible to mimic 1Bit voices on a much cheaper PSG soundchip by using tricks, then i will implement that PSG chip in my 2nd revision of my speak & spell gedjet, and so on, this is just simply amezinf, seeing,doing more with less.

[@euphorik3120]

obviously & evidently not further than what the machines are capable of.

[@Diveji]

Videos about techniques and how (and why) were they developed are the most interesting in my opinion.

[@ChronoPhoenix]

you should watch how Chrono Trigger music was done for a magic experience.

[@phrygianphreak5408]

The amiga offered some interesting shortcuts. I always used three pass hit detection: Are two objects in the same region? If so, do their bounding boxes over lap? If so, do their pixels overlap? If so, collision detected. The main problem I found with collision detection is you spend way more time figuring out two things aren't colliding than you do are colliding. This is even true on the cpu level; the cpu will usually figure out two pixels are overlapping faster than finding out no pixels are overlapping. I figured if I just give the program plenty of easy opportunities to bail out of detecting collision between two objects that clearly aren't colliding most of the resources wasted on detection would be freed up

[@thosediamonddreams]

this channel is so damn good. I'm not a programmer of any sort and these breakdown videos are so fascinating, emphasized by the hardware limitations of old times. so clever. I love it.

[@benbaez6044]

This is not an empty compliment. This is not a blatant thank you. THANK. YOU. FOR. BEING. SO. DANG. CLEVER. This stuff is probably the single most intriguing thing I have ever found on the internet. Simply. AMAZING!

[@fedup7496]

This channel always has the most fascinating videos.

[@RobertSzasz]

This is one of those titles where the initial answer is easy (of course it can be done, it just takes resources you want for other things), but the workarounds are the interesting bit.

[@paulmarko]

Yeah, sadly even interesting videos have to use click-bait headlines in order to get views. "Coding pixel-perfect collision on Amiga hardware" just doesn't have the same zing to it. Cracked.com is famous for this. They always have something interesting to say, but it's wrapped in the most sensational click-baity title, because that's often the difference between 20,000 and 80,000 views.

[@ENCHANTMEN_]

IMPOSSIBLE multiplication hack! Can the SEGA Genesis do math? CODING SECRETS!

[@okarowarrior]

THESE 2 DISGUSTING SECRETS AMIGA CEOS DONT WANT YOU TO KNOW 4k flak rare version Frozen Spiderman Despacito 2.0

[@sonicmastersword8080]

@@paulmarkoClick-bait needs to die. When everything is competing for attention with absurd statements and excessive editing, nothing is perceptible as legitimate anymore.

[@paulmarko]

@@sonicmastersword8080 Thats the tragedy of the commons. Unless it stops working or until some top-down market control can be implemented, there's no way to prevent the arms race that is click-bait, sadly. :(

[@TheGuruMeditation]

That was a great video, thank you! You made something that is very technical extremely easy to understand for a noob like me. That takes a lot of skill. This is my first video of yours that I watched. I am very glad I found your channel and can't wait to watch more!

[@Larry]

What was the reason to rename it from Leander to Legend of Galahad?

[@SirRigbyBaconKaiser]

Basically: EA.

[@GameHut]

Larry Bundy Jr EA preferred an Arthurian Legend spin for the US Market so we changed the game intro sequence and the name.

[@badreality2]

Watch the Top Hat Gaming Man. He made a video, focusing on you, Billy Mitchell, AND Channell Awesome. It is interesting. Good for you, for staying with Channel Awesome, even though they never promoted your channel, and you grew your own fanbase, with your KZbin Channel.

[@badreality2]

NuvYou You're welcome.

[@hdofu]

+NuvYou rumor are Doug and Rob aren't sticking with the channel (there were 3 prerecorded shows from what I heard, he's also changed his face book status to say worked for Channel Awesome)

[@JackBz]

This is just a classic and concise coding secrets video. Your channel is such a joy

[@KallyNui]

Shoutouts to that artist for making such beautiful art with only SEVEN colors.

[@BdR76]

Wow, very clever use of the hardware there. Reminds me of an article "Contra Collision Detection" about clever use of hitboxes in Contra on NES, a system with only limited CPU power.

[@KuraIthys]

BdR76 Mmh. NES doesn't have hardware collision either. Though never underestimate a 6502 for doing the seemingly impossible. XD

[@Holammer]

Was the Megadrive version easier to write, or did it introduce new challenges?

[@XBladenoJutsu]

EA ported the game to MD, so I seriously doubt Jon would know.

[@Imgema]

He worked on other games on MegaDrive though, like Mickey Mania and Sonic 3D Blast, so i'm sure he has an idea.

[@GameHut]

XBladenoJutsu Actually we ported it, so I would know...

[@GameHut]

Was easier to write as it had better hardware so we could do more without worrying so much about the frame rate.

[@XBladenoJutsu]

@GameHut Huh... Ok. Didn't know that. I figured it was earlier than when you started up with the Genesis. I admit though, I never played it. I was always put off by EA games, even back then lol

[@chrisf1600]

I started programming in the 80s, and as soon as you said you'd found a way to solve the score collision problem, I guessed it had to involve chasing the raster :) That technique opened the door to so many clever hacks. Great video!

[@Yourname942]

I love the logic of your coding. Thanks for sharing with us!

[@jstock2317]

These types of videos are always so interesting! It's so cool to see how the hardware dictated game design and was used to leverage what was given. Thanks!

[@marceltiel7919]

Me and a friend were very impressed by Leander back in the Amiga days, loved the gameplay and the graphics plus the nice intro!

[@Gikkman]

These videos of yours are just mesmerizing. Thank you so much for sharing all these insights! It makes me view many of these old games in a new light, and appreciate them even more

[@MattLacey]

Easily one of the most interesting series of videos I've ever found on KZbin. Keep it up!

[@munchymcmouthington298]

feeling awestruck to see this up on youtube. Leander was one of my favourite amiga games of all time :)

[@TheRealE1337ist]

It's incredible that you manage to find elegant solutions to a lot of the challenges you're faced with. I don't think I would have done the same.

[@froilanrivero2826]

your channel is amazing you deserve way more subscribers! I always get such nice insights from this channel. thank you so much in advance

[@nekononiaow]

Thanks for the video Jon! I am very happy to see some Amiga related videos and indeed Leander is impressively colorful for a dual playfield game.I hope we will see more Amiga videos coming.

[@denisevans213]

Great, short easy-to-follow technical explanation from a gaming pioneer - thanks! - I LOVED Leander - The music, smoothness, tight control - superb classic! PS - Only just discovered your channel, will be subscribing!

[@USJbroly]

I love these explanations. It's great to hear about the technical stuff in the background of games. Thanks so much for sharing!

[@banggugyangu]

Just plowed through 5 videos.... This is a fascinating channel.

[@Islandswamp]

I feel like you are a genius at this. I don't have any programming skills but your videos still amaze me.

[@GanjsmostPrime]

You have been such a blessing to the KZbin space. Keep doing you man, we love your insight

[@randomizer2240]

I sometimes wonder how people fit so much into their days? I assume as well as being a lead developer at Traveller’s Tales and a movie producer that you have a family and children you spend a lot of time with? And then you have enough free time to have a hobby making technical KZbin videos and making director’s cuts of your old games. Anyway hats off to you man, I can barely get out of bed in the morning. Let alone work on that game I always planned to develop but never did. Love your channel keep up the great work!

[@caharkness]

Very clever use of hardware for the time. I always imagined pixel-perfect collision detection to be unnecessarily expensive, but I didn't know there was ever a hardware-level implementation of collision detection made until now. I'd have to say that collision boxes are still my preferred way of collision detection, as we have plenty of CPU time to handle the collision of even hundreds of on-screen entities on today's hardware. Often times, I have both a vertical and horizontal collision box for player-like entities so that vertical and horizontal collisions aren't confused when calculating where to move the player (for things like walls and floors).

[@flatfingertuning727]

Pixel-perfect collision detection in software isn't hard if one can spare some space for pre-shifted shape tables. If monsters can be up to 29 pixels wide and players up to 20, store four copies of each monster shape, shifted horizontally 0, 1, 2, or 3 pixels, and four for each player shape, shifted horizontally 0, 4, 8, or 12 pixels. Select a proper tables, figure out the starting offsets and amount of overlap, and the actual collision detection would be three instructions per row of overlap.

[@tcindie]

That you were an Amiga developer was enough to earn my subscription. :) Great content is a nice bonus

[@EmanuelFrias]

Great video as always! Thanks for sharing some good knowledge with us! Take care

[@Lilithe]

No wonder you got to work on so many great things. You come up with some really clever solutions!

[@jon4715]

Incredible, please don’t stop making these!

[@RussDnB]

Amiga fan here! Whilst I knew the Amiga was a special machine, and knew of its wonderful chipset, I never got into coding on it (Okay, a bit of AMOS, but not a lot). It’s videos like this that I absolutely love to see after all these years. More on Amiga projects please 😊

[@dancannova]

Thank you. It's been a blast watching your videos.

[@BOLL7708]

I found this just now, and I think it's a great showcase of how something can be done when optimized/developer for a specific hardware platform. Mostly thinking of PC vs console regarding this, but this was easy to understand and fascinating at the same time 😁 Thanks!

[@ArneChristianRosenfeldt]

More like hardware optimized for specific software found in arcade

[@markduncan7638]

I've spent so many hours playing this game, loved it, and the music.

[@seronymus]

This is gold. You're like a wise elder bequeathing his knowledge to the next generations. Every video just gets better!

[@AlexVideoPlayer]

Thanks for the very interesting video and the brilliant Leander. I still play it every now and then.

[@yabbaso]

Love hearing these coding secrets. Thank you so much for sharing.

[@sheik124]

I thought the level select crash handler was the best clever game design I'd seen, but this is better. Love your videos

[@androidgameplays4every13]

So you were the creator of Leander? WOW, I've spent my childhood playing and enjoying that game, nice to you see you here :)

[@lahma69]

A very clever and elegant solution! There is nothing more satisfying than figuring out how to accomplish a task such as this in such an efficient manner requiring very little overhead or wasted CPU cycles. Obviously though, it takes an intelligent individual to come up with these types of clever tricks otherwise (most likely) most games would have been utilizing the same workarounds.

[@Valegator]

Even thou I have no experience in coding and have no idea what you are talking about 50% of the time, I still find your videos fascinating.

[@Thevaporwaveraver]

thank you for the regular uploads ! :)

[@OrioPrisco]

but does that mean that if another's objetc box toucher your box but doesn't overlap your pixels WHILE another object overlaps one of your pixel the collision detection returns that you're hitting both objetcts ?

[@GameHut]

In theory, but in practice it doesn't really happen due to how I placed the enemies and collectables.

[@OrioPrisco]

so you were aware of that little flaw. Very interesting video

[@607]

Orio Prisco Background objects overlapping would probably introduce other problems, so it makes sense that he designed the levels so it wouldn't happen. :)

[@GrimRize]

I was a bit perplexed till I realized this was made on ancient hardware hahahaha, these days you can check against everything a million times and not skip a beat with these kinds of games.

[@Templarfreak]

Maybe something that could help iron out more issues is also figuring out which objects are closest, and if multiple boxes overlap then only the closest one would actually deal damage and perform knockback. That, and some invulnerability frames which I believe are already in the game right?

[@notthere83]

This approach reminded me of how I kept thinking about today's tech "But surely, there must be a way to use stencil buffers or something like it for collision detection!". Unfortunately, I don't have a lot of time to spare for game dev experiments and my limited research efforts have resulted in "Nope, not possible [possibly as in 'not feasible']" so far.

[@RabbitEarsCh]

Brilliant hardware solution! I love this kind of out of the box thinking. Fascinating stuff.

[@tgrush1253]

Minecraft Block collision: I'm 4 parallel universe ahead of you

[@sadcrowcaws]

These videos make the perfect companion to my morning coffee, love it!

[@retrofraction]

Leander had larger sprites than most games at the time, was really impressed with it. Makes sense since you were able to optimize it better.

[@mykel723]

It's cool learning about just how much hardware affected the development of games, and how a clever programmer can take advantage of various system resources to make things run that you wouldn't expect would be able to.

[@howieb4217]

Man, that takes me back! I remember saying to my brother, back when Leander came out on the Amiga, that games would never look better than this. Top game! Cheers for the memories.

[@jackfrost884]

Great work my guy! Just found your channel and its sick

[@TheRealKaiProton]

Another amazing insight into how games work.

[@thepirategamerboy12]

Somewhat off-topic, but I just wanted to say that I think it's really awesome you included twin fire buttons support. Such a nice thing to have on an Amiga game.

[@DrTexx]

So awesome, your channel is one of my favourites 😃

[@blackattack1840]

this channel is a game programming goldmine 😍

[@anothergol]

I'm way more in favor of multi-rectangle (or poly's) collisions, though. Makes a lot more sense for gameplay. To start with, you only want your blade to act as a weapon, not the character's ponytail. Then, games that favor the player by enlarging their hit boxes & shrinking the enemy's, are more fun to play. Then different box IDs are useful to mark spots from which bullets are shot, items are held, etc. Having multiple boxes isn't even much time-consuming, as a pre-test using the largest bounding box already eliminates most of the objects.

[@Cowcatgames]

I'm a consoles gamedev and I was expecting more comments like this. On a gameplay side, it makes much more sense to use multiple rectangles rather than precise collisions because you WANT to make the player able to defeat enemies easier (and the opposite for enemies) This is what I fixed for the consoles versions of Xenon Valkyrie+ and Riddled Corpses EX to make their gameplay more enjoyable. And what you said about the blade not extending to the entier character body makes perfect sense. Precise collisions should be used for things like terrain, not characters/objects interactions.

[@DIGITALSWOON]

The guy in the video, near the end, is mostly talking about saving time computing collisions by only calculating them when the player character's pixels are rendered on screen. I'm sure you can implement whatever method of collision you want this way, right?

[@79toddy]

I totally dig the use of copper to flag the screen elements - mind blown!

[@sauzeefy]

Good Lord, this is insane! I'm so impressed!

[@VenusHeadTrap2]

Sometimes these secrets amaze me so much that I think you were born to code video games

[@AdamvanAlderwerelt]

I don't know a darn thing about coding, but I love your videos anyway. Keep up the good work!

[@ripoutyourprejudice]

This was a brilliant and insightful video.

[@brynshannon6692]

Yunno, I think I enjoy learning about how older games on older systems were made because the same kind of ingenuity comes into play when I'm optimising my builds on Armored Core games. Well, not exactly the same, but clever tricks and work-arounds abound in both situations.

[@gfdgdfgdfgdfggfdgdfgdfgdfg9709]

after having programmed many games, distance is the best collision detection. Because it is circular. It's perfect and fast. The problem with boxes is you can't rotate them well and they are unprecise compared to the entity. For my fighting game and space ship shooter I used dist (circles), because even for something long straight like a laser I just place distance tests along the line. the advantage over line colision is that it works 100% the time. With line colision detection I had the problem of lines going through other lines sometimes. I guess rounding errors. Anyway, the other advantage of distance colision over other colisions is, that you have different colision zones for different effects. Pretty cool video. Amiga coders are the best. Also best artists and music.

[@almaelma11]

Loved this. Keep up the great videos!

[@faisalwho]

In 2003 I developed a 2d game engine for my game programming class where I touted pixel perfect collision detection. The idea was while the GPU rendered the sprites on the screen using directx, I software rasterized all the objects/level into an 8 bit buffer, where each object had an 8 bit value. When the player shot a bullet (hitscan), I bresenham line traced the path through the rasterized software buffer, and when I read a pixel, the value of the pixel would identify the collidable object for me. Though I touted "pixel perfect" collision detection, in order to minimize fillrate, I actually blitted the 8bit masks at half resolution (so a 128x128 Sprite had a 64x64 byte mask blitted to the software buffer)

[@Xalusc]

Hell yes, I love Leander so much Thanks, Jon!

[@sablesanctum]

You made one of my favorite games of all time? I salute you, sir!

[@fluffycritter]

It's worth noting that the VIC-II chip in the Commodore 64 would set a sprite-to-sprite and sprite-to-background collision mask as part of its regular rasterization process, and so that system would give pixel-perfect collision for free (with one frame of latency). There was also a game development library for Turbo Pascal called AniVGA which gave a pretty close approximation to pixel-perfect collision, where it would preprocess sprites with both horizontal and vertical span information and would do the collision based on those span overlaps. There were plenty of situations where this would generate a false positive but they almost never came up in actual gameplay (and was still better than box-to-box).

[@TheBcoolGuy]

Woah. I think we take modern collision for granted. Thanks for yet another intriguing look into a veteran programmer's masterpieces!

[@youplaboum]

Hi Jon. As a European dev, do you have any insight you could share about the challenges brought by systems being 50Hz/60Hz and the differences in aspect ratio? For example, the port of this game on the Megadrive (The legend of Galahad) has the same code on both the EU and NA cartridges. Usually this means that the game was designed to be played at 60Hz and the EU release was simply not optimised. However, in Galahad the Psygnosis logo circles are drawn correctly in 50Hz mode, as is the crystal ball in the level briefs. But while the the music is adjusted to play at the correct tempo, the gameplay speed is different between 50/60Hz, and the increase in vertical resolution isn't used. So what was meant? Faster taller 60Hz or slower fatter 50Hz?

[@KuraIthys]

Now that's an interesting question. The whole conversion stuff is such a mess, even 20 years later it still gives me headaches working with retro systems. (though in fact the biggest single headache is you can often write code on a PAL machine that works fine but is impossible to run properly on an NTSC machine to the point that you basically have to start over. The reverse is almost never true, but you do get that slowdown and other issues.) I could be wrong, but intuitively I'd assume European developers are creating PAL games first, while US and Japanese devs are creating NTSC games first. The reasons for why that is should be kinda obvious. Keep in mind in the 80's working with the opposite system to your region would mean having a TV or monitor that could support that as well as the other region's hardware. Not actually a trivial thing to arrange. - imports would be expensive. Psygnosis is a European developer/publisher, so you can probably assume the logo is correct on PAL machines because it was designed for PAL machines, NOT NTSC ones. However if you made the game with an international audience in mind you'd probably avoid creating it in a way that outright wouldn't run on an NTSC machine, which is what would happen quite easily if you started using PAL specific features too much. (Long story short, due to a design quirk PAL machines are usually vastly more capable for many tasks than their NTSC counterparts. The reasons for this are a total accident, but it does have serious consequences if a program has to run on both.)

[@flatfingertuning727]

@@KuraIthys From what I understand, many older black and white sets could be made to show either 50Hz or 60Hz video by turning the vertical-hold knob; some might require a resistor change if the knob's range wasn't sufficient, but given that many sets used capacitors with +/-20% tolerance, the easiest way to make a 60Hz set that would be guaranteed usable would be to design it so that if all parts are in the middle of their ranges, the vertical hold knob could adjust vertical refresh rate from e.g. 45Hz to 75Hz. Even if component variations made the refresh rate 20% higher or lower than targeted, shifting the knob's range from 58Hz to 88Hz, or from 32Hz to 62Hz, would make the set would be usable. If components are near center, the range may extend down to 50Hz without any modifications; at worst, one may need to swap out a resistor in a way which would still leave the set usable for both refresh rates.

[@xXYannuschXx]

It continously amazes me how much work went into the programming of such games at the time to solve complex problems and make the game as good as possible on the hardware, while today we have Ubisoft struggling to render mirrrors...

[@feosTAS]

So somebody was using it!

[@Tinfoiltomcat]

This is my favorite youtube channel

[@RaymuHakurei]

Always enjoy these. Thanks for making them. on a side note, have you any plans on continuing those Genesis coding lesson videos further?

[@enigma776]

So why was the name of the game changed to The Legend of Galahad on the Mega Drive?

[@Unplanted]

The port was so different, I assume they just went with a new name to honor the differences and work they made.

[@enigma776]

Ulmo need to play the Amiga version then

[@GameHut]

EA thought it would be more successful in the US being based on Arthurian legend rather than obscure Greek/Japanese influence I guess. It was their call.

[@enigma776]

Well after owning the Mega Drive version and now spending an evening with the Amiga game, I got to say I prefer the Amiga version, even though I can only select music or SFX. Just something more responsive in the Amiga version.

[@bangerbangerbro]

GameHut I didn't realise that the name "Leander" was anything to do with any mythology

[@MrVolksbeetle]

Man, that was fascinating. I genuinely wish I knew more about programming...

[@ZILtoid1991]

My game engine has pixel perfect collision with the option for a faster box collision. I'm planning to modify it to enable testing 8 pixels at the time, which I put on hold due to the engine's capability of displaying arbitrary sized sprites (save for 16 color ones, in that case you need even number in width). The engine stores the collision data as 1 bit bitmaps that can either generated from alpha mappings or zero indexes on the fly, or custom defined for each sprites, later including multiple shapes with their own unique identifiers.

[@BluecoreG]

Pixel Perfect, my worst nightmare.

[@akpokemon]

speed running?

[@stephanemorel130]

He's talking about a mix between the movies Pixels and Pitch Perfect

[@BluecoreG]

I'm talking about the collision system

[@gimmedataids]

@@BluecoreG Ahhh. I see. You're referring to the Faith No More song "Collision" being covered by the band System of Down. I have to agree, that would be terrible.

[@novafawks]

Wow, very informative! This helps me a lot, as a beginner programmer

[@ArtificialDjDAGX]

Is there a way to perform this collision detection today, but without the box checking, so that we can be assured everything will be pixel perfect without any situational flaws?

[@sotem3608]

I really love this channel!

[@sotem3608]

Thank you very much for sharing all your information!

[@Mviews-hb4ib]

I remember years back on the amiga with Amos I found a way to just add 1- 4 points on screen I'd check during a swipe frame. It worked really well if you knew what to check for :) it was so fast .. the character even had a point so if an enemy walked into the end of your weapon then they got slight damage

[@johneygd]

I bet most games use multiple box collision detection rather then single box collision detection. It’s also impressive to know that collision detection can be used on both sprites & backgrounds.

[@Possi_ball]

You have done Leander too?!?!? I accidentally subscribed to the channel of a legendary pioneer!

[@EposVox]

Nice

[@RFC3514]

A common approach on systems that don't have any hardware support for collision detection is to do multi-level collision. For ex., first you check for collision based on a box or circle (using squared radius so there's no sqrt call) and then run it again at a smaller level (sub-sprite or pixel) for objects that passed the first check. Same in 3D games (starting with a sphere, then a simplified 3D hull - typically an oversized version of a low-LoD mesh for the object in question - then the actual models, for perfect bullet detection). Since the vast majority of objects is the scene will fail the first (very fast) test, you can afford to spend a bit more on the collisions that matter, and get them 100% accurate (though with multiplayer games where everyone is seeing a slightly different version of the scene there will still be some apparent mistakes).

[@GarrettStelly]

love your channel!

[@anactualmotherbear]

man every time you talk about a trick you used it is like "this, but, fortunately, but, fortunately, but, fortunately." As someone who coded on 80s hardware in the 90s this series is fascinating.

[@McMacMastaMan]

Thank you very much for your informative video. I feel like i understand the topic at least a bit compared to zero ideas beforehand. The only thing i have to critique is the intro music. FOR THE LOVE OF GOD ALLMIGHTY, make it so it matches the volume of your speak in the video!

[@namakudamono]

Many thanks for this fascinating explanation Jon! Leander was an absolutely beautiful game back in the day, and it still holds up incredibly well today - a fantastic achievement given the modest hardware of the time. I’m curious as to whether there are any changes you would make to the game today? Perhaps there features you would have liked to have implemented, but simply ran out of time, or memory? I really appreciate watching your videos, but those featuring Amiga titles are the most enjoyable, as it is the machine I grew up with. Thanks again, keep up the great work!

[@syrus3k]

Leander.. this game is forever in my memory.. mostly for the incredible music.

[@antjarvis]

Leander was my favourite game, still have it! Thanks Jon :O)

[@peterjohnson9438]

These days, you usually use a three-prong approach to collisions: First, get a rough candidate set using something like an octree. Then, do a coarse box check pass. Then, do a by-polygon collision mesh test. I wonder if this "global exact first" type of approach could still be used somehow?

[@PhantomHarlock78]

This remind that in Racing the Beam they talk how the sprite collision in Atari 2600 was detected by hardware, what make 2600 games very precise.