Hey Dimitrios, I know this might be covering something you already
understand, but thought to say it outloud just in case. An object lives as
long as there is reference to it in memory.
So, in this scenario below "obj" lives on even though I've tried to delete
the original reference to it ("tt" is Xray's trace method):
var obj:Object = new Object();
obj.prop = "here";
var a = obj;
var b = a;
tt("all: obj/a/b", obj, a, b);
delete obj;
tt("delete obj: obj/a/b", obj, a, b);
delete a;
tt("delete a: obj/a/b", obj, a, b);
delete b;
tt("delete b: obj/a/b", obj, a, b);
//++++++++++++++++++++++++
Which traces out
//++++++++++++++++++++++++
(41) all: obj/a/b:
prop = here
prop = here
prop = here
(41) delete obj: obj/a/b: undefined ::
prop = here
prop = here
(41) delete a: obj/a/b: undefined :: undefined ::
prop = here
(42) delete b: obj/a/b: undefined :: undefined :: undefined
With a tile based game and all the possible references you're probably
running, you might have to take a closer look at how objects are being
destroyed for garbage collection. You can easily see if they're still alive
using xray as well as delete them at runtime using the execute panel with
xray to see if that helps your memory issues a performance. Also, try
changing the visibility of your movieclips at runtime with Xray or movie
items off stage one at a time at runtime to see who's hoggin' the CPU etc.
Check out the video on the Property Inspector for xray for working with
objects/movieclips at runtime:
http://labs.blitzagency.com/wp-content/xray/videos/tutorials/indexFlash.html#Overview.propertyInspectorOverview
On 12/15/05, Dimitrios Bendilas <[EMAIL PROTECTED]> wrote:
>
> Hi Cedric,
>
> Thanks for answering.
>
> This is a puzzle game, so tiles do not dissapear outside
> the stage. They are removed with removeMovieClip when
> necessary. There are 20-35 tiles on the stage at the same time.
>
> Each tile is a movieclip with 10 different frames and each frame
> has another movieclip inside, consisting of another 9-10 frames.
> And then again each of the latter frames has a movieclip with an
> animation.
> At any given time a tile is static and sometimes the (last mentioned)
> animation plays. Even without the animation though, the game used
> to slow down.
>
> Everything in a tile is a vector graphic and the "mother" tile movieclip
> has cacheAsBitmap = true.
>
> I have disabled (I don't load them at all) all sounds intentionally
> and the memory still jumps up.
>
>
> Dimitrios
>
> ----- Original Message -----
> From: "Cedric Muller" <[EMAIL PROTECTED]>
> To: "Flashcoders mailing list" <flashcoders@chattyfig.figleaf.com>
> Sent: Thursday, December 15, 2005 2:26 PM
> Subject: Re: [FlashCoders] game slowing down - eventListener
>
>
> > how do you generate the tiles ?
> > are they removed (removeMovieClip) when going outside the boundaries of
> > the visible area ?
> >
> > because such memory size must have something to do with bitmaps or
> > sounds ....
> >
> > ??
> > Cedric
> >
> >> Thank you for the suggestions Hans.
> >>
> >> I'm pretty sure I've taken care of all listeners
> >> and intervals and destroy them before I delete
> >> an object.
> >>
> >> The memory when it's running slower 6-7MBs
> >> more than when running fast. (46MB -> 52MB)
> >>
> >> I've tried digging in with xray before, I guess
> >> I'll do it again.
> >>
> >> Any other thoughts anyone?
> >>
> >> Dimitrios
> >>
> >>
> >>
> >> ----- Original Message ----- From: "Hans Wichman" <[EMAIL PROTECTED]>
> >> To: "Flashcoders mailing list" <flashcoders@chattyfig.figleaf.com>
> >> Sent: Thursday, December 15, 2005 1:39 PM
> >> Subject: Re: [FlashCoders] game slowing down - eventListener
> >>
> >>
> >>> Hi,
> >>> using the delegates itself should not lead to problems i think, at
> >>> least i did some tests with this and garbage collection, and i didnt
> >>> need to do anything special to delete delegates or something. One
> >>> instance where problems might occur is for example fwhere you use
> >>> Key.addListener Mouse.addListener etc and you dont remove these
> >>> listeners properly. If the memory usage when the game is running
> >>> slower doesnt really differ from when its running faster, you might
> >>> wanna delve into your program deeper with a tool like xray or
> >>> something.
> >>> Another option would be to disable parts of your engine ofcourse to
> >>> try and narrow it down.
> >>> tough one, i'll take a look at your engine when i have the time,
> >>> thanks for the link!
> >>>
> >>> greetz
> >>> Hans
> >>>
> >>>
> >>>
> >>> At 11:39 AM 12/15/2005, you wrote:
> >>>> Hello Hans,
> >>>>
> >>>> I've been testing the game with the taskmanager open for
> >>>> several hours.
> >>>>
> >>>> I'm not using a textfield to debug anything at the moment.
> >>>>
> >>>> The memory is going up, but not consistently. The game has many
> >>>> backgrounds and tilesets (complete themes) but I use only one of each
> >>>> theoughout my tests, to keep the parameters minimum.
> >>>>
> >>>> Sometimes the memory adds up 2MB, for no apparent reason
> >>>> when a level is finished and the game moves to the next level. And
> >>>> other
> >>>> times (which is more often) the memory does not increase from level
> >>>> to level.
> >>>> Also, during a level sometimes there are a few KBs added.
> >>>>
> >>>> I'm thinking that maybe objects are not garbage-collected because of
> >>>> the Delegates.
> >>>> I think this has been discussed before, but I can't recall a
> >>>> definate answer
> >>>> if this is a problem and what is a possible solution.
> >>>>
> >>>> The framework is not open source and it's not a commercial product
> >>>> (at least not yet).
> >>>> If you like, you can see a game I built with it at
> >>>> http://www.total-eclipse.gr/academy-of-magic-word-spells/
> >>>>
> >>>> Dimitrios Bendilas
> >>>>
> >>>>
> >>>> ----- Original Message ----- From: "Hans Wichman" <[EMAIL PROTECTED]>
> >>>> To: "Flashcoders mailing list" <flashcoders@chattyfig.figleaf.com>
> >>>> Sent: Thursday, December 15, 2005 12:11 PM
> >>>> Subject: Re: [FlashCoders] game slowing down - eventListener
> >>>>
> >>>>
> >>>>> Have you tried opening the taskmanager to see if your memory is
> >>>>> hogging?
> >>>>>
> >>>>> The game im working on slows down as well, but this is simply becoz
> >>>>> im printin debug info to a textfield (will be replaced with xray
> >>>>> ;)) and this takes longer to update as the contents get bigger. A
> >>>>> game should not slow down, no matter the approach u take.
> >>>>>
> >>>>> As a side note is it a commercial framework/opensource etc?
> >>>>>
> >>>>> greetz
> >>>>> Hans
> >>>>>
> >>>>>
> >>>>> At 11:03 AM 12/15/2005, you wrote:
> >>>>>> Hello everyone,
> >>>>>>
> >>>>>> I have built a big, complex framework for creating 2D games in
> >>>>>> Flash.
> >>>>>>
> >>>>>> I have developed 2 large projects based on it and I'm experiencing
> >>>>>> a slow down as the game progresses. A while after you begin
> >>>>>> playing, things start to slow down and in 20-30 minutes the game
> >>>>>> is no more fun to play as it becomes much slower. They are both
> >>>>>> tile-based puzzle games. I'm using Flash 8 and FP8.
> >>>>>>
> >>>>>> The framework is written in AS2 and it uses a callback system
> >>>>>> for communication between classes (e.g. tileManager.onEvent =
> >>>>>> Delegate.create(this, ....))
> >>>>>>
> >>>>>> The use of Delegates is very common throughout the framework. I'm
> >>>>>> using the Delegate
> >>>>>> version that supports parameters too, so I often pass complete
> >>>>>> instances of complex objects
> >>>>>> as parameters.
> >>>>>>
> >>>>>> I have tried to use .destroy() on everything I can, so that
> >>>>>> objects get deleted from memory.
> >>>>>>
> >>>>>> Do you think the framework could benefit from an
> >>>>>> eventListener-system approach instead of callbacks?
> >>>>>> Will I be able to make the slow-down dissapear or decrease?
> >>>>>>
> >>>>>> Any thoughts would be very welcome.
> >>>>>>
> >>>>>> Thanks!
> >>>>>> _______________________________________________
> >>>>>> Flashcoders mailing list
> >>>>>> Flashcoders@chattyfig.figleaf.com
> >>>>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >>>>>
> >>>>> _______________________________________________
> >>>>> Flashcoders mailing list
> >>>>> Flashcoders@chattyfig.figleaf.com
> >>>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Flashcoders mailing list
> >>>> Flashcoders@chattyfig.figleaf.com
> >>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >>>
> >>> _______________________________________________
> >>> Flashcoders mailing list
> >>> Flashcoders@chattyfig.figleaf.com
> >>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >>>
> >>
> >>
> >> _______________________________________________
> >> Flashcoders mailing list
> >> Flashcoders@chattyfig.figleaf.com
> >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >>
> >
> > _______________________________________________
> > Flashcoders mailing list
> > Flashcoders@chattyfig.figleaf.com
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> >
>
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
--
John Grden - Blitz
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
