Class TCastleApplicationProperties

This item has no description.

Some platforms do not support Application.ProcessMessage, which means you cannot just write a function like MessageYesNo that waits until user clicks something. You *have* to implement modal boxes then using views, e.g. using CastleDialogViews or your own TCastleView descendants.

This item has no description.

This item has no description.

Events called at InitializeDebug. If InitializeDebug was already called, then we call the listener now, from this AddInitializeDebugListener!

Add this to OnWarning to output warnings to standard output (usually, console). Eventually, on GUI Windows programs, it will make a dialog box. This is handled by WarningWrite procedure.

Print some common information about application, for example to use in –help command-line output. It shows application name, version, CGE version, compiler version, platform.

Includes the output of SCompilerDescription and SPlatformDescription.

Initialize debug facilities, that should not be enabled in released applications, but are very useful when enabled out-of-the-box during development. Must be called early (before any files are loaded).

This includes now:

• Setting up TCastleContainer.InputInspector to enable invoking inspector at runtime, by pressing F8 key or pressing 3 fingers for 1 second on the screen.

• Setting up file monitor, so that it is possible to enable it at runtime, using "Monitor and Auto-Reload Data" from inspector.

This is called automatically from auto-generated CastleAutoGenerated unit in each project, if the DEBUG symbol was defined during compilation.

For backward compatibility, it is also called when the CGE units like CastleInternalFileMonitor and CastleUiControls are compiled with the DEBUG symbol, but please don't depend on this, it will be removed in future engine versions. You shall not depend on DEBUG / RELEASE symbols used when compiling the engine, they may be independent from the project DEBUG / RELEASE symbols.

Enable release features at run-time. This does *nothing* for now, but enables possible future extensions (e.g. special optimizations).

Free given component, at the nearest suitable moment. The pending free operations are done at least after processing all "update" events and before processing the "render" event (so the items pending to be freed will not be rendered).

Application short name. Used e.g. by InitializeLog to name the log file.

When compiled with FPC, this returns and sets the same thing as standard SysUtils.ApplicationName. When setting this, we automatically set SysUtils.OnGetApplicationName.

Pretty application name, to show to user e.g. as a window caption.

Version of this application. It may be used e.g. by InitializeLog and TCastleApplication.ParseStandardParameters.

Initialized to True on devices with a touch screen (Android, iOS, Nintendo Switch).

On such devices:

• We cannot track TCastleContainer.MousePosition when nothing is pressed (TCastleContainer.MousePressed is []) on a touch device.

• The only "mouse button" you will ever see pressed on a touch device is buttonLeft.

• On the other hand, touch devices support multitouch, exposed by TCastleContainer.Touches and TCastleContainer.TouchesCount. On touch devices, TCastleContainer.TouchesCount can range from 0 to a few (modern touch devices support up to 5 simultaneous touches).

  On non-touch devices, TCastleContainer.TouchesCount is always 1.

See documentation about touch input.

As a debugging feature, you can set this to True to simulate touch devices on a desktop. The idea is that when an application shows a different input behavior on touch devices, it should always condition it depending on this boolean property. So an application may do this:

// show the button only on mobile
ButtonExit.Exists := ApplicationProperties.TouchDevice;

To test on desktop whether everything behaves OK on mobile, you can just earlier call this:

if DebugTouchDeviceOnDesktop then
  ApplicationProperties.TouchDevice := true;

If you use our standard initialization using TCastleWindow.ParseParameters, you can also pass command-line option –pretend-touch-device to do this. If you execute the game from our editor, you can also use the menu item "Run -> Run Parameters -> Pretend Touch Device" to do this. Underneath, all these methods do is set this property to True.

Is it common, on current platform, to show the "Quit" button in your application. E.g. it is normal to show "Quit" on PC (Windows, Linux etc.). But on mobile devices and consoles (like Nintendo Switch) you should not show "Quit", it is expected that user knows how to use OS-specific mechanism to just switch to a different application.

Just like the TouchDevice, you can change this at runtime for debug purposes (to e.g. easily test mobile UI on PC).

Limit the number of (real) frames per second, to not hog the CPU. Set to zero to not limit.

The mechanism is implemented by occasionally sleeping (when we see that we render way faster than we need to). So it's a global thing, not just a property of TCastleWindow or TCastleControl.

In some cases, this also means the "desired number of FPS". This happens when we may be clogged with events (which is especially possible in case of mouse look, when we use CastleControl, or when we use CastleWindow with LCL backend). In such cases we try hard to call "update" and (if necessary) "render" events at least as often as LimitFPS. When LimitFPS is used for this purpose ("desired number of FPS, not just a limit"), it is also capped (by 100.0).

• Comments specifically about TCastleWindow:

  This limits the number of TCastleApplication.ProcessMessage calls per second, in situations when we do not have to process any user input. So we limit not only rendering (TCastleUserInterface.Render) but also TCastleUserInterface.Update processing (which includes physics and animation processing) calls per second. See TCastleApplication.ProcessMessage.

  See TCastleWindow.ProcessMessage documentation about WaitToLimitFPS parameter, and see TCastleApplication.LimitFPS documentation.

• Comments specifically about TCastleControl:

  This mechanism is activated only when some TCastleControl component is used, and only when LCL idle is fired (so we have no pending events, as LCL idle is "lazy" and fires only when process is really idle), and not at Lazarus design time.

Called before OnGLContextOpen, even before Application.OnInitialize, but after we can read files.

Callbacks called when the OpenGL context is opened or closed. Use when you want to be notified about OpenGL context availability, but cannot refer to a particular instance of TCastleControl or TCastleWindow.

Note that we may have many OpenGL contexts (many TCastleWindow or TCastleControl instances) open simultaneously. They all share OpenGL resources. OnGLContextOpen is called when first OpenGL context is open, that is: no previous context was open. OnGLContextClose is called when last OpenGL context is closed, that is: no more contexts remain open. Note that this implies that they may be called many times: e.g. if you open one window, then close it, then open another window then close it.

Callbacks on OnGLContextOpen are called from first to last. Callbacks on OnGLContextClose are called in reverse order, so OnGLContextClose[0] is called last.

This item has no description.

This item has no description.

This item has no description.

Is the OpenGL context available. IOW, we are between the first OnGLContextOpen and last OnGLContextClose.

Callbacks called continuously when (at least one) window is open.

Callbacks called when Android Java activity started. Called every time a Java activity is created.

• For the first time, it's called right before TCastleApplication.OnInitialize.

• Later this is called when Java activity died (and is restarting now), but the native code thread survived. So all native code memory is already cool (no need to call TCastleApplication.OnInitialize), but we need to reinitialize Java part.

  Note that this is different from opening a new rendering context (when the TCastleUserInterface.GLContextOpen is called). On mobile we lose OpenGLES context often, actually every time user switches to another app, but we don't necessarily have our Java or native threads killed at this moment.

For non-Android applications, this is simply always called exactly once, exactly before calling TCastleApplication.OnInitialize.

Callbacks called when Android Java activity is paused or resumed. For now not called on non-Android, but this may change — consider these events somewhat internal for the time being.

This item has no description.

Events called upon WritelnWarning.

Events called upon any WritelnLog, including WritelnWarning.