Hi
@atilim @ar2rsawseen et. al.,
While I appreciate the effort and thinking behind encrypting the image and audio assets for a project, the default encrypted export of a project using 2013.09-p1 has totally broken my apps that rely on using UIWebViews (and sometimes UIImage) to load various viewports.
While the Gideros engine now decodes encrypted assets for its rendering engine, the iOS runtime has no idea what to do with the encrypted assets. It just thinks they're invalid. Oops.
While I "could" just copy over my unencrypted assets after an export from Gideros Studio, it does become trickier when my more complex projects use *BOTH* the Gideros rendering (graphic/audio) engines as well as the stock iOS APIs for display. The "encrypt all assets" option just makes life more difficult in the management of the development pipeline as well as the QA process.
Would it be possible to have an additional check-box, so that instead of:
[ ] Encrypt code and asset files
… we have instead ...
[ ] Encrypt code files
[ ] Encrypt asset files
so I can have the luxury of encrypting my code and NOT have to encrypt all my assets as well?
Thank you for your consideration.
Best,
- Ian
Comments
https://deluxepixel.com
although i don't need encryption, just wanted to mention that special endings and so seem to be a bad solution.
Likes: OZApps
Fragmenter - animated loop machine and IKONOMIKON - the memory game
This is a rather tricky situation...
Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
Cool Vizify Profile at https://www.vizify.com/oz-apps
Probably marking files in gproj xml file would be the correct solution, but separating lua and asset encryption checkboxes could be much faster one
We will discuss it internally more
I can still manually copy my assets over that don't need encryption if I need a mix of encrypted and non-encrypted assets. For a bigger release, I'll leave it up to your collective expertise. (-:
Best,
- Ian
Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
Cool Vizify Profile at https://www.vizify.com/oz-apps
- Ian
The Encrypt/Decrypt would be an additional API available to LUA in Gideros. The reason for this is not just encrypting the source alone (I think this is where you are stating the chicken-egg issue) in fact this could be used for things like
1. High Score tables that are otherwise plain text files
2. In-App/store purchases that need to be written somewhere to indicate as purchased
it can even be used further to incorporate @ianchia's suggestion, the API can be
So if the users are rendering the textures to disk, they can be encrypted and saved rather than simple bitmap dumps.
And to your second question, salt could be the password or whatever, but IF there is a standard salt used in Gideros, then any and every file that is encrypted can be decrypted as the standard salt is used. So yes there are several ways to pass this salt in the code which itself would be encrypted. We are talking about two levels of encryption here,
1. The standard Gideros encryption that encrypts the lua bytecode
2. The asset encrption that is handled by the user for files that are not in the RESOURCE folder of the app and are in Documents or tmp etc.
Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
Cool Vizify Profile at https://www.vizify.com/oz-apps
It's very limiting and ineficient to work only with the file system. With the option to load also resources from memory it would be possible to make your own decryption algorithms, make textures and sounds in real-time....
Something like in this thread:
http://www.giderosmobile.com/forum/discussion/1102/loading-images-from-memory