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.
@@ArpeggioPegasusMusic 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. 😉
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.
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.
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.
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.
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.
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 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.
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...
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 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!
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 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.)
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 !
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.
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 :)
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.
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 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
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.
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
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.
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?
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
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.
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?
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?
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?
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
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.
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?
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 hate to hear of nice features that were in hardware of the olden days and we don’t have today in all the “fantasy machines” today (Pico8, Pyxel, etc.)
Seems like you'd have issues with multiple objects near by with this. If your flag was set on by you pixel pefectly slashing an enemy, another enemy with an overlapping box that's not pixel touching would count as a collision on that frame, right? Not a real issue, and nothing something the player would probably encounter, or notice if they did. But still something in the back of your mind.
Yes, it could be a problem with a high sprite density. But as sprites were limited in numbers on the Amiga (as it was a personal computer and not a dedicated game console), they likely rarely overlapped in the game, so the issue didn't occur or wasn't noticeable to the player. And with most other games using collision boxes, even in worst cases it was still as fair as the ones using multiple collision boxes by characters, and still faster at detecting collisions (as boxes were checked only when the sprite-playfield flag was set, and not on every frame).
