Simple Loading Screen

General Discussion
1

I’m setting up a simple app with a decent-sized environment. Panda takes a few seconds to load the environment model, during which you’re staring at a black screen. So, I tried to put the text “Loading” on the center of the screen so the user won’t think the app is broken.

The problem is that the text doesn’t come up until the environment is loaded… which kind of defeats the purpose. I tried OnscreenText and TextNode, but with no joy. Any ideas?

2

Yeah, I recently wrote some code for that.

Put this at the top of your game/app right after importing directstart (or showbase):

#set up a loading screen
from direct.gui.OnscreenText import OnscreenText,TextNode
loadingText=OnscreenText("Loading...",1,fg=(1,1,1,1),pos=(0,0),align=TextNode.ACenter,scale=.07,mayChange=1)
base.graphicsEngine.renderFrame() #render a frame otherwise the screen will remain black
base.graphicsEngine.renderFrame() #idem dito
base.graphicsEngine.renderFrame() #you need to do this because you didn't yet call run()
base.graphicsEngine.renderFrame() #run() automatically renders the frames for you

You see i call the renderFrame function, which renders 1 frame.
Since run() is not called yet, it wont do it automatically.

3

Excellent! Thanks, pro-rsoft. That works beautifully.

I have a question about it. You called renderFrame() four times. Why is this necessary? When I call it only once, of course, it doesn’t work. Do you know what Panda is up to here?

Thanks again.

4

I actually have no idea. :wink: I just want to made sure it really gets rendered.

5

The first renderFrame() call only opens the window (base.graphicsEngine.openWindows() would also achieve this). The second renderFrame() call should then be sufficient to render the text.

David

6

When I try to put this in the word Loading does not go away when the program starts up, any idea why?

I put it directly under:

import direct.directbase.DirectStart
7

It won’t go away until you tell it to, with something like:

loadingText.cleanup()

David

8

Thank you

9

Excellent solution! :slight_smile:

I’m also very curious as to why four renderFrame calls are necessary. We saw a similar issue when we did loading screens, and side-stepped it by calling taskMgr.step() twice. My concern is that when I see a stack of repeated calls like this, it makes me think there’s some kind of delay-interlock that’s missing. My worry is robustness; will I have to call renderFrame 8 times (or for that matter, taskMgr.step() 4 times) on faster machines to get the same effect?

I haven’t gotten handy enough yet with the source code to track this sort of behavior down; if anyone has any ideas, I’m very interested.

As often as this issue seems to come up, it might be wise for a trio of “setLoadingScreen, showLoadingScreen, hideLoadingScreen” calls to be added to direct. On the other hand, once multithreaded loading is ready it should make this a lot easier!

Take care,
Mark

10

Ahem. From the above post:

Thus, exactly one call to base.graphicsEngine.openWindows(), followed by one call to base.graphicsEngine.renderFrame(), is sufficient. Alternatively, two calls to base.graphicsEngine.renderFrame() is also sufficient. Four is overkill.

David