Slotman, that one purely works on rects .. many player sprites aren't exactly rect .. a typical shooter-shit is somewhat like a triangle.. and many (bigger) bullets are appraching a circle ..
most shooters are rectangles in fact..
Gradius, Aleste, all rectangles.
Ever noticed how certain parts of the plane are 'free' to be touching the walls and bullets? That's because the checking is done with rectangles
The rectangles are usually smaller than the actual object.
If you really want more accuracy, use this rectangles that engulf the entire object, and when you detect collission, test for pixel perfect collission.
You can't test pixel perfect all objects, that would be madness.
What about, if a v9938 is detected, let the game run in screen 4 instead of screen 2 in order to reduce sprite flicker for MSX2 owners? I don't know how difficult that would be, screen 2 and screen 4 are pretty similar and afaik most of the difference lays in the sprites, but... well, it's a thought.
The only difference programwise between screen 2 and 4 is that the MSX2 spritemode uses a colortable for sprite colors, the normal 'color' property has become 'reserved'. (I wish it would be used for rotation or seperate palettes )
Also, the location of the sprite attribute table is less free, because of the existance of the sprite color table.
So it would not be entirely free, but supporting sc4 is pretty much trivial.
most shooters are rectangles in fact..
Gradius, Aleste, all rectangles.
Ever noticed how certain parts of the plane are 'free' to be touching the walls and bullets? That's because the checking is done with rectangles
The rectangles are usually smaller than the actual object.
If you really want more accuracy, use this rectangles that engulf the entire object, and when you detect collission, test for pixel perfect collission.
You can't test pixel perfect all objects, that would be madness.Okay, we all know Blue Warrior was the worst! Darn game...
Ever noticed how certain parts of the plane are 'free' to be touching the walls and bullets? That's because the checking is done with rectangles
The rectangles are usually smaller than the actual object
I solved the collision matter in a game I made (for Windows) checking invisible rectangles smaller than the visible sprites and it worked great. I guess I'll do it again with this one. BTW, thanx a lot for comments. It's great to read different points of view.
What about, if a v9938 is detected, let the game run in screen 4 instead of screen 2 in order to reduce sprite flicker for MSX2 owners? I don't know how difficult that would be, screen 2 and screen 4 are pretty similar and afaik most of the difference lays in the sprites, but... well, it's a thought.
For that thing I must duplicate sprites' graphic buffer and make two diferent routines in order to render correctly the sprites... pant... I guess not, maybe in other productions... but I think the game will look great, even for the MSX2 users.
Slotman, that one purely works on rects .. many player sprites aren't exactly rect .. a typical shooter-shit is somewhat like a triangle.. and many (bigger) bullets are appraching a circle ..
most shooters are rectangles in fact..
Gradius, Aleste, all rectangles.
Ever noticed how certain parts of the plane are 'free' to be touching the walls and bullets? That's because the checking is done with rectangles
The rectangles are usually smaller than the actual object.
If you really want more accuracy, use this rectangles that engulf the entire object, and when you detect collission, test for pixel perfect collission.
You can't test pixel perfect all objects, that would be madness.
I've always used rectangles one pix smaller than the object for collision detection. Work nice and fast and with optimization u can limit those tests to few cpu cycles by object.
And collisions doesn't have to be on every frame ofcourse (no living human can react on 1/50 or 1/20 frame collision)
so you'd make a rotating "pool" of objects to be checked against each other. Every other frame you will shift the pool pointer. You don't need collision to take up half of your cpu time, so devide and concur.
gonna try some things out now.
And collisions doesn't have to be on every frame ofcourse (no living human can react on 1/50 or 1/20 frame collision)
so you'd make a rotating "pool" of objects to be checked against each other. Every other frame you will shift the pool pointer. You don't need collision to take up half of your cpu time, so devide and concur.
Good point!. This post is becoming very useful to me, thnx!
oh yeah! got it working
well.. player and enemy/enemy bullet collision (1-n relation)
now for player bullet / enemy collision (n-n relation)