PDA

View Full Version : Extremely deferred instantiation TitleWindow


justkevin
04-23-2009, 10:46 PM
In a game I'm working on I'm using a variety of TitleWindow's created with PopUpManager to provide various information/interactivity.

Some of these are non-modal and simply provide in-game help. It's this variety that sometimes take forever to appear. There's no obvious pattern-- I might test the game once and they all come up fine, then the next test one of them just can't seem to get to the creation complete stage.

Here's something really bizarre:

I added some trace statements to the TitleWindow to see how far along it gets and when. When the TitleWindow failed to appear, I saw that it had reached the "onInitialize" event. I then suspended the script using Flex Builder's "Suspend" command and began inspecting the variables. While I was scrolling through the variable inspector, the "creation complete" message appeared in the console output. I've seen this behavior several times in this situation.

Questions:
1.) How can I tell what the TitleWindow/PopUpManager is waiting for that's keeping it from reaching "Creation Complete" and displaying the pop-up?
2.) How does a trace message appear in the console while execution is suspended?

wvxvw
04-23-2009, 11:10 PM
All the layout validations in Flex are based off enterFrame event... I can imagine that if you're using timers in the game logic, it may happen that the panel is getting created to late... And, timers would also explain the not suspended execution...

justkevin
04-24-2009, 03:04 AM
All the layout validations in Flex are based off enterFrame event... I can imagine that if you're using timers in the game logic, it may happen that the panel is getting created to late... And, timers would also explain the not suspended execution...

I don't think that's it-- the main game loop is in an enterFrame event which runs normally even when the pop-up window is "stuck". But thanks for the suggestion.

wvxvw
04-24-2009, 11:24 AM
Well... Flex also uses some times dispatchLater() thing, I didn't look into the actual code of this method, but, I would imagine it is based on Timer... and it does use it when laying out visual components, so... maybe...

Peter Cowling
04-24-2009, 12:20 PM
Checking: Are you opening a titlewindow via the parent component? If so, I think the salient code would provide the answer.

justkevin
04-24-2009, 04:02 PM
Checking: Are you opening a titlewindow via the parent component? If so, I think the salient code would provide the answer.

Here's the code that opens the pop-up. It's called from within a non-display object and is passed the main game window (a canvas) as the parent:


override public function execute():void
{
var dialog:MissionUpdateDialog = PopUpManager.createPopUp(this._game.gameWindow,Mis sionUpdateDialog,false) as MissionUpdateDialog;
dialog.title = this._missionTitle;
dialog.detailText = this._missionDetails;
dialog.addEventListener("onClose",onUpdateClose);

ActionOpenUpdateWindow.dialogInstance = dialog;
ActionOpenUpdateWindow.dialogOpen = true;

}

justkevin
04-28-2009, 04:43 AM
Still haven't solved this issue, any other ideas?

JeTSpice
04-28-2009, 05:03 AM
are there any database requests from these popups, or are there any graphics which are associated with them? skins? buttons with icons?

justkevin
04-28-2009, 02:44 PM
Nope, just a style sheet, text and an "okay" button.

justkevin
05-04-2009, 05:30 AM
Still haven't found any answers to the problem of extremely deferred instantiation for TitleWindows, but I have implemented a work around:

As soon as the custom title window is created, I add an ENTER_FRAME listener. The onEnterFrame method counts the number of frames that have elapsed since the TitleWindow was created.

If the frame count gets above some number (say 100), the title window is assumed to be "stuck" sets a boolean static var isStuck = true.

If the main game loop notices that the title window is stuck, it stops processing any game logic, effectively pausing the game.

Once the TitleWindow reaches the creationComplete stage, the event listener is removed and the isStuck flag is set back to false.

My best guess is that Flex's deferred instantiation code tries to place nice and not execute some code if the the application is too busy. The problem is that if the application is always "busy" (like an action game), it's possible that a component may never fully create.