AGS 4.0 - Early Alpha 10 for public test

[Crimson Wizard]

I think the tabs icons depends on it being enabled in the Editor preferences and I think it defaults on not being enabled - not sure on this last part.

I did not know that, this is bad, it should be on by default. Otherwise nobody will know it's there.

[Crimson Wizard]

Ah, I rushed this release, and forgot to review all post-3.6.1 changes, like System.GetEngineString. They are also merged into AGS 4 now.
I must gather these and add to the changelog too.

[eri0o]

The support for moving folders in the project explorer by click and drag and adding a script and header pair too should be there. I think the name of the room itself too being readable in the editor tab - instead of only Room1.

[Crimson Wizard]

Updated the list of changes, please check the last update post again:
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-4-0-early-alpha-for-public-test/msg636662979/#msg636662979

[Baguettator]

Hi here !

I don't know if it has been already asked for a request, but is it doable in AGS to add the possibility to rotate/rescale dynamically (when game is launched) GUIs and/or GUIControls ? It would be so great...

But I don't know if it is too many work  or if it is doable for now...

[Crimson Wizard]

I don't know if it has been already asked for a request, but is it doable in AGS to add the possibility to rotate/rescale dynamically (when game is launched) GUIs and/or GUIControls ? It would be so great...

In AGS 4 it is possible to rotate GUI and almost anything else (Objects, Characters, Camera...) using Rotation or GraphicRotation property (varies depending on type of object).
There's no command to scale gui, but it's not too difficult to add. In the current state of AGS 4 it's mostly a matter of inventing a good way to set this parameter.

I might try adding this in the next update.

[eri0o]

I had made a issue for GUI Scaling here: https://github.com/adventuregamestudio/ags/issues/1656

I think it may be nice to have different width height for scaling - just thinking about when someone sets a different game resolution, instead of doing whatever is done today with the GUIs if the person clicks yes, it would just scale it - which feels less "destructive".

[Crimson Wizard]

Hm, I did not remember there's a suggestion ticket.

We have reserved transformation fields for "scalex", "scaley" in save format for almost all types of objects now, and iirc the discussed API was to have properties ScaleX, ScaleY; and something convenient to set uniform scaling, like a SetScale(x,y) function, where "y" arg is optional, and if not passed, then it is set equal to "x".

Both scaling and rotation are done using fast texture transformation (with renderers that support that), and will likewise be affected by the "Render sprites at screen resolution" setting.

[Baguettator]

Good news !!! Thanks a lot, I'm waiting this feature

[Crimson Wizard]

Made a draft PR: https://github.com/adventuregamestudio/ags/pull/2426
Test build may be downloaded here and played with:
https://cirrus-ci.com/task/5935527583547392

Added GUI.ScaleX, GUI.ScaleY and GUI.SetScale(x,y).

The transformation mechanism is already in place, so this was a matter of inventing commands and "wiring" script to internal parameters.

Allows both positive and negative scaling; negative scaling leads to a mirrored image.
Scaling "0" is forbidden, passing "0" to any scale value will reset it to 1.0. If this seems inconvenient, I may allow it, but some fixes will have to be made around the code... Of course scale 0 means that object is not drawn.

When scaled, GUI's image shifts relative to its origin, which is top-left corner. If you want to scale "centered", you must adjust X,Y position along in script. This is perfectly consistent with other types of objects, each type has its own "origin".

[Baguettator]

Nice, I will have a look at it !

How coordinates work while scaling ? If a button is at coordinates (10, 50) in its GUI which has width=200 and height =200, and you scale the GUI at (100, 100), what will be the new coordinates of that button ? Screen-related ? GUI-related ?

[Crimson Wizard]

How coordinates work while scaling ? If a button is at coordinates (10, 50) in its GUI which has width=200 and height =200, and you scale the GUI at (100, 100), what will be the new coordinates of that button ? Screen-related ? GUI-related ?

Control's coordinate properties (Button.X,Y) are unchanged, and related to non-transformed GUI.

Real position on screen changes along with GUI scaling and rotation.
Because GUI's origin is at 0,0, the real controls positions may be calculated by multiplying every control's coordinate by the scale value.
(Rotation is more complicated)

EDIT: we have Screen.RoomToScreenPoint/ScreenToRoomPoint functions because Cameras may be scaled and rotated.
I suppose we might need something similar for GUIs, in case user wants to find out real control's location in script.

EDIT2: I found a curious bug, apparently InventoryWindow does not respect transformation when being interacted with.
It is drawn correctly, but detected item positions are wrong.

[Crimson Wizard]

An updated variant:
PR: https://github.com/adventuregamestudio/ags/pull/2426
Download:
https://cirrus-ci.com/task/6618591464783872
https://cirrus-ci.com/task/5727916917522432

Adds properties and functions:
* GUI.ScaleX,
* GUI.ScaleY,
* GUI.SetScale(x,y),
* GUI.GUIToScreenPoint(int guix, int guiy, bool clipToGUI),
* GUI.ScreenToGUIPoint(int screenx, int screeny, bool clipToGUI)

Fixed InventoryWindow interaction in case of scaled/rotated GUI.

UPDATE 2: fixed to allow scaling value 0, which is useful in case of tweening between positive and negative scale.