This did seem to make it smoother, but I'm still a bit confused about
what the best approach to scrolling is.
I tried moving the setfocus() call to a step function where I handly
input and such. This made the scrolling much smoother compared to the
action approach. The coordinates for the two calls should be the same,
so I don't really get why using a focus action harms the smoothness
that much - I haven't seen any noticeable drop in framerate.
I'm just testing Cocos out so this is probably a bit ugly but this is
how it's set up:
I have a Scene ("GameScene") which holds the ScrollingManager as a
child (and a member). A layer that handles input ("ControlLayer") is
added to the manager. On the control layer, sprites and such are added
(controlled using actions and collided using RectMapCollider). Another
layer, a RectMapLayer loaded from file, is added to the manager. I
also add a background to the Scene.
So, my first approach was to make an action for the focusing,
FocusOnControl. This action is "done" on the GameScene. Here's its
step function:
def step(self, dt):
focus = self.target.control.focus
if focus is not None:
self.target.manager.set_focus(focus.x +
focus.speed.x*dt, focus.y + focus.speed.y*dt)
This causes some odd jittery motion of the scrolling.
I then moved the set_focus() to my ControlLayer step() function, using
the same call. This made the scrolling much smoother.
Is the action approach a bad idea, or is something else going on here?
Please tell me if anyone needs more info, I'm not really that familiar
with Cocos yet, and not an experienced Python programmer.
On May 20, 6:07 pm, Winston Wolff <[email protected]>
wrote:
> Cocos2d does truncate pixels to integers. I subclassed Sprite to modify a few
> methods to make it use Floats.:
>
> # Copied from cocos.sprite, and modified to use Float coordinates.
> def _create_vertex_list(self):
> if self._batch is None:
> self._vertex_list = graphics.vertex_list(4,
> 'v2f/%s' % self._usage,
> 'c4B', ('t3f', self._texture.tex_coords))
> else:
> self._vertex_list = self._batch.add(4, GL_QUADS, self._group,
> 'v2f/%s' % self._usage,
> 'c4B', ('t3f', self._texture.tex_coords))
> self._update_position()
> self._update_color()
>
> # Copied from cocos.sprite, and modified to use Float coordinates.
> def _update_position(self):
> """updates vertex list"""
> if not self._visible:
> self._vertex_list.vertices[:] = [0, 0, 0, 0, 0, 0, 0, 0]
> return
>
> img = self._texture
> if self.transform_anchor_x == self.transform_anchor_y == 0:
> if self._rotation:
> x1 = -self._image_anchor_x * self._scale
> y1 = -self._image_anchor_y * self._scale
> x2 = x1 + img.width * self._scale
> y2 = y1 + img.height * self._scale
> x = self._x
> y = self._y
>
> r = -math.radians(self._rotation)
> cr = math.cos(r)
> sr = math.sin(r)
> ax = int(x1 * cr - y1 * sr + x)
> ay = int(x1 * sr + y1 * cr + y)
> bx = int(x2 * cr - y1 * sr + x)
> by = int(x2 * sr + y1 * cr + y)
> cx = int(x2 * cr - y2 * sr + x)
> cy = int(x2 * sr + y2 * cr + y)
> dx = int(x1 * cr - y2 * sr + x)
> dy = int(x1 * sr + y2 * cr + y)
>
> self._vertex_list.vertices[:] = [ax, ay, bx, by, cx, cy, dx,
> dy]
> elif self._scale != 1.0:
> x1 = int(self._x - self._image_anchor_x * self._scale)
> y1 = int(self._y - self._image_anchor_y * self._scale)
> x2 = int(x1 + img.width * self._scale)
> y2 = int(y1 + img.height * self._scale)
> self._vertex_list.vertices[:] = [x1, y1, x2, y1, x2, y2, x1,
> y2]
> else:
> x1 = int(self._x - self._image_anchor_x)
> y1 = int(self._y - self._image_anchor_y)
> x2 = x1 + img.width
> y2 = y1 + img.height
> self._vertex_list.vertices[:] = [x1, y1, x2, y1, x2, y2, x1,
> y2]
> else:
> x1 = - self._image_anchor_x
> y1 = - self._image_anchor_y
> x2 = x1 + img.width
> y2 = y1 + img.height
> m = self.get_local_transform()
> p1 = m * euclid.Point2(x1, y1)
> p2 = m * euclid.Point2(x2, y1)
> p3 = m * euclid.Point2(x2, y2)
> p4 = m * euclid.Point2(x1, y2)
>
> self._vertex_list.vertices[:] = [
> p1.x, p1.y, p2.x, p2.y,
> p3.x, p3.y, p4.x, p4.y]
>
> On May 20, 2011, at 2:49 AM, Olof Nilsson wrote:
>
>
>
>
>
>
>
> > I've started using Cocos2d (v0.4.0) recently and encountered the same
> > problem as mentioned in the qouted year-old post below. It can be seen
> > in the test_tiles.py example, especially if you increase the max
> > speed. Basically the scrolling "jitters" when in motion.
>
> > Is there a better approach to smooth scrolling, or is this a problem
> > with ScrollingManager?
>
> > qouted:
> > "
> > I've noticed in both the 0.3 and svn cocos that scrolling with moving
> > sprites sometimes causes weird "vibration" rendering glitches which
> > look like a one pixel error interpolation issue or something. If you
> > zoom in on the car in the test_tiles while it is scrolling and
> > rotated
> > you will notice it vibrates.
> > I found this issue making a very low resolution game where I was
> > trying to use the MoveTo action to move a sprite while focusing on
> > that sprite every frame. The sprite would jump back and forth a pixel
> > while it was moving in the same direction the scrolling manager was
> > scrolling. If I manually moved the sprite with a velocity it would
> > have the same problem, but only when the call to set_focus was in the
> > layer's scheduled update or some higher level. If i put the
> > set_focus
> > immediately after the sprite position change in the sprite's
> > scheduled
> > update method the vibrating would stop for that sprite but other
> > moving sprites in the scene would still have the problem.
> > Putting the test_tiles scroller.set_focus(car.x, car.y) in a new
> > scheduled update in the main scene separate from the car's update
> > causes the vibration to occur when moving without rotation as well.
> > I've been trying to track down this bug, but I admit not knowing
> > where
> > to look. I am wondering if inting or rounding floats to pixels
> > somewhere is causing the problem but changing the int conversions in
> > the scrolling manager back to floats didn't do anything. Or perhaps
> > the ordering of update, transform, and draw somewhere is causing
> > problems?
> > "
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "cocos2d discuss" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group
> > athttp://groups.google.com/group/cocos-discuss?hl=en.
--
You received this message because you are subscribed to the Google Groups
"cocos2d discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cocos-discuss?hl=en.
