Cutscene dialogue disappears too quickly

[bergfried]

First of all, thanks for this awesome game! (I'm trying since 1.3 but never managed to beat it but who cares as long as I'm having fun?! ;D)

The text that appears during the cutscenes (for example, when replaying the intro in the Media Room), however, is unenjoyable in my case. It seems that the only text visible at any time during the cutscene is the part of the text that is being animated. As soon as the animation stops, the new line of text that just appeared disappears immediately as a whole. When I press a button, only the next part appears, but, again, only for as long as it is being animated.

When the screen should be full of text, I presume (because I do not see any text at all at that moment) that pressing a button is supposed to make it disappear. What actually happens is that it reappears in its entirety, just so it can disappear with a nice animation.

In other words, I never get the time to read a line of text after it has been animated into existence. It's either part of some animation or not there at all. Keeping the Ctrl key pressed filles the whole screen with text because and/or while it is being animated. Even then, lines that are not being animated anymore will disappear quickly. IIRC, even short new lines at the bottom will completely disappear while the old text above it is still there, visibly vanishing.

I tried some input and video options but to no avail. Fullscreen and various special effects do not seem to make a difference, neither does turning off gamepad input.

Terminal output:

W: config>config_set: Unknown setting 'fullscreen_desktop_mode'
W: config>config_set: Unknown setting 'vid_late_swap'
W: config>config_set: Unknown setting 'gamepad_axis_lr_free_sensitivity'
W: config>config_set: Unknown setting 'gamepad_axis_ud_free_sensitivity'
W: renderer/glcommon/opengl>glcommon_ext_texture_format_rg8_srgb: Extension not supported
W: renderer/glcommon/opengl>glcommon_ext_texture_format_etc1: Extension not supported
W: renderer/glcommon/opengl>glcommon_ext_texture_format_etc1_srgb: Extension not supported
W: renderer/glcommon/opengl>glcommon_ext_texture_format_pvrtc: Extension not supported
W: renderer/glcommon/opengl>glcommon_ext_texture_format_pvrtc2: Extension not supported
W: renderer/glcommon/opengl>glcommon_ext_texture_format_pvrtc_srgb: Extension not supported
W: renderer/glcommon/opengl>glcommon_ext_texture_format_atc: Extension not supported
W: renderer/glcommon/opengl>glcommon_ext_texture_format_fxt1: Extension not supported
E: util/kvparser>parse_keyvalue_file_cb: VFS error: Node 'res/shader/global.pp' does not exist
E: resource>load_resource_finish: Failed to load postprocessing pipeline 'global' from 'res/shader/global.pp'
taskmgr:global/23  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: abstract_brown: Mip level 1 dimensions are not multiples of 4 (600x762); number of levels reduced 11 -> 1
taskmgr:global/26  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: menu/mainmenubg: Mip level 2 dimensions are not multiples of 4 (450x300); number of levels reduced 11 -> 2
taskmgr:global/41  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: marisa_bombbg: Mip level 2 dimensions are not multiples of 4 (480x262); number of levels reduced 11 -> 2
taskmgr:global/28  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: stage3/spellbg2: Mip level 2 dimensions are not multiples of 4 (162x150); number of levels reduced 10 -> 2
taskmgr:global/41  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: cutscenes/opening/01: Mip level 3 dimensions are not multiples of 4 (200x150); number of levels reduced 11 -> 3
taskmgr:global/27  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: cutscenes/opening/02: Mip level 3 dimensions are not multiples of 4 (200x150); number of levels reduced 11 -> 3
taskmgr:global/39  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: cutscenes/locations/hakurei: Mip level 3 dimensions are not multiples of 4 (200x150); number of levels reduced 11 -> 3
taskmgr:global/11  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: cutscenes/reimu_bad/01: Mip level 3 dimensions are not multiples of 4 (200x150); number of levels reduced 11 -> 3
taskmgr:global/4   W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: cutscenes/opening/04: Mip level 3 dimensions are not multiples of 4 (200x150); number of levels reduced 11 -> 3
taskmgr:global/31  W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: cutscenes/opening/03: Mip level 3 dimensions are not multiples of 4 (200x150); number of levels reduced 11 -> 3
W: resource>_res_get_prehashed: bgm 'intro' was not preloaded
W: resource>_res_get_prehashed: shader program 'text_cutscene' was not preloaded
W: resource>_res_get_prehashed: shader program 'blur9' was not preloaded
W: resource>_res_get_prehashed: shader program 'cutscene' was not preloaded
W: resource>_res_get_prehashed: texture 'cutscenes/paper' was not preloaded
W: resource/texture_loader/basisu>texture_loader_basisu_sanitize_levels: cutscenes/paper: Mip level 3 dimensions are not multiples of 4 (200x150); number of levels reduced 11 -> 3

Using 1.4.1 on Arch Linux (native), see PKGBUILD for details: https://aur.archlinux.org/packages/taisei

[Akaricchi]

Are you on nvidia by any chance? Sounds like it could be a shader bug (or a driver bug…). Can you please post your ~/.local/share/taisei/log.txt?

[bergfried]

Are you on nvidia by any chance?

Nope, all AMD.

Can you please post your ~/.local/share/taisei/log.txt?

taisei.log.txt (slightly redacted)

[Akaricchi]

Hi, sorry for the delay.

I can't reproduce this, but I think I have an idea of what the problem might be. Please test this potential fix and let me know if it works.

Copy-paste this into a terminal:

mkdir -p ~/.local/share/taisei/resources/shader && wget -O ~/.local/share/taisei/resources/shader/text_cutscene.frag.glsl https://raw.githubusercontent.com/taisei-project/taisei/8c3d6f25182a8129eedd7f92973c9a812faffa12/resources/00-taisei.pkgdir/shader/text_cutscene.frag.glsl

This should download the patched shader from 8c3d6f2. Run the game and see if the issue persists.

[bergfried]

UPDATE See below.

Thanks. It certainly does change things. As in, as soon as I start the cutscene, everything just turns black and stays this way. I cannot even interact with it normally (closing the application via window manager shortcut does not work anymore, and keeping Ctrl pressed to fast-forward the dialog does not seem to work, either). Trying to SIGKILL the application based on the fullscreen window I select only seems to kill a part of it, because I can still hear the background music (which works, by the way).

Even before I send that SIGKILL, a dialog box appeared in the background that basically repeats the FATAL line (line 349) in the log (see below). As soon as I click "OK", the dialog disappears and the music stops, but the taisei process still keeps running in the background. SIGTERM is not enough to make it go away, so a SIGKILL is needed.

Not sure but I guess master and staging have diverged too much from the v1.4.1 commit my version is based on so the glsl you proposed does not work with v1.4.1.

Log file: taisei.log.txt

UPDATE: I patched the glsl file you proposed locally by undoing the change that came with 26959c4a1f299f13fb083ccd21b6d6fd539e0ae4. As in, I replaced tex_aux0 with tex_aux[0]. And now it works with my otherwise unchanged v1.4.1! Not sure how a * 0.95 can have that much of an influence but it does the trick. Thank you very much!

(Now, I only need to remind myself to remove the local glsl file when I switch to the next release …)

[Akaricchi]

I replaced tex_aux0 with tex_aux[0]. And now it works with my otherwise unchanged v1.4.1! Not sure how a * 0.95 can have that much of an influence but it does the trick. Thank you very much!

Ah sorry, I forgot to account for that change.

Not sure how a * 0.95 can have that much of an influence but it does the trick. Thank you very much!

The problem is that the smoothstep() function has undefined behavior when the first two parameters (edge0 and edge1) are equal. That happens in this case when o becomes 1. The multiplication is a workaround to avoid that without noticeably changing the look of the effect. Another solution could be to add a special case for if(o == 1) mask = 1.

Either way, glad that it's resolved now.

(Now, I only need to remind myself to remove the local glsl file when I switch to the next release …)

Don't worry, it'll remind you by breaking again because of that tex_aux0 change ;)

[bergfried]

Not sure how a * 0.95 can have that much of an influence but it does the trick. Thank you very much!

The problem is that the smoothstep() function has undefined behavior when the first two parameters (edge0 and edge1) are equal. That happens in this case when o becomes 1. The multiplication is a workaround to avoid that without noticeably changing the look of the effect. Another solution could be to add a special case for if(o == 1) mask = 1.

I see. That might explain why we were observing different things. Also, if I understand it correctly, the * 0.95 fix is going to break again as soon as o == 0.0 or slide_factor == 0.0 for whatever reason. Which is why I would prefer a more explicit fix, something like this (untested!):

float edge0 = slide_factor * o * o;
float edge1 = slide_factor * o;
if (edge0 == edge1) {
    // avoid undefined behavior
    mask = 1.0;
} else {
    mask = 1.0 - smoothstep(edge0, edge1, mask + (slide_factor - 1.0) * xpos);
}

But maybe that's just me.

(Now, I only need to remind myself to remove the local glsl file when I switch to the next release …)

Don't worry, it'll remind you by breaking again because of that tex_aux0 change ;)

Looking forward to it. :P

[Akaricchi]

I see. That might explain why we were observing different things. Also, if I understand it correctly, the * 0.95 fix is going to break again as soon as o == 0.0 or slide_factor == 0.0 for whatever reason. Which is why I would prefer a more explicit fix, something like this (untested!):

I'll double-check later, but o should never be 0 — the text should just not be drawn in that case at all. slide_factor is a constant defined in the shader, and it doesn't make sense to ever set it to 0. If o could be 0, then your fix would not be correct either, because mask would have to be set to 0 in that case (or the fragment should be completely discarded). But if o is ever 0, that's a bug in the application code and it should be fixed there.

I didn't use a branch here mostly because non-uniform control flow in fragment shaders traditionally tends to be bad for performance. o comes from an instanced attribute, so it's technically non-uniform here. This isn't always true though, and in this particular case, it probably doesn't matter, especially on modern hardware. It's probably ok to change it into a conditional. The multiplication is just a quick fix that I didn't think about too much.

[bergfried]

I'll double-check later, but o should never be 0 — the text should just not be drawn in that case at all. slide_factor is a constant defined in the shader, and it doesn't make sense to ever set it to 0. If o could be 0, then your fix would not be correct either, because mask would have to be set to 0 in that case (or the fragment should be completely discarded).

I see. My bad.

I didn't use a branch here mostly because non-uniform control flow in fragment shaders traditionally tends to be bad for performance.

You are right, and that is exactly what came to mind way after I posted my reply. Sorry, my bad, again. I am just more used to writing code in a different style. (Also, now that I think about it, testing for equality, as I proposed, might be a bad idea in itself for complicated reasons.)

The multiplication is just a quick fix that I didn't think about too much.

As long as it works and everybody involved and reading the code without any comments immediately understands that that * 0.95 is magic that protects humankind from evil yōkai, everything will be fine, I guess. :)

(Okay, now let's overthink the problem. For the current fix to work, o must not be too close to 1.0 / 0.95. I did not check the surrounding code so no idea whether it will ever happen, but it probably won't, so, all good. Now, let's try to get closer to 1 to reduce some of the theoretical side effects of that fix. If float means IEEE 754 (or any later revision) single precision, there will be 24 mantissa bits. Not sure what exactly is about to happen to the values later, but assuming that about half of the bits will be preserved, using a factor of 1 - 2 ** -12 or 0.999755859375 should still be safe …)