« Blogathon, July 26th 2003 | Main | Blogathon is Tomorrow »

OOP vs onEnterFrame

First I must confess my bias: while OOP has its strengths, I often prefer a procedural approach.

For the past few days, I've been going through old experiments, and have found that I just don't like rigid OOP design, especially when it comes to programmatic animation.

Simple things like using a single onEnterFrame, and looping through all instances of a clip each frame instead of a separate onEnterFrame for each clip (as part of an object), can greatly improve performance. This is where I find OOP challenging...how to keep oop structure but only use one onEnterFrame?

I'm toying with a hybrid, and I'm curious what others are doing.

Even if there are improvements in the next player's performance, optimization is still important.

Comments

I'm not sure that that having a central onEnterFrame would violate OOP. One could have a manager class that would notify each subitem to take an action. In fact, this would have an advantage of being able to turn the onEnterFrame off from a central location, certainly not contrary to one of the goals of OOP (having certain roles for certain objects, so changes can be made easily).

In the subclip's initialization, you could have it register to the manager to listen for the enterFrame event, then have the manager call a set method for each one of its subclips.

Perhaps subclip.setPos(x,y) would be slightly slower than going straight for _x and _y, but I'd think the difference would likely be nominal. Then you have the advantage of being able to put a trace in setPos, or alter the way certain clips work outside of the manager.

It's true though, that if you are trying to push the processor, and don't care about flexibility or maintainability, all of this stuff is not necessary.

In my latest experiment (sprites.swf), I have several objects that need to be animated and opted to implement a consistent public interface for all of them and have an objectStack that I can loop through and call the .move() method.

It would be even nicer if Flash supported full objects with inheritence and public / private members so these things could be enforced, but it seems to work for my purposes :)

dylan certainly makes the point. the first thing i'm thinking of after a problem is stated isn't what is procedural or what can be objectized (becuasue i'll be dealing with the objects anyway)... rather i'm thinking where are the portals and worm-holes between these different objects... i would rather deal with interfaces of atomic objects than have to deal with anything procedural... don't get me wrong, procedural code can play roles within objects (at least that's how i look at it)... and i hope no one flames me for chipping the ASBroadcaster here ;), but in the case you mention, you could always have a class manager, just as dylan points out, that registers every instance on creation as a listener... you know the rest

To get the best speed increase you probably need the manager object to do all the enterFrame code, not just trigger a handler in each movie clip (after all, the onEneterFrame simply trigger's a handler in each movie clip, and that's what you're trying to avoid).

Perhaps best to have a manager object with one or more routines built in. Each movieclip can subscribe to a particular update routine and the manager object performs the update for all registered movie clips, without the need to run any handlers in the movie clips. You should get the speed you need while retaining some of the benefits of oop.

I find it often helps when designing object-oriented algorithms to think about responsibility rather than encapsulation - objects should be responsible for their own behaviour.

In this instance, making each movie clip responsible for managing its own enter frame update is too slow, but you should still make each movie clip responsible for asking the manager object to handle the update (why? because then you can change the number and nature of the movie clips without altering the manager). So think of the manager as an object to which movie clips can delegate certain tasks.

I am still trying to educate myself on some of the OOP principles, but I think it would be great if one of you guys made an example FLA to show how this theory could work. I recently made a CD Rom and extensively used onEnterframe to handle fadeIn/fadeOut and this procedure was very intensive on the poor processor, so a more efficient alternative would be excellent.

Flash isn't a strongly typed language, and only supports basic prototype inheritance rather than proper class-based OOP. This means anybody can fiddle with any part of Flash code if they want to, whereas languages like Java are strict enough to deny variable access outside of constructors + methods.

Stick to precedural programming in Flash and the world would be a much happier place. Maybe.

Flash is such a unique beast. The onEnterFrame issue is very interesting to me, and I'm dealing wiht it a lot, lately. Pushing the processor isn't usually my goal, but since most of my work is used in a learning environment (think old macs) I have to keep performance a high priority.

I'm experimenting with using a move function (or object), that loops through the objects that I want to move at that time. Moving all registered objects won't work, because I sometimes have more than one species of registered objects. I run into the same problem with extending the movieclip object. I really want to extend some, but not all.

Kristin:

<<Moving all registered objects won't work, because I sometimes have more than one species of registered objects.>>

it is what makes the broadcast/listen schema--and, generally, coding to an interface--so beautiful. "more than one species", to me, means behavior that the other registered objects do not expose... it means broadcasting an event (method) that is defined for the said "species"

<<I run into the same problem with extending the movieclip object. I really want to extend some, but not all.>>

yep, same as me... we'll have to wait till the next ver of flash to see what kind of blade the MC was put under ;)... that said, i use the #iniclip | registerClass() combo (with attachMovie) to get around it, or extend the mc (after creating with createEmptyMovieClip) inline


Richard Lord:

I find it difficult to understand/agree with the points you make... maybe it's the ambiguity of language--which hasn't the terseness and/or sanctitiy of code--and so like George, i'd appreciate some code

eokyere:

Sorry, I'm very busy and haven't time to write an example for you. What I was trying to say was, if having an onEnterFrame() handler on each movie clip is too slow, why should having a move() handler on each movie clip be any quicker? You're still delegating tasks for each movie clip to perform. However, if instead of the managing object calling the move() handler on each movie clip it just moves the movie clip (i.e. changes the _x and _y properties of it) you are more likely to see a speed increase. You sacrifice some of the benefits of oop for the speed increase, but can still retain some benefits of the listener pattern. Instead of subscribing to receive messages, a movie clip subscribes to be moved.

Kristin:

You could try a more complex registering system, where a movie clip says what messages it wants to receive (the traditional oop way) or what algorithms it wants performed on it (my compromise for speed above) at the time as it subscribes and the manager sends appropriate messages or executes appropriate routines for each type of subscription.

i.e.

manager.addManaged(this, "move");
or
manager.addManaged(this, "fade");

to have the manager move or fade out the clip.

Equally
manager.removeManaged(this, "move");
or
manager.removeManaged(this, "all");

well, rich, maybe when u do find time, you could put your words in code... i don't think you've said anything new... but i'll leave it at that

eokyere

I should qualify my initial statements...it's OOP in Flash that frustrates me :-)

If you are interested in an OOP approach to Flash animation, you might want to take a look at Laslzo Systems (http://www.laszlosystems.com). It offers an XML and Javascript-based language that is object-oriented, and an extensible set of foundation classes for creating RIA's (rich internet applications).

[Full disclosure: I am a Laszlo employee, software architect in their compiler group.]