Ask a question .. images resources of the flash game , How should I load? I use the Loader class, but some people use the embedded resources.Can you tell me in which case use "Loader" class and in which case use "[Embed]"?
It all depends on the game requirements. You have to have in mind that if you use Loaders your game will not work in offline mode (without internet access), which in some cases is critical (i.e. a flash game for a mobile device).
If the final file size isn't a problem, then you should always embed your assets and load only dynamic resources (i.e. ads). You can always use assets libraries to store the resources and to reduce the initial loading time for the application.
Using the embed tag literally compiles that resource into the final SWF output. So it's a matter of how much preloading you want to do and how big you want your initial swf to be. If you are embedding some small thumbnail images or sound files, this may be okay to an extent. But if you embed all of your assets or large assets, well you can figure it out from there, you're going to merge that file size + the size of any other files into 1 file, which is also meant to be your user interface. Keep assets external (for the most part) and dynamically load them in. There might be specific cases as mentioned here in other answers where it is required but unless otherwise dictated, organize your assets and simply load/unload them as needed. The other nice thing about using the Loader class is that is gives you more control over destroying the object from memory than anything else. You can call the unloadAndStop(Boolean CallGarbageCollector) method and directly request the VM to forcefully stop, delete and clean that object up. Anyway hope this clarifies things.
If you would submit your game to Kongregate or Newgrounds, they have strict rules - game should consist of one file. If you host game yourself, you may do as you wish, but take into account that loading needs time and your game find that some resource needed and not yet loaded.
As a rule of thumb, if your game is small, embed everything. If resources are vast and not used simultaneously, think about loading dynamically - this is much harder but allows for faster game start.
Related
I'm developing a little desktop app using Adobe Air and their HTML API.
The app has two window, one displaying a slideshow of images present in a folder on the local machine and the other window allows you to browse those images (one big image and prev/next buttons).
At first for a quick test I just loaded all images from the folder into the DOM of each window and it works just fine until I reach too many images (150+) as they are high resolution JPEGs from a DSLR. Obviously each image is taking a lot of memory and will probably kill the app from overleaking. So I started with optimising the browsing window, instead of loading them all I use just a single tag and replace the .src value with javascript. But this technique is just delaying issues because as I carry on browsing all images the memory usage is growing and growing. Replacing the src of the image does not release the memory used by the previous image. Same thing if I try to delete the image from the DOM and recreate it.
An idea I have but I don't like it too much is to display the image inside a frame loading another HTML file passing it the image src as parameter. Then reload the whole frame, hopefully it can reset the memory usage. Haven't tried yet.
Anyone has an idea of how to handle this?
This is a nice tool for optimizing your Adobe Air application. Adobe Air Tuner:
I'm not familiar with your project; or how it is being implemented. The Adobe AIR has several methods that are accessible to free memory. Which will allow you correctly remove or dispose of your objects. Those cleanups can be found here.
One thing that some people do when creating media players; especially ones with large media. Example:
Lets say your media player contains six pages of content; totaling 1GB of total data. That is a very, very large memory allocation for your project. So rather then call the entire 1GB at once; the first page loads and the second page loads.
The other four pages remain 'uncalled' not dynamically loading. Then the user switches to page two; page three the content begins preloading. The user switches to page three; page four will start to load. But it also disposes of the array or objects created in page one. This way it doesn't affect the application.
Obviously this way is tedious, as your controlling all aspects of the loading. Also it poses issues if your user starts moving to quickly through the pages.
So another possible solution; would be to create thumbnails so the size is drastically smaller. Then load full size images as stand alone streams that can be disposed of without any issues once they leave that area. That way the gallery is stand alone from that.
If you provide some code or some additional details I can possibly assist you above and beyond just interface / memory suggestions of implementation.
I am making a flash game. And I want to know how big is too big for a swf file. Also, Ive been looking at my swf file and right now its at 38.2k. Is the swf file that gets created during debugging, is this the correct size for the file that will eventually be placed on the web.
thanks
Kilobytes is small stuff.
Anything less than a couple of megabytes is fine - once you get above that you might start worrying about loading times and keeping users interested during the preloader, but most portals accept files up to 10MB or so.
Yes, the file is the same. A game of 38.2 kb is pretty small, if you go on Flash game sites they regularly run in the multiple of megabytes.
The SWF is slightly smaller in release mode. The size difference is essentially nothing.
As for a guideline size, this depends on who you are expecting to play your game.
if you want your game to reach a very wide audience keep it as small as you possibly can.
a game without any heavy animation , embedded assets like png files or sound will usually be small.
a good discussion regarding Optimal swf size for flash games here at
http://board.flashkit.com/board/showthread.php?t=788271
The difference between debug and release builds is, according to my experience, some 30-40% in file size (debug version being bigger, of course), which is not insignificant.
Anyways, I think you're safe to assume that anything below 100kb is small enough to be considered an instant download, with no need to use preloaders. However, adding graphical and sound assets to the game will quickly push it up in size, at which point the preloader will probably be a good idea.
I have a project with only a couple of graphics and lots of ActionScript 3.
Anyone have any tips on reducing SWF file size?
First thing to do is turn on the size report (Don't have Flash handy, but should be in publish settings) and take a look at what is really taking up that space. From your description, it should mostly be in actionscript.
If you have any dynamic or text fields with embedded fonts, be careful you are embedding only the subset of characters you need, if you are using bitmaps, make sure you are using appropriate compression (lossless is actually better for 'computery' images, lots of solid colors or simple gradients).
As for reducing actionscript byte size... try the obvious things first: use publish or test instead of debug (Shift-F12 or Ctrl-Enter, not Ctrl-Shift-Enter) to compile release code, double-check that there are not flash built-in functions you can use instead of actionscript, use functions to share code, add local variables to reduce common sub-expressions.
You could try one of avoiding dynamic objects or using them more... each class has overhead for it's description, but I think they may have less overhead for member accesses. I have not tested this either way, though.
Either trim or copy out any methods you are using from other libraries. If you are using Flex... sorry, you are pretty boned :(. Watch out for class references that pull in a whole bunch of unused classes: making a trimmed private library copy is useful here as well.
If you are willing to sacrifice code quality: you could try using class members instead of parameters for deep call heirachies. Look out for inner functions - there are a few situations that can cause bloat. Since names are included (once), even using shorter package, class and member names (not parameter or locals), and literals instead of constants, so only the value has to be emitted, not the member name as well (I am not sure about private members, or in sealed classes).
Graphics should always be the first suspect in cases of file bloat. If you have images, reduce quality or size, or see if a different format yields smaller file sizes. Don't copy-paste vector drawings, put them in a movie clip or graphic and put that in other places. Also, if you have any sort of complicated vector art, smoothing can help reduce their complexity.
Action script can be reduced just as you would reduce any other code. Look for repetitions and other places that can be cut out. But honestly file size is not impacted much by code.
Somewhat related question: Why does my SWF file size not decrease when reducing content?
Runtime shared library
You can do couple of things..
save images as external links and load those dynamically(there is a trade off)
check SIZE REPORT , track down and trim down the large embedded files
Increase the compression of the graphics (such as lowering the jpg quality) and look for parts of your code that are not being used and see if you can trim or refactor.
Is there any significant performance/load time impact if single web page will load, say, 10 identical flash objects? 20? 30?.. any evidential data on sustainability of such kind of setup?
This would be the same flash app, each instance serving its own stream.
There's definitely going to be some overhead in size as there is a certain amount of code that is contained in every swf regardless of it's developer created content.
I'm almost certain there would be speed issues as well, which would see frame rates drop right down the more swfs you add to the page.
To be honest the concept smells a little fishy and i would think there must be a better solution to your problem.
EDIT
Also there is a restriction on having two steams coming over http per domain. Sure you could get around this but it will definitely be an issue.
I found this post which might help. The trick is to use SWFObject to embed your swf files.
I ran into a strange problem today. On the music charts page on Muziboo, I was displaying a list of songs and a playlist on the right. Each song has a small button player done in OpenLaszlo. In firefox everything was fine and in IE (not unusually), the page would freeze for sometime. This would happen once and repeat only if I delete cache and try again. I googled a bit and learnt that it's a good idea to embed give each swf a unique id otherwise the browser misbehaves. I then went ahead and used swfobject to embed the swf files and everything started working great!
Yes, it'll likely nuke the browser if you go too far down that road.
If you want to deal in multiple streams, perhaps combining all your would-be applets into one giant one might work better. It'll certainly offset the serious overhead you'd have with 10-40 of the little blighters.
If this is a music player, you want to have a serious look at doing some JavaScript remoting. It's fairly trivial to control a flash app via JS so you could have standard HTML/CSS controls without having to load up a billion flash instances.
Design-wise this just sounds like a bad idea. You'd be running multiple instances of the Flash player inside a browser, each of which has an individual cost, and the host (in this case the browser) will run all of them on the same thread (with the exception of certain elective asynchronous processes), so you're almost surely going to run into problems of various kinds -- jittery playback, UI blocking, processor burden, memory bloat, consequent instability of the host, etc.
Unless the SWFs are very tiny, and doing very little work, it seems like a design that's just asking for trouble. Indeed you could test such a thing fairly easily; have you run any tests yet? Just curious.
Also curious as to the requirements; we might be able to offer more constructive alternatives if we knew a little more about what you were aiming for. Have you considered simply loading all the SWFs into a single container SWF requiring only a single browser-hosted instance of the Flash player?
I'm looking for a simple way to put up musical "tunes" on a website.
So here's an analogy to explain my question:
Let's say I want to put up a couple of big triangles as a picture on my web page. I can either draw a bitmap and save as GIF/JPG/PNG, put it up somewhere on the internet, and link to it with an element. That works but the larger the picture the more space my image file takes up.
Alternatively, I can use SVG (even though Internet Explorer support is lacking, grr) and use vector graphics which uses very little bandwidth regardless of image size.
In the music world, I can use WAV or MP3 files. Works great -- but if I just want to publish a 1-minute song of simple notes, by knowing the durations & pitches, & don't care that it sounds 100% exactly like a piano or accordion, is there a way to (a) create a file with the song, and (b) put it online in a format that is space-efficient? 1 minute of MP3 usually takes up hundreds of kilobytes.
You could use a MIDI file, this stores durations/pitches etc. as you suggest. You should be able to easily find software to create this type of file. However you will probably find the results sound terrible, as it is very dependent on the synthesiser hardware/software that is available on the end-user's machine.
For what you need this might be reasonable though.
Look into playing music files on websites using Flash.
You can control the Flash through JavaScript calls.
This is currently the "recommended" way to play small audio clips in a website.
For larger media files, look into streaming FLV files using a Flash player.
Hope this helps :)
Check out the MIDI format for instruments.
http://en.wikipedia.org/wiki/MIDI