Sprite Candy layers

Blitz3D Forums/Blitz3D Beginners Area/Sprite Candy layers

mkg(Posted 2007) [#1]
Can someone give me some ideas on this please?

I am using HUD_CollisionShapeHitsPoint to check for hits and it works fine.

What I need to be able to do is have no hit if there is an object in a 'higher' layer that hides the target (think enemy is behind cover).


semar(Posted 2007) [#2]
layerID% =   HUD_GetObjectLayer  (  Object_Handle%  )

This command returns the Sprite Candy handle of the object's parent layer.

Object_Handle%
Handle of a Sprite Candy object (text, image, shape etc.) 

With that command, you can get the layer which the object belongs to, and with the following one:
zOrder% =  HUD_GetLayerOrder ( Layer_Handle%  )

Returns the current depth order value (display order) of a layer.


You may compare the layer order between different objects.

Hope it helps,
Sergio.

P.S.
I suggest you to have a look at the SpriteCandy help file ;-)


mkg(Posted 2007) [#3]
Thanks a lot - yes that was just the sort of pointer I needed. I'm making progress again now.

My idea now is to have two types - mobs and props. Mobs can be shot and props block shots.

When player fires the program iterates through the collection of mobs and checks if their collision shape hits shotXY. If yes then iterate through each higher layer until a prop collision shape hits shot XY. If no prop collsion shapes match then player scores a kill.

Does that sound like a reasonable approach or am I missing something?


semar(Posted 2007) [#4]
Does that sound like a reasonable approach or am I missing something?

Seems reasonable to me. You may take care, however, that you don't make unuseful checks or loops, which will slow down the program.

Let's make an example using the game Asteroids. The number of shots are always less than the number of asteroids, that's why a loop like:
for each shot
check collision with all asteroids
next


would be far better than this:
for each asteroids
check collision with all shots
next 


Of course the number of iterations remains the same, but the first loop has the avantage that when there are no shots, the loop will not be executed.

The same concept may be applied to your mobs, props and shots. Start the loop first with the collection that contains less objects. If there are less mobs than props, then loop through the mobs. If there are less shots than mobs, then start to loop through the shots. And so on.

Further more, if you run out of pfs - that is, if you notice a slow down caused by the nested loops, you can exit from the loop at each collision, like:
collided = false
for each shot
for each props
if shot collides with props
'do something
collided = true
Return 'this exits the current function
endif
next
next


Hope this has sense for you,
Sergio.