Infinite loop with the render_frame method.

[plaristote]

Greetings.

Still on the making of the very same Panda3D powered videogame. I was trying to make loading screens to make a smoother transition between one scene and the next.

Searching on the forum, I found out about the render_frame method. It worked fine at first, but now it freezes.
After investigating the reason for that, I noticed the first time I did it, I wasn't in the game's main loop yet. I wasn't in an AsyncTask: I am when it freezes.

Maybe there's a link between those two facts ? That's the only explanation I see.

So... am I right about the main_loop and render_frame ? Is it because of a Mutex thingy ? (I looked at the documentation, and that seems like a very plausible explanation)
If I am, is there an alternative to render_frame that could help me get my way ?
And if not, how do I handle my loading screens then ?

Thank you for the help !

[rdb]

Could you elaborate a bit more? What are you trying to do with render_frame, how are you calling it (show a snippet of code), and what exactly is freezing? You mean that the call is never returning?

[plaristote]

I just use it to change the content of a libRocket element and refresh the screen during loading.

Here's the method that does that:

Code: Select all

void LoadingScreen::AppendText(const std::string& str)
{
  Core::Element* input = _root->GetElementById("content");
  Core::String   content;

  input->GetInnerRML(content);
  content = Core::String(str.c_str()) + "<br />" + content;
  input->SetInnerRML(content);
  framework.get_graphics_engine()->render_frame();
}


Render_frame is never returning indeed.
It's not using the CPU, so I suspected the lock thing (I'm using the threading-model /Draw option).

[plaristote]

Well.
The bug isn't reproducible.
The render_lock isn't actually blocking anything.

I would have to check out 20 thousand lines of code looking for something I don't know anything about. So I'm probably giving up, unless someone has the slightest idea of what may have happened.

It also turns out that it works sometimes. It just doesn't work when I'm loading a level (which is sad because that's the only loading part of the game that takes enough time to require a loading screen).
While loading the game, I'm fairly certain nothing happens that doesn't happen anywhere else. I'm loading models, animations, making collision nodes... nothing special really.

I would really like an alternative for loading screen (unless there's a way to debug this, which I doubt there is).

[heek_]

It also turns out that it works sometimes. It just doesn't work when I'm loading a level

Well... I dunno whether I understand you, but I guess you are loading huge models in a separate thread. Maybe it's related:
http://www.panda3d.org/forums/viewtopic.php?t=13930

Try cleaning your cache and see if it loads ok the first time.
I guess this bug is easy to solve... I just don't know where to put the cache->consider_flush_index() without locking...

I filled this bug here:
https://bugs.launchpad.net/panda3d/+bug/1019599

[plaristote]

I'm afraid we're not having the same issue ! I tried the flush, to no avail.

I'm not really using thread (only the engine-integrated thing that uses different thread for app/cull/render).
It may be related (after all, I'm pretty sure only a lock issue could cause something like this - that is, not returning because of blocking instead of looping).

[plaristote]

Alright. I got this.

I noticed that a working LoadingScreen failed after I moved the code to something else.
I use some pretty neat signal stuff so I didn't do the math, but now that I moved it, I understand why it happened.

See, actually, the render_frame is not executed during the execution of my AsyncTask.
It is executed in a callback from a Rocket event listener.

In order to fix this issue, I can simply use a boolean and wait until the next iteration of my AsyncTask to actually execute what needs to be loaded.

So this is the issue: render_frame doesn't return if it is called from a RocketEventListener callback.
Is this a bug ?