The animation of a sprite sheet goes from frame to device. In the simulator it works perfectly.
Jump to content
I don't know what you're saying here: "The animation of a sprite sheet goes from frame to device. "
Make a demo, zip it up, share it here by attaching zip file to your post (click 'more reply options' below).
Also, tell us (using a numbered list as I have).
1. What you did.
2. What you expected to see.
3. What you saw.
4. Why you think it is wrong.
I made an animation using a spritesheet.
I'd love to help, but I need code I can run and examine
Please make a demo and share it.
I assume you mean the "Mate" Jitter is the wrong thing?
Please make a demo app with just that animation and share the code.
Question: Did you use a tool to make your spritesheets or are you doing this by hand?
I think we do not understand each other:
Thanks for the code. I've got good and bad news.
The good news is it works perfectly for me on my device.
I built it on my Windows machine using Corona 2018.3363. I then installed it on my Galaxy Tab 4 device running Android 4.4.2 for testing.
The animation played flawlessly without jitter in the simulator and on the device.
(Note: To make this easier to verify, I made the animation loop forever. This way I didn't have to reload the app over and over to test it. However, even without that change, there was no jitter.)
You can download my APK here if you want to test it yourself:
The bad news is we don't know yet what is causing you trouble.
I have some questions (I am using a numbered list, please respond with a numbered list so I can correlate answers with questions directly):
1. Did you build and test this example and verify it reproduced the problem before sharing it above?
2. Does the APK I built work for you as expected?
3. If you see an issue, please describe it. I don't see any issues and I want to be sure I understand it.
(Thus far I understand the problem to be that the sprite frames are jittering in your game or app. That is, the images are shaking side-to-side in your MP4 video.)
4. What version of Corona are you building with?
5. What device are you building for and what OS version is it running?
PS - If you want to respond in Spanish, that is OK. I'm willing to translate. I will still respond in English, but I'd like to make this as easy for you to reply as possible.
Edited by roaminggamer, 08 October 2018 - 09:11 PM.
Like Ed, I wasn't able to reproduce the jittering that you described, but I may be able to offer some additional suggestions.
1) One reason why you may be seeing problems on actual devices is because your "HojaIntroAnimacion.png" is colossal. The file's resolution is 7670x888 and that is just crazy! I literally gasped when I saw the file. You are using 32MB of texture memory to load a single image when you could get away with using less than 10% of that.
Consider the following:
- Remove the empty space from the frames. If you need those purple corners, just add them as one or four separate image(s).
- Separate the butterfly and the text. You shouldn't duplicate content that doesn't change in every frame as it will take up unnecessary resources. You'll need only a handful (or if you play with masks, two) images for the text and a series of images for the butterfly. If you use a tool like texturePacker, you could eliminate 90-95% of the empty space from the butterfly sequence.
2) You position the sprite by giving it x=500 and y=300 coordinates, however, resolutions change across devices. While those coordinates may appear to center the sprite on some specific display resolution, the end results will change on devices with different resolutions. If you position the sprite by using the likes of "display.contentCentreX and Y", the sprite will always be centered.
*Edit, improved readability
One Issue I see here is that your image file is WAY too big.
For maximum compatibility, you need to use multiple files where no file has a dimension greater than 2048
*UPDATE* Looks like XeduR @Spyric and I were typing at the same time.
I agree. You can also get rid of the black part of the images unless it serves a purpose.
OK. I took your original example and did this:
1. I split the image into 60 discrete images.
2. I got rid of the black background for the most part.
3. I used texture packer to make a new image sheet with the dimensions 504 x 814
4. I exported a new sprite image and lua file.
5. I used this to reproduce your example.
You can download my work here:
In that zip file you will find two folders:
Try this and see if it works better.
Note: I would not use it in your app/game because I probably messed up the butterfly, but if this works then you know what to do to fix the issue.
PS - The jiggling in your original code (not the demo code) is probably being caused by this:
1. Your image gets downscaled so it can be loaded fully into memory.
2. Because you have odd numbered widths , the frame alignment of some frames get shifted to the nearest pixel.
3. When Corona goes to show frames, this alignment issue is visible as jiggling left and right.
4. In the MP4 video you provided it looked like you were zooming in on the animation. So a single pixel left-right offset was getting turned into multiple pixels of offset and the jiggle was highly pronounced.
Edited by roaminggamer, 09 October 2018 - 10:34 AM.
The large width is the likely culprit, as mentioned above. More specifically this is probably a quirk of floating-point, in particular the narrower variety used by the GPU.
Details, if you're interested:
In the process of sending your sprite sheet positions along to the graphics hardware, they'll be normalized to the [0, 1] range, by being divided by the image's dimensions.
Now, see the "qualifiers" section on page 3 here (OpenGL ES quick reference).
You are only guaranteed (by hardware that honors the spec) to have 2-10 precision, or 1 / 1024ths. If you see that part about "FP Magnitude Range", all your numbers are formed by interpolating between neighboring powers of 2, in units of 1 / 1024th the distance between them. (Texture coordinates in Corona shaders fall into the mediump category.)
As an example, between 2-1 and 20 (that is, .5 and 1), you have a step size of 1 / 1024 * .5, or 1 / 2048, whereas you need closer to 1 / 8096 to land on a pixel given your width. Thus you get unpredictable results at the edges of your frame unless you pad with several duplicate pixels (filtering will at least mitigate some of this weirdness in the interior). The problem might be less severe the further left you go.
I just tried the project that is in the Mod folder. It works wonders.
Community Forum Software by IP.Board