Class TCastleApplicationProperties
Unit
CastleApplicationProperties
Declaration
type TCastleApplicationProperties = class(TObject)
Description
Events and properties of the Castle Game Engine application, usually accessed through the ApplicationProperties singleton.
These members work regardless if you use CastleWindow or CastleControl. For more fine-grained application control, see TCastleApplication (in case you use CastleWindow) or Lazarus (LCL) TApplication (in case you use CastleControl).
Hierarchy
- TObject
- TCastleApplicationProperties
Overview
Fields
Methods
Properties
Description
Fields
|
nested const DefaultLimitFPS = 120.0; |
This item has no description. |
|
nested const PlatformAllowsModalRoutines = true ; |
Some platforms do not support Application.ProcessMessages, 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.
|
Methods
|
constructor Create; |
This item has no description. |
|
destructor Destroy; override; |
This item has no description. |
|
procedure AddInitializeDebugListener(const Listener: TProcedure); |
Events called at InitializeDebug. If InitializeDebug was already called, then we call the listener now, from this AddInitializeDebugListener !
|
|
procedure WriteWarningOnConsole(const Category, Message: String); |
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.
|
|
function Description: String; |
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.
|
|
procedure InitializeDebug; |
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.
|
|
procedure InitializeRelease; |
Enable release features at run-time. This does *nothing* for now, but enables possible future extensions (e.g. special optimizations).
|
|
procedure FreeDelayed(const Item: TComponent); |
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).
|
Properties
|
property ApplicationName: String read GetApplicationName write SetApplicationName; |
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.
|
|
property Caption: String read FCaption write FCaption; |
Pretty application name, to show to user e.g. as a window caption.
|
|
property TouchDevice: boolean read FTouchDevice write FTouchDevice; |
Initialized to True on devices with a touch screen (Android, iOS, Nintendo Switch).
On such devices:
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:
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 .
|
|
property ShowUserInterfaceToQuit: Boolean read FShowUserInterfaceToQuit write FShowUserInterfaceToQuit; |
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).
|
|
property LimitFPS: Single read FLimitFPS write FLimitFPS default DefaultLimitFPS ; |
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).
|
|
property OnGLContextEarlyOpen: TGLContextEventList read FOnGLContextEarlyOpen; |
Called before OnGLContextOpen, even before Application.OnInitialize, but after we can read files.
|
|
property OnGLContextOpen: TGLContextEventList read FOnGLContextOpen; |
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.
|
|
property OnGLContextOpenObject: TNotifyEventList read FOnGLContextOpenObject; |
This item has no description. |
|
property OnGLContextClose: TGLContextEventList read FOnGLContextClose; |
This item has no description. |
|
property OnGLContextCloseObject: TNotifyEventList read FOnGLContextCloseObject; |
This item has no description. |
|
property IsGLContextOpen: boolean read FIsGLContextOpen; |
Is the OpenGL context available. IOW, we are between the first OnGLContextOpen and last OnGLContextClose.
|
|
property OnUpdate: TNotifyEventList read FOnUpdate; |
Callbacks called continuously when (at least one) window is open.
|
|
property OnInitializeJavaActivity: TNotifyEventList read FOnInitializeJavaActivity; |
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.
|
|
property OnPause: TNotifyEventList read FOnPause; |
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.
|
|
property OnResume: TNotifyEventList read FOnResume; |
This item has no description. |
Generated by PasDoc 0.16.0-snapshot.