Debug issues in Flash CS4

I am at a loss for the proper word, but I am coding in the Flash CS4 [api?] directly and not using anything like flex or eclipse...

I have already coded the login, character gen/select, game creation, and lobby chat and am moving on to the game proper, testing some ideas for displaying transparent tile overlay effects, and having some fun with it, but I want to be sure that the overlay objects I am making and destroying are getting garbage collected properly.

I am keeping ties to them at a minumum, and pushing a reference to them into an array, making all listeners weak, and then clearing the array when the effect is no longer needed. I think that should make them garbage collectable, but I would like to make sure by running some memory testing.

I have two main problems with this when I go to debug mode:

1) I am using URLloader to access php files on a server for all the login, chat, netcode stuff, and this gives me a security error for some reason when I try doing this in debug mode, although it works fine when I test the movie or when I run the swf on the server itself. Is there some security setting I am missing or is this just a shortcoming of debug mode?

2) What is a good/best way to check memory usage? I can't really get to this step due to the problem in 1 above. Maybe I can ignore the debugger and just debug with trace, but is there a way to trace out memory usage?

I am pretty used to debugging with trace, as I have always had horrible luck with the flash debugger, it would usually freeze up or take crazy long (10 minutes or so) to start up my files in flash 8. Or constantly warn me that my code was causing the debugger to run slow, even though my fps without the debugger was 50+

1) Do you need a cross domain policy?
2) Don't really know for sure, it appears to be available in Flex 3 though

I don't THINK this is a cross domain issue. I am debugging the file locally and it won't talk to my server in debug mode. Although if I go to test movie, then it compiles and runs fine.

I don't know about the memory, but the debugger normally expects you to catch all possible error or messages the URLLoader throws, so either try a "try...catch" statement, or see if there's any listener you need to setup to handle a message from the URLLoader!

Look --> monsterdebugger
In fact i have not used it but seems good
http://www.gotoandlearn.com/play?id=109

I'm assuming you have your publish settings putting the built SWF into your web server's path, but it seems possible that the debug SWF is put in a temporary directory so creating a wide-open cross domain policy on your test server might solve that issue.

My publish settings are just to my hard drive, and that works fine when I test the movie. Not sure how to setup a cross domain policy on my hard drive...

Okay, so your web server isn't the same machine as your Flash development server? Hmm, at a loss then, sorry.

With regards to number 1, have you tried adding the swf location to: http://www.macromedia.com/support/do...manager04.html ? That "may" help.

Quote:

---

Originally Posted by Alluvian

I have two main problems with this when I go to debug mode:

1) I am using URLloader to access php files on a server for all the login, chat, netcode stuff, and this gives me a security error for some reason when I try doing this in debug mode, although it works fine when I test the movie or when I run the swf on the server itself. Is there some security setting I am missing or is this just a shortcoming of debug mode?

---

I've had this problem working with web services in CS3. When exporting and playing the .swf within Flash it will throw some security error for whatever reason, saying that it can't access the URL on a server. There was also a bug related to this that made Flash crash (or instantly exit) after I tried accessing the web service within Flash. To get around this, I just published the .swf and opened the HTML.

Maybe you need a cross-domain file on the server you're trying to access? I forget how cross-domain files work.

I tried the Flash settings page but I already had set full access to my local files. Couldn't figure it out so I just worked around it.

Unfortunately I don't know how to write a cross domain file when the location of the swf is somewhere on my c:\ drive on a dynamic IP address.

For reasons I don't understand, it runs perfectly well when I just test the movie, but when I debug, all I get are security sandbox issues. I don't know why testing the movie and debugging the movie have different security settings.

Now if I try to run the SWF while flash editor is closed, I get security errors again. The SWF works fine on the server it will eventually live (same domain as the files I am accessing), but I was trying to go into debug mode so I could see if the garbage collector was killing my sprites properly.

If there was a command to access memory within flash that would maybe help as I could display that in a corner and see if it is getting eaten up as I mess around doing things that creates and deletes sprites. I am new to AS3 and not fully confident in how garbage collection works in practice. I have read several tutorials and suggestions like having to explicitly delete enterframe listeners and things like that.

Quote:

---

If there was a command to access memory within flash that would maybe help as I could display that in a corner and see if it is getting eaten up as I mess around doing things that creates and deletes sprites.

---

Dude, monster debugger lets you see how much memory flash is eating
Besides, if what you are doing is creating and deleting lots of items, you may consider recycle them instead, with something like this pool class
http://lab.polygonal.de/2008/06/18/using-object-pools/

Quote:

---

Originally Posted by Alluvian

I am at a loss for the proper word, but I am coding in the Flash CS4 [api?] directly and not using anything like flex or eclipse...


2) What is a good/best way to check memory usage? I can't really get to this step due to the problem in 1 above. Maybe I can ignore the debugger and just debug with trace, but is there a way to trace out memory usage?

---

http://board.flashkit.com/board/show...t=active+graph

There is a complete util/class in the thread there that I found digging around, the creator no longer hosts the file. He talks about it as well as other memory issues in this thread.
http://www.kirupa.com/forum/showthre...=262507&page=3

I haven't really used it much, but I might let it run for a while sometime. Basically it graphs/averages your 'active' memory usage. If you see a gradual increase in memory usage (the average) over a long period of time, then it is pretty safe to assume you have a memory leak. At least that is how I understand it is supposed to be used. You just call it with the constructor

ag = new ActiveGraph(0, false, true, 0);

add it to your stage, you can drag it around too.
edit: there are more details on how to use it in the kirupa link.

I like the idea of the object pool incrue, I think that will serve my purposes pretty well, since these objects are pretty much going to be white squares with filter effects and transparencies added to them to show when tiles are selected and such.

Quote:

---

Originally Posted by Alluvian

For reasons I don't understand, it runs perfectly well when I just test the movie, but when I debug, all I get are security sandbox issues. I don't know why testing the movie and debugging the movie have different security settings.

---

I don't have any experience with server technology and Flash, but I think it's a more general occurrence (wouldn't call this a problem). Basicly your debugger is more strict then your player. Your player tries to keep playing, as this is it's main function. If it runs into a bug or whatever, it tries if it can stil go on withough running into a loop or some other impossible situations. The debugger however does not try to keep playing no matter what, it tries to find and report bugs no matter what. So some coding can produce a bug, this doesn't mean it has to stop the program if it would continue. The player will therefor continue, but the debugger will not.

In conclusion: this isn't necessarily a different security setting, but some strict coding practice.