Game Code Movieclip Optimization

Quote:

---

Originally posted by jeroen84
I agree.. Just look at the Flash improvements over the last few years. Then look at Directors improvements. Who's on top, do ya think?

---

um... director...

dot syntax is still marginally slower than flash4 syntax;
http://www.fatorcaos.com.br/flash5tests/speed_1.html
download the .fla and run it.
these are the facts;
A. Flash actionscript is over 1000 times slower than java.
B. The majority (by far) of posts in this forum are about or relate to performance.
C. If you had to choose between dot syntax and your .swf running even 10 times faster, what would you choose?
D. Lingo and Actionscript are produced by the same company. How do you explain why one runs super fast and the other is slow?
my 2c
BlinkOk

I noticed onece whilst using an action script viewer (I own the version, on my own swf. Totally legal), that for in loops' targets are saved in the swf as Flash 4 dot notation in Flash 5. FlashMX doesn't do this though.

Try this code, and be shocked at the results:

Code:

---

start = getTimer();

for(x=0;x<100;x++){
        tellTarget("/"){
                nada();
        }
}

st = getTimer()-start;

for(x=0;x<100;x++){
        _root.nada();
}

dt = getTimer() - st;

trace("Tell target:  "+st+"ms");
trace("Dot notation: "+dt+"ms");

---

Quote:

---

Originally posted by Markp.com
um... director...

---

:p Rright.. Director's only improvement has been 8.5 with the 3D stuff. But that's from a very long while back.

Now look at Flash. Flash5 was a major improvement over 4, and MX was a major improvement over 5.

Flash Remoting..
Flash Communication Server..
*continues*

Blink - I would make my game with dot notation, as I'm used to that. Then if my game needed the speed bonus(ex. 3d engine), then I would convert all the dot notations to tellTargets on the end.

Quote:

---

Originally posted by jeroen84
:p Rright.. Director's only improvement has been 8.5 with the 3D stuff. But that's from a very long while back.

---

HAHAHAHAHAAAA!!!!
http://www.macromedia.com/software/d...info/features/
A little more than just a 3d update :)

As I said, Director is better than flash. It can do more, has a more powerful, faster programing language and is generally put together in a more professional way.

Quote:

---

Originally posted by Markp.com
HAHAHAHAHAAAA!!!!
http://www.macromedia.com/software/d...info/features/
A little more than just a 3d update :)

As I said, Director is better than flash. It can do more, has a more powerful, faster programing language and is generally put together in a more professional way.

---

THEN WHY ARE WE USING FLASH??? :doughnut::cow: I mean, if Director is bether (I dont know what it is but I thrust you all :D) then why are we using flash?

Quote:

---

Originally posted by Markp.com
HAHAHAHAHAAAA!!!!
http://www.macromedia.com/software/d...info/features/
A little more than just a 3d update :)

As I said, Director is better than flash. It can do more, has a more powerful, faster programing language and is generally put together in a more professional way.

---

But you surely don’t think directors Lingo is a ‘better’ language to use? Action script is based off standards, where as Lingo has grown organically and is not as structured. Also if you take a look at http://www.mozilla.org/js/language/es4/index.html and http://msdn.microsoft.com/library/de...ng07142000.asp the future of ECMAScript looks very promising, assuming macromedia go down this route.

This "Flash 4 syntax is faster than Flash 5 syntax" thing is blown way out of proportion. A dot syntax action may be 3 times slower than telltarget action or whatever, but the actual difference is something like a 10th of a millisecond. Even if your game is running at 100 fps (which it probably wont) you'd have 10 milliseconds between frames, so 1/10 of a millisecond means jacksh#t...he did 60,000 repetitions of each action in that test to make the difference look significant, you'd never have to do that in a real program. IMHO it's not worth the trouble to use the older syntax.

for you _root bashers out there (=p) try running Ed Macks script like this


start = getTimer();

for(x=0;x<100;x++){
tellTarget("/"){
nada();
}
}

st = getTimer()-start;

rootstart =getTimer()
for(x=0;x<100;x++){
_root.nada();
}

dt = getTimer() - rootstart;

trace("Tell target: "+st+"ms");
trace("Dot notation: "+dt+"ms");



only difference is that that the timer does not work off of the tell targets timer.

overallstart = getTimer()
start = getTimer();

for(x=0;x<100;x++){
tellTarget("/"){
nada();
}
}

st = getTimer()-start;

rootstart =getTimer()
for(x=0;x<100;x++){
_root.nada();
}
dt = getTimer() - st;
/*dt = getTimer() - rootstart;*/

totaltime = getTimer()-overallstart

trace("Tell target: "+st+"ms");
trace("Dot notation: "+dt+"ms");
trace("Total Time: "+totaltime+"ms");

If speed is a primary concern, look at the visual aspects of the site. In most cases the majority of speed bottlenecks occur when attempting too many (or too complicated rendering tasks.) Optimizing the visual can achieve significantly greater gains than a slight improvement in code processing.

For optimization tips, see Streaming and file optimization techniques for Flash Player.




Some items to consider: When possible, try not to manipulate long strings. Break the strings up into small pieces, run the string operations and concatenate the result into a final string for output. The smaller the string the faster the operation will complete. This should also be a consideration with incoming XML data. Large amounts of XML should be broken up before loading into Macromedia Flash if possible.

If manipulating a lot of data in the client, consider using the server to prefilter the data that client actually sees. Server side processing will be faster, eases the processing burden on the Macromedia Flash Player (and the viewer's CPU) and will become increasingly important as the audience for low-memory portable devices such as PDA's and cell phones increases.

Avoid lengthy scripts that may prevent the user from interacting with the content. If it's necessary to process a lot of information, considering breaking the processing into chunks and distributing the task across a series of frames. One frame can do the initial calculation, set up the necessary variables, then finish processing and rendering the visuals. In the next frame pick up those variables, perform more calculation, then again allow the frame to process and render. This type of "distributed processing" may be more difficult to write and debug, but will insure a more consistent experience for your users.

On a similar note, there may be simple scripts that are being evaluated on every frame. Consider if it might be possible to run these scripts once, save their results and call them when needed instead of rerunning the script every time.

If you're controlling a large number of movie clip instances using ActionScript, consider how many times you might be repeating the same routines or resetting the same variables. Can that information be broken out into a single custom Function? Is it possible to use a function to calculate that information once and pass it back to the clip instances instead of processing the function multiple times?

For Function details, see the definition of Function in the online Flash Dictionary

In some cases it may be possible to achieve faster script processing by using deprecated Macromedia Flash 4 ActionScript syntax. That might achieve an immediate goal of faster code processing. But keep in mind that deprecated syntax is deprecated for a reason. There is no guarantee that the underlying mechanisms used to achieve that speed will be around in the next revision of the Flash Player, and an extensive recoding might be necessary.

Note: Macromedia Flash Player 6 includes signficantly improved ActionScript performance, eliminating virtually all the cirumstances in which it would be necessary to use Macromedia Flash 4 ActionScript syntax.

Bitmaps are fixed-resolution images. They look best when one pixel of source imagery exactly matches one pixel of screen display. Because SWF streams and scales, it's rare to have this type of one-to-one correspondence. This means you're asking the computer to create new screen pixels from groups of source pixels and draw them onscreen every time the playback moves to a new frame. Bitmap-heavy projects can be slower to redraw because of this. Make user of vectors and bitmap fills whenever possible to avoid this.

Also, it may seem simple to mention it, but any item used more than once in the SWF should be inside a symbol. This includes bitmaps, imported vector art and art created in Flash.

Looping: tight loops can be problematic. Give the player a chance to break out of the loop so it can process other actions.

Minimize simultaneous streaming whenever possible. Multiple streams cost processing power and bandwidth.

If multiple streams of audio are necessary or multiple SWF's must be loaded use a preloading technique at the beginning of the movie. This costs more time up front, but at that point it's possible to let the viewer know that something is happening. Later in the movie a lag might be interpreted as a system problem or may lose the viewer's attention.


www.macromedia.com

More tips here www.level7.no/forum