I have a few projects with flash that i'd like to turn into apps for mobiles, I started reading adobe air and i've noticed that it uses back some things like inframe action script, something that I have not done since as2.
Is there a way to load scripts and classes like a normal flash file?
If I have a noncomplicated swf, is there a way to migrate it easily into adobe air for android and iOs?.
I've been struggling to find examples of adobe air projects, does anyone have a tip for this?
It is easy. I have converted 30 games to run on iOS and Android. The biggest problem was that they were in AS2 and had to be converted to AS3 first. If your uncomplicated swf projects are in AS3, and developed using Flash Pro, then just change the publishing output from swf for a web page to iOS pr Android. Android would be easier to start because you don't need to get an Apple developer account, create a certificate and provisioning file. With Android you can create a certificate right in Flash Pro. You test publish on your pc or mac first. When you are ready to test on a device you create an ipa (iOS) or .apk (Android).
Yes, there are a lot of screen sizes out there. But you know how you can create Flash in a web page so that it will resize with the page and keep its aspect ratio? Well its the same on mobile - it will resize to fit whatever mobile screen it displays on. Most likely your game is in landscape orientation. Just keep it that way and test it on whatever device you have (an iPad would be good because that aspect ratio or 1024 x 768). Actually, we kept the stage to 736 x 552 and that fit on any screen out there. On tall (wide) screens like the iPhone 5 & 6 you will have space on the sides, but so what.
Just give it a shot and you'll see how easy it is to write an app for both platforms at the same time. And you don't even have to own a Mac (you only need one to upload your completed app to the store, but you can rent time on one and log into it for 10 minutes to do that.)
There's no "how to" when porting a Flash project to Ios or Android. It's the same technology so it's compatible in theory. You can simply compile and publish and you'll get a Ios and Android app in most cases. Now there's 3 major problems that probably 100% of Flash projects will face when publishing for mobile and in probably 99% of cases those problems might imply recreating the whole thing from scratch.
First problem: Sizing and Density. So many phones/tablets sizes and density, chances are your Flash project doesn't have a single line of code dealing with that and as a result your app won't display correctly across any mobile devices. You'll have to put together a big piece of code to handle that and make sure it doesn't break anything in the original project. Good Luck with that.
Second Problem: Performance and memory management, I'm yet to see a Flash project that doesn't systematically waste CPU and memory constantly. That's no problem for a Flash project except when publishing for mobile: can we still waste CPU power? NO, can we still waste memory: NO. You'll have to go through your entire Flash project and optimize everything to not waste CPU and memory. Once again Good Luck with that.
Third Problem: assets. Did you use a bunch of MovieClip here and there? Well no more on mobile unless you want your app to lag and drain the battery down and make the user experience as bad as possible. All assets have to be optimized for mobile, the right asset, the right type, the right size or else ... lag and bad experience. Here again Good Luck with that.
And this is just a small run down of the problems you'll be facing. You will spend probably hundreds of hours trying to port that Flash project to mobile and at the end it will still be running bad anyway. Chances are you should just start over.
EDIT:
Simple Guidelines:
render mode: usually "gpu" (very efficient with bitmap) but "cpu" is also possible (you get more CPU power but less bitmap display efficiency) and also "direct" if you want to use Stage3D (more complicated).
Display: usually bitmap and only rarely vector. Don't oversize them and don't undersize them either. Reuse as much as possible (saves memory and battery)
Handling sizes and density: scaling your content is the easy way but not the less efficient one, as long as your bitmaps are of good quality you should be able to get a good resolution in most density and size. Because there's so many different sizes out there you'll decide if you want your content to fit any size or to display as much as possible while filling the side gaps. AIR/Flash has no built-in system for handling that so you'll have to create your own or to find something open source out there that can do that. Basically you have a content that is n x n and it needs to display on a mobile screen that is n x n, you calculate the scale factor and scale your content and center it.
perf, memory, battery: reuse object as much as possible. If there's a bitmap that you'll use often don't get rid of it just reuse it. If you reuse you don't need more CPU, don't need more memory and don't need more battery.
how to get perf: displaying something and running code, that's the 2 things that will slow down the app so optimize both and test often. Maybe reducing the quality of some bitmap will boost your perf. maybe optimizing your code in some places will get you a few more fps, etc. This is a per project try and test.
Related
I plan to publish my unity game (a simple 2d game) on Android, Web and ios.
So, when I finish my project after testing in the web player, what do I have to consider
when publishing to all the platforms?
If my game is dimensions 900 px hight and 400 px width, will it fit in all screens when I publish
it for iOS and android.
Do I need to change some things?
I think this post might be of use to you: http://answers.unity3d.com/questions/660799/scale-camera-to-fit-screen-size.html
Overall, it really depends on how far you go. The easiest route to go would be letter-boxing. Keeping your game area the same size and then fitting the camera to the aspect ratio at start-up.
Obviously, this is a pretty common issue people come upon when porting their games, so there are tools made. I've never used it, but AspectRatioEnforcer looks like a pretty simple tool that will ensure your game is playable on any platform.
After implementing something, its always good to test it in the Unity editor, switching resolutions around and seeing what happens.
I am building an android application with Adobe Flash cs6 and Adobe AIR for the first time. Initially it looked good but later I faced a lot of problems. What I have till now is more of movieclip and less as3 coding. My app scales automatically according to different screen sizes. However since there are more movieclips my app somewhat lags in Kindle Fire. My question:
1. Do I need to convert my movie clips to Bitmaps or something? How is that done?
2. While converting to bitmap, do I need to specify width and height of the movieclips? Doesnt it get scaled automatically acc. to screen size?
Well, I am new to actionscript, AIR and stuff... so any help would be appreciated.
All display objects have 'cacheAsBitmap' and 'cacheAsBitmapMatrix' propertiues that help with performance, but only for certain class of objects (primarily those not frequently changed).
More info: Caching display objects
Also, make sure you have HW acceleration turned on for maximum benefit, especially on mobile: HW acceleration
I am building a mobile application that will target iPhone/iPad and Android phones. The application will involve users taking photos and uploading to my server and later on the users will be able to look at those photos on their mobile devices (although not necessarily their own photos so an Android user might be looking at a photo taken with an iPhone).
Which sizes should I save the photos to be able to cover the most use cases? iPads are 1.333 W/H, most mobile phones are 1.5 or 1.333 W/H with some rare 1.666 W/H. Specifically:
iPad: 1024x768, iPad3: 2048x1536, iPhone and some other phones: 960x640, 480x320, 800x480.
To be able to keep it manageable, I need to decide on a few certain image sizes and save the photos in those sizes. I am not really looking for help on the technical side. I can do image scaling on the server side etc. I am looking for recommendations / best practices / lessons learned about image sizes before I go too far into building it.
Which sizes should I save the photos in to cover the most use cases?
Do you recommend any client side scaling before uploading to server to save on transfer time (for example scaling down 2048x1536 iPad photos) or should I always transfer originals?
How should I handle incompatible image sizes (showing a picture taken with an iPad on an Android device for example)? Should I pre-cut those images on my server before sending to client or should I let the client phone handle image resizing?
There is also the issue of UI. There will be other things on the page other than the photo maybe a button or two for navigation. Should I go for something smaller than the full screen size while keeping the same aspect ratio when saving pictures?
I know some of these questions don't have one answer and the answers are relative but I wanted to get some opinions. Thanks.
For Android, I think the best place for you to start would be here, it has a lot of information including standard screen sizes and how to display images while keeping them in the best possible quality.
http://developer.android.com/guide/practices/screens_support.html
I'd also suggest doing as much image manipulation as possible on your server. Images are a pain to work with on Android due to memory constraints and fragmentation. Two phones may store pictures taken the same way with different orientations, and there is no simple way to handle rotations, though it can be done (thankfully, I've yet to encounter a phone that incorrectly records Exif data, but I wouldn't be surprised if they existed...). The more you rely on the phone to do, the more chances you have for error due to manufacturers putting wrappers around and otherwise customizing how it handles media.
As for how to display, ideally if your back end is already doing a bunch of different resizes, you can include your screen density when you request the images and send the best size based on the dev guide. If you want to keep differences to a minimum, at least support med or high density for phones, and extra high density for tablets.
Just my two cents, I'm sure you'll have a lot of opinions. Good luck.
I don't have a full answer for you, but I do have some thoughts...
1) I'd suggest reducing the image sizes before uploading. If I were using your application and I had to upload a 4 meg photo, everytime I wanted to use your application, I'd probably pass. And as we venture forward, we're hitting much better technology in terms of camera phones; Nokia has released a 41 megapixel camera, which I'm guessing will create rather large images. Users having to download a 4-6 MB image is also not a great idea. Just some thoughts from a user point of view.
2) I wouldn't cut the images. You don't necessarily know what parts of the image aren't important, so how would you know where to crop it? Let the phone size the pictures accordingly and rely on the ability to zoom into pictures to see things at a larger size.
3) You could try to make a UI that hides buttons. If you have something really simple (like just going forward or backwards) you could rely on gesture controls (swiping) to move around your application. You can implement sliding drawers and menus that take up space temporarily, when in use, but give you the space back when you want to look at the main content (pictures, in your case). I've typically found that hiding buttons doesn't work well and people seem to want/search for buttons that let them navigate, but the Android gallery works just fine with menu + swiping only, so who really knows.
Long version:
I have a very particular issue. I'm a multimedia artist working at the moment together with an animator - we are trying to create an interactive animation that I want to make available online as a website and as free app on the App Store and the Android Market.
But here's the key problem I am faced with now.
The output video of the actual animation will be massive in resolution - probably something like 4 or more times the HD resolution, but it's for a reason. The idea is to let the viewer only watch a part of the video at one time - like when panning around in Google Maps or any other canvas-like view (eg. MMORPG or strategy computer games). So you only see a part of the whole image at one time, and then you can move around to see what's "behind the corner".
So the animation would be a Google Maps-alike canvas (panning and perhaps zooming if there's enough time to implement it) but with video instead of images.
The big problem that comes up is performance. I was thinking that the best way to make it run would be to scale down the video for different devices accordingly. But then even just considering desktop computers for now - scaling down to 720p for HD screen means there is in total of about 4 times 720p in resolution, which is probably too much for an average computer to decode (Full HD is quite often already problematic) - and the output resolution would be more than the 4K standard (5120 by 2880, whilst 4K is 4096x2160). Anyhow, that is unacceptable.
But I reached the conclusion that there is really no point in decoding and rendering the parts of the video which are invisible to the user anyway (why waste the CPU+GPU time for that) - since we know that only about 1/6th of the full canvas would be visible at any given time.
This inspired an idea that maybe I could split the output video into blocks - something between 8 to 64 files stacked together side by side like cells in a table, then have a timecode timer playing in some variable and enabling the video-blocks on demand. As the user drags the canvas to the visible element it would automatically start the playback of the file at the given timecode read from the global variable. There could be some heuristics anticipating users movement and prematurely activating the invisible blocks in order to remove any delay caused by seeking within video and starting the playback. Then blocks which are no longer visible could deactivate themselves after a certain amount of time.
So my first attempt was to try and see what are my choices platform-wise and I really see it comes down to:
HTML5 with JavaScript (heavily using <video> tag)
Adobe Flash (using Flash Builder to deploy the apps to all the different devices)
And HTML5 would really be more preferable.
So I did some research to see if it would be at all possible to even synchronize more than one video at a time in HTML5. Unfortunately it's far from perfect, there are two available "hacks" which work well with Firefox, but are buggy in Webkit (the videos often get out of sync by more than a few frames, sometimes even up to half a second, which would be quite visible if it was a single video split into blocks/segments). Not to mention the fact that I have not even tried it on mobile platforms (Android / iOS).
These two methods/hacks are Rick Waldron's sync as shown here:
http://weblog.bocoup.com/html5-video-synchronizing-playback-of-two-videos/
And the other one, also developed by Rick is the mediagroup.js (this one doesn't work in Chrome at all):
https://github.com/rwldrn/mediagroup.js
My test here: http://jsfiddle.net/NIXin/EQbAx/10/
(I've hidden the controller, cause it is always playing back earlier than the rest of the clips for some reason)
So after explaining all that I would really appreciate any feedback from you guys - what would be the best way of solving this problem and on which platform. Is HTML5 mature enough?
Short version:
If I still haven't made it clear as to what I need - think of a video zoomed in at 600% so that you can't see everything (some bits are off screen) and you need to pan around by dragging with your mouse (or flicking your finger on mobile devices) to see what's going on in different places of the video. How could I do that (have the video run smoothly) across platforms, while retaining the high quality and resolution of the video?
Thanks a lot, let me know if you need any more details or any clarification of the matter.
I'm making a flash game this week, it needs to be compatable with both PC browsers and Android devices.
I have no problem making two slightly different versions of the game, one optimized for PC and the other optimized for mobile devices. I'm just wondering if there's anything in particular that I should keep in-mind when I'm building the first PC edition of the game, I don't want it to be too difficult to port the game over to android.
One thing that I'm concerned about is the screen size/stage size, should I have the game adjust it's self to fill the whole client area (like a youtube video in full screen) with a dynamic width and height?
Is there anything else that I should be aware of before I start on this? Like specific flaws in the android deployment of flash.
Thanks for your advice on this, it's much appreciated.
There were more number of restrictions when i started developing flash apps for android.
We need the device's processor at least 1GHz [This i am not aware of current situation , coz i am a little busy with xCode]
Screen resolution always plays more role in troubling you. For this instead of using screen size as reference , use the aspect ratio. Use flash.capabilities class's screenResolutionX and screenResolutionY and make your game objects resize them accordingly