Iterate through Types

Blitz3D Forums/Blitz3D Beginners Area/Iterate through Types

Mikel(Posted 2008) [#1]
I have been looking for some code that is already written but have not had any luck with my searches.

Basically, I want to iterate through a collection of Types against itself.

For example, I have a Type that is a cube. Let's call it target. I create 50 of them.

I want to select the first cube in the list and then compare it against the rest of the list (the other 49).

If we call the first one cube1 then I want to compare cube1 against cube2, cube3, cube4, etc... to the end of the list.

And then I want to get cube2 and compare it against the rest of the list...cube1, then cube3, cube4, etc...

I hope it is clear what I am trying to do. Has anyone got any code to do this? I hate to reinvent the wheel.

Thanks!

By the way - I am doing this as an alternative to using regular Blitz collision code. I may have to resort to using Linepicks though.


stayne(Posted 2008) [#2]
In this example, c\id is your handle. I will get slammed for this :).

Type cube
  Field mesh
  Field id
End Type

For i = 1 To 50
  c.cube = New cube
  c\mesh = CreateCube()
  c\id = i
Next



Stevie G(Posted 2008) [#3]
Eh.. not sure what stayne is on about ..

If you're doing collisions then you do not need to check each cubeT with every other as you're going to duplicate your checks i.e. cube1 v cube2 and cube2 v cube1 :

for c1.cubeT = each cubeT
  for c2.cubeT = each cubeT
       if c1<> c2
         ;compare c1 <> c2
       endif
  next
next


Here is a better method which means you only check each pair once:

For c1.cubeT = Each cubeT
	c2.cubeT = c1
	While c2 <> Last cubeT
		c2 = After c2

		;compare c1 and c2 etc..
		
	Wend
			
Next


It's effectively the same as :

for i = 0 to 48
  for j = i+1 to 49
      ;check cube i against cube j
  next
next



Mikel(Posted 2008) [#4]
Thanks Stevie G

Your better method is what I was looking for. I may still end up having to do linepicks because if a couple of cubes are running parallel right next to each other then it may look as if they had collided.

I am searching for a way to do collision checking without using Blitz collisions because I am running into some sort of float error and my pitch and roll gets changed slightly over time even when I am forcing both to zero.


Stevie G(Posted 2008) [#5]

I am searching for a way to do collision checking without using Blitz collisions because I am running into some sort of float error and my pitch and roll gets changed slightly over time even when I am forcing both to zero.



Do you have an example showing this issue? I would avoid linepicks for cube/cube collisions like the plague - too many will be slooooow.


Mikel(Posted 2008) [#6]
It happens randomly and I cannot determine when or what makes it happen.

I have an arena that is 512 x 512. Scaled cubes as walls on each side.
50 cubes (targets) randomly distributed, yaw set randomly and speed set randomly, Y is fixed at 2.0.

Cubes currently do linepicks as well as collisions and will randomly change direction (yaw = rnd( -180.0, 180.0)) when near walls, other cubes or player.

The float problem occurs when there are a lot of bullets flying around (which use normal Blitz collisions).

I am also using Particle Candy for bullet hit effects and explosions.

I just looked at my code and the random angle I set for yaw uses a local variable called angle which is not declared as a float. Maybe that is the problem.


Warner(Posted 2008) [#7]
Maybe the collisions are causing the anomalies ? For instance a sliding collision that is barely noticable, but does affect the rotation of the source entity somehow. On the other hand, collisions should only affect X/Y/Z. Still, after resetting the Pitch/Yaw to zero, try using ResetEntity.


IPete2(Posted 2008) [#8]
Mikel,

From what others have said, Newton offers lighting fast linepicks although that may mess up your current set up.

The other thing I would suggest is you look at Object and Handle in the docs or on the code archives instead of re-iterating through all the instances in a type.

Once set up correctly every collision would immediately know which instance has hit which other instance using these under used commands.

IPete2.


Mikel(Posted 2008) [#9]
Maybe the collisions are causing the anomalies ? For instance a sliding collision that is barely noticable, but does affect the rotation of the source entity somehow. On the other hand, collisions should only affect X/Y/Z. Still, after resetting the Pitch/Yaw to zero, try using ResetEntity.


I thought the same thing which is why I started looking for alternatives. I did add the ResetEntity() command after every PositionEntity too.

IPete2 - thanks, I will definitely look into that.

I just wonder if I fixed the problem though because I made the changes to the RotateEntity command.

I was doing: angle = rnd( -180, 180 )

and then calling RotateEntity like this:

RotateEntity Entity, EntityPitch( Entity ), EntityYaw( Entity ) + angle, EntityRoll( Entity ), False

I changed it to: angle# = rnd( -180.0, 180.0 )

and changed the rotate command to:

RotateEntity Entity, 0.0, EntityYaw( Entity ) + angle#, 0.0, True

After making those changes I have not been able to duplicate the problem.