Demo of showing loading progress, WaitForRenderAndCall utility, new TCastleTouchNavigation

News
1
zombie_fighter demo - loading
zombie_fighter demo
zombie_fighter demo

  1. We have new TUIState.WaitForRenderAndCall utility, especially useful to implement loading inside TUIState descendant.

  2. Our examples/user_interface/zombie_fighter features now a demo showing loading progress (as a descendant of TUIState, which is our advised approach for loading screens now).

  3. Whole examples/user_interface/zombie_fighter was remade to use editor.

  4. We have a new UI control, available from code and in editor: TCastleTouchNavigation.

    This shows controls that you can drag to navigate within a viewport. Thus it allows navigation in a TCastleViewport on touch devices. It is a “reboot” of previous TCastleWindowTouch use-case, now expressed as UI control that can have any size, can be attached to any viewport, and in general is consistent with the rest of CGE.

    In a typical usage scenario, you just add it as a child of TCastleViewport, set FullSize=true, set Viewport to the parent. Then control the touch interface. It is easiest to call MyTouchNavigation.AutoTouchInterface := true to let it be automatically assigned. Set MyTouchNavigation.AutoTouchInterface := ApplicationProperties.TouchDevice to let it be automatically assigned, but only on touch devices (that do not have regular keyboard / mouse).

    See TCastleTouchNavigation API docs for more info. An example is in examples/mobile/simple_3d_demo.

4 Likes
2

In the example, when we click on ‘New Game’, a view called ‘Loading’ appears, and after some time it closes and we go to the ‘Play’ view.
I don’t understand why this happens, since the heavy calculations or loading occur in the ‘Game’ view.

3

Good point. The reason is that it is an imperfect example :slight_smile: As the comments in the GameViewLoading unit say:

  { Fake loading something big, one time. Just do something time-consuming there. }
  Sleep(100);

The existing TViewLoading implementation indeed doesn’t really do anything useful. It’s a demo that you can show a nice loading screen, with progress bar, if you already have a code doing multiple steps to prepare your game.

Note: Also calling Sleep(...), like the example does, should never be done in a real application, see comments in that file:

{$ifdef WASI}
{ WebAssembly will crash when we call standard Sleep.
  So we implement our own sleep below in a stupid way: just "busy waiting"
  until the time passes.

  DO NOT USE THIS IN YOUR OWN APPLICATIONS.

  This is used in this example just to "fake" that we're doing something
  time-consuming, to show that you can do something useful and show progress.
  This is the purpose of "Sleep" in this application (both on web and non-web).

  It is not good to be used in real applications, because

  - This "Sleep" implementation, with "busy waiting",
    is uselessly consuming CPU time.
    The "busy waiting" is a bad way to sleep, consuming CPU time doing nothing.

  - Even the proper "Sleep" on non-web platforms is useless in real games.
    It hangs the process, doing nothing, which is something you should never
    do. Instead always finish what you want to do as quick as possible,
    and adjust to passing time by accounting for SecondsPassed in the Update
    methods.
    See https://castle-engine.io/view_events .
}
procedure Sleep(const Milliseconds: Cardinal);

Summary: In a real application,

  • do not do Sleep in GameViewLoading
  • do something useful there – like loading scenes and preparing resources (TCastleScene.Load, TCastleViewport.PrepareResources) or doing anything game-specific (loading game-specific data files, connecting to some server on the network etc.),
  • reorganize the calls to UpdateProgress(...) and WaitForRenderAndCall to reflect the steps you want to do.

The GameViewLoading in that example indeed does not do anything sensible :slight_smile: It is a demo that, if you have already some code doing some useful preparation then you can organize it into a loading view with progress.

1 Like
4

Okay, I don’t use Sleep. :slightly_smiling_face:
I explained the main problem here:

https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/2

1 Like