Panning and Zooming a scene with Box2d?

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

Panning and Zooming a scene with Box2d?

(10 posts) (4 voices)

Started 1 year ago by Xemacobra
Latest reply from Xemacobra

Tags:

Xemacobra
Member

Hi,

I've been away from cocos2d since v0.8 and I was very impressed with the changes and updates that happened. Thanks for all the people working on making it better.

I searched everywhere for a sound and clean solution for panning and zooming but couldn't find any. I found many solutions like moving the layers, CCCamera, or even putting the scene on a UIScrollView. Each solution has limitations though and there are no clear code snippets for any of them.

I'm creating a game and I wanted to have the same kind of panning and zooming with parallax in AngryBirds. Can you please help me by guiding me in the correct direction? Which solution? Code snippets would be greatly appreciated.

Also, when I happen to solve my problem and if needed, I will create a code snippet to share.

Thanks in advance.

Posted 1 year ago #
mobilebros
Moderator

Just a quickie from me: Moving/Scaling layers has always worked for me, the one advantage (as I see it) is that it keeps things simple and it's easy to "visualize" in my mind.

Posted 1 year ago #
patrickC
Member

On the other hand, I've always used the camera methods and it also works fine ;)
It's a matter of preference.

I happen to have replied to a similar question the other day, posting a small code snippet on this thread: http://www.cocos2d-iphone.org/forum/topic/10543

I'm doing zooming and panning in a box2d world using the camera in my game Paper Bridge.
What exactly are the limitations you refer to?

Posted 1 year ago #
Xemacobra
Member

@mobilebros: Thanks for the input. Moving the camera should be logical but you're right visualizing the layer movement is much easier.

@patrickC: Thanks a lot for the reply. I checked the link you posted and tried the code snippet. It didn't work for me but I'm sure it was just my implementation and not the code itself since I've been testing many approches in the same project without properly cleaning it. As for the limitations I was talking about, the limitation I see till now is basically that every single point needs to be shifted. The camera moves, the view changes, Box2d bodies move properly but all touches are shifted. How do you handle this issue?

Posted 1 year ago #

The code snippet from the other thread is quite simple, at any rate all I'm doing is moving and changing Z value of the camera.

Regarding touches, here's yet another code snippet, this takes a touch coordinate and returns it's "world" value taking into account camera movement and Z value.
Hard-coded values means it works only in landscape, just change the order of values for portrait (or better yet do it the proper way)

-(CGPoint)convertCoordToLayer:(CGPoint)point {

	float centerX, centerY, centerZ;
	float eyeX, eyeY, eyeZ;
	[self.camera centerX:&centerX centerY:&centerY centerZ:&centerZ];
	[self.camera eyeX:&eyeX eyeY:&eyeY eyeZ:&eyeZ];

	point.x = (centerX + point.x);
	point.y = (centerY + point.y);

	if(IS_IPAD()) {
		//ipad
		point.x = point.x + ((point.x - centerX - 512)*eyeZ/885);
		point.y = point.y + ((point.y - centerY - 384)*eyeZ/885);

	}
	else {
		//iphone
		point.x = point.x + ((point.x - centerX - 240)*eyeZ/416);
		point.y = point.y + ((point.y - centerY - 160)*eyeZ/416);
	}

	return point;
}

Posted 1 year ago #

marcotronic
Member

Hi Patrick,
thanks for posting this. I´m starting with a tilemap based side scroller right now and I´m wondering why so many examples I find are just moving the layer instead of the camera. I read here and there that using a camera movement isn´t a good solution due to some traps to run into but I´ve never read any explanation why this is so and what kind of traps I could run into.

Moving a camera seems to me the more logical approach, though (just like you do in your game). So could you maybe point out why so many people don´t like using a moving camera? Is it just the fact that you have to convert some coordinates (e.g. touch coords)?

If I understand your last code right you convert the touch coords of the screen to those of the layer, right? One other question: How do you get these numbers: 885 and 416?

Thanks a lot for your help in advance.
Marco

Posted 1 year ago #
patrickC
Member

To be honest I'm not entirely sure what people refer to as "traps" when using the camera.
I think it's more a matter of preference and what one is used to, I can't see any potential problems with using the camera, and I myself have never ran into major problems.
Moving/scaling a layer still requires you to manually calculate a touch screen coordinate and translate into the layer's relative coordinate.

You are correct in understanding that the above code converts the touch screen coords to those of the layer, to put it in other words.

The magic numbers you see are 416 for the iPhone screen and 885 for the iPad screen, which are calculated by dividing the screen's width by the (what I think might be) f-value, that cocos2s has hard-coded as 1.1566f (which is also why this is hard-coded for landscape mode).
We need those numbers to understand how far out the camera is zoomed, and by how much we need to multiply the coordinates to take into account the zoom factor and obtain the correct coordinate.
For retina display my guess is that you need to take into account yet another magic number, I don't have a device to test.

I hope this all makes sense, I'm finding it somewhat hard to use proper words today ;)

Posted 1 year ago #
marcotronic
Member

Thanks a lot, Patrick. I really appreciate your answer.
Marco

Posted 1 year ago #
mobilebros
Moderator

Just want to add that when I do start moving/scaling layers, the convertTouchTo[blah]Space and other similar functions are your friend. Using that in conjunction with the winSize method from CCDirector can pretty much eliminate any hardcoding of values.

Posted 1 year ago #
Xemacobra
Member

Thanks a lot @patrick for the code snippets and thanks for the input from everyone.

From what I understand now and as @mobilebros said, moving layers seems simpler. Moving the Camera is the more logical solution though but it needs some work to make it as easy to implement as moving the layers. I'll try to do that on my free time and share anything I get.

I just wanted to make sure of one thing though. @patrickC, does moving the Camera affect using Parallax in any way?

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.