stuck with 2D scrolling, screen vs world coordinates

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

stuck with 2D scrolling, screen vs world coordinates

(5 posts) (2 voices)

Started 2 years ago by redsky
Latest reply from psionic

Tags:

redsky
Member

let's say i've got a 2d map thats 4x the screen size. i understand the concept between world coordinates and screen coordinates. what i'm stuck on is where do i do this translation for my sprites?

my first thought was check to see if Sprite has a draw method I could override and convert the sprites world coordinates to screen coordinates. that seemed to be a dead end.

i see that the Layer class has a draw method and if I override that it doesn't actually replace the drawing functionality, it looks like it calls my code in addition to the standard drawing code.

so i guess my question is...

Is the draw method on the layer class the best place to update all my sprites positions based on the current x,y scrolling offset?

if the answer is yes, it seems like that wouldn't scale well performance-wise? unless i do a down-selection of sprites to determine what could be in the visible screen area.

if it helps at all, i'm using AtlasSprite and AtlasSpriteManager.

Bonus karma for a tutorial or example! :) I searched, but came up empty handed.

---

off topic: how do you set your avatar graphic on here? i didn't see it in the profile area.

Posted 2 years ago #
psionic
Member

Optimally you want an update function running off a scheduler. The
draw method is a bad place to be doing logic, since you don't
necessarily need to update the positions every single frame.

in this update function you update taking into account your camera's position.

sprite.position = CGPoint(spriteWorldPos.x - cameraWorldPos.x,
spriteWorldPos.y - cameraWorldPos.y);

then whenever your sprite happens to draw, it'll use its position.

Chris.

On Sun, Jun 21, 2009 at 12:14 AM,
<cocos2d-iphone-discuss@gamesforfood.cl> wrote:
> redsky says:
>
> let's say i've got a 2d map thats 4x the screen size. i understand the
> concept between world coordinates and screen coordinates. what i'm stuck on
> is where do i do this translation for my sprites?
>
> my first thought was check to see if Sprite has a draw method I could
> override and convert the sprites world coordinates to screen coordinates.
> that seemed to be a dead end.
>
> i see that the Layer class has a draw method and if I override that it
> doesn't actually replace the drawing functionality, it looks like it calls
> my code in addition to the standard drawing code.
>
> so i guess my question is...
>
> Is the draw method on the layer class the best place to update all my
> sprites positions based on the current x,y scrolling offset?
>
> if the answer is yes, it seems like that wouldn't scale well
> performance-wise? unless i do a down-selection of sprites to determine what
> could be in the visible screen area.
>
> if it helps at all, i'm using AtlasSprite and AtlasSpriteManager.
>
> Bonus karma for a tutorial or example! :) I searched, but came up empty
> handed.
>
> ---
>
> off topic: how do you set your avatar graphic on here? i didn't see it in
> the profile area.
>
> Read the whole thread.

Posted 2 years ago #
redsky
Member

Thanks, Chris.

Is that a common practice then to iterate through all sprites in the scheduler tick and adjust their positions there? That feels excessive/wasteful as most the sprites will never be on the screen at one time. I'm probably over thinking it. I guess just updating a sprites position is probably not too expensive.

Posted 2 years ago #
psionic
Member

Depends on how many sprites you'll be having. Some common methods to
do something like this is a spatial partition, like BSP

I'd suggest starting with looping through all your sprites in a
scheduler tick and setting them visible or not depending on whether
they're in screen space. That same 'is in screen space' calculation
can then be used to update the sprites positions, and perform
different things like animations. You could also stop animations on
non-visible sprites in this manner as well (like lights blinking, not
something that requires temporal coherence like a radar-type sweep,
though this too could be just started at whatever time value is
necessary when it's inside screen space again).

Chris.

Posted 2 years ago #
psionic
Member

Another method would be to place a bounding circle around local
clusters, and check if that bounding circle is within the screen space
or not, then proceed to the actual individual checks.

Chris.

On Sun, Jun 21, 2009 at 12:53 AM, chris forrester<psionic81@gmail.com> wrote:
> Depends on how many sprites you'll be having. Some common methods to
> do something like this is a spatial partition, like BSP
>
> I'd suggest starting with looping through all your sprites in a
> scheduler tick and setting them visible or not depending on whether
> they're in screen space. That same 'is in screen space' calculation
> can then be used to update the sprites positions, and perform
> different things like animations. You could also stop animations on
> non-visible sprites in this manner as well (like lights blinking, not
> something that requires temporal coherence like a radar-type sweep,
> though this too could be just started at whatever time value is
> necessary when it's inside screen space again).
>
>
> Chris.
>

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.