Jump to content

Sturb
 Share

Recommended Posts

Hey guys! I'm having another issue with my endless runner and arcade physics bodies. This time bodies seem to flicker for a frame after I have call kill/reset on their sprites. Basically I have three chunks which are laid out and scrolled on screen one other the other. Once a chunk has scrolled off the opposite side of the screen, the layout is reshuffled and it is positioned behind the previous chunks so it can scroll back on screen. Before reshuffling the layout, I forEachAlive -> member.kill(). This is because it's possible that no every child of the chunk will be used in the new layout, so I want to pool them. When I generate the new layout, I reset(x, y) the child. This seems to cause the body of the child to flicker on screen despite the chunk being off screen.

I wrote an example and attached it to help demonstrate the issue I am having.

example.zip

Link to comment
Share on other sites

You can fix this by calling `preUpdate` after repositioning each “fresh” sprite: 

The physics body is synchronized with the sprite’s position during `reset` and `preUpdate`. If you reposition the sprite after `reset` the body will be misplaced during the subsequent `render` (until the next `preUpdate`).

Link to comment
Share on other sites

Awesome! Thanks for that. It appears though that it doesn't work for nested groups, which is how my project is set up. The chunk is the parent group that moves, which has children groups for different object types. Calling preUpdate on those nested groups didn't seem to have any effect, however if I add my objects directly to the chunk and call preUpdate on that, it works. This isn't ideal because I want to handle collision differently for each of the nested groups (tiles, collectables, obstacles, etc).

Link to comment
Share on other sites

Yea I tried calling callAllExists("preUpdate", true) on the nested groups after I shuffled and positioned the layouts with no luck. I then tired calling preUpdate on each sprite as I respawned them in their nested group, which also had no effect. It's unfortunate, but my solution is to just manage nine groups instead of just three. It doesn't really effect performance, just doesn't allow me to structure my levels as nice as I would like lol. 

Perhaps this is a bug? Forcing a preUpdate call kind of feels like a hack. I mean it works and all, and I'm greatful for that, it just feels weird lol.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

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