AGS 4.0 - Alpha 17 for public test

[Baguettator]

Crimson, sorry for double post, but here is what I can observe about the sprite problem :

it seems sprites rendering is "decreasing in quality". Because my scripts gives DynamicSprites to many buttons, I can see one of them in pretty good quality, and then, others are like less and less in quality. Until they become invisible. I can see as if the sprites were "cut" with a knife, making transparent lines on them. And they got more and more "cuts".

i'm not sure if it's important for you, but it seems the process is worser and worser, or better and better. I don't know... Hope it will help you !

EDIT : I just saw that the DynamicSprite.CreateFromFile function has a second optional parameter : colorformat. Should it be the issue ? In my game, I don't use this parameter (all of my DynamicSprite.CreateFromFile have only 1 parameter).

[Baguettator]

Also, not a great problem, but I noticed that if selectedBackgroundColor=0; 0; 0 for a ListBox, it makes it transparent. Before, in AGS 3.6, it was black (as intended).

(sorry for multiposts, I don't know if you are notified if I make "quick edits" in my old posts, so I create a new one, but tell me if I'm doing wrong please !)

[Crimson Wizard]

Also, not a great problem, but I noticed that if selectedBackgroundColor=0; 0; 0 for a ListBox, it makes it transparent. Before, in AGS 3.6, it was black (as intended).

This is a known problem, but I must clarify: color 0 is treated as transparent by SelectedBackgroundColor property.
The reason why "black" color worked before was that it was written in palette index other than 0 (16 to be precise), but it's not possible to do now in AGS 4, where colors in 32-bit games must be written as 32-bit RGBs.

There's no other way around this than to select slightly non-black color at the moment.

I do not know what the actual fix should be, as there's no way to select "transparent color" in these properties. Either we have to implement that somehow, or maybe there could be a separate property that sais "show or not show the selection".

Personally, I'd prefer selectable transparent color, as "selection" awhole may involve multiple things, not just the bg color, while user may want to have front color for selected items, for instance, but not bg color.

EDIT: Perhaps having 0 color be black in 32-bit would work as a quick fix. Because it's more likely that users want a bg color for selection. And if they want transparent color, they may assign the background GUI color. The only case when that won't work is if the GUI has a non-trivial background graphic...

[Snarky]

I do not know what the actual fix should be, as there's no way to select "transparent color" in these properties. Either we have to implement that somehow

Would there possibly be a need for three versions of the color picker?

- 24-bit (RGB) for colors that must be fully opaque
- 24-bit/transparent for colors that can be opaque or not drawn at all
- 32-bit (RGBA) for colors that can have alpha-transparency

[Crimson Wizard]

Would there possibly be a need for three versions of the color picker?

- 24-bit (RGB) for colors that must be fully opaque
- 24-bit/transparent for colors that can be opaque or not drawn at all
- 32-bit (RGBA) for colors that can have alpha-transparency

I am currently not certain if it is necessary to have all 3 variants and not just the fullest one.
But besides (or rather - before) the editor GUI there's a problem of
a) saving this value in game data. Right now all the colors in AGS 4 are interpreted uniformly as R8G8B8, the uniformity keeps things simple.
b) having this value in respective script properties.

Because even if you take just the single transparent color as an addition, it's not im clear how to incorporate it in the existing system without treating alpha bits as alpha. I.e. classic 255,0,255 color may be opaque too.

I had a ticket open (https://github.com/adventuregamestudio/ags/issues/2525), but it received a mixed reaction from other devs. I suggest that we need to come to a conclusion on it.

EDIT: I think (and noted in the last comment to that ticket), that I put several separate things in it by mistake. Maybe these things should be disconnected and dealt with separately.

[eri0o]

I mentioned in the ticket, what if we do that Color managed struct, all these properties are now this type, and things that need color properties would instantiate these managed structs and hold a reference internally. Then we can either make these readonly (so people must use the properties) or handle the pointer assignment as way that only copies the values (but not the pointer, or people could pass the same pointer to multiple properties and get confused when changing one property change another).

Then we could do obj.Color.RGB = 0xRRGGBB or obj.Color.ARGB = 0xAARRGGBB (or obj.Color.RGBA = 0xRRGGBBAA, and however we handle it, we hide it internally (including any mask color necessary).

[Crimson Wizard]

Above looks alright on its own (in api sense), but naturally my concern is that this will break all the people scripts... If that's fine, we could try that approach.


EDIT:
Also, I am mentioning this since you have brought the script function speed before, this will make setting colors somewhat slower, because that would require 2 function calls:
- get_Color - that returns a pointer to Color struct
- set_RGB - that sets value as rgb.

[eri0o]

Two things often appear when I use the VS Profiler in the AGS Engine when I am trying to do something visual (like the recent Particles script module)

• Engine Script API calls
• BitmapToVideoMemory methods

Other than this for some reason loops in AGS Script feel slower than they should, but these don't appear when profiling.

The Color having to be fast is an issue only in one place, which is the DrawingSurface.DrawingColor property, which is critical for doing fun effects!

I guess we could try the plain int approach and see how that works.

Whatever is done has to be throughly tested in the hard case that is a game with a linear interpolation, to see if the border of sprites are affected since the ticket with all the changes written impacts how sprite importing would happen.

[Crimson Wizard]

Whatever is done has to be throughly tested in the hard case that is a game with a linear interpolation, to see if the border of sprites are affected since the ticket with all the changes written impacts how sprite importing would happen.

I don't understand, how does that ticket impacts sprite importing?
I re-read it, and I do not see anything mentioning sprite import...
EDIT: i found something in comments, is it about sprite->texture conversion?

In any case, I am not suggesting to implement that ticket as-is. It may be split apart and done in steps, discussing and testing every step separately.

[Crimson Wizard]

EDIT 2 : new problem I encounter in AGS 4. If I attach a function On_Click on a button called "Objectif", the function is by default called Objectif_OnClick. If I rename it, let say Fouille, then in the editor I click in the "..." button of on_click function in the right panel of the gui's window (with the Objectif button selected, so in this box there is the name of its onclick function, so in my case it's written Fouille), the editor creates a new function called Fouille. Previously in AGS 3.6, he knew that there was a function called Fouille, and he didn't create a new one, he jumped to the right function directly.

@Baguettator  could you please post step-by-step instruction on how to reproduce this problem? At first I thought I got it, but trying now it works fine, so maybe I am not doing what you were doing.

[Baguettator]

Yeah, in my last working time, I didn't encounter the bug. Will notice you if I encounter again, because perhaps it was the previous AGS 4.0 version (was alpha 13 before).

The main problem for me is the dynamicsprite not rendering correctly. Hope you will fix it as soon as possible !

[Crimson Wizard]

The main problem for me is the dynamicsprite not rendering correctly. Hope you will fix it as soon as possible !

I found what was wrong with some sprites not visible after loading, but I don't know how to reproduce the other problem where sprites have lines on them.

Does this happen with particular sprites (which ones?), or after you do something to them?

EDIT:
here's the temp build which has sprite loading fixed:
https://cirrus-ci.com/task/6201304671846400

[eri0o]

@Baguettator can you make a small game and project that has the same lines issue and share the project here?

Also, does the issue happens with all three graphics drivers (D3D, OGL, and Software)?

[Baguettator]

Thanks Crimson ! Is it safe to test my game with your fixed version ?

Will have a look and tell you what I'll see

[Crimson Wizard]

I mentioned in the ticket, what if we do that Color managed struct, all these properties are now this type, and things that need color properties would instantiate these managed structs and hold a reference internally. Then we can either make these readonly (so people must use the properties) or handle the pointer assignment as way that only copies the values (but not the pointer, or people could pass the same pointer to multiple properties and get confused when changing one property change another).

Then we could do obj.Color.RGB = 0xRRGGBB or obj.Color.ARGB = 0xAARRGGBB (or obj.Color.RGBA = 0xRRGGBBAA, and however we handle it, we hide it internally (including any mask color necessary).

I've been thinking this over for several hours, and while I like the syntax, I am much concerned about the implementation particularly in AGS, and thus became reluctant to do something like that. If this was a new engine, or a different script language, then maybe it would be easier or better justified...

There are multiple issues here: the color storage in dynamic memory that has to be serialized, how game objects will be accessing these, will the Color instance duplicate color values from object's own data or read/write directly to them?
There will be a use of Color in object properties, but also in user script, then likely it has to contain all data within itself.
Then, AGS engine's code currently has a number of problems in its organization, which may make it inconvenient to bind a game class to a separate managed object. An example is GUI classes that do not have any proper "runtime" class equivalent yet which would allow to handle access to managed data. We'd need to reorganize them first prior to doing something like that.

Then, if we replace properties, then should not we also replace function arguments? There is "color" arg in some functions, like Overlay.CreateTextual. Game.GetColorFromRGB would need to return Color struct.

An idea of having separate DrawingSurface.DrawingColor as integer just for the sake of maintaining performance, while having a practical purpose, looks bad for consistency of API.

If script API uses Color struct, then users should be able to store colors in the same struct too, to keep things smooth.
But then another big inconsistency is going to be color assignment: as you say, when stored in objects they should not be shared, so assigning a Color reference to object's property will act as a copy. But if users use Color struct in their scripts, these will not copy when assigned but share a reference? Which will lead to mass confusion. So this might require designing a specific syntax approach. I'd even say: an ability to pass and assign PODs (plain structs) could come handy.

Overall this means that implementing such approach would require good amount of effort, while breaking user scripts and requiring them to change some habits.

Repeating myself, if this were a new engine then this could be justified. But what do we gain with such overhaul in the existing one? It's the ability to set "transparent color", or provide "alpha" value to color properties, where latter is not normally required alot.
Looking at the cost / benefit relation here makes me quite doubtful.

Maybe this idea could be planned to be looked into again after a bigger refactor of the game classes in the engine, as a part of the big script api overhaul, where other complex things, such as various transformation and graphical properties, would receive same change.

[eri0o]

We could use the plain int approach, this could work nice with the hex assignment. 0xaarrggbb or 0xrrggbbaa or just 0xrrggbb depending how the colors are thought through.

[Baguettator]

@Crimson Wizard Hi, I have tested with your fixed version : everything is ok !

I think the problem was "per GUI" : the first images you generate within the same GUI will have problems (invisible), and less and less problems for the followings. That's why the images became more and more visible, and only 1 or 2 of them were fully displayed.

Each time it was 3-4 GUIControls within a GUI, every control was invisible. In my Tabletop GUI, I had 40-50 controls who received DynamicSprite.CreateFromFile as graphics. The first who received the sprites were invisible, and then, the last were without problems, and at the middle, a "crescendo" of visibility

[Crimson Wizard]

I think the problem was "per GUI" : the first images you generate within the same GUI will have problems (invisible), and less and less problems for the followings. That's why the images became more and more visible, and only 1 or 2 of them were fully displayed.

The problem I fixed was loaded sprites being invisible. But I cannot explain other things.

[Crimson Wizard]

We could use the plain int approach, this could work nice with the hex assignment. 0xaarrggbb or 0xrrggbbaa or just 0xrrggbb depending how the colors are thought through.

I've been thinking about 2 approaches in regards to plain int values.

1. Have all colors treated uniformly as ARGB in all properties and arguments.

That will be most consistent, and simple to implement, but will make 0xFF... prefix mandatory for opaque colors when you define the color by hand, which may be seen as annoying by some, and be prone to user mistakes.
Two more notes here:
- Value 0 will be the easy way to set "transparent color".
- Alpha has to be in highest bits, because 0xRRGGBB may be cast (assigned) to 0xAARRGGBB, but cannot be cast to 0xRRGGBBAA (will require value conversion).
- Majority of users can just use Game.GetColorFromRGB / Game.GetColorFromRGBA functions to form colors; where old one will always return opaque color (alpha 0xFF).

--------

2. Have separate properties for RGB and ARGB.

After some hesitation, I wanted to propose this as an alternative to having a Color.RGB/ARGB syntax.
The reasoning here is that in majority of cases users will likely want opaque colors, and specify alpha in relatively very small number of situations.

The idea is to have a "argb" property pair for each xColor property. For example:
- GUI.BackgroundColor
- GUI.BackgroundColorA
- Button.TextColor
- Button.TextColorA
- DrawingSurface.DrawingColor
- DrawingSurface.DrawingColorA
etc

where Object.Color would interpret positive integer values as RGB, and let's say "-1", or any invalid value would mean "transparent color".
And Object.ColorA would interpret any value as ARGB.

The downside here is obvious duplication of each Color property (but I think there are not too many of those).
There is also a room for mistake, where one would try to assign full argb to rgb property.

The upsides are:
- This allows to restrict certain things to no alpha support, and make alpha support more explicit.
- Users are not required to remember to put alpha 0xFF when they define opaque colors.

There's a remaining question of colors as function parameters though.

[eri0o]

I see you using the word "Opaque" a lot, and so more making a note here to remind me when making docs, alpha is actually a measure (or a value?) of Opacity. Throughout AGS Script API we use Transparency, which is the inverse. A 100 value of Transparency is a 0 value of alpha.

Also with alpha in the color a lot of things that used to be blit can't be blit if the alpha is not 255.