AGS 4.0 - Alpha 23 for public test

[eri0o]

What property is TextProperties? Do you mean specifically Custom Properties? Where is the "é" character used? Is it in the value? Can you show a screenshot of what happens?

[Crimson Wizard]

Small issue concerning TextProperties : for hotspots, if I use the 'é' letter, after closing the editor and relaunch it, the letter is not normally displayed in game (nor in the editor in fact). Seems to be a formating issue.

Entering `é` letter in Hotspot description turns into what seems like a utf-8 combination of characters after reloading the game.
Same occurs to the Room Object's description.
Same occurs to the custom property values in the hotspots and objects.

At the same time, non-room objects, like Characters, work fine.

This does not seem to happen in 3.6.2.

A quick guess: this is related to the new room serialization in ags4. Possibly something is missing or broken in their serialization of text properties of the room elements.

EDIT: These texts look correct inside Room's data.xml, and it's saved as UTF-8. Which means that they get broken when loading rooms back into the editor.

EDIT2: It turned out that all this time AGS 4 Editor was loading rooms in ANSI mode. Any unicode text in room data (not scripts) was lost.

[eri0o]

Uhm, from looking at SerializeUtils (the last lines of the file), it looks like we manually insert the UTF8 declaration, but looking this stackoverflow answer, it looks like there is a way to set so itself will write such header somehow? Also, from the comments in this question in SO, it seems that .NET uses UTF-16 strings by default? (I may be misunderstanding)

[Crimson Wizard]

Uhm, from looking at SerializeUtils (the last lines of the file), it looks like we manually insert the UTF8 declaration, but looking this stackoverflow answer, it looks like there is a way to set so itself will write such header somehow? Also, from the comments in this question in SO, it seems that .NET uses UTF-16 strings by default? (I may be misunderstanding)

RoomComponent was using its own procedure, where it loaded xml as bytes furst, and then converted these bytes to text using "default encoding", which is current ANSI codepage. Hence utf-8 was lost in the process.

EDIT: Yes, .NET uses UTF-16 strings in memory. Whenever we save or load text, we have to convert between our format and UTF-16.


EDIT2:
Actually, I am confused by the manual addition of UTF-8 as well. Need to compare this with the 3.* version, because the encoding should depend on the "Text format" property in the project (so long as we still support ASCII mode).

[Baguettator]

Oh my mistake, I'm sorry, I wrote so quickly that I again forgot to precise some informations...

Yes it's about Customproperties, applying to Hotspots. It seems Crimson has identified the problem though, so glad to see that it has been found

[Crimson Wizard]

I fixed this texts problem, but there's a significant change coming along, so it's better to wait until the proper update release.

[Baguettator]

Hi,

Is there anything broken about drawing transparent color on drawing surface in last version of AGS4.0 ? If I remember well, in AGS 4 was implemented the fact that drawing transparent color made the drawing surface really transparent ("erasing" anything that was drawn there).

Here is my code :

Code: ags

void FondRoomExp()
{
  int w;
  if (gTextesExpedition.Visible==true) w=750;
  else w=1920 - mission.x - 10;
  DynamicSprite *ds=DynamicSprite.CreateFromFile("$INSTALLDIR$/Sprites/Boutons/Fond_Exp.bmp");
  DrawingSurface *d=ds.GetDrawingSurface();
  d.DrawingColor=COLOR_TRANSPARENT;
  d.DrawRectangle(mission.x, mission.y, mission.x + w, mission.y + 750);
  d.Release();
  
  o_roomexp=Overlay.CreateGraphical(0, 0, ds.Graphic, true);
  o_roomexp.ZOrder=1;
}

function on_key_press(eKeyCode keycode, int mod)
{
  if (keycode==eKeyO)
  {
    if (o_roomexp.Valid==true)
    {
      o_roomexp.Remove();
      Display("Enlevé !");
    }
    else
    {
      FondRoomExp();
      Display("Mis !");
    }
  }
}

So I'm creating a  dynamic sprite from a sprite (mainly white with some pictures on it, no transparent zones on it), then I'm trying to draw a transparent square  near the center to allow seeing through that zone (there is another GUI behind and I want it to be able to move without seeing it on left or right). The overlay is just a way to "hide" the GUI in some places of the screen.

I know there are numerous ways to code it (by drawing part of the sprite on other GUIs' backgrounds for example, so that they are not transparent and we can't see the GUI moving behind them), but I thought using an overlay was easier, simpler and easy to manipulate even if ideas change a bit after time.

But I thought drawing a transparent square will make this square really transparent. Instead of that, the transparent square doesn't erase anything. The overlay completely hides the GUI behind. So I made a on_key_press debug to remove the overlay, in case of. And the GUI is really behind. So...

Is anything broken ? For testing, I changed the drawing color to something "normal" (like a beautiful green flashing eyes), and the square is placed exactly where intended.

[Crimson Wizard]

Is there anything broken about drawing transparent color on drawing surface in last version of AGS4.0 ? If I remember well, in AGS 4 was implemented the fact that drawing transparent color made the drawing surface really transparent ("erasing" anything that was drawn there).

Because in AGS 4 now any drawing works as "alpha blending", using transparent color normally does not draw anything.
If you want to cut shapes using transparent color, then you must set DrawingSurface.BlendMode to eBlendCopy.

[Baguettator]

Oh, of course, I forgot about it. Sorry for my message

[Crimson Wizard]

I've been thinking that maybe we can add a compatibility fix, and let engine override BlendMode under following conditions:

- DrawingColor is COLOR_TRANSPARENT
- BlendMode is Normal.
- A geometry shape function is called (DrawLine, DrawPixel, DrawRectangle, etc)

In such case the engine will use BlendMode Copy just for the current operation (without changing properties).

But my concern is that if we do this, then users will never notice anything and won't know about the new rules.

What would others think about this?

[Baguettator]

For me it seems fair, because it allows to not change (or check) everytime BlendMode each time we use DrawingSurface.

But as a beginner coder, my point of view is maybe a bit strange !