Code optimization.

[gazj82]

There is some great great stuff here that will help loads, especially eliminating the slow zones. Really busyy at work at the moment. As soon as I get some free time I will get back to you all properlyl.

[Master484]

Hmm, I tested the Zone() again, and looks like I have made a small mistake.

When I made the test, I tested with Zone(x,y) , but didnt notice that before the test part I had the line "x=test()\x" hanging out there, and test()\x hadn't been given any value yet. I believe that this caused some strange value to end up in x, which caused the Zone command to go crazy.

But when I removed that, then the Zone speed returned to "normal".

In comparison to RectsHit, it performed the following way in 100 checks:

Zone() = frame 1, VPos at 141
RectsHit() = frame 1, VPos at 94

So RectsHit is actually slightly faster, although it requires additional code in comparision to Zone.

However, it is possible that Zone() bugs like the one I described are happening in the game, and this causes slowdown in this relatively simple pacman game.

[Master484]

Ok, I tested the Zone() command some more, and there indeed seems to be a bug in the command.

Although I don't know how this command works since it's not mentioned in the manual, but from the looks of it you just make a hitbox with SetZone (zoneID,startX,startY,Width,Height), and then check if some XY coordinate is inside this hitbox with "If Zone(X,Y) = zoneID" .

But I found out this: if you set either of the values of Zone(X,Y) to either lower than than the zone start XY, or higher than the zone Width or Height, you get the massive slowdown that I mentioned. But all other values are OK, and with those values the speed is "normal".

Here is the code that I used:

SetZone 0,20,20,50,50

lol=5
a=0

Repeat

 If Zone(23,35) = 0 Then lol=5

 ; put values to (51,51) or higher to get massive slowdown
 ; also values (19,19) or lower cause massive slowdown

 ; only values between 20-50 behave normally

 a+1
Until a=100

This bug happens in the classic Blitz 2.1, dont know if AmiBlitz has fixed this command.

[E-Penguin]

Fascinating to read the thread so far.

I was planning on doing collision detection by first comparing the radii of the shapes to the distance between them (if distance is less than radii then probably a hit). That's an addition for the radii, but the distance requires finding the hypotenuse - two multiplications, an addition then a square root. I'm beginning to think RectsHit would be faster? Currently nowhere near an Amiga so can't test.

[Master484]

I tested RectsHit vs this method posted by Daedalus:

If x >= zonex1
  If x <= zonex2
    If y >= zoney1
      If y <= zoney2
        collision = True
      End If
    End If
  End If
End If

And 1000 repeats gave the following results:

RectsHit Method : 1 frame, Vpos at 221.
If Structure Method : 1 frame, Vpos at 172. (when all Ifs were true)

So checking collisions with If's is faster, and I often use a similar method in my own games.

And in practice it's even faster than the number presented here, because the y-axis check rarely happens. The two x-axis checks eliminate most cases right away, and so the y-checks happen only for those cases that are "inside the X zone".

Also the "If method" is more flexible, and can be customized for different collision check types. For example in a space invaders game all "bullets vs aliens" can be "skipped" on the first "If then" if the bullet Y pos hasn't yet reached the area where the aliens fly, or the position of the lowest alien. This sort of customizing can greatly increase the speed of collision checks.

While in comparison with RectsHit we are always doing a general purpose "rectangle vs rectangle" collision check, which always checks and compares both X and Y axis.

I was planning on doing collision detection by first comparing the radii of the shapes to the distance between them (if distance is less than radii then probably a hit). That's an addition for the radii, but the distance requires finding the hypotenuse - two multiplications, an addition then a square root. I'm beginning to think RectsHit would be faster? Currently nowhere near an Amiga so can't test.

I tested the speed of two multiplys and 1000 repeats took 1 frame with Vpos at 152. But the square root operation was much slower, at least when done with the Blitz SQR command; 1000 Sqr operations took 5 frames. But without the square root the speed of this would probably be around the same as the two other methods.

[E-Penguin]

It's about 154k for a 320*240 word lookup table... Perhaps worth it if collisions are taking up a lot of processing - you could skip the multiplications too and store the result of the hypotenuse calculation, as a 2d array distance(x_dist)(y_dist).

Assuming you'd sorted the shapes by x and y order you can do something like :

Radii.w = shape1/radius + shape2/radius 
Distance.w = distance_lut(shape1/x - shape2/x)(shape1/y - shape2/y)

If Distance < Radius
    Collision = True 
End If

Syntax errors notwithstanding.

[gazj82]

Well, I did a total rewrite based on some of your above replies.

The game is now in the zone as kcmunchkin.adf

The code is saved on the disk image if you would like to see it.

Thanks for all your help guys.