AGS 3.6.0 - Release Candidate (RC 11)

[NeoDement]

Hi! I've noticed some dialogue timing issues when compiling my game in the latest build:

Built in 3.6.0.38:
https://cdn.discordapp.com/attachments/221048075207180288/1049333789693837332/Steamed_Hams_YpoQ56vlDg.mp4

Built in 3.5.1.15:
https://cdn.discordapp.com/attachments/221048075207180288/1049334294239264768/Steamed_Hams_m3tH5X918S.mp4

As you can hear, the audio has gone from being nearly seamless to cutting out the end of the first part of both of these two-part sentences:

"I'm from Utica and I've never heard" ... "anyone use the phrase 'steamed hams'."
"You know, these hamburgers are quite similar" ... "to the ones they have at Krusty Burger".

I've tried deleting my audio cache and vox files to completely force a rebuild, and it doesn't do anything to mitigate the problem.

[Crimson Wizard]

Hi! I've noticed some dialogue timing issues when compiling my game in the latest build:

This may be related to changes to the audio code in 3.6.0, where it actually starts the new clip playback only once the game frame updates (therefore related to fps).

Another possible cause (or maybe an additional one that sums with the first one), is that bufferization may work slightly differently.

[eri0o]

@Crimson Wizard I wonder if it could be a problem in SDL2: https://github.com/libsdl-org/SDL/issues/6326#issuecomment-1267599472

Theoretically the resampling change could mean maybe it works when using the 2.26.1 SDL dll? (https://github.com/libsdl-org/SDL/releases/download/release-2.26.1/SDL2-2.26.1-win32-x86.zip)

[Crimson Wizard]

@Crimson Wizard I wonder if it could be a problem in SDL2: https://github.com/libsdl-org/SDL/issues/6326#issuecomment-1267599472

Are not they are talking about distortions there? Here the issue is in timing of a playback start.

[eri0o]

It appears the sample rate would be slightly wrong when using the Windows in some case and the distortion is almost imperceptible except by being slightly slower from icculus description above. I had not notice it in AGS before, but thought maybe it could be relevant.

[Crimson Wizard]

It appears the sample rate would be slightly wrong when using the Windows in some case and the distortion is almost imperceptible except by being slightly slower from icculus description above. I had not notice it in AGS before, but thought maybe it could be relevant.

I would expect that the whole clip would be slower then, but in above example the difference is in the moment when the second clip starts, relatively to the previous one's end.

[NeoDement]

Sorry, I had the clips labelled backwards. I've edited the original post. That probably made diagnosing the issue confusing.

[Crimson Wizard]

Ok, so, after speaking with NeoDement a little more on Discord, it appeared that the clips were labeled wrong, the other way around, and that the problem is not what I thought at first.

The problem is that the endings of the clips are audibly cut off a bit, so that half of the last word is lost.

This is actually "opposite" (in a way) to the problem I was thinking about.

EDIT: more info: the voice clips are WAVs, and windows player also cuts them off (according to NeoDement), so this may be a WAV playback issue.

EDIT2: this sound also gets its end cut off when played as a regular sound clip, so this is not a dialog/speech problem, but a particular sound clip problem.

[Snarky]

With the replacement SDL2.dll it fails to crash.
Thanks @Crimson Wizard! Though I don't suppose that is very helpful to isolate the problem.

So, I guess we need to
1) find out what's the difference between SDL2.dll that I built and SDL2.dll that is supplied with the AGS.
2) report to SDL2 team, as this is a SDL2 error, not AGS error.

I built from a release-2.24.1 tag from their repository, and built using provided SDL.sln with MSVS 2015.

Sounds like a plan! Where does the standard SDL2.dll that comes with AGS come from? How about just using the one you built for this test?

[eri0o]

Our dll comes from SDL2 releases from their page here:

https://github.com/libsdl-org/SDL/releases

It's the asset that ends in VC.

[vga256]

First off - so glad to see how 3.6 has progressed. I took a few months away from AGS to work on other projects, and I'm glad to be back.

I'm running RC3 and I noticed a (new) bug with the SDL2 Software Renderer. There is a single line of missing pixels at the very bottom of each room. When I hover the mouse over the location, the immediate area surrounding the mouse renders properly. When the mouse leaves, the pixels return to black as shown in the link below:

Screencap of missing pixels

It seems to only affect the room background, as GUIs dragged down to this area render properly.

Let me know if you'd like me to upload a test project to demonstrate this. My project is running in 512x384, with room backgrounds of exactly 512x384.

When I switch to the OpenGL renderer, it renders properly. Testing all done in Windows 10.

[eri0o]

I managed to reproduce the above (thanks @vga256 !), I opened an issue here:

https://github.com/adventuregamestudio/ags/issues/1847

[eri0o]

@Snarky , fun stuff, I went to look and the SDL release assets don't come from their (SDL project) CI system, so I have no idea how it's actually build and I can't seem to match it exactly when building locally! I asked them about it, I will update you once I have an idea.

[vga256]

I managed to reproduce the above (thanks @vga256 !), I opened an issue here:

https://github.com/adventuregamestudio/ags/issues/1847

many thanks to you and CW for the patch. Looking forward to testing it in the next RC.

[Crimson Wizard]

There's a sudden problem found, that 3.6.0 seem to not able to load a Steam plugin correctly on Linux.
According to the log output, it finds and tries to load `libagsteam.so`, but then fails to load a `libsteam-api.so`, which is a dependency of `libagsteam.so`. The reported error is "No such file or directory", although the file is right there in the same dir.

Other plugins load fine, which makes me think this problem manifests when the plugin itself requires a second library.

I've been testing older builds of 3.6.0, but none work so far, including versions which are year and more old.

Have anyone else tried using 3.6.0 on linux with the steam plugin yet?


EDIT

So, this looks like not an engine's own problem, but the engine's build / setup issue. I still do not know what exactly did change in 3.6.0, but now it may require a different launch script on linux to make it work with the steam plugin. Namely add "LD_LIBRARY_PATH" option.

Something like:

Code: sh

if [ "$(uname -m)" = "x86_64" ]; then
    LD_LIBRARY_PATH="$scriptdir/data/lib64" "$scriptdir/data/ags64" "$@" "$scriptdir/data/"
else
    LD_LIBRARY_PATH="$scriptdir/data/lib32" "$scriptdir/data/ags32" "$@" "$scriptdir/data/"
fi

Alternatively:

Code: sh

if [ "$(uname -m)" = "x86_64" ]; then
    export LD_LIBRARY_PATH="$scriptdir/data/lib64":$LD_LIBRARY_PATH
    "$scriptdir/data/ags64" "$@" "$scriptdir/data/"
else
    export LD_LIBRARY_PATH="$scriptdir/data/lib32":$LD_LIBRARY_PATH
    "$scriptdir/data/ags32" "$@" "$scriptdir/data/"
fi

We'd need to adjust the Editor to generate a launch script with this addition.

[Crimson Wizard]

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

Editor:
- Fixed project tree items not updated when changing item ID.

Engine:
- Various performance optimizations for both raw drawing and texture updates (Direct3D/OpenGL). (This will be mostly noticeable in high-resolution games.)
- Fixed software renderer may have an unpainted black line at the bottom, if there's a GUI or Overlay positioned partially offscreen.
- Fixed Parser.Said() could lead to a program crash in case there are space-separated words following the comma (e.g. "climb,get in bed").


Reported issues remaining:
* GUI controls incorrectly blend (mix colors) with the parent GUI if parent's transparency is anything but 0. Unfortunately this takes longer than expected to fix, because some of the new feature should be rewritten. This is related to the rendering performance optimization, which proved to be too significant to drop.
* Direct3D is said to still be not fully stable when alt+tabbing in exclusive fullscreen mode: https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-release-candidate-rc1/msg636650995/#msg636650995
* Linux port cannot load a AGSSteam plugin. There's a workaround mentioned right above this post.

[Crimson Wizard]

Updated to RC5 (3.6.0.40)
(use download links in the first post)

Editor
- Fixed games built for Linux cannot load AGSSteam plugin.

Engine:
- Fixed GUI controls incorrectly blended with gui background if GUI.Transparency is > 0.
- Optimized memory usage in Direct3D/OpenGL renderers related to plugin raw drawing.
- Fixed Direct3D/OpenGL renderers were displaying plugin's raw drawings in a wrong position in the scrolling rooms, if the drawing was done on AGSE_PRESCREENDRAW or AGSE_POSTROOMDRAW events.

Plugins:
- Fixed SnowRain plugin drawing particles only in 320x200 bounds.


Reported issues remaining:
* Direct3D is said to still be not fully stable when alt+tabbing in exclusive fullscreen mode: https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-release-candidate-rc1/msg636650995/#msg636650995

[Crimson Wizard]

EDIT: Had to reupload the RC5 update once more, with 1 extra bug fixed. (details under spoiler)

Spoiler

So, there's immediately a new bug that I did not notice in time: the GUIs have few pixels cut off from their top and right edge.
OpenGL has a slight difference: looks like it's cut from top and right edge.
EDIT: hmm, or rather gui elements are shifted up or down. Also, not sure why, but it looks like this only happens to buttons or backgrounds made of sprites.

Easily seen with the iconbar in Sierra template, where buttons are suddenly not centered in Direct3D, or cut from the top in OpenGL.

EDIT: I found an approximate reason, will need to make a quick fix and reupload a release.

EDIT: Ah, so this is a stupid rounding error, which creates a 1 px mistake if the GUI has non-even size.

[close]

[rongel]

Thanks for the new Release Candidate version!

I noticed a possible issue, at least I'm not sure what else could have caused it other than updating to the new version. So here goes:

So earlier I used the version 3.6.0.37 and everything worked well. I have a GUI button that has a normal image, pushed image and a mouse over image. After I click the button, I make it invisible. Then, if I make it visible again, it will show the normal image (it's reseted to the default look). So all is well.

After updating to 3.6.0.40, the button behaviour changed. When I make the button visible again after clicking it and hiding it, it still displays the mouse over image (the button is highlighted). This happens even if the mouse isn't over the button. The only way to "reset" the button to the normal image, is to hover the mouse over it again, and then move the mouse away from it. This behaviour might have started already in the previous RC 4 version.

Hope this makes sense! It's a small issue, but seems very tricky to fix. Maybe someone else could test this? Not 100 % sure what could have caused this change, but updating the engine is my guess. Thanks!

EDIT: Found another instance of this bug: I have a map gui that has location buttons (with normal images, pushed images and a mouse over images). When I click a button, the map gui closes and player is teleported to the new room. When I enter the map again, the button I pressed still uses the mouse over image, even when to mouse is nowhere near it.

[Crimson Wizard]

So earlier I used the version 3.6.0.37 and everything worked well. I have a GUI button that has a normal image, pushed image and a mouse over image. After I click the button, I make it invisible. Then, if I make it visible again, it will show the normal image (it's reseted to the default look). So all is well.

After updating to 3.6.0.40, the button behaviour changed. When I make the button visible again after clicking it and hiding it, it still displays the mouse over image (the button is highlighted). This happens even if the mouse isn't over the button. The only way to "reset" the button to the normal image, is to hover the mouse over it again, and then move the mouse away from it. This behaviour might have started already in the previous RC 4 version.

I cannot reproduce this, in a test game I made button acts properly when becoming visible again. I tried both making button invisible and whole gui invisible (and visible again).

I may mention that between 0.37 and 0.40 I did one fix related to button update after interface gets disabled and enabled (on game pause/unpause). Maybe this is connected somehow, but so far I cannot tell what went wrong.

Can I see your game somehow, is it available for download?