[casual_games] re: Flash Local Storage Issue
sonicron at gmail.com
Mon Aug 28 13:05:44 EDT 2006
Zinc is just as guilty as most of the other wrappers when it comes to speed.
It seems to be an issue using the Flash OCX control. The two Flash wrappers
I know of that don't use the OCX control - they wrap the Macromedia
projector itself - run at full speed. They are FlashJester and swfXXL.
FlashJester has minimal support for extended code (joystick support, file
management, etc.) while swfXXL is purely a screen resizer with no support
for additional functions.
Hope this helps!
On 8/28/06, Hal Barwood <hal at finitearts.com> wrote:
> And now I have a Flash question: how's Zinc for Flash speed? When I
> wrapped one of my games into SWF Studio v3 it slowed performance by
> around 50% compared to the native standalone Flash Player. Ouch.
> Dimitrios Bendilas - ZEFXIS wrote:
> > Steven, Hal,
> > Thank you for your answers.
> > The reasons I needed to save data to the hard drive is to store
> > local highscores, player profiles and game options.
> > When I posted here, I was aware that there could only be
> > a workaround and not a "real" solution, since this is a native
> > flash player thing, which you cannot by-pass.
> > Luckily I had already found a solution by Friday evening,
> > which was my deadline - a very strict one too.
> > I really didn't want to switch to SharedObjects, so
> > I tried to see what can be done without leaving the file system model.
> > So, these are my findings:
> > 1. Zinc seems to need a few Kbs in the local storage by default. Even if
> > you
> > create the simplest app with 1 line of code, e.g.
> > mdm.Dialogs.prompt("test");
> > or even only mdminit(), Zinc will have to access local storage.
> > I don't really know why.
> > Fortunately, it needs less than 10K of local storage, which seems to
> > the size the flash player allows by default. So, if you have a Zinc
> > application
> > that doesn't save files on the local drive, the 10K limit is enough
> > for you
> > and the Local Storage Dialogs does not popup.
> > 2. The problem comes when the application needs to save more than 10K
> > session. This means that if you need to save a file larger than 10K
> > the dialog
> > will come up. Of course, there is no way to by-pass this thing if you
> > really
> > need to save more than 10K, since it's a native flash player thing.
> > The only solution would actually be a workaround.
> > 3. Zinc does not only save stuff to the hard drive when saving a file or
> > folder, e.g. with mdm.FileSystem.saveFile() but also when DECRYPTING
> > a file or a string. In my case, that's what was happening. My
> > application
> > didn't save files larger than 10K, and those that it did save (3K,
> > 2K, 8K etc)
> > didn't cause any issue.
> > But the application descrypted several files, one of which was larger
> > than 10K (it was 50K). All others didn't cause any issues, but this
> > was big and Zinc apparently needed disk space to decrypt it, so it
> > actually
> > tried to save data on the hard drive, which was more than 10Kb and
> > this caused the
> > Local Storage dialog to come up, asking for permission to save
> > up to 100K to the local storage.
> > 4. The solution that applied in my case was to divide that file into
> > smaller
> > ones, each one less being than 10K. It was quite easy to do and I
> > have to change the data saving model.
> > Thanks again for your replies!
> > Best regards,
> > Dimitrios
> > ----- Original Message ----- From: "Hal Barwood" <hal at finitearts.com>
> > To: "IGDA Casual Games SIG Mailing List" <casual_games at igda.org>
> > Sent: Saturday, August 26, 2006 11:21 PM
> > Subject: Re: [casual_games] re: Flash Local Storage Issue
> >> My understanding of the Flash security sandbox is -- permission to
> >> create a locally stored object or net access, but not both. If the
> >> game in question is downloaded and playing on a local machine, access
> >> to an LSO is perfectly legit, but Flash never allows explicit access
> >> to the directory structure, right?
> >> One of the major Flash pains is Adobe's idea of changing local Flash
> >> Player settings and permissions by forcing a trip to a web page. Ai
> >> yi yi.
> >> My advice is, structure all your data in a Flash object and use LSOs.
> >> Is there a better way?
> >> Steven Davis wrote:
> >>> Dimitrios -
> >>> You are running into an inherent part of the Flash security sandbox.
> >>> Flash SHOULDN'T permit access to the file system without explicit
> >>> user authorization. The Shared Object feature may be a better way to
> >>> avoid triggering this check or, even better, using server side
> >>> storage via an HTTP POST or a cookie. Java's applet security sandbox
> >>> also should trigger the same sort of security check.
> >>> The big question is... why do you need file system access? I would be
> >>> happy to address this either online or off.
> >>> Steve
> >>> Steven B. Davis
> >>> CEO
> >>> IT GlobalSecure Inc.
> >>> ceo at secureplay.com
> >>> +1.202.742.5936 main
> >>> +1.202.332.5106 direct
> >>> +1.202.345.2151 mobile
> >>> +1.202.478.1743 fax
> >>> secureplay skype
> >>> product: http://www.secureplay.com/
> >>> blog: http://www.playnoevil.com/
> >>> corporate: http://www.itglobalsecure.com/
> >>> To no longer receive email from Steven Davis & IT GlobalSecure Inc.,
> >>> please respond to this email: ceo at secureplay.com
> >>> _______________________________________________
> >>> Casual_Games mailing list
> >>> Casual_Games at igda.org
> >>> http://seven.pairlist.net/mailman/listinfo/casual_games
> >> _______________________________________________
> >> Casual_Games mailing list
> >> Casual_Games at igda.org
> >> http://seven.pairlist.net/mailman/listinfo/casual_games
> > _______________________________________________
> > Casual_Games mailing list
> > Casual_Games at igda.org
> > http://seven.pairlist.net/mailman/listinfo/casual_games
> Casual_Games mailing list
> Casual_Games at igda.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Casual_Games