Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Issue 526: [FEATURE REQUEST] Copy file from application APK to write dir

Author
Message
MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 13th Jun 2013 10:25
Paul ? this feature is essential for me if i want to release soon ...

any hope to see this command soon ?

https://code.google.com/p/agk/issues/detail?id=526
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 13th Jun 2013 10:41
did you copy the file now like that and its to slow?
writeline(out,readline(in))
MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 13th Jun 2013 10:42
yes...
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 13th Jun 2013 13:19
10k lines?!

Well you should only need to copy this to the write folder once, right? Can't you run the copy method as markus said on the first run of the application, then anytime after that you can just access it from the write directory.

MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 13th Jun 2013 13:36
Quote: "Well you should only need to copy this to the write folder once, right? Can't you run the copy method as markus said on the first run of the application, then anytime after that you can just access it from the write directory."


That is what i'm doing .. but reading line by line is very slow (even only if it's the first time) that's why i want a real copyFile command

I have 10k lines by Track for my Racing game ... and i cant wait 2 real minutes for loading that ... (once it is in the write dir it's ok and take 1 or 2 seconds)
Hodgey
15
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 13th Jun 2013 13:56
A copyfile command would be ideal in this situation, but for the time being it might be worth experimenting with the zip commands. You could try making a zip folder, adding your file to that folder, closing it and then extracting it at your selected destination. Not sure how it will compare time-wise to manually reading in the file and then writing it again but could be worth a shot.

Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 13th Jun 2013 14:37 Edited at: 13th Jun 2013 14:39
what? 2 real minutes?
are you sure its a agk problem?
then maybe should paul search the reason why it is slow.
until you have a copy command, maybe you can try write/read your data in
differnet way and not as lines.
MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 13th Jun 2013 17:32
Hodgey : good idea i will zip it in the media folder and will try to unzip it directly to write folder

Markus : between 60 and 120 seconds yes ... only in APK Standalone (when i broadcast with the player i have no problem but it doesn't works the same way and it's normal.). Reading line by line from an APK integrated file is slow (uncompression)... that's why when uncompressed (in write folder) it's 50x faster .. but i don't know how agk handle the file before opening it for the code (temp folder ? or reopen for each access .. ? i don't think and i don't know

I have the same problem on all my android devices (Samsung Galaxy S3, google nexus 10, Samsung Galaxy Ace, Galaxy Tab 8.9)
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 13th Jun 2013 17:51
ahh, i understand what you mean, the problem is reading from
a archive (apk) file.
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 13th Jun 2013 18:51
Just out of curiosity I had to try to benchmark this.
It's pretty slow, but unless you're using massive files it should be reasonable.
In Win 7 it copies at 3mbps (44mb in 14sec)
In Android 2.3 it copies at 0.56Mbps (44mb/78sec)
In contrast, copying or moving a file in Windows 7 of this size is nearly instantaneous for me. On Android 2.3 it copies at ~ 2.5-3.0mbps.
How big is this 10k line file you have?
I'd also like to see even this method speed up.



Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 13th Jun 2013 19:34
That is a pretty cool function. Nice use of byte read/write. I suspect it would definitely be faster than using the readline/writeline functions.

The ReadLine function actually must do a lot of work. It must read the file a byte at a time until the end of string marker (probably just a zero) is encountered. And then it needs to convert the stuff to a string. The WriteLine does the opposite. It's not impossible that the actual engine is using standard file reads and writes.

Using the Line functions requires a lot of memory handling and I wouldn't be surprised if there were memory leaks.

The Byte functions only deal with a single integer variable and would be much quicker and less likely to create potential memory leak issues.

By the way, perversely IMHO, the ReadByte function returns a signed integer and the WriteByte one expects a signed integer as input. This is only apparent when working in Tier 2 and not an issue. In Tier 1, there are no bytes or unsigned anything, everything is an integer (or float or string).

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 13th Jun 2013 19:35
I tried your code naphier in Win7.

Small file:
Time: 0.85s
Size: 3.92MB
Rate: 4.6 MB/s

Large file:
Time: 16.11s
Size: 78.77MB
Rate: 4.889 MB/s

I seem to copy a fair bit faster

Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 13th Jun 2013 21:33
With stand alone APKs Android compresses the media files and accesses them in place when they are read. It doesn't extract your file and then read all the lines, it will extract a bit, then wait for your next readline then extract a bit more, and so on. To avoid this you can trick Android into thinking your file is not compressable. Rename it to a JPG like mytextfile.jpg and then load it using the normal AppGameKit OpenToRead commands and it should be fast, since it isn't having to uncompress the data on the fly. We had to do this for one of the driving test apps on Android.
MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 13th Jun 2013 22:18
Thanks Paul ! It explains everything. An extension like zip will also prevent compression ?
MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 14th Jun 2013 06:50 Edited at: 14th Jun 2013 06:52
Ok i tried it with zip and didn't work :p.. with .jpg extension it's ok but to manage multiple materials OBJ files , i also need to parse MTL and obj files and rewrite to seperate OBJs files (to apply one texture on each part) on the first launch. So i will also have to rename OBJ files to JPG to parse them quickly ? :p not very easy to deal with that .. (a lot of renames etc etc)

So, This is my FIRST need before all others for next version: make AppGameKit to support MTL files (multiple textures in one OBJ file). it will drastically improve loading times (for me). It's possible to use an atlas texture (all in one texture) but need a lot of work to do that for each 3D models (rewrite UVs etc) and there are some limitations due to max texture size to keep a good quality ....

Login to post a reply

Server time is: 2024-11-24 15:32:48
Your offset time is: 2024-11-24 15:32:48