Messages

Game memory is not only occupied by variables. I think that statistically graphics take most part. That is unless you allocate abnormally large dynamic arrays in script.

If you are worried about memory consumption, then calculate it! The amount of memory that variables take may be predicted (with certain level of precision).

Also, the simple way to see how much memory your game requires is to run it and check the process memory in Windows Task Manager.

AudioChannel.Pause and Resume are available since AGS 3.6.0, so this module might be mostly obsolete by now.

_Debug\acres.exe is a temporary exe created for game testing. You may try to delete it by hand, and see if that helps.

Are you sure about that? The way I remember it, every TextBox currently visible receives the input.

Weird. So this is even dumber than I remembered.

[may]

Mainly to prevent any sub-pixel appearance when the sprites are shown one over the other, like a mouse cursor sprite on a room area.

This cannot be fixed by scaling a graphic. This may be only fixed by forcing the cursor movement to the same resolution as the room.

Same is related to GUI. Scaled or not, but if their position is in different coordinate resolution than the underlying room, there may be "subpixel" issues.

I opened a summary proposal thread for GUI controls:
https://www.adventuregamestudio.co.uk/forums/editor-development/gui-controls-update-proposal/

So the only thing I can think of at this time is to having an object for presenting the mouse sprite in any of the rooms (since we can't have global objects)

Cursor may be represented by a GUI or screen overlay, which are global objects.

[NOTE:]

GUI controls in AGS games did not receive much updates since it turned opensource. While AGS allows to create many custom things with scripting, using raw drawing and/or overlays (for instance), there are situations when things would rather be achieved using standard GUI controls, but they are either missing a property or behavior.

Here I tried to organize ideas and requests that I heard over previous years. I think that for the long term it's best to not rush adding stuff to gui controls, but think this over first. I also think that, since GUI controls have a class hierarchy already, it is easier to expand multiple controls at once, as you may add common behavior to the parent class instead of adding same thing to many controls many times.

I also look at some classic GUI frameworks, such as C# WinForms, for comparison and example.

Related tickets (some directly, some indirectly):
https://github.com/adventuregamestudio/ags/issues/1208
https://github.com/adventuregamestudio/ags/issues/472
https://github.com/adventuregamestudio/ags/issues/669
https://github.com/adventuregamestudio/ags/issues/1876

NOTE: here I would not like to discuss dynamic creation of GUI controls (a well known request), as that's tangential to their looks and behavior.


So here's my thoughts and proposals.
Following list may be amended and altered after discussion.


1. Common Control events.

GUIControl should have a OnClick event, available to all the subtypes.
In addition to that: OnMouseDown/OnMouseUp events, in case one wants to distinct these events. @eri0o once suggested to have more "generic" name like OnPointerDown/OnPointerUp, suitable for multiple sorts of "devices". There may be other alternatives (to avoid mixing "pointer" terms), e.g. OnCursorDown/Up, etc.

The purpose of having these in the parent class is to let script low-level handling of player's input for any control.

2. Common Control appearance.

GUIControl should have Background and Border properties, so these are available to all subtypes. Including Background/Border Color and Image.
Optionally: Border width.
Optionally, Advanced: tiled Border graphics (but not sure how to configure these conveniently).

Alternatively, we might insert an intermediate class, something like FrameControl, which defines a control which has a "box" like appearance. This will keep an option to have controls derived from GUIControl but having a completely different kind of appearance.

The reasoning: sometimes user may like to have an underlaying color or image for a control, but with the exception of a Button (and maybe Slider) there's no direct way to do this. The workarounds are: either put another nonclickable button with a graphic underneath, or paint GUI background. The latter is inconvenient, as you will have to repaint it anytime if controls are moved.

This involves properties:
* BackgroundColor;
* BorderColor;
* BorderWidth;
* Image; maybe having "Image" is better than "BackgroundImage"? but need to consider pre-existing properties in derived controls, such as Button and Slider.
* ImageStyle: normal, stretched, tiled (?).

3. Labels.

Labels are defined as a control that displays a text or image and does not have any additional "interactive states" or values.

OTOH there's a suggestion to make Labels support image animation, similar to how Buttons are animated currently (Animate command). See the feature suggestion ticket.

New properties:
* Padding for the text or image. (ticket)
* Full set of TextAlignment options (like Button has currently).
If animation is supported, then it also will have to have:
* readonly View, Loop, Frame.

4. Buttons.

Buttons become a subtype of Label, inheriting its properties and behavior.
They are defined as a control that has multiple states depending on user input: normal, highlighted (under cursor), pushed.

While Buttons may reuse "BackgroundColor" as "NormalColor" (it's not necessary to do this though), they have multiple states, and so would likely need extra Color properties for "MouseOver" and "Pushed" state as well.

In regards to the BorderColor, buttons have a quirk that in their 3D look they draw border with 2 colors: a lighter color on top and left and darker color on right and bottom. At the moment I'm not sure which would be the best option here. Either they may derive these by mathematically darkening/lightening BorderColor property value, or require separate properties.

Buttons should have a ClickAction and NewModeNumber properties deprecated. These properties are a legacy from times when Iconbars were not scripted, but had cursor modes appointed to each button. All of this may be done in script now.
ClickAction = NoAction is equivalent to not having any registered OnClick function, so that's similarly redundant.
Buttons will simply be either ones which run some script on OnClick or not.

5. ListBoxes.

Properties that let to define a fixed row height, and/or row padding (padding is added to the font's height). I suppose that row height should be exclusive with row padding.
Text alignment including vertical alignment, in case row height is larger than the font.

Support for multiline List items, where a long text is wrapped into multiple lines instead of being cut at the control's edge.
(This may be mutually exclusive with row height)

Item arrangement property: allow to display items from bottom up.

Custom graphics for the scrollbar: arrow sprite(s), scrollbar sprite, scroll position sprite. And/or tiled scrollbar setting, where scrollbar is defined by upper/bottom edge and a middle tile.

There's a open ticket for this:
https://github.com/adventuregamestudio/ags/issues/2384

[focused control]

On the same time, I think that if there could be another property there for 'OnEnter' for example to selecting a list item using the keyboard could be a very nice add-on, as currently we have to doing so manually using the on_key event.

Having OnEnter event is by far not enough for handling keyboard input.
The problem with AGS controls is that they don't have a concept of a focused control, that is a control which currently is receiving an input.

Imagine having multiple list boxes on screen, which one should be reacting to key presses?

With TextBox this is handled in a dumb way, the first enabled TextBox found receives input. User has to enable/disable textboxes manually to achieve a wanted effect.

Only if we introduce a Focus concept, and make all Controls have a Focused property, then this will be possible.

[table]

I don't think that it is a good idea to mix InventoryWindow with texts. InventoryWindow is a specialized control for displaying inventory items using their graphics. For lists of strings there's already a ListBox. Filling ListBox with inventory names is a rather trivial thing to script, this may be a good option for a script module.

In regards to displaying ListBox items horizontally, that's an curious idea, but I am not certain if it's good thing to force this unorthodox behavior into the ListBox. First of all, such behavior would require a property which defines an item's width limit, as it cannot be limited with the control's width in such case.
Which in turn makes ListBox akin to a table.
Perhaps designing a completely new Table control would be a better choice.

@Gal Shemesh I took a liberty to rename the topic, just to make the purpose more clear.

So, I tried to reproduce this earlier, and could not; it was working perfectly fine for me.
But I have vague memories that this happens sometimes, as if something breaks the tabs behavior.

Without finding what causes this glitch, this may be difficult to fix...

[is]

Honestly speaking, this request is so confusing... probably worded all wrong.

listbox.Items is an option to grab "literal strings" from items. Because Items is an array of strings.
"A easy straightforward way to grab the string from a listbox item index" is ListBox.Items[index]. What could be more straightforward than that?

What you probably ask for, is a "quicker" way to get selected string. Like having a ListBox.SelectedItem property.

I don't quite understand this topic, if this is about scaling GUIs, then this feature is already implemented in the latest AGS 4 build.

Scaling cursor graphic is as trivial as creating a resized dynamic sprite and setting to cursor.

There's also an idea of scaling full game image with certain ratio, as I mentioned in another thread here -
https://www.adventuregamestudio.co.uk/forums/editor-development/feature-request-agi-21-aspect-ratio-support/msg636663194/#msg636663194
- engine has to support whole "GUI layer" transformation and/or whole Game screen transformation.

[EDIT:]

For the proper Unicode support you must handle 2 events:
- on_key_press - for service keys
- on_text_input - for typing printable characters

Explanation is here:
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Event.html#on_text_input

Code: ags

function handleParser(eKeyCode k, int ch) {
  if (k == eKeyReturn) {
    lblParser.Text = lblParser.Text.AppendChar('\n'); // add a linebreak
  }
  else if (k == eKeyBackspace) {
    if (lblParser.Text.Length > 0) // truncate by 1 character
      lblParser.Text = lblParser.Text.Truncate(lblParser.Text.Length - 1);
  }
  else if (ch != 0) {
    lblParser.Text = lblParser.Text.AppendChar(ch); // append a printable character
  }
}

function on_key_press(eKeyCode k) {

  if (gParser.Visible) {
    handleParser(k, 0); // handle service keys
    ClaimEvent(); // prevent other scripts getting this key press
    return;
  }

}

function on_text_input(int ch) {

  if (gParser.Visible) {
    handleParser(eKeyNone, ch); // handle printable characters
    ClaimEvent(); // prevent other scripts getting this character event
    return;
  }

}

EDIT: The above script is practically how TextBox is working internally in the AGS engine.

including all the other part results in compilation errors:
GlobalScript.asc(92): Error (line 92): Type mismatch: cannot convert 'String[]' to 'String'

which is line 5 of your 3rd code

"String[] spriteList" is a C# syntax.
In AGS it has to be "String spriteList[]".

If not for the 2 separate global settings, I'd simply expand existing character property to be used in both cases.
(Also, this property has "walk" in its name, which could be confusing if worked for turning when standing too.)

Is there actually a use case for having 2 separate settings with different values?

Check the "Transparent colour" selection in the Import Sprite window.
https://adventuregamestudio.github.io/ags-manual/EditorSprite.html#import-sprite

According to the manual, the same per-character property controls both behaviors, if the "Characters turn to face direction" setting is true.

If so then the manual is wrong, existing character property affects only turning when walking.

I don't know if 3.6.x is considered pretty much closed and done, but I was wondering if it would be possible to implement a small QOL feature to make "characters turn to face a direction" a character property, the same way as "characters turn before walking". The latter is adjustable on a per-character basis as well as from script, but unfortunately the former isn't.

From the looks of it, this will be trivial to add. But if added, this is going to be in the next 3.6.x version, not in 3.6.1 patches.

EDIT:
On second thought, would not it be convenient to have this as a parameter in Face* functions? Because I may easily imagine situations when same game may have a need to turn the character quickly or slowly depending on circumstances.