Game Development Reference
In-Depth Information
How it works...
Most of the work in this recipe consists of getting the XML layout right. It's a good idea to
sketch it on paper first and visualize the flow of the elements.
The reason the fade effect is shorter is because by the time it fades out, the game is ready to
be played and the player doesn't need to wait longer than necessary. When the loading
screen is first shown, the player has to wait for the game to load.
There is a reason why we set loadingPanel to visible="false" at the beginning
and used onShow rather than onScreenStart effects. The onStartScreen method
in the controller is called after the screen has been started and onScreenStart effects
have been fired (and completed). This means that any fading will occur before we set the
images, and they would pop into existence after some time has passed. Since the onShow
effects are called once the element becomes visible, we get around that problem this way.
Another possible gotcha here, especially if we use a test case to show the screen, is that we
can't call nifty.gotoScreen just after initializing NiftyAppState . Since the Ap-
pState initialization method is called in a thread-safe way, it doesn't run until the next
update cycle. This means that if we try to change the screens on the next line, we will get
NullPointerException .
Search WWH ::




Custom Search