Jump to content

get a Sprite (find) by position


s4m_ur4i
 Share

Recommended Posts

Looping through your sprites and checking their x and y coordinates (and/or including their width and height if you're checking for a sprite at a specific pixel coordinate) is almost always the most efficient way to do this. You already have a reference to every single sprite via game.world and its children - if your potential target sprites are kept in an array then that's even better as you only have to check those.

Link to comment
Share on other sites

The physics (Arcade, P2, etc) systems all have collision functions you can use to do just what you ask, however these all will involve keeping sprites in spatial data structures to optimise spatial tests I suspect. Typically keeping a [another] reference to "every single sprite" is just not that expensive especially compared to what it saves when preforming many collision tests.

EDIT Note: commented before I saw Lewster32's post

Link to comment
Share on other sites

what i think is maybe there is somthin' wrong with your algorithm. not only because there is no such function in the doc ,but also in many other programe languages, on GDI programming there is no such way to do it. maybe you should try another way.

Lewster32's post is just what i thought,too not directly but useful.

Link to comment
Share on other sites

what i think is maybe there is somthin' wrong with your algorithm. not only because there is no such function in the doc ,but also in many other programe languages, on GDI programming there is no such way to do it. maybe you should try another way.

Lewster32's post is just what i thought,too not directly but useful.

The Win32 GDI was not designed for games and is not a programming language nor importantly is it a game engine/framework. I say this because I feel strongly that it is definitely not wrong or remotely unusual to want to do collision/intersection/hittests - it is fundamental to the way games work; and it involves asking the OP's question which is what game objects (eg. sprites) are are some particular point in space (this might be a hitest with the mouse position to allow an object to be draggable or it might be a AABB test to determine if two sprites have collided and one damages the other)

Lewster's suggestion wins on the presumption the OP is making the call about not wanting to pay for spatial partitioning based upon unstated but sensible reasoning (to reuse a former example, perhaps they only want to do hittesting for mouse clicks) - a similiar solution is surely done inside the Pixi InteractionManager but that only helps the OP if they are specifically looking for mouse/touch interaction which they have not indicated.

Link to comment
Share on other sites

Just wanted to know if there is a predefined way. lewster32's answer was what I was searching for. doing it this way in an array.
Is there a performance issue for using an array over a group?  (lets say with 100 sprites in it).
Since I do not need too much of the group function, I can easily got them to work with simple arrays which keep reference to my sprites.
It's all about detecting positions and relations (if sprite is positions besides).

- Collision wount work I do not use any collision system since it makes no sense in the kind of game I'am working on.
It's more a strategy like controlled game. So there is no collision / overlaping that I want to detect.

I calculate if there are 3 sprites besides and or 2x3 for space requirements ( a room need at least 2x2 sprites besides ).

regards

Link to comment
Share on other sites

An array will be slightly faster than a group, but probably not noticeably. The benefit of an array is that it allows you to make a collection of objects separate from the display logic, which groups are inherent to. If you create a group you're also changing how the sprites in that group are rendered; the sprites' positions, display order and other things can be affected. On the other hand you can add sprites to an array from anywhere in or out of the display list and they'll remain visually unaffected.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...