Tricks to getting a large animation sequence to play smoothly on an iPad 1
TouchTiltGames
Member Posts: 1,162
In my upcoming Tiny Diggers game:
http://forums.gamesalad.com/discussion/37749
I've got the arm of my Excavator that is an animation 420x450. However this is just too much for an iPad 1 to handle, even when the animation is ~7 frames. I can't use joints obviously and I can't make it smaller. I think I read somewhere about making the animation sequence an Image attribute or something? Anyone ever use this successfully?
Does anyone know any tricks to getting an image sequence of this size to play smoothly? I've optimized the hell out of the images, but I know that has nothing to do with memory really...
cheers.
http://forums.gamesalad.com/discussion/37749
I've got the arm of my Excavator that is an animation 420x450. However this is just too much for an iPad 1 to handle, even when the animation is ~7 frames. I can't use joints obviously and I can't make it smaller. I think I read somewhere about making the animation sequence an Image attribute or something? Anyone ever use this successfully?
Does anyone know any tricks to getting an image sequence of this size to play smoothly? I've optimized the hell out of the images, but I know that has nothing to do with memory really...
cheers.
Comments
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
sequentially and numerically name your images: 1.png; 2.png, etc. (your static start image should be 0.png)
in the Rule you use to start the animating (button press ???)
Rule:when
touched is pressed
--Rule: when
--Attribute: self.Image ≤ 7
----Timer: Every: (???) second
-----changeAttribute: [exp] self.Image To: [exp] self.Image+1 (you don't need to type in the .png )
--Otherwise:
----changeAttribute: [exp] self.Image To: 0
Otherwise:
--changeAttribute: [exp] self.Image To: 0
works for me … needs tweaking for timing … and event initiation when you don't use a button/press.
MH
"I can't use joints obviously and I can't make it smaller"
I think at a push - using maths (lots of sin and cos!) - you could actually construct simple jointed movements, but I expect you already have your animation in place and as you like it.
As for 'smaller' - have you optimized the animation sequence as much as you can ?
@Mother Thanks! Ahh that's what I was looking for!
@Tynan - Yeah with a lot of constrains? But that's pretty taxing on the devices I believe.
Really appreciate your responses, I'll try Mothers out.
How are you doing a self.image ≤ 7 ?
In a Rule you can't set that, all you get for self.image is "contains", begins with, ends with..etc.
I don't think it should take too many, all the work is in working out the maths I think, I was thinking of a simple two or three arm linkage, but I don't know what your App does so it might not be right for what you are doing, but I think with a bit of work you could get it going.
Look at this (terrible) quickie example (prepare to be underwhelmed!)
http://www.mediafire.com/?r12x9qryv18tb25
Drag the white square left and right, I've not bothered to get it working properly but it is possible to create a simple moving linkage.
Only prob is could this work when it's moving? Heh. Thanks for doing that!
Your issue is prob due to the actual File Size. You could always try to break un the animated part of the Digger into a second actor. That way you are not repeating and using the RAM for the static part of the Machine. Hope that gives you ideas. otherwise hopefully Tynan's Stuff can help you out. I'll download and see if it looks like something that can be made to move around.
If I could make sense of MotherHoose's code there, like this: Attribute: self.Image ≤ 7
You can't set a self.image and then a < or > sign...Or is there another way?
"Only prob is could this work when it's moving?"
Of course ! The central pivot (the white block) is the master 'parent' (for the arms) - so just constrain the white block to anything you want, it's 30 seconds work . . . . . in fact, hold on let me chuck something together . . .
Right, here you go, attached to a "moving truck" (cough cough): http://www.mediafire.com/?ay91fvya7p9p2n8
I've made the white block big so you can grab it as the trucks moving, obviously it's all incredibly crude as it's just a few minutes of clicking, but I am sure with an afternoon or two of work you could have something really good going.
I use a lot of both game and scene Index attributes … to monitor the flow of things in my work
(various actors respond to an Index# with minimal amount of behavior coding … everything can do something at the same time when scene.Something = 10 !)
(and great when using one pauseScene to properly display 8 possible static cutScenes!)
so an important step would be make a scene.ImageIndex
and the Rule: when
touch is pressed
Rule: when scene.ImageIndex ≤ 7
changeAttribute: self.Image
changeAttribute: scene.ImageIndex To: scene.Image.Index+1
funny, how if you frequently do something the explanation is easy … but you forget chop the 'lettuce' ;D
hope I didn't forget any other important step!
MH
cheers!
I will try both methods and see which has better performance.
I would definitely go for circular tyres.
Anyway this is VERY much appreciated
If you look at the 2nd last screenshot here: http://forums.gamesalad.com/discussion/37749 with the Excavator arm, it moves down when you press the down arrow on the dashboard, and moves up when you press the up button. Both up and down motions should be the same, so on a scripted/animated track if you will. Is that still possible with your genius invention?
Also how are you constraining the base (white box) to the truck?
"lol Tynan, your truck is so rad. Love the blinking lights - I'm so inspired now for Tiny Diggers lol"
I know, it's excellent isn't it, I am going to give Pixar a call first thing in the morning, see if they need any help.
$-)
Constrain the box's X to the truck's X.
Constrain the box's Y to the truck's Y.
(the white box is not a prototype, you need to double click it in the scene to get to it's rules)
"the Excavator arm, it moves down when you press the down arrow on the dashboard . . . Is that still possible"
Almost certainly !
ps. IOU some graphics for this...
"Ok I've got it rotating now with interpolate"
I kind of approach linked joints in a different way, I simply couldn't work out how to have compounded rotations (where one thing rotates whilst belonging to another that is rotating) that's all far too complicated and will eventually make you blind and friendless, I think you'd end up in a real mess - I find it much easier to 'move' stuff in circular paths than to rotate them.
Have a look at this: http://www.mediafire.com/?zms0pyp5nk6njmc
I placed an orange square in the middle, it's not doing anything (although you can drag it around - taking it's children with it)
Then I made a blue square travel in a path around the orange square.
Then I made a little yellow square move around the blue square.
So you have all these orbits but not a single rotate behaviour anywhere.
Take a look it's just the same file from above - hacked around a bit (the rules for blue and yellow are on the scene instances not the prototypes - so click on the actors in the scene to see what they are doing).
Ok, looking at the three squares moving around each other (not rotating !!!) do this thought experiment . . .
Imagine first pulling out the orange square so it is a long horizontal bar about the width of the blue circle's orbit.
Now the blue square is still moving in a circle but it just touches the left and right ends of the orange bar as it moves.
Now we want to move the whole of the blue square (and it's orbit) to the left so that it is now orbiting the left hand end of the orange bar.
Now we pull the blue square out so that it is a long horizontal bar too - a long horizontal bar (that remains horizontal all the time) orbiting the left hand end of the orange bar
(continued) . .
Try a few obvious numbers first - you don't have to sit around calculating it's speed, just throw something in - and then see if you need more or less - it's usually a division or multiplication of some other speed you've used in the set up.
Hey presto ! The blue arm is pivoting from the left hand end of the orange bar. Now Imagine now doing the same for the yellow square and you get this . . .
http://www.mediafire.com/?clwusfvmwy0u09h
Hope that makes sense / helps a little . . .basically as far as I can see moving the X and Y in a circle is easier than rotating stuff (worry about what angle your 'arm' is at later on, that part is trivial)
You can do my entry for the next "PLEASE MAKE ME SOME GRAPHICS FOR FREE" 'contest'.
X_X
I also wish there was a resolved button at the top. This is a lot of reading! lol
Hope it goes well.
I haven't even started, lol !! . . . . [TouchTiltGames runs for cover] :o3
@ TouchTiltGames
Here is the same two link arm with a slider to operate it, just to show you it can be done, you could obviously make the slider buttons or a dial or whatever you want - and the arms and angles and stuff are all over the place, but it might offer you some clues . . .
http://www.mediafire.com/?84l7t2bobuihbd7
I promise I will stop now !
:-B
:-B
I've opened the prototype on the scene...can't find that.
"Ok stupid question time - how did you get scene.Background.uber1 on the Parent actor?"
Constrain 'parent's' X position to this >> (100*cos( game.Lever)) + scene.Background.uber 1.Position.X -111
Constrain 'parent's' Y position to this >> (100*sin( game.Lever))+ scene.Background.uber 1.Position.Y
Constrain 'parent's' Rotation to this >> game.Lever
(continued . . . . )
(100*cos( game.Lever))
This means oscillate the actor left & right by 100 pixels each way (so back and forth over a 200 pixel range around the actors centre point).
The thing in the brackets (game.Lever) is where the actor is in this oscillation - so for example if you stuck the value of 50 in there the actor would sit still (not moving) at wherever 50 is in our association (as we are sweeping 100 pixels left and 100 pixels right, I would guess 50 would be halfway from the centre to either the left or right, not sure which). But . . . . . if you stuck some changing value in there (like self.time) then the actor would just keep moving back and forth forever (or until the game stops!) . . . . for this value I stuck in "game.Lever" (which is simply the Y value of the slider on the right - so essentially 0 to 768) - so we can send our actor left and right through 768 pixels of this oscillation.
(continued)