Copy link to clipboard
Copied
Hi,
I am having some trouble with some ATF textures I am uploading to memory on a few different IOS devices.
When the texture starts to upload using Texture.uploadCompressedTextureFromByteArray( data, offset, isAsync ) I get a #3669: Bad Input Size error occur.
Taking at look at the properties in the data I can see that the position is always 16. Im not sure if that has anything to do with it but i thought i would mention it.
I have tried using the png2Atf and also using Texture Packer but i get the same result.
I can replicate the issue every time on iPad Air IOS 8.4.1, we have also replicated it on a number of other IOS devices running different IOS versions.
My textures are 2048x2048 and I am using baselineConstrained for the Stage3D profile.
I am using Starling but I have used the following code for testing to make sure that it is not starling that is failing.
It would also be good to know that I load about 4 other ATF textures successfully before it tries fails to load this texture. I have opened up Adobe Scout and it looks like I have enough graphics memory available so i'm not really sure what is going on.
Below is my test code. This triggers once the core assets have been loaded and the home screen has been displayed. I have also moved this before I load anything else and it still fails.
var file:File = GGGlobals.EPISODE_PATH( "2" ).resolvePath( "x2/episode.atf" );
var ba:ByteArray = new ByteArray();
var fs:FileStream = new FileStream();
fs.open( file, FileMode.READ );
fs.readBytes( ba );
var texture:flash.display3D.textures.Texture = Starling.context.createTexture(2048, 2048, Context3DTextureFormat.BGRA, false);
texture.uploadCompressedTextureFromByteArray( ba, 0 );
Any help would be really appreciated.
Thanks,
Chris
Hi All,
I have managed to fix the issue. My startup in the app was causing the ATF bytes to become corrupt.
In my startup I move the ATF files from the Application Directory to the Documents directory and the app was continuing before the process had finished moving each file. The bytes were the correct length but the the wrong values.
Apologies for not getting back sooner. Thank you for your responses.
Thanks
Chris
Copy link to clipboard
Copied
My issue is now happening on two Android devices running 4.4.2 and 5.1 running AIR 18.
The ATF files are not using ETC or PVRTC they are just containers for PNG as the file size is smaller than normal PNGs.
Can anyone help? Its driving me mad and the project is for a high profile client.
Copy link to clipboard
Copied
maybe this post on the starling forum will help: http://forum.starling-framework.org/topic/assetmanager-bad-input-size
I'm not familiar with using ATF as a "container for PNG" - do you mean you're using RGB format inside the ATF?
If you're not using compressed textures, you might as well use PNG - PNGs are compressed pretty well, and IPAs are compressed as well (zip file).
I'm currently using ATF PVRTC on ios and ATF ETC on android for my starling games, I switched from PNG for smaller memory usage. However, I had to pull a few tricks due to compression artifacts.
Copy link to clipboard
Copied
HI Chris,
Could you please share a sample app and ATF that you are using . It would be easier for us to debug using it.
-Vivek
Copy link to clipboard
Copied
Hi,
Below could be the reason for method uploadCompressedTextureFromByteArray:
public function uploadCompressedTextureFromByteArray(data:ByteArray, byteArrayOffset:uint, async:Boolean = false):void
"when there is integer overflow of byteArrayOffset
or if byteArrayOffset
+ 6 is greater than the length of data
, or if the number of bytes available from byteArrayOffset
to the end of the data
byte array is less than the amount of data required for ATF texture"
Please try this. If the issue still exist, please let us know.
Thanks
Copy link to clipboard
Copied
Hi All,
I have managed to fix the issue. My startup in the app was causing the ATF bytes to become corrupt.
In my startup I move the ATF files from the Application Directory to the Documents directory and the app was continuing before the process had finished moving each file. The bytes were the correct length but the the wrong values.
Apologies for not getting back sooner. Thank you for your responses.
Thanks
Chris