Camera System Help

Solar2D General Questions/Discussion
#1

Hello, this is my first time posting so bear with me. 

I am currently in the process of developing a roguelike, top-down shooter.  The rooms are being loaded with the PonyTiled library, the only problem being that my “walls” are static physics object layers and do not translate together with the map. From what I understand, this prohibits the use of a camera system that simply moves the map around the player, creating the illusion of movement.  I also read about problems spawning from moving physics objects… 

Is there a way to load sections of the map off screen and then simply change where the screen “looks”? As in actually following the player off screen? 

Also, are static physics objects a bad idea for walls? Is there a better system I could be using? 

Any help would be greatly appreciated. 

#2

the general principle of using a group to simulate a camera works just fine with physics AS LONG AS YOUR “CAMERA” GROUP CONTAINS THE ENTIRE PHYSICS WORLD.

moving groups is a view-only effect, box2d knows nothing about it, it does NOT affect the internal model of the world at all - and that happens to be exactly what you want when implementing a global camera.

You only get into trouble when you try to differentially move separate groups that contain physics objects, because then the resulting multi-origin view won’t agree with the model (the relative visual positions of objects in those transformed groups will not match their relative world positions in the model).  But if you move them all the SAME (via your single camera group) then the whole view has been transformed the same, relative positions preserved, no problem.

to pan your “camera” right, slide the group left, et cetera.

statics are appropriate for absolutely immovable objects.  so if your walls CANNOT move, then static is appropriate.  if you need to have repositionable walls, then they should probably be kinematic.  or if you find that your walls need to respond to forces then they’ll have to be dynamic.

#3

Ok! Thanks for the information.

I am having some trouble moving my static objects in a group, however.  

They move fine when called individually, but refuse to move while in a group. Any suggestions?

#4

I found the issue!  The physics hybrid view does not show the static object movement in the way I presumed it would.  It works great!

#5

I was having a similar issue although it is related to resize events and changes to layout because of changes to device orientation between portrait and landscape.  It seems that resetting a master group with all display objects is a convenient way to re-position all display objects/groups within it.  However, it seems that the physics model does not/cannot understand a position of a physics body relative to changes to the group it was created in.  Therefore, it seems that any convenience gained through display groups for resize events is lost if making use of physics.  Is that correct?  Is there a convenient/preferred method for managing resize events caused by device orientation changes for physics bodies or should allowing orientation changes for games utilizing box-2D just be avoided?

#6

as long as it’s truly a “master group” (equivalent to OP’s camera group) then yes - everything i said above regarding positioning (ie, translating) a camera group also applies to rotating and/or scaling it.  as long as the transform is applied consistently to the entire physics world’s “view” then it’s a valid approach.

corona’s internal orientation handling will automagically rotate the entire canvas for you, you’d just maybe want to adjust the overall scale to better “fit” wider/taller if you desired (but that’ll depend on the specific needs of your app)

#7

by the way, this is all super-easy to test…

build some simple side-view test world with gravity - maybe “ball falls to the floor”, for example.

make sure everything is inside a single master/camera group.

now rotate that group by 90 degrees.

note that “world down” (gravity) now points to the right, because you have rotated the CAMERA (like tilting your head), but you have not rotated the WORLD (the floor is still “below” the ball, not to the side of it - it only LOOKS like it’s to the side of it, because the view is rotated).

box2d doesn’t know and doesn’t care what your “view” looks like.

#8

the general principle of using a group to simulate a camera works just fine with physics AS LONG AS YOUR “CAMERA” GROUP CONTAINS THE ENTIRE PHYSICS WORLD.

moving groups is a view-only effect, box2d knows nothing about it, it does NOT affect the internal model of the world at all - and that happens to be exactly what you want when implementing a global camera.

You only get into trouble when you try to differentially move separate groups that contain physics objects, because then the resulting multi-origin view won’t agree with the model (the relative visual positions of objects in those transformed groups will not match their relative world positions in the model).  But if you move them all the SAME (via your single camera group) then the whole view has been transformed the same, relative positions preserved, no problem.

to pan your “camera” right, slide the group left, et cetera.

statics are appropriate for absolutely immovable objects.  so if your walls CANNOT move, then static is appropriate.  if you need to have repositionable walls, then they should probably be kinematic.  or if you find that your walls need to respond to forces then they’ll have to be dynamic.

#9

Ok! Thanks for the information.

I am having some trouble moving my static objects in a group, however.  

They move fine when called individually, but refuse to move while in a group. Any suggestions?

#10

I found the issue!  The physics hybrid view does not show the static object movement in the way I presumed it would.  It works great!

#11

I was having a similar issue although it is related to resize events and changes to layout because of changes to device orientation between portrait and landscape.  It seems that resetting a master group with all display objects is a convenient way to re-position all display objects/groups within it.  However, it seems that the physics model does not/cannot understand a position of a physics body relative to changes to the group it was created in.  Therefore, it seems that any convenience gained through display groups for resize events is lost if making use of physics.  Is that correct?  Is there a convenient/preferred method for managing resize events caused by device orientation changes for physics bodies or should allowing orientation changes for games utilizing box-2D just be avoided?

#12

as long as it’s truly a “master group” (equivalent to OP’s camera group) then yes - everything i said above regarding positioning (ie, translating) a camera group also applies to rotating and/or scaling it.  as long as the transform is applied consistently to the entire physics world’s “view” then it’s a valid approach.

corona’s internal orientation handling will automagically rotate the entire canvas for you, you’d just maybe want to adjust the overall scale to better “fit” wider/taller if you desired (but that’ll depend on the specific needs of your app)

#13

by the way, this is all super-easy to test…

build some simple side-view test world with gravity - maybe “ball falls to the floor”, for example.

make sure everything is inside a single master/camera group.

now rotate that group by 90 degrees.

note that “world down” (gravity) now points to the right, because you have rotated the CAMERA (like tilting your head), but you have not rotated the WORLD (the floor is still “below” the ball, not to the side of it - it only LOOKS like it’s to the side of it, because the view is rotated).

box2d doesn’t know and doesn’t care what your “view” looks like.