Apparently, the new ActionScript Compiler 2.0 no longer supports the old [frame] metatag which allowed you to add preloaders to pure actionscript projects.
I've verified this IntelliJ - switching the "Prefer ActionScript Compiler 2.0 for pure ActionScript build configurations" makes a difference between the preloader being instantiated and executed, and the main class being instantiated and executed.
Googling yield no result, so is there currently any way around this issue - use ASC2.0 but have the benefits of the Frame metatag?
This still works when using the mxmlc commandline tool;
mxmlc Loader.as -frame=ContentFrame,Main
(produces a 2-frame SWF; the first has no name and contains Loader, the second is named ContentFrame and contains Main).
Related
I'm trying to add a "on fire effect" to our UI.
I am achieving this using BitmapData and PerlinNoise and some others.
The issue comes when anything I do with the BitmapData causes this error:
ArgumentError: Error #2015: Argument error: Invalid BitmapData.
at effects::FireFX/updateBitmaps()...
Something as simple as this will cause the error to show up.
displayBmp = new BitmapData(200, 200, true, 0);
scratchBmp = displayBmp.clone();
In my case, functions like clone() or perlinNoise() or colorTransform.... etc... are causing the crash.
Debugging / Running it under Animate CC works just fine.
PD: Publishing to Flash 10.3, using Scaleform: 4.1.19
Thanks
Scaleform does support the BitmapData API, as of version 4.1 (reference). However, 4.1.19 was the first release of 4.1, and thus the initial release with BitmapData support. You may want to upgrade to a newer version, as there have certainly been fixes to the BitmapData support since its initial release.
The most common reason to get this error, is to not pass a ThreadCommandQueue instance into MovieDef::CreateInstance as the last parameter, and BitmapData operations are used on the first frame. Without an instance of the ThreadCommandQueue, the renderer cannot create the backing for the BitmapData objects within Scaleform. A more descriptive warning was added to Scaleform in later versions.
For ThreadCommandQueue, you generally need to implement this yourself, to integrate properly with your application's rendering code. The simplest multi-threaded implementation would simply store ThreadCommand objects in a (thread-safe) list, when called from PushThreadCommand, and call Execute on the objects at some point during the application render loop.
In later versions of the SDK, there is a class provided called SingleThreadedCommandQueue, which provides an basic implementation that will execute all commands immediately. This only works if you are using Movie::Advance and HAL::Display on the same thread. You can see a more complex version of a ThreadCommandQueue implementation, used in the Scaleform samples from the RenderHALThread class, which defers most of the important implementation to RTCommandQueue.
I have an application written in ActionScript 3 which has to run on all versions of the Flash runtime, including the latest - Flash 18.
One section of my code passes a rather complex object (actually a tree of objects) from AS3 to JS via ExternalInterface.call(). The object has internal cyclic references, and it always used to work, up to and including Flash version 17.
In Flash 18 this object no longer gets passed, there is a very long pause, and a stack overflow is thrown. Upon further inspection (with the debugger and FlashBuilder) I find that the pause is in a toJSON method getting called recursively (obviously not correctly handling the cycles in my object).
The documentation for ExternalInterface states that marshalling is done using XML and in the past I've had problems when I've tried to marshal data that can't be represented easily in XML but would work in JSON, I now appear to be having the opposite issue, and this is quite a backward step if cyclic references in existing compiled applications will now break.
Has anyone else seen this issue?
Do we know if this is intentional, permanent, and/or documented? It doesn't appear in the release notes for Flash 18, so far as I can see.
I have a big actionscript project with several external libraries added to dependencies tab. To optimize compilation time I decided to create a module that will compile all these libraries to a single swc. And that is something I've encounter problem with as IntelliJ seems to ignore linkage settings for these libraries. I set linkage to 'include' so that my swc will aggregate all the code from external libraries but instead it looks like I always end up with 'merged' linkage mode.
If my swc-module has no additional code, then IntelliJ will refuse to compile it at all because it says that there's nothing to compile. If I create a dummy class that will access some classes from external libraries then it will compile an swc but with only mentioned classes. That's exactly what 'merged' linkage mode is.
I don't know if it is me doing something wrong or it is a bug in IntelliJ but it's definitely a problem. So I decided to start with a question on StackOverflow.
When I compile the same project with ant many times it gives a different sizes for each compilation
I added the rsl and more option to mxml it works fine ,but the size is still changed
Please any idea to unify the size
This is not really possible, unless you do some, quite involved post-processing. Below is the list of things I know to change the size between compiles, but it may not be exhaustive:
When you compile pure AS3 project or a project that uses framework:
Resources you embed on variables have their class names generated using the current date in the name.
Flex compiler generates a tag of obscure purpose (can be removed manually, but persists in release builds), which seem to contain a GUID and a compilation time or something similar. It is usually found at the very beginning of the SWF file, somewhere after the rectangle of the SWF dimensions.
In a project that uses framework:
All code generation is suspect to generating inconsistent names, particularly, all bindings will certainly produce different assembly upon each compile. Styles and some other rarely used metadata will cause this too.
Specifically for spark skins, which come as sources rather then compiled libraries - some of them embed resources in a bad way, so you would probably need to compile them into a library and plug it into a project, removing the sources from the source path.
All in all, if you are using pure AS3 project, your task is difficult, but doable (will require following certain conventions and some post-build script that unzips the SWF, purges the compiler-added extra tag and zips the SWF back. But if it is a SWF based on the framework - I'd say the effort isn't worth it, just accept it cannot be done.
[Edit: Short version - how do you properly handle namespace collisions in SWC files if one SWC has fewer classes from that namespace than another?]
I have a rather large Flash application which I'm building in Flash Builder (because coding/debugging in the Flash IDE is... not good) and I've got a ton of external SWC files which I'm linking in to my application. This has worked well so far - the file size is on the large side, but it's a lot simpler than loading in SWFs, especially since I am extending most of the classes in each SWC and adding custom code that way (it's a very design-heavy app.) The problem I'm having is when I have Flash Components, like ComboBox or TextInput, in more than one SWC. Whichever SWC was compiled last will work fine, but the others will fail with errors like the following:
TypeError: Error #1034: Type Coercion failed: cannot convert flash.display::MovieClip#1f21adc1 to fl.controls.TextInput.
at flash.display::Sprite/constructChildren()
at flash.display::Sprite()
at flash.display::MovieClip()
at com.company.design.login::LoginForm()
at com.company.view::Login()[/Users/ken/Workspace/src/com/company/view/Login.as:22]
at com.company.view::Main/showLogin()[/Users/ken/Workspace/src/com/company/view/Main.as:209]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at com.company.view::Navigation/handleUIClick()[/Users/ken/Workspace/src/com/company/view/Navigation.as:88]
I've been researching components, ComponentShim, etc. but I'm running up against a brick wall. I thought it might be the fact that some of the components had their skins modified in the source FLA, so I tried replacing them with the default skins, but that didn't seem to help. How can I ensure that I have the components imported and available to all my classes, yet still be able to skin them and include them in my various FLAs? (I am never creating new instances of them, they are all laid out by my designer.)
I dunno if this will help you, but I had a similar problem with an asset in a SWC library that was the visual representation for a class in my main project. What I ended up doing was having the visual asset be a Flash-created class that extended the class in my project rather than having the same name.
For example, my asset and the class were both com.blah.TitleBackground. To fix the issue I made the visual asset have teh class of com.blah.TitleBackgroundAsset and set the base class for the component to com.blah.TitleBackground. That fixed this particular issue for me. I still have more to wade through, but your post sparked the idea for the solution to get around the name conflicts.
I can't find the detailed fix (apparently, the work email I used at the time was trashing older messages without my knowledge!) but the short answer is to create one FLA that has all the components you want to use in it, set those components (and the ComponentShim) to 'Export for Runtime Sharing'. Then, in your other FLAs, whenever you want a component, drag it from the components FLA library (it should show up in your main library with 'Import for Runtime Sharing' turned on.) Make sure you don't have a ComponentShim in your main library. You'll need the compiled component SWF file in the same folder as your FLAs.
What this does is keep all the component code, including skins, in one central place, so when you compile (be it as a SWF or a SWC, though this problem mainly crops up when using SWCs) there are no conflicts.