views:

70

answers:

3

I have quite alots of display objects to manage during runtime, so Im currently using Arrays to manage them. But the problem is I have few many types of displays objects(eg. Tile, Npc and Building) which are basically MovieClips linked to the library. Each display object plays different role where it will be checked on enter frame, a loop.

Method 2 sounds much more faster and extensible however Im worried if it would affect the checking rate of each display object during runtime as the displays:Array grow larger and probably making it glitchy

So which one of the following method is faster+less glitchy and explain why you choose it.

Thanks in advance.

Method 1

var tiles:Array = new Array()
var npcs:Array = new Array()
var buildings:Array = new Array()

function createTiles(){
for(var i:Number=0; i<10; i++){
var t:Tile = new Tile() //Display object in the library
t.x = i * 50
t.y = i * 50
addChild(t)
tiles.push(t)
}
}

function createNpcs(){...}
function createBuildings(){...}

addEventListener(Event.ENTER_FRAME, loop)

function loop(e:Event){
for(var i:Number=0; i<tiles.length; i++){
//some codes
}
for(var j:Number=0; j<npcs.length; j++){
//some codes
}
for(var k:Number=0; k<buildings.length; k++){
//some codes
}
}

Method 2

var displays:Array = new Array();

function createDispalys(){
for(var i:Number=0; i<10; i++){
var t:Tile = new Tile() //Display object in the library
t.x = i * 50
t.y = i * 50
addChild(t)
displays.push(t)
}
for(var j:Number=0; j<10; j++){
//some code
displays.push(t)
}
for(var k:Number=0;k<10; k++){
//some codes
displays.push(t)
}
}
addEventListener(Event.ENTER_FRAME, loop)
function loop(e:Event){
for(var i:Number=0; i<display.length; i++){
if(display[i] is Tile){
//some codes
}else if(display[i] is Npc){
//some codes
}else if(display[i] is Building){
//some codes
}
}
}
+1  A: 

If performance is what you are after, you should be using Vectors instead.

Gregor Kiddie
A: 

What about extending those classes (Tile, Npc, Building), from one basic class - let's say TypeClass, which has an overwritable method getType().

This method returns "None" by default, but by expanding the class and overwriting the method it can return "Tile", "Npc" or "Building"...

With this, it is possible to make switch statements, and basically easier to manage code...

switch (anObject.getType()){
    case "etc"...
}
Aurel300
+3  A: 

Have you considered refactoring method 2 to put the logic inside the class itself?

Ie:

public interface DisplayAsset
{
     void onEnterFrame();
}

// Implementations ommitted
public class Npc implements DisplayAsset {}
public class Tile implements DisplayAsset {}
public class Building implements DisplayAsset {}

Then, your loop remains extensible (just add another DisplayAsset impl.), and fast -- your code becomes:

var displays:Array = new Array();  // As per Gregor Kiddie's comment, use a vector here if possible
// as a vector:
// var displays:Vector.<DisplayAsset> = new Vector.<DisplayAsset>();

function createDispalys(){
   for(var i:Number=0; i<10; i++){
     var t:Tile = new Tile() //Display object in the library
     t.x = i * 50
     t.y = i * 50
     addChild(t)
     displays.push(t)
   }
   for(var j:Number=0; j<10; j++){
       //some code
       displays.push(t)
    }
    for(var k:Number=0;k<10; k++){
       //some codes
       displays.push(t)
    }
}
addEventListener(Event.ENTER_FRAME, loop)
function loop(e:Event){
     for each (var displayAsset:DisplayAsset in displays)
     {
          displayAsset.onEnterFrame();
     }
 }
Marty Pitt
While I appreciate this from an architecture standpoint. Why does it make the code faster, as your answer seems to claim?
www.Flextras.com
+1. correct answer.
back2dos
@www.Flextras.com: It is faster, than `is` and the subsequent cast, for quite obvious reasons. The only slowdown in comparison to approach number 2 is, that you have the call to `DisplayAsset::onEnterFrame`, which should be negligible compared to what happen's in the implementation.
back2dos
as a not though: this is not the strategy pattern. the strategy pattern is about encapsulating the behaviour of an object into a strategy, rather than determining it through numerous flags (as done classically). this is "just" polymorphism, or the dependency inversion principle, if you will.
back2dos
so does that means Martys solution is almost same 'fast' as my current method 2?
Exoot
@back2dos I'm not seeing a cast anywhere, but I can accept that having a long set of conditions to figure out what to do is a lot less efficient than just calling a method.
www.Flextras.com
@Flextras - This method is (only) slightly faster than the Method 2 proposed by the question holder, because we're not doing type comparison. It's also more extensible - which was indicated in the original question as being a consideration.
Marty Pitt
@back2dos - You're correct. I've removed the claim of strategy pattern
Marty Pitt
@www.Flextras.com: I assume, after determining the value's type, it will be cast, to perform the desired operations on it. Not doing so is likely to perform even worse, since untyped access is signifficantly slower.
back2dos
@Exoot: Yes, it is just about the same speed.
back2dos
I dont understand Interfaces much and googling for it doesnt helped me, those are very confusing..For instance in Martys code where should I place the code like building.x += 10 or building.type = "house"
Exoot