rabbyt using animated textures

[Zombie Mariachis]

Can anyone direct me to a simple example of achieving the same result
below but with using a rabbyt sprite instead of pyglet? I've tried
just replacing 'pyglet.sprite.Sprite' with 'rabbyt.Sprite' but I get
the following error 'ValueError: texture should be either an int or
str.' Thanks for any help!


class Exhaust(pyglet.sprite.Sprite):
def __init__(self, image, x, y, batch=None):
super(Exhaust, self).__init__(image, x, y, batch=batch)


ship_animations =[]
exhaust_images_image = resource.texture('exhaust2.png')
exhaust_images = pyglet.image.ImageGrid(exhaust_images_image, 1, 4)
map(center_anchor, exhaust_images)
exhaust_animation = \
pyglet.image.Animation.from_image_sequence(exhaust_images,
.05,
loop=True)

engine_1 = Exhaust(exhaust_animation, ship.x, ship.y)
ship_animations.append(engine_1)

[Jonathan Hartley]

I don't know whether Rabbyt Sprites are a drop-in replacement for Pyglet
Sprites. I suspect they are two very different beasts and therefore you
cannot simply replace one with the other.

There are many examples of how to correctly use Rabbyt sprites in the
Rabbyt source code, under the 'examples' directory. View them online here:
https://bitbucket.org/mmarshall/rabbyt/src/tip/examples/

Cheers,

Jonathan

--
Jonathan Hartley tar...@tartley.com http://tartley.com
Made of meat. +44 7737 062 225 twitter/skype: tartley

[Matthew Marshall]

The rabbyt sprite class works with pyglet textures, but not with the
pyglet animation class. You'll need to write your own code to
manipulate the rabbyt.Sprite.tex_shape property to show each frame of
the animation.

MWM

> --
> You received this message because you are subscribed to the Google Groups "Rabbyt" group.
> To post to this group, send email to rab...@googlegroups.com.
> To unsubscribe from this group, send email to rabbyt+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rabbyt?hl=en.
>
>

[Zombie Mariachis]

I've gotten this far in trying to figure this out. With the
tex_shape.left lines below I'm able to grab each frame that I need
from the image. Further below is the def update where I'm stumped
with my current knowledge. I can't think of a way to slow the
animation down. Right now it runs at warp speed in time with dt. Any
tips for this scrub?

sprite.shape.width = 19
sprite.shape.height = 64
sprite.tex_shape.width = 0.15
sprite.tex_shape.height = 1.0

#sprite.tex_shape.left = 0.0 #frame 1
#sprite.tex_shape.left = 0.15 #frame 2
#sprite.tex_shape.left = 0.3 #frame 3
#sprite.tex_shape.left = 0.45 #frame 4

def update(self, dt):
if dt:
self.tex_shape.left += self.tex_shape.width
if self.tex_shape.left > .45:
self.tex_shape.left = 0

[Matthew Marshall]

The problem is that you're advancing one animation frame every render
frame. How about saving the frame as a floating point value, so you
can increment it by a smaller amount each call to update(). Then
convert it to an int to find which animation frame you need to use.

Something like this:

def update(self, dt):
self.frame += dt*animation_frames_per_second
self.tex_shape = self.animation_frames[int(self.frame) %
len(self.animation_frames)]

MWM

[Jonathan Hartley]

What Matthew says is completely correct if you want the animation to
proceed in discrete jumps from one position to the next (as you imply by
your commented out lines showing 'left' proceeding from 0.0, 0.15, 0.3...)

An alternative, possibly simpler, way to think about it if you instead
would prefer smooth animation from one position to the next, is as follows:

In order for the object to move slower, you have to increment its
position by less each frame. Instead of doing "shape.left +=
shape.width" each frame, how about adding a new, smaller value to it,
which I'll call 'SPEED':

SPEED = 1.0

def update(self, dt):
self.tex_shape.left += SPEED

Now 'SPEED' can be defined as a module level constant, as I've done
here, or it can be put as a property on your sprite, which might be
better if you end up having several moving things and a different speed
for each of them.

There is a problem with this, which is that if you are on a fast
computer, your frames will be drawn rapidly, and the sprite will move
faster than if you are on a slow computer (or if your computer is busy
with another CPU hogging program). The way to compensate for this is to
multiply the speed by the value of 'dt' passed to update:

def update(self, dt):
self.tex_shape.left += SPEED * dt

As you seem to have already noticed, the very first time pyglet calls
'update', the value of dt is zero, so you need to guard against that. I
use 'max':

def update(self, dt):
dt = max(dt, 1/60.0)
self.tex_shape.left += SPEED * dt

Also, if for some reason your computer gets really slow (or maybe if
someone hits the 'pause' key) then the value of dt will get really
large, perhaps so large that it breaks the program in some way (e.g.
imagine adding a value to shape.left that moved the object miles off the
screen) So you also need to guard against that. I use 'min':

def update(self, dt):
dt = min(1/30.0, max(dt, 1/60.0))
self.tex_shape.left += SPEED * dt

Now you've got this in place, you can tweak the value of speed to achive
the effect you want.

This should work, more or less. There are some issues:

Firstly, you need to remember that if you are changing any other
gameplay-related values over time, then generally speaking you ought to
remember to scale the rate of change by 'dt' for those values too. (e.g.
if you were gradually turning up the lights to make your sprite visible,
and you wanted the lights to reach full brightness just as the sprite
reached the center of the screen, then you need to remember to scale the
light-brightening by dt too, or else of a slow computer the two will get
the spite movement and light brightening out of sync)
I once posted an overly-long post about the implications of this, such
as how to scale things that you are multiplying instead of adding, here:
http://www.mail-archive.com/pyglet...@googlegroups.com/msg05080.html

Secondly, this doesn't deal well if dt ends up changing rapidly from one
frame to the next. This might happen if you get the odd slow frame, due
to your game occasionally doing some sporadic processing, or if your
computer gets distracted dealing with some other process. This will
manifest as a flicker of jerky-looking motion. I think you might be
able to improve this somewhat by using a rolling-average value for dt,
but I've never actually tried this out myself.

Cheers,

Jonathan

[Zombie Mariachis]

Thanks for your help guys! Pyglet is almost useless without rabbyt,
so I really appreciate you guys being around to offer help in putting
rabbyt into action.