display.newMultiSprite() needed

Solar2D Daily Builds and Public Releases
#1

Hi,

as posted by Jonathan Beebee:
http://www.coronalabs.com/blog/2012/03/06/image-sheets-image-groups-and-sprites/

The other function, display.newMultiSprite(), is used when an object has animation sequences that span across multiple image sheets. [Editors Note: Sprites and multisprites are now available via a single API display.newSprite(): http://docs.coronalabs.com/api/library/display/newSprite.html#multiple-sequences]
We really need the functionality to span animation sequences across multiple image sheets, and we think lots of games need this.

Are you planing to implement it soon?

Best,
Andreas [import]uid: 107675 topic_id: 27827 reply_id: 327827[/import]

#2

+1 For this feature. When, for example having lots of animation for the player sprite that needs jump, walk, shoot gun, fall, die and other animations, putting all this in one single image is impossible. This is in my opinion the most important feature that needs to be implemented in Corona.

Looking forward for an update on this.

[import]uid: 38119 topic_id: 27827 reply_id: 112661[/import]

#3

Haven’t switched over to new sprites because of this, it does make we wonder how people are getting over this limitation? [import]uid: 33275 topic_id: 27827 reply_id: 112662[/import]

#4

+1. I emailed Peach about this as well but haven’t heard back yet. This is definitely a blocker for our current project. [import]uid: 94248 topic_id: 27827 reply_id: 112663[/import]

#5

@SegaBoy

Well, we often use sprites with one animation that are set to invisible, and when the animation is needed the sprite with the new animation is set to visible and the old sprite is hidden.

But it’s only a bad workaround. [import]uid: 107675 topic_id: 27827 reply_id: 112666[/import]

#6

Hi a.lepel - thanks for the tip.

So you’re essentially creating multiple sprites and toggling their visibility?

So just for example, if you had a character with multiple animations that won’t fit into a single sprite sheet (walk, jump, slide, shoot, etc…), then you would have individual sprites for these actions and toggle them on/off accordingly?

Is that correct? [import]uid: 33275 topic_id: 27827 reply_id: 112667[/import]

#7

@SegaBoy: Yes, absolutly correct. It’s bad, but it works.

We normally get the frame number of the last sprite displayed and then switch to the other sprite, make it visible and in some cases change the starting frame number of the animation depending on the last frame of the former animation.

But sometimes now you really NEED to have the animations in the same sprite sheet, an example:

You have your game hero running as animation loop (A), e.g. 6 frames: a1-a2-a3-a4-a5-a6

Hero is jumping is animation (B), e.g. 6 frames b1-b2-b3-b4-b5-b6

Now a special little trick: I put a jumping animation (B) together with first all the frames of the running hero and additionally the frames for the jump: a1-a2-a3-a4-a5-a6-b1-b2-b3-b4-b5-b6

Now when my hero is running and animation frame a3 is displayed when the player pushes the “jump” button, I switch to animation (B) and go directly to the a4 frame of (B).

This way there is a guaranteed smooth transition between running & jumping. :slight_smile:

BUT: Using a trick like this on needs to use animation frames of (A) and (B) - and this is right now only possible when all (A) and (B) frames are in ONE sprite sheet.

And this is bad for bigger games with lots of animations.

So I hope CoronaLABS will implement this soon,
best,
Andreas
[import]uid: 133261 topic_id: 27827 reply_id: 112697[/import]

#8

Bumping – Although I’m not even sure if this thread is showing up in the forum list… [import]uid: 94248 topic_id: 27827 reply_id: 112918[/import]

#9

Bump… Any sort of update would be appreciated by all. [import]uid: 94248 topic_id: 27827 reply_id: 113340[/import]

#10

Last i heard, this was not a priority and if we want it a priority we should insist on forum and other contact forms. [import]uid: 38119 topic_id: 27827 reply_id: 113342[/import]

#11

Waiting for this future for so long now… please add it again :slight_smile:
Many Thx! [import]uid: 9592 topic_id: 27827 reply_id: 113372[/import]

#12

Wow - I’ve never even come close to running out of space on a 2048x2048 pixel sheet for a single character, but I can imagine the hassle if you do.

So, + 0.5 from me! [import]uid: 70134 topic_id: 27827 reply_id: 113374[/import]

#13

@Thomas

There are some reasons why it is really needed:

  1. You cannot use 2048x2048 pixel sheets on each device, sometimes you only have 1024x1024

  2. At other times your spritesheet with all added physics data is already full, but you need to add one more animation for your sprite mainly located on the other sheet. And you cannot easily switch sprites with physics data (if you are e.g. using tools that support this) from one sheet to the next

There are more reasons but this should illustrate the point. :slight_smile:

Best,
Andreas [import]uid: 107675 topic_id: 27827 reply_id: 113438[/import]

#14

Hi Andreas,

Yeah I can imagine that it’s needed. I work on iOS mainly so all supported devices for the latest build can handle 2048 x 2048 which is nice for me, and I don’t work with physics either which is nice for me, but I assume would create more need for multisprites.

Okay, out of solidarity I will raise my support to +1 ! :wink: [import]uid: 70134 topic_id: 27827 reply_id: 113440[/import]

#15

I may be getting my sprites completely wrong, but what if you had an epic boss who took up the whole screen (~960 pixels height), you’re not going to be able to fit too many frames on one sprite sheet.

Or do I have this completely wrong? [import]uid: 33275 topic_id: 27827 reply_id: 113447[/import]

#16

@Thomas

Great, we developers have to stick together. :wink:

@SegaBoy

You could do it this way, but normally you would split big bosses in smaller parts, not every part needs to be animated frame by frame, some parts only need to be moved / scaled / rotated.

Otherwise it would just take up too much memory.

Best,
Andreas

[import]uid: 107675 topic_id: 27827 reply_id: 113449[/import]

#17

Starting the week off with a BUMP! [import]uid: 94248 topic_id: 27827 reply_id: 113895[/import]

#18

Extended 4th of July celebratory BUMP! [import]uid: 94248 topic_id: 27827 reply_id: 114316[/import]

#19

Hump-day bump [import]uid: 94248 topic_id: 27827 reply_id: 115057[/import]

#20

Let me see what I can do to slide this in — it’s out of band from our current feature cycle so can’t make any promises, but it would be nice to fill this gap in the new sprite api.

In terms of API, it’ll look something along the lines of:

local sequenceData = {  
 { name="walking", imageSheet=sheet1, start=1, count=3 },  
 { name="running", imageSheet=sheet1, frames={ 3, 4, 5, 6, 7, 8 }, time=50, loopCount=4 },  
 { name="jumping", imageSheet=sheet2, start=9, count=13, time=300 },  
}  
  
display.newMultiSprite( sequenceData )

There will be several limitations:
* a sequence (e.g. walking) must all reside on the same image
* this cannot be added to an imagegroup [import]uid: 26 topic_id: 27827 reply_id: 116288[/import]