sprite sequence - multiple sheets in a single sequence possible?

Audio and Graphics
#1

wondering if there’s a syntax for specifying a single sequence that uses frames from multiple sheets?

(and yes, i already know how to create multiple sequences from multiple sheets)

(and no, it’s not possible to put all frames on a single sheet)

for instance, the first N frames come from sheet1 and the remaining M frames from sheet2 – within the same sequence.  follow?

for my particular use, i currently work around it by mixing sequences from separate sheets and carefully reindexing the frames to function as if they were a single sequence.  so it’d be “convenient” if i could actually specify a single sequence and just control it with a wider range of true frames from separate sheets.  but i don’t recall seeing that syntax described for the sequence data.

tia

#2

(and no, it’s not possible to put all frames on a single sheet)

How absolute is this? Is it the nature of the problem, or more on account of, say, not wanting / able to redo art?

If it’s the latter, you could give canvases a go and splat the frames into that. I did some basic tests with them and sprites seem to work ( rakoonic has pushed it further, though I forget if he’s spelled this out on the forum). Then just load a new sprite with the canvas as the source image. You’d have to manually generate the sprite sheet info, but that’s probably on par difficulty-wise with what you’re already doing.

A proviso would be that you might want another in-between, 2-pixels-thicker sprite to capture any borders as well, during transfer.

#3

Thanks for the idea…

>> How absolute is this? Is it the nature of the problem, 

Not absolute, but practical.  Consider four 2048x2048 sheets, the first of which is a “common” sheet, the other three are different variations of a “specific” sheet, used one at a time to form a “pair” with the first, and thus the “complete” sheet.  (that is, never more than two are needed simultaneously)

So, in essence, it is to “behave” as if it were three pre-merged 4096x2048 sheets, as per your splatting.  (there would just happen to be a lot of duplicated pixels if it were stored on disk this way, rather than splatted at runtime)

However, I’m leery of pushing dimension beyond 2048, so I’d prefer to treat it as if it were an absolute constraint on the problem, and just “point” the frames at the separate (smaller, individual) sheets.

#4

The general idea has some pretty interesting implementations, if you look up “megatexture” or “sparse virtual texture”.

Specifically on the Corona side of things, thomas6 was championing something along these lines for quite a while (because of large sprite sheets that were noticeably slow to load), so it was one of the early things to occur to me to look at when the canvas resource was unveiled. I recall he also had a big “Aha!” moment when it was mentioned that powers-of-2 textures weren’t a strict necessity, so I wonder if that wasn’t related to the same problem. Anyhow, maybe there’s some interesting related material there.

#5

I’ll give it a go, specifically as per what thomas6 was doing, thanks.   still a bit worried about memory consumption during the intermediate blitting though.  btw, my use of PoT’s is really just “coincidence” - they’re full, not unnecessarily padded to PoT.

#6

(and no, it’s not possible to put all frames on a single sheet)

How absolute is this? Is it the nature of the problem, or more on account of, say, not wanting / able to redo art?

If it’s the latter, you could give canvases a go and splat the frames into that. I did some basic tests with them and sprites seem to work ( rakoonic has pushed it further, though I forget if he’s spelled this out on the forum). Then just load a new sprite with the canvas as the source image. You’d have to manually generate the sprite sheet info, but that’s probably on par difficulty-wise with what you’re already doing.

A proviso would be that you might want another in-between, 2-pixels-thicker sprite to capture any borders as well, during transfer.

#7

Thanks for the idea…

>> How absolute is this? Is it the nature of the problem, 

Not absolute, but practical.  Consider four 2048x2048 sheets, the first of which is a “common” sheet, the other three are different variations of a “specific” sheet, used one at a time to form a “pair” with the first, and thus the “complete” sheet.  (that is, never more than two are needed simultaneously)

So, in essence, it is to “behave” as if it were three pre-merged 4096x2048 sheets, as per your splatting.  (there would just happen to be a lot of duplicated pixels if it were stored on disk this way, rather than splatted at runtime)

However, I’m leery of pushing dimension beyond 2048, so I’d prefer to treat it as if it were an absolute constraint on the problem, and just “point” the frames at the separate (smaller, individual) sheets.

#8

The general idea has some pretty interesting implementations, if you look up “megatexture” or “sparse virtual texture”.

Specifically on the Corona side of things, thomas6 was championing something along these lines for quite a while (because of large sprite sheets that were noticeably slow to load), so it was one of the early things to occur to me to look at when the canvas resource was unveiled. I recall he also had a big “Aha!” moment when it was mentioned that powers-of-2 textures weren’t a strict necessity, so I wonder if that wasn’t related to the same problem. Anyhow, maybe there’s some interesting related material there.

#9

I’ll give it a go, specifically as per what thomas6 was doing, thanks.   still a bit worried about memory consumption during the intermediate blitting though.  btw, my use of PoT’s is really just “coincidence” - they’re full, not unnecessarily padded to PoT.