AGS 3.6.1 - Release Candidate (RC 6)

[Dave Gilbert]

Ah. Good question. I tested it and the problem seems to have gone away when I switch to "nearest neighbor." But since the game is so high res, the nearest neighbor filter scales the character sprites *horribly* when in windowed mode (especially when the monitor is 1920 x 1080, the window size is smaller than the game's native resolution) so I prefer to stick with linear interpolation.

[Crimson Wizard]

Strictly speaking, for the 1920x1080 game "render sprites at screen resolution" setting is useless, unless the monitor is much bigger (2k, 4k).

I will try to investigate this problem again, but last time I failed to get any fixing ideas in the engine, so cannot promise anything.

[Dave Gilbert]

4K monitors are quite common now! But keeping it in "linear interpolation" mode fixes any problem.

For my end, I was experimenting with zooming in, and I noticed it got very pixellated when "render at screen resolution" was disabled, and looked much better when it was ticked. But I was just playing around. I can just as easily do without it.

[Crimson Wizard]

4K monitors are quite common now! But keeping it in "linear interpolation" mode fixes any problem.

I am confused, earlier you said that the problem appears with "linear interpolation"?

[Dave Gilbert]

The problem occurs with linear interpolation AND "render at screen resolution". If I untick "render at screen resolution", the lines don't appear in windowed mode even if I'm using linear interpolation.

What I was referring to is if the game is running on a 4K monitor, keeping it in linear interpolation mode still looks decent.

[Crimson Wizard]

What I was referring to is if the game is running on a 4K monitor, keeping it in linear interpolation mode still looks decent.

Ah, alright.

Have you tried "smooth scaled sprites" option? I think it uses linear interpolation for scaled sprites, while keeping the final game scaling using nearest neighbour.
This may or may not improve things with zooming things even without "render in screen resolution", but I cannot predict how that will look like.

[Crimson Wizard]

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

Engine:
- Updated to SDL 2.28.5 and SDL_Sound 2.0.3+.
- Display critical alerts as message boxes on all platforms that support that (unless engine is run with "--no-message-box" parameter).
- Fixed failing comparison between character[] script array's element and a Character* pointer (regression since the recent 3.6.1 RC).

iOS:
- Fixed some game elements could potentially be rendered incorrectly in "Render in screen resolution" mode.
(NOTE: this is NOT related to Dave Gilbert's problem described above.)

[noblonski]

hello, something probably pretty specific happened to me after upgrading from 3.6.0 to RC2 (haven't tried RC3 yet): i'm using the FloatingHotspot Module by Calin Leafshade and in order to not show any hotspots when the interface is inactive,

repeatedly_execute_always

Code: ags

if (IsInterfaceEnabled()== false) FloatingHotspot.SetMaxWidth(0);
else FloatingHotspot.SetMaxWidth(100);

worked like a charm in 3.6.0. after the upgrade it seems as if it was not set to 0 as all the hotspots were still displayed when the interface was inactive but with something like 10 px or so (the hotspots were still displayed but vertically). I'm already using another dirty workaround by doing this instead

Code: ags

if (IsInterfaceEnabled()== false) FloatingHotspot.SetVerticalOffset(400);
else FloatingHotspot.SetVerticalOffset(0);

[Crimson Wizard]

@noblonski

I found the module here:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-floating-hotspot-label/msg636606047/#msg636606047

When I check the code for the SetMaxWidth, here how it looks like:

Code: ags

static void FloatingHotspot::SetMaxWidth(int width)
{
  MaxWidth = _clamp(width, 10, System.ViewportWidth);
}

In other words, it limits hotspot to the range 10 -> ViewportWidth.

I am not sure how this may have different effect between 3.6.0 and 3.6.1.
Could there be another reason why it became invisible in 3.6.0?

On a side note, I think it's a design flaw that there's no function that would hide this overlay explicitly, like FloatingHotspot.SetVisible.

[noblonski]

that would explain THAT 
i have no idea why it worked (or in this case rather didn't work) in 3.6.0
maybe a bug that worked in my favour haha. just checked the script in the 3.6.0 and it's the same.
thanks a lot.

[Crimson Wizard]

The cases like this may be difficult to diagnose within a full game. It would be more convenient if one makes a dummy test game with just this module and commands that set it up, and does this SetWidth change.
If that alone does not work, then keep copying any parts of the code that may affect the module or overlay that it creates.

[Crimson Wizard]

@Dave Gilbert, there's a good chance that I found the fix for these "lines" around the objects.

https://github.com/adventuregamestudio/ags/pull/2315

The test build will be found here in a short while:
https://cirrus-ci.com/task/6006716257533952

[Dave Gilbert]

Oh awesome! Thanks! I'll nab this and test in an hour or two when I'm at my desk.

[Dave Gilbert]

I confirmed with CW already, but for everyone else: this seems to have fixed the issue for me. Thank you!

[edmundito]

@Crimson Wizard The links on the first post need to be updated. Part of the URL path is still pointing to the previous version so the files are not found.

[Crimson Wizard]

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

Editor:
 - Fixed "Auto-number speech lines" and "Create voice acting script" operations failing if a Character's name contains underscore.

Compiler:
 - Fixed escaped character literals not being parsed correctly. This makes character literals like '\n' and '\t' actually work in script.

Engine:
 - When Texture Cache is comparable in capacity to the Sprite Cache, the engine will skip storing raw sprites in the cache when creating textures from them, in order to avoid meaningless duplicate memory usage.
 - Ensure that when Overlays have identical ZOrder they will be sorted in the order of their creation. Besides convenience, this is also meant to restore historical behavior from before Overlay.ZOrder property was introduced.
 - Improved OpenGL texture management, which should result in less system and video memory spent on sprite textures.
 - Fixed OpenGL renderer causing scaled sprites to have colored outlines sometimes while using Linear filter.

Windows:
 - 32-bit Windows engine is now built as "large address aware" program, which will allow it to use up to 3 GB of RAM on 32-bit systems and 4 GB of RAM on 64-bit systems (was 2 GB previously).

WinSetup:
 - Added options to disable particular graphic drivers and graphic driver selection.

[Dave Gilbert]

Woo! Dutifully nabbed. So far so good. Will let you know if any weird issues crop up.

[cat]

I have a very weird issue with 3.6.1 (RC2 and RC4) related to "ShowPlayerCharacter". When I set this to false in my starting room (a title screen) the mouse cursor is invisible. When I move the cursor over GUI buttons, the hover effect is activated and I can click the button. When I now click exit with my invisible mouse cursor, the exit confirmation dialog of the BASS template shows up and suddenly the mouse cursor is back. When I now click "Play" i.e. cancel the quit dialog, the cursor is invisible again. When I click to start the game (change to room1) the cursor is still invisible, even though this room has a visible player character.
I can directly relate this to the "ShowPlayerCharacter" setting of the starting room. I searched the manual but wasn't able to find anything related to this setting. Is it even accessible in code?

I mitigated the problem by moving the player character outside the screen instead of using the setting.

[Crimson Wizard]

I have a very weird issue with 3.6.1 (RC2 and RC4) related to "ShowPlayerCharacter". When I set this to false in my starting room (a title screen) the mouse cursor is invisible.
<...>
I can directly relate this to the "ShowPlayerCharacter" setting of the starting room. I searched the manual but wasn't able to find anything related to this setting. Is it even accessible in code?

According to the engine code, "ShowPlayerCharacter" disables the "Walkto" cursor mode.
Accidentaly, BASS template uses "Walkto" mode as default, even though it's just a pointer graphic.

Possible solutions are:
1. Fix BASS template to use another default cursor mode instead, like Interact or Pointer.
2. Enable "Walkto" mode right after room is loaded (using Mouse.EnableMode().

[cat]

According to the engine code, "ShowPlayerCharacter" disables the "Walkto" cursor mode.
Accidentaly, BASS template uses "Walkto" mode as default, even though it's just a pointer graphic.

Ah, this was the missing information. I suspected that it might be related to the BASS template. AGS is mostly built for the Sierra interface with all those mouse modes.

Possible solutions are:
1. Fix BASS template to use another default cursor mode instead, like Interact or Pointer.
2. Enable "Walkto" mode right after room is loaded (using Mouse.EnableMode().

I think this should be fixed in the BASS template, because it is shipped with AGS and a very popular one. However, I would be cautious just changing the default cursor mode. Who knows what else might break when doing this.

At least, now the problem is documented somewhere. The next person searching the forums for it will find this thread and possible workarounds.