Coding on Timeline? page 2

35 posts

Flag Post
Originally posted by jasonjie88:

depending on how you code, you would need to re-route variables throughout the code to different classes, (e.g. re-route a boolean recording a keypress to a Player class in platform games, re-routing a variable recording the player killing something to a scoring class, etc.)

In an ideal OO world, the player class never, ever needs to even know that a keypress happened. What I do is have the main game engine listen for keypresses (it’s also listening for pause, mute, etc—none of which have anything to do with a player so I might as well have all of the key listening happen in one place) and, if the left arrow (or whatever the player has mapped to “move left”) is pressed, it then says to the player object, “hey player, you need to move left.” And so the player does what it’s told like a good object.

 
Flag Post

The simple act of using a class doesn’t automatically make it a better system.

Well, no it doesn’t, but admittedly, when you’re making sequels, taking into account you may install new concepts and maybe improve some old systems (i.e. hitboxes, optimization and other such stuff), it would be A LOT easier to install some new classes and change some old ones than to search through thousands of lines of code and find the lines programming the concepts, and then change all of those functions. So my argument is, productivity-wise, it is better, but really at the end of the day your program only really gets benefit if you can optimize it in the right ways and reduce the number of functions.

 
Flag Post
Originally posted by BigJM:

My timeline code will almost neglibly out-perform your abstracted class system any day of the week. The timeline is where boss playas code.

I doubt it.

1) Open a new AS3 project for AIR
2) Make several frames with buttons on each frame
3) Each button tells the movie to goto and stop on another frame
4) Add some static text to each frame
5) Marvel as sometimes when navigating around, weird shit happens (extra objects that shouldn’t be there, missing objects that should be, etc.)

 
Flag Post
Originally posted by BigJM:

My timeline code will almost neglibly out-perform your abstracted class system any day of the week. The timeline is where boss playas code.

I don’t doubt it.

 
Flag Post

Why would the easier way perform better?

An operating system that does nothing but to calculate pi’s decimals is faster than a Windows machine that runs a program for it. That’s just the way it works with computers.

I may be wrong, but timeline code is just a class with a bit of code checking the current frame, Flash just doesn’t show that to you.

 
Flag Post

Flash does all kinds of weird crap with timeline code. I tried to understand it once, and gave up.

I’ll argue that anything that can be done via timeline code can be done just as fast or faster without it. Adobe doesn’t have any “magic” on the timeline. It just hides a bunch of stuff from you — a lot of which is probably unnecessary and just slowing things down.

Based on the existence of the (undocumented) MovieClip.addFrameScript() method, I posit that putting timeline code is similar to a function wrapped in an event listener. That is, I’d suggest that putting the following on the timeline on frame 4:

doA();
doB();
doC();

is the same as:

//in the class
private function doFrame4()
{
    doA();
    doB();
    doC();
}

//somewhere, possibly onLoad
addFrameScript(4, doFrame4);

which would be the same as

//in the class
var frames:Array;
private function checkFrameEvents(e:Event)
{
    if (frames[currentFrame]) { frames[currentFrame](); }
}
private function doFrame4()
{
    doA();
    doB();
    doC();
}

//somewhere, possibly onLoad
frames = new Array(4);
frames[4] = doFrame4;
addEventListener(Event.ENTER_FRAME, checkFrameEvents);

True, I don’t know if Adobe does any compiler-based optimizations, such as directly embedding the functions within the checkFrameEvents, or having a special undocumented onFrame4 event or something. I doubt they do, because they’re Adobe, and because that wouldn’t work for things added with addFrameScript. But even if they did, the performance boost is marginal, and can be tied or outperformed with “class code”.

*I assume that Adobe would use an Array, rather then a Vector, because Vector hasn’t always existed and because Adobe is stupid. If this assumption is correct, then outperforming timeline code is trivial, even if they’ve done all the other optimizations, since the implied cast thing going on is all kinds of expensive. If the assumption is not correct, it’s still totally possible to tie or outperform this system.


Originally posted by BigJM:

My timeline code will almost neglibly out-perform your abstracted class system any day of the week. The timeline is where boss playas code.

This is sarcasm, right?

 
Flag Post

Everything in the timeline gets compiled into a class called MainTineline in a namespace with the same URI as your fla. Script in a frame (other than property and method definitions) gets moved into functions (frame1, frame2, etc.) and addFrameScript is called for each, much like you have there.

The second line was sarcasm; the first wasn’t. Classes by definition create abstraction between objects. This abstraction leads to slower access.

 
Flag Post

Classes by definition create abstraction between objects. This abstraction leads to slower access.

Not necessarily true all the time, just a good general rule. I maintain for this, a good no-timeline-code solution could be created that at least matches the speed of what Adobe does “natively.” I may not be correct. Adobe could have some “magic” behind addFrameScript, but I doubt they do.

 
Flag Post

It is necessarily true but notice that I said neglible. I don’t actually advocate using the timeline for a real AS project; I was mostly just stirring the pot.

 
Flag Post

If you are an animator and use the timeline for that reason, some ActionScript code on the timeline could help you with some of your animation tasks. For example, you could have animations inside containers and require the main timeline to continue after the container’s timeline gets to a certain point.