Using DoColl/PColl is incredibly fast if you poke one sprite against 1 single bitplane. This is great if you don't have to test what collided with what (example: every enemy has an outline drawn with color 1, if touches player, player dies. You don't need to know what touched the player, you just need to know an enemy touched it and now he's dead ). Preliminary tests I made indicate this is faster than comparing a Word with a Word 5 times.

Now if you have a space ship that can shoot up to 8 bullets at the same time on screen, and you have 30 enemies on screen, each one will die if hit by one of the bulelts.... what's the fastest way to do that test?

I am really scratching my head trying to figure out a fast way, anything I try seems to be slow as hell. (I am badly used to work with super fast CPUs, coding for a 7mhz one is very challenging ). If anyone can could come up with ideas (if possibly ,please, with examples ), I'll be very grateful.

I've been pondering the same thing. Comparing everything with everything else is O(n²) - exponential computing cost. Probably there's some optimisation to be done by first filtering by general area (if all the bullets are in the left and all the enemies are on the right there can't be a collision).

I wonder whether some sort of binary search would speed it up, at the cost of maintaining the enemy list in a sorted order?

I wonder whether some sort of binary search would speed it up, at the cost of maintaining the enemy list in a sorted order?

If all enemies can be at any X or Y without actually have one side of the screen more used than the other, I have the feeling that the time you will take sorting it will not compensate for what you may gain with a binary search.

I was thinking about trying to use some kind of grid structure... my screen is 320x256. I divide this maybe ine 10x8 32 pixels cells. Bullet check collisions only against enemies on the surrounding cells it is right now. But I just can't wrap my mind on how to make something like this work anyway.

I'm already doing 2 checks there, before I move to the other 4 checks. Ok, this may halve the overload, but still seems to be a lot, isn't it? And it's 2 more checks for each grid check that is "validated"

Well, I can do just one grid check on the Y axis first and only if this one is valid, I go for the X axis check. This may give me up to 50% less overload.

EDIT: Also I can't think of any way of keeping the grid position without doing a division ( px = x / cellsize) , and from what I hear, divisions are slow as hell.

I'm already doing 2 checks there, before I move to the other 4 checks. Ok, this may halve the overload, but still seems to be a lot, isn't it? And it's 2 more checks for each grid check that is "validated"

Well, I can do just one grid check on the Y axis first and only if this one is valid, I go for the X axis check. This may give me up to 50% less overload.

EDIT: Also I can't think of any way of keeping the grid position without doing a division ( px = x / cellsize) , and from what I hear, divisions are slow as hell.

If all enemies can be at any X or Y without actually have one side of the screen more used than the other, I have the feeling that the time you will take sorting it will not compensate for what you may gain with a binary search.

I dunno... You would avoid having to check every bullet against every enemy. Let's assume you maintain a list L sorted on x position containing enemies...

Pseudo code :

Code:

For each bullet b do
Enemy e = BinarySearch(L, bullet.x)
If e != null then
CheckBounds(e, bullet)
End if
Next

Let's assume your BinarySearch function returns a valid enemy pointer from list L if the x is within some distance of the enemy's x. If that is valid then do a bounds check. That way you're not comparing everything with everything else. The code complexity then approaches O(n) which is a vast improvement. You would probably need to also repeat this until no more enemies are found for that X.

It does have sprite against sprite collision which works great and it's pretty fast. It has sprite against playfield collision which is fast enough if you use it smartly, but it only tells you a collision happened, not where it happened, so it's not useful if you need to know what collided with what. All the other collision functions are basically pretty ways to do the classic 4 IFs structure to check if 2 rectangles are touching each other.

Quote:

Most Amiga games probably use blocking anyway for the Map the Enimies everything.

Ok but a grid could work well like you say that way you don't won't have to check them all however I assume most Games know exactly where on screen everything is at all times incase Bullet hits wall etc

I don't know enough about Blitz can you not do If Baddy BOB 1 collide and IF Bullet 6 BOB collide.

There's a sort command on Blitz and I have no idea of how to use it, as any way I try to write it gives me a Syntax Error, and the manual is just extremely vague about (even citing something like "we will work out on this function at a later version")