Alternatives to large animation

0 favourites
  • 8 posts
From the Asset Store
Ninja char for your game! Make your own Shinobi game with this art.
  • Hi C2'ers,

    I currently have a puzzle game on the arcade "Hexzul" play here or (http://www.scirra.com/arcade/addicting-puzzle-games/3478/hexzul), try it out (you might like it!). I'm hoping to eventually release the game on mobile devices (both phones and tablets).

    I'm currently using a 1024 x 670 animation (x17 frames) to get the effect of the tunnel, but I realize this may be quite heavy on memory so I'm looking for a better way to do this.

    I've read various threads which discuss ways to fake an animation or effect, to help keep memory usage to a minimum (although they don't usually go into too much detail).

    I'm still pretty new to all of this, and I'm just not sure what my options are. So I was wondering if one of you lovely people could offer some advice on how I might be able to get the same result, by using one of these "fake" methods. I've spent a couple of days looking through the forum, but haven't found anything that resembles my problem (although I could've just been looking in the wrong places!).

    I wouldn't want the game to change too much, so it'd need to provide a similar result to my current option, but I'd be really grateful for any help / advice anyone could offer.

    Thank you in advance.

    <img src="smileys/smiley4.gif" border="0" align="middle">

  • Blacksmith - Off the top of my head, I would say a black background image with the diagonal lines and then thin sprites used to build the boxes, scaled and moved programmatically, would be what I would try. That would definitely be more efficient in terms of memory usage when compared to 17 images 1024 x 670, but it would take a bit of brain work to get the placement and movement right.

    It looks like at any one time, there are approximately 10 boxes on the screen, so it would take 40 moving and scaling sprites to accomplish that. I doubt that would to too much for C2 to handle well, but it'd be something you'd have to try first to really know...

  • Hi rogueNoodle,

    Thanks for the reply.

    I did try your suggestion this morning, but with that many large scaling sprites on the screen it seemed to slow down quite considerably. It certainly was not as smooth as my animation. But perhaps I was doing something wrong, I'll tinker with it some more to see if I can make any improvements.

    Thanks again.

  • Blacksmith - when you say large scaling sprites, how large where they? The largest would be 1024 x 4 pixels (or whatever the line width is), so I wouldn't think that would cause a problem...

    Or were you trying to scale large boxes? That would be different, because C2 would still have to draw the transparent pixels in the centre, which is why it would be necessary to break the box into 4 thin sprites.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • rogueNoodle,

    Yes I was using a large (1024 x 670) box. I can give your suggestion a try. Although I was under the impression that devices generally saved images in powers of 2 boxes, so 4 sprites of 1024 x 4 would actually be saved in boxes of 1024 x 1024, making a total of four 1024 x 1024 boxes as opposed to my one. Wouldn't that make things slower, or have I misunderstood?

    Thanks

    <img src="smileys/smiley1.gif" border="0" align="middle" />

  • Blacksmith - As long as each dimension is a power of two, you'll be fine - they don't need to be the same. So as another example, 256x512 would be valid...

    (Also, you'll be using the same texture for all four lines, just rotating and scaling as needed)

  • rogueNoodle,

    Ahhh! Okay that makes sense, I'll try again then.

    Thanks very much for your help!

  • Blacksmith - No problem - I hope it works for you!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)