AGS 4.0 - Alpha 18 for public test

[Crimson Wizard]

I opened a bug ticket: https://github.com/adventuregamestudio/ags/issues/2651

[eri0o]

For the dynamic sprite rotation in ags4, there is a build in the CI here with a fix: https://cirrus-ci.com/task/5179283984875520

[Baguettator]

Also, I have another request but I know I several times suggested it by the past : because you told about RGBA colours and things about that, is it possible to add PNG management by the editor ? It could be so great to have the possibility to add png files with their alpha channel instead of "magic pink backgrounds" for BMP files.

I don't know how much it is complicated/not planned/not wanted

[eri0o]

Editor supports importing a png file with alpha, just select the leave as is for alpha when importing.

Did the editor in the link fix the issue with rotating dynamic sprites for you?

[Crimson Wizard]

Also, I have another request but I know I several times suggested it by the past : because you told about RGBA colours and things about that, is it possible to add PNG management by the editor ? It could be so great to have the possibility to add png files with their alpha channel instead of "magic pink backgrounds" for BMP files.

This is already supported in the editor for many years. Do you maybe mean loading a PNG with DynamicSprite?

What we said about RGBA colors is not related to this.

[Baguettator]

Yes sorry, I meant : using PNG files for DynamicSprites

@eri0o : I didn't try yet, will have a look !

[Baguettator]

Hi all,

@eri0o : the fix for the rotation with dynamicsprites worked for me, thank you !

I noticed a problem with the GUIControl.GetByName function : I didn't change anything in my game, just ported it to AGS 4.0 (last build, the fix erioo sent me), and I have a null pointer instead of something working like before.

For example, I have a button called "Button1" in my game (it's the script name of the button). Here's my code in game_start function :

Code: ags

int u=1;
  GUIControl *g=GUIControl.GetByName(String.Format("Button%d", u));
  u=g.ID; // error is here, g appears to be a null pointer, whereas it exists in my GUI !
  Display("%d", u);

[Crimson Wizard]

I noticed a problem with the GUIControl.GetByName function : I didn't change anything in my game, just ported it to AGS 4.0 (last build, the fix erioo sent me), and I have a null pointer instead of something working like before.

GetByName got broken again, you will need to use the most recent unreleased build to make it work:
https://cirrus-ci.com/task/6345700029497344

[Baguettator]

Does it include the rotation fix for dynamicsprite too ?

[Crimson Wizard]

Does it include the rotation fix for dynamicsprite too ?

This is the latest build which includes everything.

But I forgot that the above includes update of a color format, so may not be entirely safe. It's still in testing.
After upgrading, users will have to fix all of their color constants if they have these in scripts,
that is - assignments like "GUI.BackgroundColor = 123456;". These should be replaced with AARRBBGG format like, which is easier to write in hex (like "0xFFRRGGBB").
If you don't have such things in script, then it's safer, but still I recommend making a game backup.

If you don't want to do this right away, there's a temporary workaround for GetByName:

Code: ags

GUIControl *MyGetByName(GUI* parentGUI, String name)
{
    for (int i = 0; i < parentGUI.ControlCount; i++)
    {
        if (parentGUI.Controls[i].ScriptName == name)
            return parentGUI.Controls[i];
    }
    return null;
}

[Baguettator]

Oh, you mean you are trying to implement the alpha value directly in the number of the color ?

I'll wait for a stable update, don't worry, I'm not in a hurry

[Crimson Wizard]

Updated to Alpha 18
(Please use download links in the first post)

IMPORTANT: starting from this version Editor will require a different VC Redistributable to run.
Installer contains the VC Redist, but if you are getting AGS in an archive, and the necessary component does not happen to already be on your system, then here's a download link to Microsoft's site:
https://download.visualstudio.microsoft.com/download/pr/5319f718-2a84-4aff-86be-8dbdefd92ca1/DD1A8BE03398367745A87A5E35BEBDAB00FDAD080CF42AF0C3F20802D08C25D4/VC_redist.x86.exe

Contains all the new features and fixes from 3.6.2 Beta 6 (excepts ones related to backwards compatibility).


Own changes:

Common:
 - Color number properties now correspond to the encoded 32-bit ARGB (A8R8G8B8 format).

Editor:
 - In 32-bit game projects you can assign full RGBA color definition, where alpha is optional, and is assumed 255 if not specified. Color value 0 means "transparent" regardless of game's color depth.
   NOTE: color picker currently does not let define alpha, so only opaque colors may be selected using it; but you may still enter RGBA value into properties by hand as "RR; GG; BB; AA".

Compiler:
 - Fixed unnecessary warnings about function parameters in function declarations "hiding" global functions of same name. Only report such warnings for function bodies.
 - Fixed incorrect "overflow" error reported for a bitwise left shift operation, when shifting a byte value by 24 bits.

Script API:
- All existing Color properties now assume full ARGB values (0xAARRGGBB) in 32-bit games. This means that you *must* specify alpha value when assigning a color number directly, otherwise the game will treat the color as fully transparent.
- Added Game.GetColorFromRGBA() function that creates a color number for red, green, blue and alpha combination.
- Added DrawingSurface.BlendMode property that lets define blend mode for primitive drawing operations (line, rectangle, triangle, etc).
- Added DrawingSurface.SetPixel() function that lets to set a pixel value of specified color, disregarding any surface's drawing settings.

Engine:
 - All color settings in a 32-bit game now respect alpha value, meaning they may be translucent. This refers to almost anything that may have a color: texts, GUI backgrounds, DrawingSurface's DrawingColor, and so forth. The exceptions are things that only make sense with opaque color: Tint settings, and screen Fade effects.
 - Fixed Type.GetByName() functions not working again.
 - Fixed loss of precision in sprite rotation, which could cause rotating sprites by a multiple of 90 degrees to cause unexpected shifts of an image by few pixels (regression in 4.0 Alpha).
 - Fixed 32-bit images loaded with DynamicSprite.CreateFromFile() becoming completely transparent (regression since previous 4.0 Alphas).
 - Fixed GUI not redrawing properly by software renderer.


This update is likely the last change to the color format. I wish it was done altogether from the start, but somehow the changes were split into multiple updates, where one update made it proper 32-bit color but without alpha, and this update finally makes AGS respect alpha component as well.

If you're upgrading an older project, you need to know that:
- Color properties in the editor are supposed to update automatically.
- In script, if you were using Game.GetColorFromRGB when assigning colors, then no changes are necessary.
- But if you were assigning color numbers directly, then you will have to fix them all to the ARGB format: either use Game.GetColorFromRGB, or change to a number that has ARGB encoded. The easiest way to do the latter is to write color in hexadecimal notation (some graphic editors let you display colors like that): that is - 0xAARRGGBB; for example: 0xFF000000 is a opaque black, 0xFFFF0000 is a opaque red, 0x8000FF00 is a half-translucent green, and so forth. Note that if you're writing colors as a raw number, then you must define opacity (alpha) value, there's no way around it, except using Game.GetColorFromRGB that automatically makes opaque color. If you forget alpha, then your color will be treated as transparent.

[brushfe]

Hi! Thank you for the new update!

Entirely out of curiosity, is there a reason for some of the colour features being ordered RGBA, and others in ARGB? And is that purely on the backend, or will we using both formats at different times in the 4.0 editor?

[Crimson Wizard]

Entirely out of curiosity, is there a reason for some of the colour features being ordered RGBA, and others in ARGB? And is that purely on the backend, or will we using both formats at different times in the 4.0 editor?

It's ARGB when typed as a number in the script for two reasons:
- because then it matches internal representation in the engine, so less data to convert and less hassle.
- because then it's possible to cast between RGB and ARGB by a simple assignment and adding alpha with bitwise OR, e.g. "int argb = rgb | 0xFF000000". If it were RGBA, then extra conversion would be required in such case.


On another hand, it's made RGBA when you type the color in the properties in the editor, in a string like "128;64;64;255". This is made so to let Alpha be optional, in which case it's reduced to 3 numbers ("128;64;64"). If alpha were first, then it would have to be made obligatory. This is done for user convenience, in assumption that 99% of colors set this way will be opaque with default alpha of 255.
But since this form is used in GUI only, it may be changed too if found inconvenient, without affecting the game data.

[brushfe]

Awesome, thanks for such a detailed reply! It's great to hear all the details and considerations that go into something as seemingly small as this. I've not seen argb in the software I've used, so this was very educational!

Edit: the rgba default to max opacity definitely feels right!

[Baguettator]

Hi @Crimson Wizard , I encounter a crash when launching the new version (not my game, but the editor) of AGS 4.0 (I can't launch it, everytime the same crash), here's what's displayed :

https://drive.google.com/file/d/1iNk0P9ZIMU9-EgFXNHexVFDCIpjn6ZWu/view?usp=sharing

What I wanted to verify with the last version of AGS is a bug I found in the previous version : it seems overlays have a problem. I use an overlay when I right click on a button to make it "selected", it's a dynamic sprite where I draw colored lines on a transparent background. When I was on AGS 3.6, it worked perfectly, but since I'm in 4.0, it's a weird thing : the Overlay seems to take for its graphic the last sprite that was created by the game. I managed to see that the overlay takes its graphic as intended, and suddenly I create a dynamicsprite from a file and the overlay takes the same graphic whereas the graphic of the overlay doesn't use the same sprite. The funniest moment was when I wrote "display" functions at soime points to have a look of what's happening, just after the overlay is created I wrote "Display("Oh ?");", so it pauses the game with the message displayed, and I saw the overlay's graphic changed into the graphic of the message (a white square, with black borders, and "Oh ?" written inside !). Really strange...

I'm sorry, I can't develop furthermore nor give a project to test it with my code because I don't have any time right now, but I swear I don't manipulate the same dynamicsprites during the code, all I do is creating a Overlay.Graphical on which I draw something, and it suddenly changes to another sprite that was just created (just like the Display function does).

Take this as a report, I will look deepier in the code if anything is wrong, but I swear in 3.6.1 it was working perfectly, perhaps things changed in overlays in 4.0 and something's broken ?

EDIT : about my overlay problem : it seems things have changed in 4.0, so I added the "true" parameter to clone the overlay's dynamicsprite that's used to make it, because the dynamicsprite was not saved out of the function. By the way, I don't know why sprite 0 was the last dynamicsprite created in script, because sprite 0 is existing in the sprites saved in editor (it's a blank square for me). Perhaps the problem is that overlay's graphic doesn't properly resets to sprite 0 in engine ?

[Crimson Wizard]

Hi @Crimson Wizard , I encounter a crash when launching the new version (not my game, but the editor) of AGS 4.0 (I can't launch it, everytime the same crash), here's what's displayed :

https://drive.google.com/file/d/1iNk0P9ZIMU9-EgFXNHexVFDCIpjn6ZWu/view?usp=sharing

You need to install a newer VC Redistributable. This is the same case as with the latest 3.6.2 version, but I forgot to mention it here.

Either use installer program, which contains VC Redist, or download and install separately using this link:
https://download.visualstudio.microsoft.com/download/pr/5319f718-2a84-4aff-86be-8dbdefd92ca1/DD1A8BE03398367745A87A5E35BEBDAB00FDAD080CF42AF0C3F20802D08C25D4/VC_redist.x86.exe

[Crimson Wizard]

What I wanted to verify with the last version of AGS is a bug I found in the previous version : it seems overlays have a problem. I use an overlay when I right click on a button to make it "selected", it's a dynamic sprite where I draw colored lines on a transparent background. When I was on AGS 3.6, it worked perfectly, but since I'm in 4.0, it's a weird thing : the Overlay seems to take for its graphic the last sprite that was created by the game.

What does "right click to make it selected" mean in terms of script? how is overlay and dynamic sprite declared, how sprite is assigned to overlay? Please give actual details, or better post a script of what you are doing.

By the way, I don't know why sprite 0 was the last dynamicsprite created in script, because sprite 0 is existing in the sprites saved in editor (it's a blank square for me). Perhaps the problem is that overlay's graphic doesn't properly resets to sprite 0 in engine ?

Since v3.6.2 (and in 4,0) Engine no longer reset any objects to sprite 0 when the dynamic sprite is deleted. This was done on purpose, for several reasons.

[eri0o]

 I think the clone option was removed in ags4 from the graphic overlay create method. If you were using it before you now have to manage keeping the dynamic sprite for the same lifetime as needed for the overlay while it is using it.

[Crimson Wizard]

I think the clone option was removed in ags4 from the graphic overlay create method.

It was not removed. I thought about removing it once, but did not do so.