Hello,
have a prototype for the app, and just wanted to consult you folks before getting any further in wrong direction.
So let's say I have a large, predefined, generated box2d world, that is larger than visible screen. And I have a main character (which is a dynamic body) walking, running, jumping in this box2d world, interacting with it's objects, etc.
So what would be the best way to move the screen through box2d world, so it follows the character.
In simple game (without box2d), I'd simply leave character at constant position and move all the world by adding all world elements to one sprite and moving this sprite.
But in box2d world, this dynamic body moves with it's own forces, you can't restrict him to one position, only need to move screen as camera.
So unless I'm not missing any possible feature, the first solution that comes to mind, is to store global x and y offsets and apply them when positioning sprites according to box2d bodies, which would mean that sprites are actually elsewhere, not where the bodies are. Can't imagen if it would work or not right now, but still seems to be kind of a pain to implement and not sure if it is the right solution.
So want to hear your thoughts. Anyone?
Comments
I'm still experimenting, so I don't have an answer right now: would certainly be interesting to know what the best practice is!
Mike
http://www.sharksoupstudios.com
and this: http://www.emanueleferonato.com/2010/05/04/following-a-body-with-the-camera-in-box2d-the-smart-way/
But either due to lack of my ActioncScript knowledge or error in example, I can't seem to figure out what he does with x and y variables, which are calculated in the bottom of update function
However, there are requirements for interactions so complex that physics can definitely help: in those cases, knowing where to look at (and especially what to avoid) would help!
Let me built something to proof the concept.
Likes: atilim
I know this can be really complicated but we're also working on efficient culling of off-screen sprites.
Inactive bodies does not participate in calculations, thus meaning they will consume lesser resources.
So how about create boundary of sensors around screen and move these boundaries together with screen, and on collision with object, activate and deactivate bodies.
Activate the ones that go inside and deactive the ones that go outside the screen. I think it could be comparably easier to implement, but would that provide enough optimization?
Edited: Yes of course if only inactive bodies received collisions )
IMO, if you need to add and remove sprites while the game proceeds, then it's worth to add and remove related bodies as well: maybe not exactly on screen boundaries, as you probably want to give the impression that "something" is happening while you get there, but certainly when they're too far to have any influence on the game.
Even if you have a large number of bodies (e.g. outside of the screen) and many of them are sleeping then Box2D handles this case very well.
About optimization, would it be possible to set some sort of callback, when body starts to sleep, to remove representing sprite?
World I'm creating is too small to bother this kind of optimization, but still it would be interesting to see a viable solution
I like @MikeHart's approach since it doesn't require you to change how you draw your physics objects. I'd like someone to develop a small camera class based on this idea ... I've tried it myself but my small attempts so far have ended in frustration. I (think) I want something like:
Mike
http://www.sharksoupstudios.com
place the movie clips in a sprite and re position the sprite.(see the source file)
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
---------------------------------------