0

I am currently looking into the best practices of implementing images and graphics to a new Adobe air project and would like to know which is the best practice in using images . I have a fair bit of experience in Flash with web development and am familiar with a lot of the standard coding issues however as I'm new to integrating data into the mobile domain would like to ensure I'm doing it in the best possible way as the information available is often contradictory to tutorials and existing material online.

I am currently building the project with the following : Adobe Air, Flash CC for Android, testing on a Samsung g6.

I have my main app class and so now have set a class to determine the system Capabilities etc and now have access to the following information to pre plan my layout etc :

dpi : 640

stageResolution : 1440 width x 2464 height.

Adobe Templates for android as3 projects are 480 x 800.

Is it wise to stick with this as a size even though my target app is a higher resolution and to create all images and MovieClips to this size and to integrate a scaling mechanism for lower/higher resolution, or is it common practice to keep to the 480 x 800 template and allow for all resizing options within the code?

Having trawled through a number of links and articles on how the Capabilities doesn't faithfully cover the exact sizes and specifications etc, what dpi is best for images being loaded into the the app?

For background images and gallery images, ie splashScreen embedded images etc, what dpi is best used for maximum quality?

I loaded a 1440 x 2464 *.jpg @72 dpi and it filled the screen perfectly on mobile, I also loaded a 1440 x 2464 *.jpg @640 dpi and couldn't notice any difference so is this effectively not worth worrying about?

Should I just use relative images to size at 72 dpi for everything? Backgrounds, buttons etc, and or resize or bitmapData with them when I add them to the stage.

Example, I create a series of new images in photoshop, set them to 1 cm x 1 cm for a button in the app. I create the same in 72, 160, 640 dpi for variation and to see the difference.

I load them all into my project as is next to each other.

The 72 dpi 1cm x 1cm = Actual size on screen, just over 1 mm.

The 160 dpi 1cm x 1cm = Actual size on screen, just over 2.5 mm.

The 640 dpi 1cm x 1cm = Actual size on screen, just over 1.1 cm.

Clearly the definition and size is relative, the 640 dpi image is almost right to the scale on screen despite it being slightly larger than the size of the image I created, only 1mm but ok, but if I were to plan my layout using cm/mm in photoshop or whatever program, it would fail miserably in regards to layout if I relied on these equations!?

I sourced links like this http://www.dallinjones.com/ whereby it helps give an insight into conversion etc, however it still doesn't add up as it should.

According to the Pixels to Millimeters algorythm:

    mm = ( pixels * 25.4) / dpi;

My equation in as3 amounts to the following :

    1440 x 25.4 = 36,576 / 640 = 57.15mm

The actual screen size of the phone is 63+ mm !?

Also I've seen that vector graphics aren't as effective when being used on mobiles.

I've seen documentation suggesting that vectors need to be set to 'cache As Bitmap' also, is this for all vectors and drawn graphics?

Say I want to dynamically draw a background panel with rounded corners and a gradient that fills the stage.

drawBackgroundPanel(0, 0, stage.stageWidth, stage.stageHeight).

I create the rectangle, draw add backgroundPanel to stage. Do I then have to cache as bitmap also?

Thank you for your help.

clm
  • 1
  • 3
  • Impressive elaborate question. However, classic Flash content will make your mobile application slow and laggy as soon as you need to redraw a portion of screen big enough. In order to create a rich mobile app that runs at smooth 30-60 FPS, you need GPU rendering (no, "use GPU" option in Publish Settings does not make it) rather than classic CPU rendering: something like Gamua Starling Frmework: https://gamua.com/starling/ . Then, for the most part, it's enough that you use textures that get downscaled from their original size. – Organis Mar 20 '18 at 06:04
  • Thanks for the reply. I appreciate that 'direct' is often better and subject to restrictions however in essence, despite the potential for reDraw being problematic, surely vectors, cacheAsBitmap, spriteSheets etc should all help reduce strain, finding out the key benefits when starting a new app are a nightmare due to the conflicting information etc. I'm just desperate to work out and try and establish the functional norm and the best way to implement and use graphics properly so I don't have to suffer further down the line. – clm Mar 20 '18 at 18:27
  • Implementing and pulling data in is easy but there is little recent information helping people use a medium which has had long enough time to establish some basic best practices. I know I'm not alone in pulling my hair out trying to decipher the basics for such an important issue which is imperative to the whole potential design of a project. @Organis – clm Mar 20 '18 at 18:31
  • Well, it's up to you. Still, you don't need DPI. As long as your images are displayed in 1:1 scale (in the pixel sense) with no subpixel offsets to their coordinates, they will be sharp. If you cannot guarantee scale and offset, you will still be fine as long as you set **smoothing** to **true** while images are not upscaled. – Organis Mar 20 '18 at 23:47

0 Answers0