Updating Progress Label During Long Calculation in Start

[michalis]

@Hamid

This example loads correctly with Delphi and does not produce any errors.
However, when it is compiled with FPC for any platform, it does not work.

Thank you – we had a bug in the engine that made TThread.Synchronize do nothing when used with CastleWindow (not LCL) with FPC.

Fixed now in this commit. As usual, the engine download will soon contain the fixed version, once the new engine passes a few automated tests. You can observe this page, when it will no longer contain a commit titled “Make TThread.Synchronize work in FPC applications using CastleWindow…” then the fix is part of download.

So this makes your example work the same with FPC and Delphi.

Update: A subsequent commit fixes FPC+Android which required one thing to be correct. So please wait until also the commit titled “Set MainThreadID on Android…” is part of the downloads, to have it working flawlessly on FPC+Android too.

That said:

Your application calls CGE API from non-main thread. The application you send is already not guaranteed to work.

Please heed the warning I mentioned a few posts above and emphasized on threads manual page:

@michalis

To be clear: all the usage of CGE API must happen from the same, single thread. As documented on Threads | Manual | Castle Game Engine . Our API is not thread-safe (which is similar to other game engines and Pascal libraries too ). Don’t try executing CGE API from random threads and looking whether it will work – due to how threads work, some incorrect code may sometimes randomly work, randomly crash. The only thing that is guaranteed to work is when you execute all CGE API from one, single thread, which is the thread where your code is during Application.OnInitialize, views methods etc.

Engine internally may employ threads to do other things (like downloads, streaming music, and in the future the async loading of assets mentioned here). On Android there are already 2 threads, one for communication with Java. None of this should be visible to you, and it’s platform-dependent when threads are used.

To be clear, you can use threads for your own work, of course. Just make sure to synchronize all the work such that all CGE API calls are within our thread. From your post, I can see you do such synchronization, but I’m not sure how do you do it / whether it is correct Again, a testcase showing your code would make it clear.

The application you submitted does use CGE API from non-main thread:

• you iterate over X3D graph,
• you do Target.RootNode.AddRoute,
• you setup TCastleCapsuleCollider

← you do these things in TViewMain.DoLoad and CopyAnimationOnly which are not in the main thread.

I understand what you’re trying to solve (speedup animation copying by threads) but this way is really not reliable. It may work by accident (it seems it does now, at least in the simple application you submitted, but evidently your larger application has random errors). Our API is not thread-safe (and it’s the same as LCL, VCL, or other game engines).

If you want to speedup animation → this can likely be done by just making that code faster, even in single thread. I see your testcase in Sharing Animations Between Multiple Characters With the Same Skeleton - #19 by michalis – thank you, I have it on TODO to investigate and propose a speedup.