I did notice that loading times for stuff inside the expansion file are much higher. This is a very unfortunate side effect of the need for the expansion file. Loading ~85MB takes around 20 seconds (before it was 3-5 secs). Are you experiencing the same?
In my opinion Google managed to make the store submission process much worse than Apple’s with this expansion thing. They could at least increase the maximum size for apps to something like 100MB.
Is the OBB file being copied to another location, or is it being read directly? What is the OBB file format you’re using? ZIP, or something else?
The obb file is a simple zip with the extension renamed to .obb.
It is pushed into the application during development like this:
adb push com.purpletreestudio.mygame/main.2.com.purpletreestudio.mygame.obb /mnt/shell/emulated/obb/com.purpletreestudio.mygame/main.2.com.purpletreestudio.mygame.obb
I’m using Thomas’ extension and also read other instructions here: [Showcase] Adventure Time: Rockstars of Ooo
About reading, using the extension it reads directly from the zip every time. For files other than pure text, you get haxe.io.Bytes, turn them into a ByteArray then into a BitmapData, or Sound file.
This ended up being much slower than getting stuff directly from a bigger apk. So what i’m doing now is on the first run i’m getting stuff from the zip file and writing them to the application storage folder. I’m still in the middle of the implementation but i think this will be almost as fast as the old method.
Hey, sorry I didn’t see this sooner, I’m pretty sure you can zip things without compression, I imagine that’s the slow down your getting. It might be as easy as adding a flag to the tool.
In this file…
sysProxy.command(‘zip’, [’-r’, ‘main.$version.$pack.obb’, ‘$source’]);
sysProxy.command(‘zip’, [’-r0’, ‘main.$version.$pack.obb’, ‘$source’]);
See the 0?
To rebuild the tool.
After that, try remaking your OBB file and test it out.
If that fixes it for you please send the PR.
Thanks for the answer! I’ll try it tonight and if it works i’ll make the PR.
I ended up implementing a two-step loading because i thought the slowness was unavoidable. So the first time the game runs it unzip the files and saves them in the application storage directory. From there i load the files as fast as before.
I wish i had analyzed the code in tools better, it would have saved me a lot of work, hehe.
Btw, i also had a problem when compiling on windows through FlashDevelop: the
expansionReader/src folder does not get copied to the
bin/deps/expansionReader folder, so the
build.xml script returns an error - i had to manually copy it to make it work. Any idea on why this happens (i’ll investigate, if i discover the cause i can also make a pull request).
Cool, yea let me know how it goes. As for the compilation problem, I’m not sure, perhaps this is something in NME that’s not in OpenFL? Maybe it’s as simple as an nmml grammar difference. @singmajesty should be able to spot it out pretty quick I bet.
@thomasuster Hi there! Apologies for digging up this old topic. I’m using this extension in my project - when reading from the obb on Android there is a significant delay when loading sounds and images to the game - I’ve followed the instructions to the best of my ability (and made sure I compiled my zip without compression). I was wondering if there is some way to remedy this delay?
@Tiago_Ling did you succeed with your implementation that mentioned here?
I’ve been using the extension I linked in production for Pakka Pets for a long time. I’ve never experienced to big of a delay, but then again I don’t do a pure “lazy load”. Basically before each scene in Pakka Pets I go into a loading state where each frame I load either a few sounds or a large texture or two. By the time I get into a scene where I actually need them I already have them loaded into memory so it’s as fast as can be.
@thomasuster Thanks for the swift reply, I really appreciate it. Pakka Pets is an impressive piece btw, nice work.
When I first tried the extention I did, admittedly, do a pure “lazy load” but, after realizing pretty quick that this wasn’t the way to go, I did try different implementations (such as attempt to load all assets from the obb on the initial loadscreen of the game and place them into the memory. You can probably imagine how bad that went). Unfortunately I couldn’t find a solution that worked without causing problems with the normally smoothly running project (due to the nature of how the project is built and how assets are applied, using your technique would cause some undesirable consequences).
In conclusion, I surmise the delay is due to the extention having to read the external obb each consecutive time an asset is loaded from it. Could you advise a way I can mod the extention so that it reads only once and unzips all assets at the same time?
I remember the Android documentation saying not “unzip” the OBB and instead just load assets from within it directly.
TBH, did you try checking your compression? Your OBB file can have 0% compression, so it should be just as fast as a normal load if you’re doing it right. The extension I wrote should have a ZIP utility built inside of it you could also try.