I love this one because it's a great example of an impressive feat that didn't require any code wizardry like using hardware to do things it was never meant to do or exploiting a quirk of the machine code. This was accomplished through understanding the hardware you were working with and not being lazy. Pure and simple.
As good as the Amiga hardware manual was, it wasn't perfect. For instance, there is no indication that reading the collision flag would reset the flag. That's just the sort of thing you had to find out through trial and error. The hardware was full of interesting intricacies like this, and it's why the demo scene was so consistently prolific.
*Some games, like King of Fighter's on the NEO*GEO would use one collision box per frame per character, then, if there was a collision in those 2 larger boxes between the characters, it would then start to check smaller sub boxes for greater accuracy.*
I believe that most of the Unreal Tournament games did something like this too; because when you view the collision in game there is an extra box around players. I could be wrong though, but it makes sense.
@@CUTIE_POXX Actually, it's not, Street Fighter 2 does not do that. It maintains multiple collision boxes on each frame instead of just one like the King of Fighters. Can you name some examples to support what you said?
That's usually the difference between broad and narrow phase collision and is used in modern day collision systems too. Simple collision is used to query whether a proper collision check is necessary, then more precise collision is done between the two overlapping objects.
On the 486 we did it all in software. It's a much more powerful PC than the Amiga, but still very ancient, and pretty much a potato by today's standards. Basically we would do a "broadphase" box check, and if the boxes were colliding, we'd find the overlap and do a per-pixel check -- which was actually pretty fast if you do it cleverly. What we did was precompute a 1bpp collision mask of each sprite as we loaded them in (and for rotating sprites, we'd precompute 256 versions of it). It was a pretty small increase to loading times, and RAM usage. Then you could just find the offset between any two sprites and perform a a Bitshift and a Bitwise-And to compare the two of them; letting you compare up to 32 pixels at once. It was blazing fast. 😉
I have been an avid gamer since my first NES back in the early 90s. Even today I still love playing games and even my son is a huge gamer who is just starting to get into coding himself. I would LOVE to pick the brain of someone like yourself that has been in the industry for as long as you have. Everyone of your videos are just gold to me, to learn how all these things were done. Keep the videos coming.
Amiga's hardware and software design were ingenious. All the respect to the engineering team. It's so depressing that the management screwed up and went bankrupt.
@@sirkastic You're the only smart one in this comment thread. It's sad we live in a world where there are more stupid people than smart people and the stupid demonize smart people for speaking truth just because it's negative truth. Worse yet they use smart people's inventions, like computers and internet, to make themselves seem right because there's more of them and they'll supporting each other with likes and shoot down the smart person with dislikes and rude unjustified comments. They like to think it's 'majority rules' with anything in life, even being right or wrong, but it's not, right is right wrong is wrong no matter what the ratio of right to wrong people is, simple as that.
No, otherwise this wouldn't count as a coding secret, which is what this video and this entire channel is all about. That's like saying making unique and efficient code for the CPU counts as "hardware acceleration". This is unique hardware utilization coding, not simply hardware acceleration. Otherwise every single Amiga game would have pixel perfect collision detection, and that's definitely not the case.
I love this. Constraints lead to creative solutions. Game development is one long history of cheating to make something appear a certain way, without actually having to simulate it realistically. It’s all sleight of hand magic tricks. Thanks.
This is why I love watching videos like this. I love ingenuity and problem solving that went into the days of limited hardware. And as stated even the graphics designer was able to make awesome backgrounds with the limited colour palate.
I was getting to the point where I didn't even know if this game actually existed. I used to play the Mega Drive port Galahad and fricking loved it, I am so glad I have started watching your videos. Totally oblivious that you actually created one of my favourite (albeit a port) Mega Drive games.
Amazingly satisfying series for a developer who’s always been more interested in how games work than in actually playing them. And as you’ve shown here, a lot comes from using every trick the hardware supports! Fantastic.
I've just came along this channel and found this video after watching the SEGA Sonic videos you have made, not knowing that YOU coded one of my favorite games from psygnosis back then and probably my first purchases ! Thank you so much for this channel, absolutely love it. The music was escellent with the harp ish lead sound in he first level if i remember correctly. There were ,at least for me, not much resources available on how to program the amiga hardware or 68000 assembly in general so i went the AMOS route. Anyways, i'm glad i've found this channel and i hope to see more of this. Perhaps a tutorial on how to make a pong clone in assembly for the amiga and then go on to a more graphics driven simple platform game, or perhaps a line by line explenation if possible. Anyways, thank you for this, kudos, big ups !
Awesome content! Also, thanx for Leander! As an original owner (and yes, I mean I bought it back in the day), this was one of my favorite games. Not that I was above a bit of piracy from time to time (sorry..), but not for games I really wanted to play. And Leander was one of my favorites! I'll eventually re-buy it as I have been rebuying most of the games I used to own, but it is going for crazy prices still. Which is justified. Great game!!! And this video makes me appreciate it all the more...
Genius. I love the way the inherent restrictions of the consoles forced developers to think so creatively and become extremely intimate with the hardware. This was great and so satisfying to see the solution.
clever use of the hardware, and even if there was limitations, I like that you acknowledged that the limitations on the colour scheme was overcome by excellent graphics work. Must have been an interesting conversation you had with the artists
I actually implemented pixel-collision into my game engine because of the first version of this video. That was a mistake for a lot of reasons. Anyways, I love to see this stuff explained! I feel like this video had a lot added since the first version; may just be my awful memory, don't know. In any case, keep it up; I always look forward to these videos!
Small world. You helped make a lot of my fav games. Wow, my mind is moved, you helped with crash bandicoot, sonic and lego star wars, thats boss. Subscribed.
I loved that game and became an instant fan of Traveller's Tales ... I remember showing it and playing it with my high school friends back then ^^ to this day I still had the music in my head :)
My uncle had an Amiga and I, unfortunately, never really got too much into it as a child. As an adult, the Amiga is my favorite platform for playing retro games.
Just recently finally completed Shatterhand on NES. Brilliant game that played super well, but with one small caveat. Your robot helper's weapon could in some occasions seemingly pass through a boss without hitting. A good example of how often times in games the hitboxes were generous in good and bad, but in rare occasions just the slightest bit annoingly off and you found just the way to get punished.
Wow, this is a great example of knowing the technology you are working with and using it to it's maximum potential. As my comp sci teacher would say: "RTFM!"
*groan* While the sentiment is an accurate and fair one, I absolutely hate when people use this as a catch-all for basically every issue they come across. Especially if you have a nuanced question with many variables and only a few of which you want to tweak, or a unique set of constraints in which to consider a certain problem.. ..and then this kind of person usually doesn't listen to the context, cuts you off halfway and goes "yup! RTFM" and they usually back it up with this smug face of like "I know the answers you want but im not going to give it to you because I have a superiority complex" - ok that last part was an exaggeration but the rest i swear is true. The IT industry is full of people like that and they make me wanna strap them into some kind of saw contraption... and when they scream to be let out ill get right up in their sweaty little face and be like _"RTFM! Why don't you just RTFM??"_ And then I'd laugh as I watched them die in a furious cloud of rust-tainted blood and tattered sinew. .... Oh dear ive gone a bit mad again, haven't I? Sorry about that- Im sure your teacher is probably a great person. 🤐
@@swine13 haha no he wasn't. It's okay, it looks like I hit a trigger point for you! I do think that, especially lately, devs don't take the time to read thoroughly into the tech they are using. I am guilty of that being a new grad. But seeing videos like this helps me see that taking the time to read documentation can take my work to another level.
I doubt many people understood how collision works in video games in 1991. I don't think many people really cared that Super Mario World used collision boxes.
@@bWWd0 Pixel-perfect collision would prevent these cases where people think the game is unfair due to things not visually touching and yet registering damage anyway.
@@Nikku4211 even with pixel perfect, people still think it's unfair. A good way to ensure the player thinks it's fair is to actually cheat on their behalf and use slightly smaller collision rectangles, that way, when they do lose, it's super obvious and it can't be argued with. (There've been studies on this, believe it or not.)
PLEASE PLEASE PLEASE do one about 3d character movement, it seems like everyone is just adding force to physics systems these days and there's no good videos on how to do quality character movement.
Adding forces to physics systems is actually the best way to do things. If you want better movement than that, you could (in unity) calculate the exact player speed and use a coroutine to smoothly use rigidbody.moveposition. Just my idea. (I am not an expert, I once wrote a raycaster that barely worked and that was all I did that was not in an engine).
I remember this game being previewed on TV as a kid. Bought it, loved it. LTUS was the code for the last level if I remember rightly? Still waiting on Tigrander/Tigranda
I still remember the poem from a magazine at the time. Christmas comes but once a year And each one’s even grander But this one is the best of all Cause you can buy Leander
Did this also mean that collision detection in your game had one frame of latency since you had to wait for the graphics chip to have completed rendering to be able to check the flag?
I remember playing this game on Amiga 500 till this day. It is in my opinion one of the best platform games for A500. Have you also worked on Shadow of the Beast 1-3? Could you please share some more stories about game development on Amiga?
Did you code Atari ST version of Leander as well! If this amount of code trickery through special Amiga chips was required to run Leander, than ST's Leander, which runs preety good for ST terms, is a work of miracle. Anyway, Leander was one of my favourite games on Amiga, and although I play lot of Amiga games on emulation, I don't play Leander because it is to hard without joystick with "push down auto-fire" that I played on back in the day. See, when auto-fire is on, Leander can move and jump but since his sword is hiting constantly, no anoying off screen enemies can hit me cheaply! Since it was push-fire button and hold to auto-fire, as soon as you release it, auto fire stops. Without it, playing Leander on standard joypad these days, for me, is unplayable!
So basically this collision overlapping is probably just sprites rendering in a playfield, when a pixel is drawn on a location where already a pixel is located the flag goes to 1. Combining this with hitbox collision is brilliant. Then its only a question if the player is looking into the right direction... otherwise it could hit boxes with his back :P
This was very very cool, I LOVE Leander! Played it to death back in the day! Also have the Galahad port for the Genesis. Why exactly was the name changed for that?
Pixel perfect collision are very resource heavy, normally I just make square boxes smaller than the sprites, simple approach, but I found another way, instead of checking every object against other object, check every object against a 2d array, makes things way lighter.
coarse to fine! First you do boxes then pixels! Also seems like the Amiga did not improve over the 8-bit family here. I guess on 68k people expect slopes and loopings like with Sonic.
interesting about the collisions knew more or less the idea the techniques for this; but I am curious about a console created by the same ones that made the Amiga PC and it is the techniques that were used in the Atari Lynx that its Sussy processor had a very special function which was the "collisions of particles and Sprites", I suppose thanks to This processor saved a lot in writing programming code; And it is still not clear to me if it was something that made a big difference since none of the consoles of the 16-bit era used anything similar; I also remember that this processor had functions such as the deformation and redrawing of Sprites that I have seen scaled, stretched and even rotated these Sprites. I suppose that this was a great help when the memory of the Rom cartridges was very expensive and also in the use of Ramen the console ... it would be interesting if you did a report on the uses of that console since many say it was the based on what we say today are graphic accelerators.
Wow psygnosis they were based at the pier head if I remember right?(Liverpool) I used to work in bits and bytes in Liverpool and a few of them used in come now and again.
That's a very clever usage of a platform feature. What made the Amiga's pixel-perfect detection so fast? Also, we're you able to detect whether it was the character's swinging weapon or its body that was overlapping with something?
The Genesis / Mega Drive is vastly different to the Amiga: same CPU, but different architecture and dedicated chips. For a collision testing example : huguesjohnson.com/programming/genesis/collision-vdp/
I'm surprised this wasn't more common... For sprite-based games, this seems like it would be a MUST have on any console. Otherwise, you slow down the console using a bunch of separate animated boxes, or you just make them oversized with large invisible hazards. Why not make it so specific sprites set a flag when they overlap? Why did it have to be an obscure mode on the coprocessor?
Respect. I really liked "Leander" on the Amiga :) I'm guessing this Amiga-specific trick couldn't be employed in the ST or Megadrive ports, and a more conventional hitbox approach had to be used by the devs tasked with porting the game to other hardware? Can you shed any light on the thinking behind the Megadrive version being renamed "Legend of Galahad" when (imho) "Leander" was a much more evocative and memorable name? It reminds me of the way "The Chaos Engine" was renamed "Soldiers of Fortune" for the US market ... and lost some of its vibe in the renaming. I'm guessing that kind of thing happened because publishers assumed (maybe rightly) that the American market preferred bluntly functional names for their games, shorn of any of that evocative poetic nonsense ;)
How would it handle, say, two enemies colliding with each other? Or an enemy walking over a powerup or something like that? I assume that's handled in the box-check routine?
As I understood it, the enemies were all part of the same layer, and the collision was determined between layers not within. So enemies crossing each other wouldn't flag.
Wouldn't it been a lot easier to ignore copper and if a collision happened with the score, do a box check without giving the score a box? If no collision boxes overlap, ignore the collision
Joujoubox if you’re fighting a large enemy, they might overlap the score (or the mountains in the distance as they were also sprites) as well as being in range of your hit box
I love this one because it's a great example of an impressive feat that didn't require any code wizardry like using hardware to do things it was never meant to do or exploiting a quirk of the machine code. This was accomplished through understanding the hardware you were working with and not being lazy. Pure and simple.
"Hardware never meant to do" isnt quite right.... The pixel collision register was put there to do exactly that.
This, my friends, is why you read the manual...
As good as the Amiga hardware manual was, it wasn't perfect. For instance, there is no indication that reading the collision flag would reset the flag. That's just the sort of thing you had to find out through trial and error. The hardware was full of interesting intricacies like this, and it's why the demo scene was so consistently prolific.
Feels good when a person with actual experience of programming a console is explaining what it can do.
the amiga isn't a console
@@giampaolomannucci8281yeah, but, this coder, judging by his chanel, worked on lot console games also!
i'd love to hear a deep-dive into leander, it's history and some development stories
I´d love a remake/port for the new consoles.
It was a cool game and the graphics still hold today.
I want a SNES port of Leander.
I believe it sounds something like this:
**splooshhhhhh**
**glub glub**
You can't emulate it?
I never get tired of watching this
*Some games, like King of Fighter's on the NEO*GEO would use one collision box per frame per character, then, if there was a collision in those 2 larger boxes between the characters, it would then start to check smaller sub boxes for greater accuracy.*
I believe that most of the Unreal Tournament games did something like this too; because when you view the collision in game there is an extra box around players. I could be wrong though, but it makes sense.
That's most fighting games actually.
@@CUTIE_POXX Actually, it's not, Street Fighter 2 does not do that. It maintains multiple collision boxes on each frame instead of just one like the King of Fighters. Can you name some examples to support what you said?
That's usually the difference between broad and narrow phase collision and is used in modern day collision systems too. Simple collision is used to query whether a proper collision check is necessary, then more precise collision is done between the two overlapping objects.
It's amazing how much a dev o dev team need to find ways to push the envelope on x or y areas, great video as always
On the 486 we did it all in software. It's a much more powerful PC than the Amiga, but still very ancient, and pretty much a potato by today's standards. Basically we would do a "broadphase" box check, and if the boxes were colliding, we'd find the overlap and do a per-pixel check -- which was actually pretty fast if you do it cleverly.
What we did was precompute a 1bpp collision mask of each sprite as we loaded them in (and for rotating sprites, we'd precompute 256 versions of it). It was a pretty small increase to loading times, and RAM usage. Then you could just find the offset between any two sprites and perform a a Bitshift and a Bitwise-And to compare the two of them; letting you compare up to 32 pixels at once. It was blazing fast. 😉
That's amazing! What games did this?
What speed was the processor you were using? The 68000 was 7.68 MHz for comparison...
reading this while setting up my 486 is getting me hyped up
I've got to try this on my 3.58 MHz 65c816...
@@CodingSecrets Wikipedia says “16 MHz to 100 MHz” for the i486
I have been an avid gamer since my first NES back in the early 90s. Even today I still love playing games and even my son is a huge gamer who is just starting to get into coding himself. I would LOVE to pick the brain of someone like yourself that has been in the industry for as long as you have. Everyone of your videos are just gold to me, to learn how all these things were done. Keep the videos coming.
So, basically it was HW accelerated collision detection built-in in the Amiga.
Amiga's hardware and software design were ingenious. All the respect to the engineering team. It's so depressing that the management screwed up and went bankrupt.
No, and you're stupid for thinking this
It was exactly that. He literally describes it as such in the video.
@@sirkastic You're the only smart one in this comment thread. It's sad we live in a world where there are more stupid people than smart people and the stupid demonize smart people for speaking truth just because it's negative truth. Worse yet they use smart people's inventions, like computers and internet, to make themselves seem right because there's more of them and they'll supporting each other with likes and shoot down the smart person with dislikes and rude unjustified comments. They like to think it's 'majority rules' with anything in life, even being right or wrong, but it's not, right is right wrong is wrong no matter what the ratio of right to wrong people is, simple as that.
No, otherwise this wouldn't count as a coding secret, which is what this video and this entire channel is all about. That's like saying making unique and efficient code for the CPU counts as "hardware acceleration". This is unique hardware utilization coding, not simply hardware acceleration. Otherwise every single Amiga game would have pixel perfect collision detection, and that's definitely not the case.
I think it slips our minds at times just how much goes into a game. Especially back in gaming infancy.
Great video. Thank you
These kind of videos are my favorite kind of videos to watch.
I'M LEARNING SO MUCH. So happy I found this channel, it's blowing my mind.
I love this. Constraints lead to creative solutions. Game development is one long history of cheating to make something appear a certain way, without actually having to simulate it realistically. It’s all sleight of hand magic tricks. Thanks.
This is why I love watching videos like this. I love ingenuity and problem solving that went into the days of limited hardware. And as stated even the graphics designer was able to make awesome backgrounds with the limited colour palate.
This channel cold start a trend of devs sharing their secrets about their old jobs. This is really interesting and exciting.
What are those channels called?
I remember seeing this game being studied in another video about pixel perfect detection collision. It's nice to see the original creator adressing it
Oh Leander! I remember playing it on A1200 and that it was the first game I tested with audio connected to a stereo :-). Such a beautiful game.
I was getting to the point where I didn't even know if this game actually existed.
I used to play the Mega Drive port Galahad and fricking loved it, I am so glad I have started watching your videos. Totally oblivious that you actually created one of my favourite (albeit a port) Mega Drive games.
Amazingly satisfying series for a developer who’s always been more interested in how games work than in actually playing them. And as you’ve shown here, a lot comes from using every trick the hardware supports! Fantastic.
I love this kind of problem solving. Nice work.
Incredible! It's a joy to look under the hood of these games that loom so large in our memories.
I've just came along this channel and found this video after watching the SEGA Sonic videos you have made, not knowing that YOU coded one of my favorite games from psygnosis back then and probably my first purchases ! Thank you so much for this channel, absolutely love it. The music was escellent with the harp ish lead sound in he first level if i remember correctly. There were ,at least for me, not much resources available on how to program the amiga hardware or 68000 assembly in general so i went the AMOS route. Anyways, i'm glad i've found this channel and i hope to see more of this. Perhaps a tutorial on how to make a pong clone in assembly for the amiga and then go on to a more graphics driven simple platform game, or perhaps a line by line explenation if possible. Anyways, thank you for this, kudos, big ups !
That's awesome. What a clever way to do it, very ingenious.
Awesome content! Also, thanx for Leander! As an original owner (and yes, I mean I bought it back in the day), this was one of my favorite games. Not that I was above a bit of piracy from time to time (sorry..), but not for games I really wanted to play. And Leander was one of my favorites! I'll eventually re-buy it as I have been rebuying most of the games I used to own, but it is going for crazy prices still. Which is justified. Great game!!! And this video makes me appreciate it all the more...
Genius. I love the way the inherent restrictions of the consoles forced developers to think so creatively and become extremely intimate with the hardware. This was great and so satisfying to see the solution.
clever use of the hardware, and even if there was limitations, I like that you acknowledged that the limitations on the colour scheme was overcome by excellent graphics work. Must have been an interesting conversation you had with the artists
I never knew about this feature! And very clever application. How I miss those old days with the good ole copper!
I would love to see some Amiga specific coding examples from you. Great video.
I'd so love you to do a series on programming for the Amiga :D
Just when I think I couldn't possibly like you more than I already do, I learn you made leander.
i fucking love this channel, keep it up my man
I actually implemented pixel-collision into my game engine because of the first version of this video.
That was a mistake for a lot of reasons.
Anyways, I love to see this stuff explained! I feel like this video had a lot added since the first version; may just be my awful memory, don't know. In any case, keep it up; I always look forward to these videos!
@@StarlightLumi My game engine was for the PC. That's reason 1 why it was a mistake.
Small world. You helped make a lot of my fav games. Wow, my mind is moved, you helped with crash bandicoot, sonic and lego star wars, thats boss. Subscribed.
I loved that game and became an instant fan of Traveller's Tales ... I remember showing it and playing it with my high school friends back then ^^ to this day I still had the music in my head :)
My uncle had an Amiga and I, unfortunately, never really got too much into it as a child. As an adult, the Amiga is my favorite platform for playing retro games.
Brilliant!
And now I know why this game felt so good to play back then.
amazing.
Wow, this is amazing
Just recently finally completed Shatterhand on NES. Brilliant game that played super well, but with one small caveat. Your robot helper's weapon could in some occasions seemingly pass through a boss without hitting. A good example of how often times in games the hitboxes were generous in good and bad, but in rare occasions just the slightest bit annoingly off and you found just the way to get punished.
Love your content. Thank you 🙏
Wow, this is a great example of knowing the technology you are working with and using it to it's maximum potential. As my comp sci teacher would say: "RTFM!"
*groan*
While the sentiment is an accurate and fair one, I absolutely hate when people use this as a catch-all for basically every issue they come across. Especially if you have a nuanced question with many variables and only a few of which you want to tweak, or a unique set of constraints in which to consider a certain problem..
..and then this kind of person usually doesn't listen to the context, cuts you off halfway and goes "yup! RTFM" and they usually back it up with this smug face of like "I know the answers you want but im not going to give it to you because I have a superiority complex" - ok that last part was an exaggeration but the rest i swear is true.
The IT industry is full of people like that and they make me wanna strap them into some kind of saw contraption... and when they scream to be let out ill get right up in their sweaty little face and be like _"RTFM! Why don't you just RTFM??"_ And then I'd laugh as I watched them die in a furious cloud of rust-tainted blood and tattered sinew.
....
Oh dear ive gone a bit mad again, haven't I? Sorry about that- Im sure your teacher is probably a great person.
🤐
@@swine13 haha no he wasn't. It's okay, it looks like I hit a trigger point for you! I do think that, especially lately, devs don't take the time to read thoroughly into the tech they are using. I am guilty of that being a new grad. But seeing videos like this helps me see that taking the time to read documentation can take my work to another level.
Absolutely loved this game! Cool topic too!
i never would have guessed there were so few colors on the screen if it wasnt pointed out
Beautiful memories
This is really cool.
Porting games between consoles was a huge deal back then because the hardware was so different. It wasn’t all standardized x64 or 86 architecture
Awesome I played game this as a kid on my friends amiga. Thank you for the memories
Clever.
Still have fond memories of the Amiga and its games
Man I loved Leander!
I always loved what a cool hack this video described.
so was pixel perfect collision part of the promotion for this game ? i imagine you would make sure people knew you had such a cool feature.
I doubt many people understood how collision works in video games in 1991. I don't think many people really cared that Super Mario World used collision boxes.
We just played the games and if it was good we rented them more than once back then.
@@2beJT Or in the Amiga's case you just bought them, and if they were good, you copied them and gave the copies to your friends.
@@bWWd0 Pixel-perfect collision would prevent these cases where people think the game is unfair due to things not visually touching and yet registering damage anyway.
@@Nikku4211 even with pixel perfect, people still think it's unfair. A good way to ensure the player thinks it's fair is to actually cheat on their behalf and use slightly smaller collision rectangles, that way, when they do lose, it's super obvious and it can't be argued with. (There've been studies on this, believe it or not.)
Holy shit. I wanna see the whole Leander process start to finish.
This man is a literal genius
These BG-sprite collision flags remind me of the Sprite 0 hit flag on the NES/Famicom/SUBOR/Dendy.
PLEASE PLEASE PLEASE do one about 3d character movement, it seems like everyone is just adding force to physics systems these days and there's no good videos on how to do quality character movement.
Adding forces to physics systems is actually the best way to do things. If you want better movement than that, you could (in unity) calculate the exact player speed and use a coroutine to smoothly use rigidbody.moveposition. Just my idea. (I am not an expert, I once wrote a raycaster that barely worked and that was all I did that was not in an engine).
I remember this game being previewed on TV as a kid. Bought it, loved it. LTUS was the code for the last level if I remember rightly? Still waiting on Tigrander/Tigranda
Fantastic video. Makes me realize how spoiled I am. The engine I use (Unity) does all of the things you talk about for me
Just program in assembly lmao
I still remember the poem from a magazine at the time.
Christmas comes but once a year
And each one’s even grander
But this one is the best of all
Cause you can buy Leander
I really enjoyed playing this game at the time it was released on amiga.
Very interesting. Thank you.
Could you do a video on how you coded the scrolling routine in this game?
woah. Just woah.
Can we talk about how badass the cover art for leander is though? Who drew that?
Tim White www.mobygames.com/game/amiga/leander/credits
Love it!
Title: Is super-fast Pixel Perfect Collision Possible?
Scratch(coding engine): Am I a joke to you?
Yes, it is a joke to me
scratch isn't fast lol
Did this also mean that collision detection in your game had one frame of latency since you had to wait for the graphics chip to have completed rendering to be able to check the flag?
wait you worked on Leander? I loved the Genesis port, Galahad, still take it out for a spin once in a blue moon to this day :D
I remember playing this game on Amiga 500 till this day. It is in my opinion one of the best platform games for A500. Have you also worked on Shadow of the Beast 1-3? Could you please share some more stories about game development on Amiga?
Did you code Atari ST version of Leander as well! If this amount of code trickery through special Amiga chips was required to run Leander, than ST's Leander, which runs preety good for ST terms, is a work of miracle. Anyway, Leander was one of my favourite games on Amiga, and although I play lot of Amiga games on emulation, I don't play Leander because it is to hard without joystick with "push down auto-fire" that I played on back in the day. See, when auto-fire is on, Leander can move and jump but since his sword is hiting constantly, no anoying off screen enemies can hit me cheaply! Since it was push-fire button and hold to auto-fire, as soon as you release it, auto fire stops. Without it, playing Leander on standard joypad these days, for me, is unplayable!
Looks like a promising game for its time, likes the graphics
the double olayfueld technique is elegant
Today: Psst, hey kid, wanna download some Physx?
Amiga: Oh yeah, it's just built into the hardware. Pixel perfect.
PhysX: Hardware-based collision detection.
Imagine SDL being taken for granted rn
So basically this collision overlapping is probably just sprites rendering in a playfield, when a pixel is drawn on a location where already a pixel is located the flag goes to 1. Combining this with hitbox collision is brilliant. Then its only a question if the player is looking into the right direction... otherwise it could hit boxes with his back :P
This was very very cool, I LOVE Leander! Played it to death back in the day! Also have the Galahad port for the Genesis. Why exactly was the name changed for that?
Pixel perfect collision are very resource heavy, normally I just make square boxes smaller than the sprites, simple approach, but I found another way, instead of checking every object against other object, check every object against a 2d array, makes things way lighter.
I'm a simple man. I see Leander, I watch.
i had this game on my sega genesis, but it was called "galahad"
So basically CLXCON was an AND function that ran alongside the sprite drawer? Pretty handy!
Why did I find this channel just now?
coarse to fine! First you do boxes then pixels! Also seems like the Amiga did not improve over the 8-bit family here. I guess on 68k people expect slopes and loopings like with Sonic.
this was one of my favorite games when i was little. like REALLY little
interesting about the collisions knew more or less the idea the techniques for this; but I am curious about a console created by the same ones that made the Amiga PC and it is the techniques that were used in the Atari Lynx that its Sussy processor had a very special function which was the "collisions of particles and Sprites", I suppose thanks to This processor saved a lot in writing programming code; And it is still not clear to me if it was something that made a big difference since none of the consoles of the 16-bit era used anything similar; I also remember that this processor had functions such as the deformation and redrawing of Sprites that I have seen scaled, stretched and even rotated these Sprites. I suppose that this was a great help when the memory of the Rom cartridges was very expensive and also in the use of Ramen the console ... it would be interesting if you did a report on the uses of that console since many say it was the based on what we say today are graphic accelerators.
Wow psygnosis they were based at the pier head if I remember right?(Liverpool) I used to work in bits and bytes in Liverpool and a few of them used in come now and again.
Please give us some more stuff on Leander!
Oh man this game. So many hours.
That sounds like the occlusion queries or the stencil buffers of the current gen graphics hardware
So basically when we play it's the character but a bunch of boxes crashing into eachother.
Great episode! So was collision detection managed the same way in Legend of Galahad on Megadrive?
pepitaux13 Great question! I didn’t code the port so I have no idea (or can’t remember)
This guy RTFM! :)
That's a very clever usage of a platform feature. What made the Amiga's pixel-perfect detection so fast?
Also, we're you able to detect whether it was the character's swinging weapon or its body that was overlapping with something?
That's interesting. I didn't know any game system other than Atari VCS had hardware collision detection.
Ohhh ... I see Galahad on Sega Genesis is Leander on Amiga. So its the same kind sorcery there? hehe. Amazing video as ever.
The Genesis / Mega Drive is vastly different to the Amiga: same CPU, but different architecture and dedicated chips.
For a collision testing example :
huguesjohnson.com/programming/genesis/collision-vdp/
I'm surprised this wasn't more common... For sprite-based games, this seems like it would be a MUST have on any console. Otherwise, you slow down the console using a bunch of separate animated boxes, or you just make them oversized with large invisible hazards. Why not make it so specific sprites set a flag when they overlap? Why did it have to be an obscure mode on the coprocessor?
Please post more Genesis and Amiga vids! :-)
Respect. I really liked "Leander" on the Amiga :) I'm guessing this Amiga-specific trick couldn't be employed in the ST or Megadrive ports, and a more conventional hitbox approach had to be used by the devs tasked with porting the game to other hardware?
Can you shed any light on the thinking behind the Megadrive version being renamed "Legend of Galahad" when (imho) "Leander" was a much more evocative and memorable name? It reminds me of the way "The Chaos Engine" was renamed "Soldiers of Fortune" for the US market ... and lost some of its vibe in the renaming.
I'm guessing that kind of thing happened because publishers assumed (maybe rightly) that the American market preferred bluntly functional names for their games, shorn of any of that evocative poetic nonsense ;)
How would it handle, say, two enemies colliding with each other? Or an enemy walking over a powerup or something like that? I assume that's handled in the box-check routine?
As I understood it, the enemies were all part of the same layer, and the collision was determined between layers not within. So enemies crossing each other wouldn't flag.
Wouldn't it been a lot easier to ignore copper and if a collision happened with the score, do a box check without giving the score a box? If no collision boxes overlap, ignore the collision
Joujoubox if you’re fighting a large enemy, they might overlap the score (or the mountains in the distance as they were also sprites) as well as being in range of your hit box