2

I'm using a Spritesheet in an AS3 project, and upgrading from using a very resource heavy method of cutting up the bitmap into each frame and then storing them, to using scrollRect so it just displays the required frame. That is working mostly fine with a HUGE resource saving.

That said, there is a problem as the sprite as displayed via scrollrect is now jumping around like crazy. The Spritesheets have been checked and are fine, and seam to be okay on small sheets where there is only one row of sprites, so only the X axis is moved in.

However, on larger ones, like the main character, where there are more then one row, it's a lot worse.. When the sprite is loaded, it is given the values for the height and width of the sprite in question, and then it works out how many sprites in the sheet (counting blank spaces which are later ignored) and puts the values into an point array. The sprites are a fair size, so each frame is 480 width by 631 height (I know that isn't a square of 2 but I don't see an issue with that).

the code for making that array is pretty simple and is as follows:

'var tempSprite:Point;
for (var k:int = 0; k < h; k++){
for (var j:int = 0; j < i; j++) {
   tempSprite.x = (SpriteWidth) * j;
   tempSprite.y =  (SpriteHeight * k)
   SpriteOffsets.push(tempSprite);
}
  }'

Bitmapdata is given for each time it changes to a new sheet and that works fine, also it checks to make sure its not changing it to a new sheet when one isn't required. scrollRect is done passing the X and Y value from the point array (SpriteOffsets) along with giving the width and height of the sprite, so it knows the full size. it is then set to cacheAsBitmap (to make sure) and smoothing is turned on.

problem appears to kinda be weird.. as if it's trying to do a scale and screwing up as often it's a pixel out, sometimes more. When scaling the player window, it also appears to affect the amount it is out by differently. It appears to only be the Y axis though.

When using a transparent PNG source for the bitmap data, it also appears that it is 'snapping' to the top of the frame more then displaying everything, including the blank lines.

the code i'm using for the Scrollrect is just:

bitmap.scrollRect = new Rectangle(SpriteOffsets[FrameOrder[AnimSet][AnimFrame]].x, SpriteOffsets[FrameOrder[AnimSet][AnimFrame]].y, RSpriteWidth, RSpriteHeight);
                    

where the Spriteoffset bits call from the SpriteOffset array which stores (and I've checked) the correct X and Y position for the start of the frame, and RSpriteWidth and RSpriteHeight are the height and width of the frame, which are static for all frames. So all fairly typical of creating such as thing as I understand.

Really, this is my first try at upgrading to using scrollRect and while there are SOOO many pluses.. this seam to be creating a huge problem for me..

I have tried to manually work out the sprite offset and to account for that, it also appeared, at one time, that the rectangle was in fact, 1 pixel too tall, despite being told the correct number of pixels, so I tried to just reduce the height by 1 but to little avail.

Thank you for any help or advice.

Tempy111
  • 21
  • 1
  • 1
    You know, I can't see the difference between storing 1 bitmap of 480x631 versus 48 bitmaps of 80x79. When I was working with spritesheets, I used static array of bitmapdatas, then if a sprite wants to display a certain frame, its internal `Bitmap` object changes its `bitmapData` pointer to the relevant bitmapdata from that array, with `cacheAsBitmap=false`. It was pretty fast and lightweight, 600 sprites of one type didn't eat up more than 1 megabyte and framerate remained at 25 (project setting). Why do you want to use scrollRect over this? – Vesper Nov 02 '20 at 12:33
  • Also, if you insist on using scrollRect approach, you can as well cache (precalculate) rectangles for each frame, then use a link to corresponding rectangle instead of constructing it out of the `SpriteOffsets` array. It's possible that your array gets garbled somehow while your app is running, and you are looking elsewhere for your actual problem. – Vesper Nov 02 '20 at 12:40
  • I guess I COULD just manually cut up the sprite sheets and just have each frame loaded and stored.. the method I was using was to have the code cut up the sheets and with each frame being 480x631, this ended up in a huge memory issue, i'm not sure why it was as high as it was just by doing this as it was, but it was. changing bitmapdata is done for swaping between frames in that case, but ScrollRect method did save a lot. – Tempy111 Nov 02 '20 at 13:23
  • I can't really see too much difference between having the X & Y position for the Top Left, and knowing the width and height is too much different from having all the rectangles cached but it is worth a try though, if the SpriteOffsets array is getting damaged, I can't see how the rectangle caching wouldn't get damaged in the same way.. – Tempy111 Nov 02 '20 at 13:25
  • To avoid damage of rectangle caching, you declare the array of rectangles static and just don't touch it for assignment elsewhere but initialization code. To reduce the size of frames, you create new bitmapdata objects with width&height equal to your frame's, then draw or `copyPixels()` te required region to each of them, also declare the array static and fill it only once at initialization. – Vesper Nov 02 '20 at 14:08
  • surely, copypixels would just use up more memory but.. mm.. tried making rectangles and caching and it appeared to make it a BIT bitter.. bit there appears to be a lot of jumping around at different scale levels of the window.. which shouldn't and didn't happen before.. so.. I kinda really don't want to have to have thousands of bitmaps with one frame each as it does get extremely messy – Tempy111 Nov 02 '20 at 15:38
  • 2
    really can't figure scrollRect out as some things that SHOULD do something, didn't.. so I decided to move to copyPixels as Vesper suggested. works fine, need to do a fuller memory check but appears to take a bit more then scrollRect but nowhere near as much as originally done, so thanks ^_^ – Tempy111 Nov 02 '20 at 21:37

0 Answers0