Scaleform best practices

This document provides best practices for asset creation for use with GFx 3.0 and higher.How to Contact Autodesk ScaleformDocument Scaleform GFX Best Practices GuideAddress Scaleform Corporation6305 Ivy Lane, Suite 310Greenbelt. MD 20770. USAWebsitewww.scaleform.comEmailinfo@scaleform.comDect|(③01)4463200Fax(301)446-3199Table of contents1. Overview1.1 General Usage.....aa:aaa:aaa.aaaaaaaaaaaa:aaa:aaaa1aaaaa1.2 Setup Considerations2. Content Creation Memory and Performance Considerations…,……2. 1 Draw primitives1334452.2 Movie Clips2.3 Artwork…2.3. 1 Bitmaps vs Vector graphics23.2 Vector Graphics…2.3.3 Bitmaps.............5557q2.3.4 Animation2.3.5 Text and fonts103.0 Action Script Optimizations123.1. General Actions Script Guidelines口重1看重m.123.1.1. Loops153.1.2. Functions………………153.1.3. Variables/ Properties……,……153.2 Advance3.3 on Clipevent and on events量面面173, 4 onEnterFrame3.5 Var Keyword….aaaaaaa:aaaaaa:aaaaaa:a日.a:.aa.:a183.6 Preaching.193.7 Precache Long Paths203.8 Complex Expressions2040 HUD Development……4. 1 Multiple swF Movie Views224.2 Single Movie View Containing Multiple SWFs234.3 Single movie view244.4 Single Movie view( Advanced)……244.5 Custom HUD Creation without Flash255.0. General optimization Tips…275. 1. The flash Timeline275.2. General Performance Optimization276.0 Additional Reading.28OverviewThis document contains a growing list of best practices when developing Adobe@ Flash@ content foruse with Scaleform GFX30 and higher versions. These practices are specifically geared towardsimproving memory and performance of flash content in games; however they can also be applicablefor other use cases. The content creation section in this document is targeted toward artists anddesigners, whereas the Action Script TM (AS)section is targeted toward technical artists and engineersThe Heads-Up Display hud) development section is a general overview of the possible developmentscenarios for HUD creation. We encourage both artists and engineers to read this section beforedeveloping a HUD system with Flash and grxThis document provides a compilation of a wide variety of information from different sources such ascustomer support requests, developer forum posts, and various flash and as resources on the webGFx can be used on many different platforms(from cell phones to cutting-edge consoles and PCs)and integrated with many different engines, and as a result there are unfortunately no " one size fits allsolutions. Every game and project requires a different solution for optimal memory consumption andperformance(e.g, code tweaks may be required when porting from a high-end pc to a handheldplatform)We have tried our best to provide relevant performance data along with these best practices; however,these results will not be the same for your project, as there are many variables to account for. Werecommend all User Interface(U) work be thoroughly tested and alternative solutions should be stresstested for each use case early on in the Ul development processFlash designers and developers must write code and structure applications in a way that is intuitiveand beneficial to themselves as well as to the other people who are working on the same project. Thisis particularly important in FLa files with many assetsAs it is common for more than one designer or developer to work on a single Flash project, teamsbenefit when everyone follows a standard set of guidelines for using Flash, organizing Fla files, andwriting AS code. The sections in this document outline the best practices for writing as and bestpractices when using the flash authoring tool to create rich media content. Adopt best practices at alltimes, whether a designer or a developer, working alone or as part of a team the following are a fewreasons why learning and following best practices is beneficialWhen working on Flash or As documentso Adopting consistent and efficient practices helps speed up workflow. It is faster todevelop using established coding conventions, and easier to understand and rememberhow a document was structured when editing it further. Additionally, code is often moreWIen portable within the framework of a larger project, and easier to reusesharing FLA or AS fileso Other people editing the document can quickly find and understand As, consistentlymodify code, and find and edit assetsWhen working on applicationso Multiple authors can work on an application with fewer conflicts and greater efficiencyProject or site administrators can manage and structure complex projects orapplications with fewer conflicts or redundanciesWhen learning or teaching Flash and as:o Learning how to build applications by using best practices and following codingconventions reduces the need to relearn particular methodologies. If students learningFlash practice consistent and better ways to structure code, they might learn thelanguage faster and with less frustrationDevelopers are bound to discover many more when they read these best practices and develop theirown good habits. Consider the following topics as a guideline when working with Flash; developersmay choose to follow some or all of the recommendations. Developers can also modity therecommendations to suit the way they work. Many of the guidelines in this chapter will helpdevelopers utilize a consistent way of working with Flash and writing asAreas of possible optimization in Flash are as followsIncrease animation performance by optimizing graphics for fast redrawIncrease computing performance by writing code that executes quicklyIf code runs slowly, it is often a sign that the developer needs to reduce the scope of the application orinvestigate another method that solves the problem in a more efficient way. Developers should identifyand remove bottlenecks, for example, by optimizing graphics or reducing the work done byAction Script.Often performance is about perception. If the developer attempts to perform too much work in a singleframe, Flash doesn t have time to render the Stage, and the user perceives a slowdown. If thedeveloper breaks up the amount of work being performed into smaller chunks, Flash can refresh theStage at the prescribed frame rate and there is no perceived slowdown1. 1 General UsageConsider reducing the number of objects on the stage. Add objects one at a time and takenote when and by how much performance degradesAvoid using the standard ul components available in the Components panel in Flash ).Thesecomponents are designed to run on desktop computers and are not optimized to run in gFX3.3. Utilize the Scaleform Common Lightweight Interface Kit(Clik)components instead1.2 Setup ConsiderationsConsider reducing the depth of the object hierarchy. For example, if some objects don't moveor rotate independently, they don't have to exist within their own transform groupa large user interface is typically best broken into separate Flash files. For example, anMMORPG's trading room would be one flash interface and the life-meter HUd would beanother. On the as side, different files can be loaded through loadMovie or Movie ClipLoaderAPls. These functions enable the application to load only the interfaces necessary at any giventime and free content when no longer needed. Another alternative is to load and unloaddifferent SWF files via C++ APl (creating different GFx Movie view instances)GFx 3.3 supports multithreaded loading and playback. Background loading of multiple Flashfiles will not adversely impact performance if extra CPU cores are available. However, thedeveloper must take care when loading multiple files from CD or DVD, as disc seeking is slowand may significantly slow down file loadingAvoid using Scenes as they often result in large swf filesRealistic amounts of Ul memory used for a game may fall in the following rangeso Simple game HUd overlay: 400K-15Mo Startup/Menu screen with animations and several screens: 800K-4Mo Simple game fully in Action Script with assets(Pacman 700K-15Mo Prolonged vector animation with constantly changing assets: 2M-10M+2. Content Creation Memory and Performance ConsiderationsWhen developing flash content, there are a number of considerations and optimizations that shouldbe followed and implemented in order to get the best performance2 1 Draw PrimitivesDraw primitives(dPs are 3d mesh objects created by gfx to render 2d Flash elements such as agroup of shapes on the same layer. Each draw primitive is rendered independently, incurring asignificant cost. In general, Display performance will tend to decrease linearly as more dPs areintroduced into the scene; therefore it is a good practice to keep the dp count as low as possible. thenumber of draw primitives can be determined via the gexPlayer hud by pressing the(F2) key, whichbrings up the AMP HUD summary screen. This screen displays triangle counts, DPs, memory use andother optimization informationhe following are a few facts to help keep draw primitive count low1. Gradient fills can increase the number of dPs if several of them are used in a shape at thesame time2. Vector graphics with solid fills and no strokes on the same layer are very cheap. Only one DP isrequired to represent any amount of these types of shapes on a single layer, even if thoseshapes use different colors.3. Each vector shape(or group of vector shapes) on its own layer requires one DP4. Strokes are more expensive than fills, unless all strokes are the same solid color5. Each dissimilar(different color) solid stroke on a layer adds one dP6. Empty movie clips do not require a dP; however, a movie clip with objects in it will require theamount of dps dictated by those objects7. Alpha, Blends, and Transparency effects do not affect the number of dPs required; however,they will have an impact on rendering performance.8. Each bitmap/texture on the Stage requires one DP9. Each text field requires at least one DP. Adding a border/background will add one more DPAlthough in most cases all of text glyphs will be rendered from texture with one dP, large textmay end up being rendered as vector shapes with each glyph using is a separate primitive. Ifclipping of vector glyphs is necessary then the text field will use a mask, which adds one moreDP Masks currently have a significant performance cost and clipped text fields will compoundthis penalty2.2 Movie clipsRather than hiding movie clips, it is best to delete them completely from the timeline when notin use, otherwise they may take up processing time during Advance2. Avoid excessive nesting of movie clips, as this will affect performance3. If it is necessary to hide a movie clip then use visible-false rather than alpha-O Makesure you have stopped the animation in hidden movie clips by calling the " stop"functionOtherwise, invisible animation will still take place and affect performance2 3 Artwork2. 3. 1 Bitmaps vs. vector graphicsFlash content can be created with vector art as well as images and gFx can seamlessly render bothvector and bitmap graphics. However, each type has its advantages and disadvantages. The decisionto use vector or bitmap graphics is not always clear, and often depends on several factors. Thissection discusses some of the differences between vector and bitmap graphics to help make contentauthoring decisionsVector graphics maintain their smooth shapes when scaled in size, unlike bitmaps images that canappear box-like, or pixelated, when scaled. But unlike bitmaps, vector graphics require moreprocessing power to generate. Although simple solid-color shapes will usually be as fast as bitmapscomplex vector graphics with many triangles, shapes and fills can be expensive to renderConsequently, heavy use of vector shapes can sometimes reduce overall application performance. Asa rule of thumb, any vector shape that generates more than 200 triangles is probably best convertedto a bitmapBitmap graphics can be a better choice for some applications because they don 't require as muchprocessing time to render as vectors, however, bitmap graphics significantly increase the amount ofmemory required, compared to vector graphics2.3.2 Vector GraphicsVectors graphics are more compact than other image formats because vectors detine the math(points, curves, and fills required to render the image at runtime rather than the raw graphic (pixel)data of a bitmap. However, converting the vector data to the final image is time consuming and mustbe done whenever there is significant change in appearance or scale of a graphic. If the movie clipcontains complex shape outlines that change every frame, animations may run slowly5The following are several guidelines to help render vector graphics efficientlyExperiment with converting complex vector graphics to bitmaps and test how this affectsperformanceKeep the following in mind when using alpha blendso Solid-filled strokes are cheaper to compute than alpha-blended strokes since they canuse a much more efficient algorithmo Avoid using transparency(alpha). Flash must check all pixels underneath a transparentshape, which slows rendering down considerably. To hide a clip, set its visibleproperty to false rather than setting the a l pha property to o graphics renderfastest when their alpha is set to 100. Setting the movie clip's timeline to an emptykeyframe(so that the movie clip has no content to show is usually an even fasteroption. Sometimes Flash still tries to render invisible clips; move the clip off stage bysetting its x and y properties to a position off the visible stage in addition to settingthe visible property to false, so Flash doesn 't try to draw it at allOptimize vector shapeso In using vector graphics try to simplify the shapes as much as possible eliminatingredundant points. This will reduce the amount of calculations that the player has tocompute for each vector shapeo Use primitive vectors including circles, squares, and lineso Flash's drawing performance is tied to how many points are drawn per frame. Optimizeshapes with the Modify ->Shape submenu, then select either Smooth, Straighten orOptimize depending on the graphic in question)to reduce the number of pointsrequired to draw it. This helps reduce the mesh data that is created by the gex vectortessellation codeCorners are cheaper than curveso Avoid complex vectors with too many curves and pointso Corners can be mathematically simpler to render than curves. When possible, stick withflat edges, especially with very small vector shapes. Curves can be simulated in thiswayUse gradient fills and gradient strokes sparinglyAvoid shape outlines(strokes)o Whenever possible, do not use strokes with vector shapes, because doing so increasesthe number of rendered lineso Outlines around vector images have a performance hito Whereas a fill has only an outside shape to render, outlines have an inside and anoutside to render This requires twice as much work to draw a line over a fillMinimize the use of Flash's Drawing APl. It may cause significant performance overhead ifused unnecessarily. If needed, use the Drawing API to draw on a movie clip once. There are noperformance penalties for rendering such a custom movie clip6