R3vo/Sandbox – User

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(357 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{SideTOC|0.85}}
{{TOC|side}}
== Introduction ==
If you have ever wondered why you scenario is running so badly, performance profiling is the way to find it out. It allows you to find bottlenecks and slow code by capturing a "slow" frame.
The captured data can then be viewed and analysed.


Dialogs are one way to provide custom graphical user interface in your missions and allow interaction with the player aswell as they are able to run [[Code|code]]. They are defined as classes in the [[Description.ext|missionConfigFile]] ([[description.ext]]), [[campaignConfigFile]] ([[Campaign Description.ext]]) or [[configFile]] ([[config.cpp]]).
== Getting the correct Version ==
Profiling is enabled in the following {{arma3}} versions
* arma3profiling_x64.exe - '''Part of the Performance Profiling Build'''
* arma3diag_x64.exe - '''Part of the Development Build'''


=== Difference between dialogs and HUDs ===
Read [[Arma_3: Steam Branches]] for a guide on how to access these branches.


*Dialogs: Displays that interact with the player through controls. While dialogs are opened player can not move.
{{Feature|informative|It is recommended to use the '''Performance Profiling Build''' (arma3profiling_x64.exe) for performance profiling because:
**'''Commands:''' [[createDialog]], [[closeDialog]], [[createDisplay]], [[closeDisplay]]
* Has tools that might not make it into development build
*HUDs: Displays that print information about the game (amount of ammo, stance,...). HUDs do not interfere with the player's movement.
* Has all the profiling related commands that ''arma3diag_x64.exe'' has
**'''Commands:''' [[cutRsc]]
* Its performance is closer to the default ''arma3_x64.exe''}}


== Dialogs ==
== Frame Capturing ==
There are several commands that allow you to capture a frame.
* [[diag_captureFrame]]
* [[diag_captureSlowFrame]]
* [[diag_logSlowFrame]] - not available in Arma 3 :(
* [[diag_captureFrameToFile]]
In most cases you do not want to capture any or all frames, you just want to capture "slow" frames. A slow frame is a frame that takes longer than the average frame and slows down the game.


Dialogs are parent containers for the actual controls it contains. Their definition contains several properties on the controls it contains, how the dialog can be addressed, and whether or not the player is able to continue regular movement while the dialog is shown.
== How to Use ==
# Run a mission
# Execute a scripted command <sqf inline>diag_captureSlowFrame ["total", 0.3];</sqf> using any means ([[Arma 3: Debug Console|Debug Console]], mission radio trigger...)
# Once a slow frame is detected, a window will open
# In the window you will be able to browse a lot of performance-related data, which can be interesting
# To export the gathered information for sharing with others:
## Select Main Thread (if not selected yet)
## Press the Copy button
## Open an external text editor
## Paste the text into a new file
## Save the file


They can be defined in the [[Description.ext|description.ext]] file or externalized to separate hpp-files, which are included in the description.ext file using the [[PreProcessor_Commands#.23include|#include]] preprocessor directive. The latter method is generally a good idea to split a large description.ext file into several small chunks in order to keep track of what's where.
== Capture Frame UI ==
[[File: arma3-capture frame ui overview.png]]


=== Properties ===
# {{Wiki|TODO}}
{| border="1" align="left" cellpadding="3" cellspacing="0" |
# {{Wiki|TODO}}
! colspan="3" bgcolor="#bbbbff" | Properties
# {{Wiki|TODO}}
|-
# {{Wiki|TODO}}
! bgcolor="#ddddff" | Name
# {{Wiki|TODO}}
! bgcolor="#ddddff" | Type
# {{Wiki|TODO}}
! bgcolor="#ddddff" | Remark
# {{Wiki|TODO}}
|-
# {{Wiki|TODO}}
| '''idd'''
# {{Wiki|TODO}}
| [[Integer]]
| The unique ID number of this dialog. Used with [[findDisplay]] to find the display. Can be -1 if no access is required from within a script.
|-
| '''access'''
| [[Integer]]
|
*0 - ReadAndWrite - this is the default case where properties can still be added or overridden.
*1 - ReadAndCreate - this only allows creating new properties.
*2 - ReadOnly - this does not allow to do anything in deriving classes.
*3 - ReadOnlyVerified - this does not allow to do anything either in deriving classes, and a CRC check will be performed.
|-
| '''movingEnable'''
| [[Boolean]]
| Specifies whether the dialog can be moved or not (if enabled one of the dialogs controls should have the ''moving'' property set to 1 so it becomes the "handle" the dialog can be moved with). Doesn't seem to matter in Arma 3
|-
| '''enableSimulation'''
| [[Boolean]]
| Specifies whether the game continues while the dialog is shown or not.
|-
| '''onLoad'''
| [[String]]
| Expression executed when the dialog is opened. See [https://community.bistudio.com/wiki/User_Interface_Event_Handlers#onLoad User Interface Event Handlers]
|-
| '''onUnload'''
| [[String]]
| Expression executed when the dialog is closed. See [https://community.bistudio.com/wiki/User_Interface_Event_Handlers#onUnload User Interface Event Handlers]
|-
| '''controlsBackground'''
| [[Array]]
| Contains class names of all background controls associated to this dialog.<br>
The sequence in which the controls are listed will decide their z-index (i.e. the last ones will on top of the first ones).
|-
| '''controls'''
| [[Array]]
| Contains class names of all foreground controls associated to this dialog.
|-
| '''objects'''
| [[Array]]
|
|-
|}<br clear="all">


===Example===
== External Viewer ==
<spoiler><syntaxhighlight lang="cpp">class DefaultDialog
* chrome://tracing
{
* https://ui.perfetto.dev/
  idd = -1;
  access = 0;
  movingEnable = true;
  onLoad  = "hint str _this";
  onUnload  = "hint str _this";
  enableSimulation = false;
  controlsBackground[] =  
  {
    //Background controls;
  };
    controls[] =
  {
  //Controls;
  };
  objects[] =
  {
    //Objects
  };
};</syntaxhighlight></spoiler>


[[File:Performance_Profiling_04.png|thumb|diag_captureFrame sample output with custom subtree]]
== Creating Your Own Subtree ==


Once you have defined (or prototyped) dialogs you want to use, be sure to reload the mission in the editor if it is already running.
When Profiling Per-Frame Eventhandlers (PFH), [[diag_captureFrame]] only shows one blob called siFEH that contains all PFH's so you can't see what part of that is caused by your PFH.<br>
In the Eden editor it's enough to save the mission via CTRL + S (Default). This will precompile the description.ext.
You can create your own subtree inside siFEH by wrapping your function call inside a [[isNil]] CODE statement like this:<br>
Turn your old call which may look like this:
<sqf>
addMissionEventHandler ["EachFrame", {
call myPFHFunction
}];
</sqf>


== HUDs (RscTitles) ==
Into something like this:
HUDs need to be defined in RscTitles ([[configFile]],[[missionConfigFile]]). Once they are defined one can use [[cutRsc]] to open them.
<sqf>
===Example===
addMissionEventHandler ["EachFrame", {
isNil { call myPFHFunction } // isNil creates the subtree
}];
</sqf>


<spoiler><syntaxhighlight lang="cpp">class RscTitles
Now when you run [[diag_captureFrame]] inside of siPFH you will have a subtree called gsEva and behind that you can see the first line of code inside the isNil statement.<br>
{
It will only show a part of the first line of that code so you should put something descriptive into the [[isNil]] statement.<br>
  class RscInfoText
You can use the same to create a subtree for any function you like. This will also work inside [[Scheduler#Scheduled_Environment|Scheduled]] ([[spawn]]ed) scripts. <br>
  {
But using this method to "subtree" a function with return values requires a little bit of trickery to get the return value out.
      idd = 3100; //ID Display. Unique identifier
      fadein = 0; //Duration of fade in effect when opening in seconds
      fadeout = 0; //Duration of fade out effect when closing in seconds
      duration = 1e+011; //Duration the HUD is displayed after opening in seconds. Use a very large number to have it always open
      onLoad = "uinamespace setvariable ['BIS_InfoText',_this select 0]"; //Code called when the HUD is created
      onUnLoad = "uinamespace setvariable ['BIS_InfoText',nil]"; //Code called when the HUD is destroyed/closed
      class Controls
      {
          class InfoText
          {
              idc = 3101;
              style = "0x01 + 0x10 + 0x200 + 0x100";
              font = "RobotoCondensedBold";
              x = "(profilenamespace getvariable [""IGUI_GRID_MISSION_X"", (safezoneX + safezoneW - 21 * ( ((safezoneW / safezoneH) min 1.2) / 40))])";
              y = "(profilenamespace getvariable [""IGUI_GRID_MISSION_Y"", (safezoneY + safezoneH - 10.5 * ( ( ((safezoneW / safezoneH) min 1.2) / 1.2) / 25))])";
              w = "(20 * ( ((safezoneW / safezoneH) min 1.2) / 40))";
              h = "(5 * ( ( ((safezoneW / safezoneH) min 1.2) / 1.2) / 25))";
              colorText[] = {1,1,1,1};
              colorBackground[] = {0,0,0,0};
              text = "";
              lineSpacing = 1;
              sizeEx = 0.045;
              fixedWidth = 1;
              deletable = 0;
              fade = 0;
              access = 0;
              type = 0;
              shadow = 1;
              colorShadow[] = {0,0,0,0.5};
              tooltipColorText[] = {1,1,1,1};
              tooltipColorBox[] = {1,1,1,1};
              tooltipColorShade[] = {0,0,0,0.65};
          };
      };
  };
};</syntaxhighlight></spoiler>


=== Creating dialogs ===
Dialogs can then be created and shown using the [[createDialog]] function. If you do so by script and await a responsive action from the user, you might also want to wait until the user has closed the dialog by using a wait statement (e.g. [[waitUntil]]) in conjunction with the [[dialog]] function, if you intend to handle the dialog result within the same script.


* '''Example:'''
== Notes ==
<code>
_ok = [[createDialog]] "MyHelloWorldDialog";
[[waitUntil]] { !dialog }; {{codecomment|// hit ESC to close it}}
[[hint]] "Dialog closed.";
</code>


=== Closing dialogs ===
* 0.3 is a time in second used to determine what duration of a frame you consider abnormal, and first such frame will be captured.
In most use cases a dialog "closes itself", ie. by invoking the [[closeDialog]] function in an ''action'' field. However dialogs don't necessarily have to close themselves, but can also be closed from the "outside" (ie. by scripts or triggers). Once closed, the [[dialog]] function returns <tt>false</tt> and wait statements with a <tt>!dialog</tt> condition will end.
* 0.3 is definitely something you should not see in a normal game.
* If you do not capture any frames with 0.3, try lowering it to 0.2 or 0.1.
* If it triggers too early, before the main slowdown happens, increase it to a higher value, e.g. 1.0.


* '''Example''' - close by action
<syntaxhighlight lang="cpp">
class CloseButton : RscButton {
/* … */
type = CT_BUTTON;
text = "Close";
action = "closeDialog 0";
}
</syntaxhighlight>


* '''Example''' - close by external request
== See Also ==
<code>[[closeDialog]] 0;</code>


== Controls ==
* [[Code Optimisation]]
* [[Mission Optimisation]]


Controls are the actual content of dialogs and can be anything, ranging from simple solid rectangles to a complex 3d object within a dialog. Like dialogs, controls can have a unique ID saved in the ''idc'' property to access them from within scripts using [[:Category:Command_Group:_GUI_Control|GUI functions]].


The type of the control is usually set in the ''type'' property. Different types allow or require a different set of properties. However most controls share a set of properties in addition to the properties described in the following sections:
[[Category:Arma Scripting Tutorials]]
 
{| border="1" align="left" cellpadding="3" cellspacing="0" |
! colspan="3" bgcolor="#bbbbff" | Common properties
|-
! bgcolor="#ddddff" | Name
! bgcolor="#ddddff" | Type
! bgcolor="#ddddff" | Remark
|-
| '''idc'''
| integer
| the unique ID number of this control. can be -1 if you don't require access to the control itself from within a script
|-
| '''moving'''
| boolean
| whether the dialog will be moved if this control is dragged (may require "movingEnable" to be 1 in the dialog. In Arma 3 works regardless). Another way of allowing moving of the dialog is to have control of style ST_TITLE_BAR
|-
| '''type'''
| integer [[#CONTROL TYPES|CT_TYPES]]
|
|-
| '''style'''
| integer [[#CONTROL STYLES|CT_STYLES]]
| can be combinatorial: style = "0x400+0x02+0x10";
|-
| '''x/y/w/h'''
| float
| the position and size of the control in fractions of screen size.
|-
| '''sizeEx'''
| float
| the font size of text (0..1)
|-
| '''font'''
| string
| the font to use. See the list of [[Fonts#Available_Fonts|available fonts]] for possible values
|-
| '''colorText'''
| color array
| text color
|-
| '''colorBackground'''
| color array
| background color
|-
| '''text'''
| string or texture
| the text '''or picture''' to display
|-
| '''shadow'''
| 0,1 or 2
| can be applied to most controls (0 = no shadow, 1 = drop shadow with soft edges, 2 = stroke).
|-
| '''tooltip'''
| string
| Text to display in a tooltip when control is moused over. A tooltip can be added to any control type except CT_STATIC and CT_STRUCTURED_TEXT. Note: As of Arma 3 v1.48 (approx), most controls now support tooltips.
|-
| '''tooltipColorShade'''
| color array
| Tooltip background color
|-
| '''tooltipColorText'''
| color array
| Tooltip text color
|-
| '''tooltipColorBox'''
| color array
| Tooltip border color
|
|-
| '''autocomplete'''
| string
| Option for entry fields (e.g. RscEdit) to activate autocompletion. For known script commands and functions use autocomplete = "scripting".
|
|-
| '''url'''
| string
| URL which will be opened when clicking on the control. Used on e.g. a button control. Does not utilize the Steam Overlay browser if enabled, opens the link in the default browser set by the OS.
|}<br clear="all">
 
=== Attributes class ===
{| border="1" align="left" cellpadding="3" cellspacing="0" |
! colspan="3" bgcolor="#bbbbff" | Properties
|-
! bgcolor="#ddddff" | Name
! bgcolor="#ddddff" | Type
! bgcolor="#ddddff" | Remark
|-
| '''font'''
| string
|
|-
| '''color'''
| HTML color
|
|-
| '''align'''
| string
| center, left, etc
|-
| '''shadow'''
| integer
| not image class
|}
<br clear="all">
 
=== AttributesImage class ===
{| border="1" align="left" cellpadding="3" cellspacing="0" |
! colspan="3" bgcolor="#bbbbff" | Properties
|-
! bgcolor="#ddddff" | Name
! bgcolor="#ddddff" | Type
! bgcolor="#ddddff" | Remark
|-
| '''font'''
| string
| optional
|-
| '''color'''
| HTML color
|
|-
| '''align'''
| string
| center, left, etc optional
|-
|}<br clear="all">
 
To save space and effort, it is generally a good idea to make use of class polymorphism, i.e. deriving from very basic classes that already have some specific properties set. See the [[#Best_practice|Best practice]] for details.
 
== CONTROL TYPES ==
There is an ingame dialog with examples of how the control types look and act like:
<code>createDialog "RscTestControlTypes";</code>
 
{| class="wikitable sortable"
! Define !! Decimal !! Hexadecimal !! Remark
|-
| [[CT_STATIC]] || 0 || 0x00 ||
|-
| [[CT_BUTTON]] || 1 || 0x01 ||
|-
| [[CT_EDIT]] || 2 || 0x02 ||
|-
| [[CT_SLIDER]] || 3 || 0x03 ||
|-
| [[CT_COMBO]] || 4 || 0x04 ||
|-
| [[CT_LISTBOX]] || 5 || 0x05 ||
|-
| [[CT_TOOLBOX]] || 6 || 0x06 ||
|-
| [[CT_CHECKBOXES]] || 7 || 0x07 ||
|-
| [[CT_PROGRESS]] || 8 || 0x08 ||
|-
| [[CT_HTML]] || 9 || 0x09 ||
|-
| CT_STATIC_SKEW || 10 || 0x0A ||
|-
| [[CT_ACTIVETEXT#CT_ACTIVETEXT=11|CT_ACTIVETEXT]] || 11 || 0x0B ||
|-
| [[CT_TREE]] || 12 || 0x0C ||
|-
| [[CT_STRUCTURED_TEXT]] || 13 || 0x0D ||
|-
| [[CT_CONTEXT_MENU]] || 14 || 0x0E ||
|-
| [[CT_CONTROLS_GROUP]] || 15 || 0x0F ||
|-
| [[CT_SHORTCUTBUTTON]] || 16 || 0x10 ||
|-
| CT_HITZONES || 17 || 0x11 ||
|-
| CT_VEHICLETOGGLES || 18 || 0x12 ||
|-
| [[CT_CONTROLS_TABLE]] || 19 || 0x13 ||
|-
| [[CT_XKEYDESC]] || 40 || 0x28 ||
|-
| CT_XBUTTON || 41 || 0x29 ||
|-
| [[CT_XLISTBOX]] || 42 || 0x2A ||
|-
| [[CT_XSLIDER]] || 43 || 0x2B ||
|-
| [[CT_XCOMBO]] || 44 || 0x2C ||
|-
| [[CT_ANIMATED_TEXTURE]] || 45 || 0x2D ||
|-
| [[CT_MENU]] || 46 || 0x2E || Arma 3 (EDEN)
|-
| [[CT_MENU_STRIP]] || 47 || 0x2F || Arma 3 (EDEN)
|-
| CT_CHECKBOX || 77 || 0x4D || Arma 3
|-
| [[CT_OBJECT]] || 80 || 0x50 ||
|-
| [[CT_OBJECT_ZOOM]] || 81 || 0x51 ||
|-
| [[CT_OBJECT_CONTAINER]] || 82 || 0x52 ||
|-
| CT_OBJECT_CONT_ANIM || 83 || 0x53 ||
|-
| [[CT_LINEBREAK]] || 98 || 0x62 ||
|-
| [[CT_USER]] || 99 || 0x63 ||
|-
| [[CT_MAP]] || 100 || 0x64 ||
|-
| [[CT_MAP_MAIN]] || 101 || 0x65 ||
|-
| [[CT_LISTNBOX]] || 102 || 0x66 ||
|-
| CT_ITEMSLOT || 103 || 0x67 ||
|-
| CT_LISTNBOX_CHECKABLE || 104 || 0x68 ||
|-
| CT_VEHICLE_DIRECTION || 105 || 0x69 ||
|}
 
=== Control Types Defines ===
<spoiler>
''All defines can be retrieved by executing''
<code> "Default" [[call]] [[BIS_fnc_exportGUIBaseClasses]];</code>
<syntaxhighlight lang="cpp">
#define CT_STATIC   0
#define CT_BUTTON   1
#define CT_EDIT   2
#define CT_SLIDER   3
#define CT_COMBO   4
#define CT_LISTBOX   5
#define CT_TOOLBOX   6
#define CT_CHECKBOXES   7
#define CT_PROGRESS   8
#define CT_HTML   9
#define CT_STATIC_SKEW 10
#define CT_ACTIVETEXT 11
#define CT_TREE 12
#define CT_STRUCTURED_TEXT 13
#define CT_CONTEXT_MENU 14
#define CT_CONTROLS_GROUP 15
#define CT_SHORTCUTBUTTON 16
#define CT_HITZONES 17
#define CT_VEHICLETOGGLES 18
#define CT_CONTROLS_TABLE 19
#define CT_XKEYDESC 40
#define CT_XBUTTON 41
#define CT_XLISTBOX 42
#define CT_XSLIDER 43
#define CT_XCOMBO 44
#define CT_ANIMATED_TEXTURE 45
#define CT_MENU 46
#define CT_MENU_STRIP 47
#define CT_CHECKBOX 77
#define CT_OBJECT 80
#define CT_OBJECT_ZOOM 81
#define CT_OBJECT_CONTAINER 82
#define CT_OBJECT_CONT_ANIM 83
#define CT_LINEBREAK 98
#define CT_USER 99
#define CT_MAP 100
#define CT_MAP_MAIN 101
#define CT_LISTNBOX 102
#define CT_ITEMSLOT 103
#define CT_LISTNBOX_CHECKABLE 104
#define CT_VEHICLE_DIRECTION 105
</syntaxhighlight>
</spoiler>
 
== CONTROL STYLES ==
 
=== Common Controls Styles ===
{{Important | Note that drawing of vertical text is not supported and any attempt to use <tt>ST_UP</tt>, <tt>ST_DOWN</tt>, <tt>ST_VCENTER</tt> is likely to result in the following ''.rpt'' spam:<br><tt>Obsolete, sizeH and sizeW calculation missing</tt><br>In addition, <tt>ST_UP</tt>, <tt>ST_DOWN</tt>, <tt>ST_VCENTER</tt> are stand alone styles and should not be mixed with any other styles}}
To get an idea of how the styles look like you can create the following dialog:
<code>createDialog "RscTestControlStyles";</code>
{| class="bikitable"
! Define !! Decimal !! Hexadecimal !! Remark
|-
| ST_LEFT || 0 || 0x00 || Default, text left aligned
|-
| ST_RIGHT || 1 || 0x01 || Modifier, adding this to another style will force text to be aligned to the right
|-
| ST_CENTER || 2 || 0x02 || Modifier, adding this to another style will force text to be centered
|-
| ST_DOWN || 4 || 0x04 || Vertical text alignment (See the note above)
|-
| ST_UP || 8 || 0x08 || Vertical text alignment (See the note above)
|-
| ST_VCENTER || 12 || 0x0C || Vertical text alignment, same as ST_DOWN + ST_UP (See the note above)
|-
| ST_SINGLE || 0 || 0x00 || Plain single line box without a border
|-
| ST_MULTI || 16 || 0x10 || Plain multiple line box with a slight border. To remove border add 512 (+ ST_NO_RECT) to the style (style 528, 529 and 530 are therefore border-less). Additional parameter ''lineSpacing'' is required for this style. ''lineSpacing'' = 1; is normal line spacing. Any '''\n''' character in the text string will be interpreted as new line.
|-
| ST_TITLE_BAR || 32 || 0x20 || Plain single line box with semi-transparent background and somewhat embossed border. When this style is used, the dialog containing control becomes draggable by this control
|-
| ST_PICTURE || 48 || 0x30 || Border-less picture box. Text string is treated as a path to a texture. Alignment has no effect. The texture is stretched to fit the box by default. To force original aspect ratio add 2048 (+ ST_KEEP_ASPECT_RATIO) to the style. Background is ignored, ''colorText'' controls texture colour and opacity
|-
| ST_FRAME || 64 || 0x40 || Legend like frame without background with text showing over the frame edge. Alignment has no effect. ''colorText'' defines both text and frame colour
|-
| ST_BACKGROUND || 80 || 0x50 || Single line box with always black opaque background and thick raised beveled border
|-
| ST_GROUP_BOX || 96 || 0x60 || Single line box with delicate semi-transparent background and slight border. Only text colour can be controlled
|-
| ST_GROUP_BOX2 || 112 || 0x70 || Plain single line box, same as ST_SINGLE, only with a slight border similar to ST_MULTI box border
|-
| ST_HUD_BACKGROUND || 128 || 0x80 || Sets special texture for corners. It was used for rounded corners in OFP, Arma and Arma 2. In Arma 3, square corners are used everywhere, so the texture is adapted to the unified style, but the technology is not removed. In Arma 3 it looks the same as normal ST_SINGLE. Corner textures are defined in <tt>[[configFile]] >> "CfgInGameUI" >> "imageCornerElement"</tt> (can be set only globally for the whole game, not per control)”
|-
| ST_TILE_PICTURE || 144 || 0x90 || The picture is tiled according to ''tileH'' and ''tileW'' values. To force tiled picture to keep aspect ratio of original image, add 2048 (+ ST_KEEP_ASPECT_RATIO) to the style.
|-
| ST_WITH_RECT || 160 || 0xA0 || Single line box frame, similar to ST_FRAME box. The text however is displayed inside the frame. Frame and text colour are set with ''colorText''
|-
| ST_LINE || 176 || 0xB0 || Diagonal line going from left top corner to bottom right corner. To control line direction, width ''w'' and height ''h'' parameters of the box could be negative. Line and text colour are set with ''colorText''
|-
| ST_UPPERCASE || 192 || 0xC0 || Forces control text to upper case
|-
| ST_LOWERCASE || 208 || 0xD0 || Forces control text to lower case
|-
| ST_ADDITIONAL_INFO || 3840 || 0x0F00 || ST_SHADOW + ST_NO_RECT + SL_HORZ + ST_KEEP_ASPECT_RATIO
|-
| ST_SHADOW || 256 || 0x0100 ||
|-
| ST_NO_RECT || 512 || 0x0200 || This style works for [[CT_STATIC]] in conjunction with ST_MULTI
|-
| ST_KEEP_ASPECT_RATIO || 2048 || 0x0800 || When used with image or texture, stops it from stretching to fit the control
|-
| ST_TITLE || 34 || 0x22 || ST_TITLE_BAR + ST_CENTER
|}
 
=== [[CT_SLIDER]] Specific Styles ===
{| class="bikitable"
! Define !! Decimal !! Hexadecimal !! Remark
|-
| SL_VERT || 0 || 0x00 ||
|-
| SL_HORZ || 1024 || 0x0400 ||
|-
| SL_TEXTURES || 16 || 0x10 ||
|}
 
=== [[CT_PROGRESS]] Specific Styles ===
{| class="bikitable"
! Define !! Decimal !! Hexadecimal !! Remark
|-
| ST_VERTICAL || 1 || 0x01 ||
|-
| ST_HORIZONTAL || 0 || 0x00 ||
|}
 
=== [[CT_LISTBOX]] Specific Styles ===
{| class="bikitable"
! Define !! Decimal !! Hexadecimal !! Remark
|-
| LB_TEXTURES || 16 || 0x10 ||
|-
| LB_MULTI || 32 || 0x20 || Makes [[CT_LISTBOX]] multi-selectable (see also [[lbSetCurSel]], [[lbCurSel]], [[lbSetSelected]], [[lbSelection]])
|}
 
=== [[CT_TREE]] Specific Styles ===
{| class="bikitable"
! Define !! Decimal !! Hexadecimal !! Remark
|-
| TR_SHOWROOT || 1 || 0x01 ||
|-
| TR_AUTOCOLLAPSE || 2 || 0x02 ||
|}
 
=== Control Styles Defines ===
<spoiler>
''All defines can be retrieved by executing''
<code> "Default" [[call]] [[BIS_fnc_exportGUIBaseClasses]];</code>
<syntaxhighlight lang="cpp">
#define ST_LEFT 0x00
#define ST_RIGHT 0x01
#define ST_CENTER 0x02
#define ST_DOWN 0x04
#define ST_UP 0x08
#define ST_VCENTER 0x0C
#define ST_SINGLE 0x00
#define ST_MULTI 0x10
#define ST_TITLE_BAR 0x20
#define ST_PICTURE 0x30
#define ST_FRAME 0x40
#define ST_BACKGROUND 0x50
#define ST_GROUP_BOX 0x60
#define ST_GROUP_BOX2 0x70
#define ST_HUD_BACKGROUND 0x80
#define ST_TILE_PICTURE 0x90
#define ST_WITH_RECT 0xA0
#define ST_LINE 0xB0
#define ST_UPPERCASE 0xC0
#define ST_LOWERCASE 0xD0
#define ST_ADDITIONAL_INFO 0x0F00
#define ST_SHADOW 0x0100
#define ST_NO_RECT 0x0200
#define ST_KEEP_ASPECT_RATIO 0x0800
#define ST_TITLE ST_TITLE_BAR + ST_CENTER
#define SL_VERT 0
#define SL_HORZ 0x400
#define SL_TEXTURES 0x10
#define ST_VERTICAL 0x01
#define ST_HORIZONTAL 0
#define LB_TEXTURES 0x10
#define LB_MULTI 0x20
#define TR_SHOWROOT 1
#define TR_AUTOCOLLAPSE 2
</syntaxhighlight>
</spoiler>
 
== Eventhandlers ==
* [[User Interface Event Handlers]]
 
== Positioning ==
//Some description, common issues/problems, best practices
* [[Arma_3_GUI_Coordinates]]
* [[Arma 3 Pixel Grid System]]
* [[SafeZone]]
 
== Scripting ==
* [[:Category:Command Group: GUI Control|GUI Commands]]
 
== Best practice ==
 
=== Inheritance ===
<!-- added by Dr_Eyeball. Example not tested. 11 May 2007. Modify it as you see fit, but don't forget this important topic. -->
<!-- Nasty person and Java developer that I am, I dared to move all opening braces at the end of the previous line to make it look more compact. Furthermore I removed some placeholders, because they didn't seem to be needed that much. I hope you don't mind. Also, I love to meddle… :) ~~~~ -->
Using inheritance can reduce your dialog class definitions significantly by standardising common attributes in base classes and just changing unique attributes in derived classes. There is no need to redeclare all attributes for each class definition.
 
* '''Example:'''
<syntaxhighlight lang="cpp">
class RscText // Base definition used for inheritance
{
type = CT_STATIC;
idc = -1;
style = ST_LEFT;
colorBackground[] = {0, 0, 0, 1};
colorText[] = {1, 1, 1, 1};
font = FontM;
sizeEx = 0.04;
h = 0.04;
text = "";
};
 
class My_BlueText : RscText // My_BlueText inherits all attributes from RscText defined above, thus only x,w & colorText need to be changed
{
colorText[] = {0, 0, 1, 1};
x = 0.1;
w = 0.4;
};
 
class My_Dialog
{
//…
 
controls[] = {
My_Text_1,
My_Text_2
};
 
class My_Text_1 : My_BlueText // My_Text_1 inherits all attribute from My_BlueText, therefore only text & y attributes have to be changed
{
text = "Line 1";
y = 0.2;
};
 
class My_Text_2 : My_BlueText
{
text = "Line 2";
y = 0.25;
};
};
</syntaxhighlight>
 
=== Preprocessor instructions ===
Note that you can also add your own [[PreProcessor_Commands|preprocessor instructions]] for commonly used data, eg. for colors, to save yourself the hassle of writing it in several different places and then adapt each of them if you want to change them afterwards (especially if class inheritance isn't applicable). Also it can make your code look more readable sometimes.
 
* '''Example:'''
<syntaxhighlight lang="cpp">
#define COLOR_LIGHTBROWN { 0.776, 0.749, 0.658, 1 }
#define COLOR_HALF_BLACK { 0, 0, 0, 0.5 }
#define COLOR_TRANSPARENT { 0, 0, 0, 0 }
 
// …
 
class MyDialog {
idd = -1;
movingEnable = 1;
objects[] = {};
controlsBackground[] = { MyDialogBackground };
controls[] = { MyDialogText };
 
class MyDialogBackground : RscText {
colorBackground[] = COLOR_HALF_BLACK;
x = 0.7;  y = 0.1;
w = 0.25; h = 0.15;
};
 
class MyDialogText : RscText {
style = ST_MULTI;
colorBackground[] = COLOR_TRANSPARENT;
colorText[] = COLOR_LIGHTBROWN;
text = "No power in the 'Verse can stop me.";
lineSpacing = 1;
x = 0.71; y = 0.11;
w = 0.23; h = 0.13;
};
};</syntaxhighlight>
 
[[Category: Dialogs]]

Latest revision as of 12:37, 26 October 2024

If you have ever wondered why you scenario is running so badly, performance profiling is the way to find it out. It allows you to find bottlenecks and slow code by capturing a "slow" frame. The captured data can then be viewed and analysed.

Getting the correct Version

Profiling is enabled in the following Arma 3 versions

  • arma3profiling_x64.exe - Part of the Performance Profiling Build
  • arma3diag_x64.exe - Part of the Development Build

Read Arma_3: Steam Branches for a guide on how to access these branches.

It is recommended to use the Performance Profiling Build (arma3profiling_x64.exe) for performance profiling because:
  • Has tools that might not make it into development build
  • Has all the profiling related commands that arma3diag_x64.exe has
  • Its performance is closer to the default arma3_x64.exe

Frame Capturing

There are several commands that allow you to capture a frame.

In most cases you do not want to capture any or all frames, you just want to capture "slow" frames. A slow frame is a frame that takes longer than the average frame and slows down the game.

How to Use

  1. Run a mission
  2. Execute a scripted command diag_captureSlowFrame ["total", 0.3]; using any means (Debug Console, mission radio trigger...)
  3. Once a slow frame is detected, a window will open
  4. In the window you will be able to browse a lot of performance-related data, which can be interesting
  5. To export the gathered information for sharing with others:
    1. Select Main Thread (if not selected yet)
    2. Press the Copy button
    3. Open an external text editor
    4. Paste the text into a new file
    5. Save the file

Capture Frame UI

arma3-capture frame ui overview.png

  1. 🚧
    TODO: this must be updated.
  2. 🚧
    TODO: this must be updated.
  3. 🚧
    TODO: this must be updated.
  4. 🚧
    TODO: this must be updated.
  5. 🚧
    TODO: this must be updated.
  6. 🚧
    TODO: this must be updated.
  7. 🚧
    TODO: this must be updated.
  8. 🚧
    TODO: this must be updated.
  9. 🚧
    TODO: this must be updated.

External Viewer

diag_captureFrame sample output with custom subtree

Creating Your Own Subtree

When Profiling Per-Frame Eventhandlers (PFH), diag_captureFrame only shows one blob called siFEH that contains all PFH's so you can't see what part of that is caused by your PFH.
You can create your own subtree inside siFEH by wrapping your function call inside a isNil CODE statement like this:
Turn your old call which may look like this:

addMissionEventHandler ["EachFrame", { call myPFHFunction }];

Into something like this:

addMissionEventHandler ["EachFrame", { isNil { call myPFHFunction } // isNil creates the subtree }];

Now when you run diag_captureFrame inside of siPFH you will have a subtree called gsEva and behind that you can see the first line of code inside the isNil statement.
It will only show a part of the first line of that code so you should put something descriptive into the isNil statement.
You can use the same to create a subtree for any function you like. This will also work inside Scheduled (spawned) scripts.
But using this method to "subtree" a function with return values requires a little bit of trickery to get the return value out.


Notes

  • 0.3 is a time in second used to determine what duration of a frame you consider abnormal, and first such frame will be captured.
  • 0.3 is definitely something you should not see in a normal game.
  • If you do not capture any frames with 0.3, try lowering it to 0.2 or 0.1.
  • If it triggers too early, before the main slowdown happens, increase it to a higher value, e.g. 1.0.


See Also