Sprite Collision Class (SpriteHit) query

[stevmjon]

to kev

   i know about spitehit() command, and  i use it to check if say sprite no.1 has hit any class 4 sprites etc. it works fine.  the query i have is i want to check if any other sprite has hit a particular class sprite, without checking every sprite created. for eg.  i have 1000 sprites in my world, and i drop 20 mines. the mines have their own collision class. how do i read from a class list first (mines), and then check if it has collided with any other sprites.
   at the moment i need to read every sprite created one by one to find the ones i want first (the mines), then use spritehit() command to check if this mine has collided with any other sprites. this reads every sprite unecessarily. maybe i am doing it wrong.
   this is my code:

gfs=getfirstsprite()
while gfs>0
gcc=getcollisionclass(gfs)
if gcc=%1000
ss=spritehit(gfs,getfirstsprite(),%100)
while ss>0
do action here
endwhile
endif
nextgfs=getnextsprite(gfs)
gfs=nextgfs
endwhile

hope my code written here is correct. i shortened what i actually have.
if i had 1000 sprites in my world, this would take time to check all of them, to see which ones are the mines, then check if it has been collided with. any help would be great.

also, does playbasic check all sprites, or only what is visible on screen?

thanks stevmjon

[kevin]

Surely you'd have your own 'Object' layer sitting above the sprite system for such a recursive situation.  

Meaning you'd keep list(s) of the your created created (ie. the mines), then loop through them checking for impacts.

also, does playbasic check all sprites, or only what is visible on screen?

Any sprite that exists, is visible and shares the same collision class as the request will be checked.

[stevmjon]

to kev

i thought i could use a command to search a particular class list, instead of making my own list. my own list will need to be added too and taken from during gameplay. guess i was lazy.

in reply to the sprites checking question, i meant if i had a very large world (much larger than the screen) with multiple sprites all over, are all the questioned class sprites checked, or only the ones currently in the visible screen bounds.

 stevmjon

[kevin]

Sprite collisions occur in sprite/world space, the screen/view port/camera size  have no effect.      

   In your previous example, is there any reason why 1000 sprites would ever exist at any one time ?

[stevmjon]

to kev

the no. 1000 was a number i just picked to indicate a large number, that's all.

i only thought that if your world was very big, and you created a large no. of sprites to fill this world in all areas, it would add up. i am making a scrolling platformer game, and i will have things to collect, and moving sprites everywhere, so will have quite a number of sprites around the world. should i create sprites as i scroll around the world,or create them all at once at start of level?

at the moment i am still working on a game engine. it certainly takes time. i haven't even created level one yet.

 stevmjon

[kevin]

Well, conceptually games of this type (and most games in general) have two (or more) object lists.  One is the current active objects (within the players zone) and the other is the object allocation through out the world space.   The activate list is dynamically processed while the allocation list in world space don't need to be moved/updating at all. Their list si merely a database.  Since their conceptually too far away from the viewer.  What this does is limit the number of actual objects that need controlling to a minimum, while giving the player the impression the world space is globally 'alive'.  

As the player moves through each zone in the world, the engine triggers the activate objects within this space.   In other words their added to the activate object list.  The active list controls the activate objects until they either die (if they do they must be deleted from the world list also) or move out of scope (too far away from the player).  

For activate objects, I generally have two zones.   The first is a region around the player that's twice the size of the view port.  When objects are inside this zone their activate (moving, collision etc ) ,  the second zone is twice as large again and this is 'sleep' zone, so the when the object is in this zone it's sleeping (it's not moving or animating and is invisible to collision).   Then when a object is outside the second zone, it's removed from the activate list a and reinit's it's world instance (it's position/animation/health etc).  

If you think about it, what this type of approach (there is many approaches) does is perpetuate the illusion that world space is actually alive.  When in reality it's not.   Probably should throw an example of this type of trigger point system.