Opened 3 years ago
Last modified 2 years ago
#13169 new defect
MYST3: missing scene transition effect on PowerPC (big-endian) machines on all OSes
Reported by: | kas1e | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | Engine: Myst3 |
Version: | Keywords: | big endian, BE, Myst3, AmigaOS | |
Cc: | kas1e | Game: | Myst 3: Exile |
Description (last modified by )
While testing AmigaOS4 builds of ScummVM (v2.5.0 and daily build from 25.12.2021) find out a rendering issue.
The issue is that switch between scenes in Myst3 does not have that nice cross-fade effect when one image is fade out and another one fade it, making one image replace another with tasty cross-fade effect. Instead, we have or just a white screen for a time while the cross-fade effect should happen or a bit of visual trash (depends on the drivers we use).
If we use an older version of our drivers called MiniGL we have such a visuall mess:
https://youtu.be/ndhmxNXlLH4?t=78
If watch carefully between switching of scenes then instead of effect we have some purple vertical lines all over the screen for a time of effect. Mean that no-cross-fade happens, but nothing instead and unitialized stuff have place.
And that if I use another more modern OpenGL driver called GL4ES:
https://youtu.be/KiDJ3ox51lU?t=37
There all visibly better. Just instead of a color mess, we have a white screen for the time while the effect should happen and when a new scene happens.
When I test the same version of the game but on win32/x64 then all fine means it's probably a Big-Endian issue.
If needs any more details or tests just ask :)
Thanks!
Change History (22)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
Yes, can confirm that on AmigaOS4 effect also works in software mode.
That probably mean that OpenGL-based code in Myst3 needs to be byte-swapped when handling of this effect happens ? (software renderer seems to be Endian aware and that is why it works imho?)
comment:3 by , 3 years ago
Summary: | Myst III Exile: missing scene transition effect on PowerPC (big-endian) machines under AmigaOS4 → Myst III Exile: missing scene transition effect on PowerPC (big-endian) machines on all OSes |
---|
comment:4 by , 3 years ago
At the moment we only reach to the point that seems that it can be be a bug in glCopyTexImage2D() in all 3 realisation of GL drivers : MiniGL, OGLES2 and MorphOS GL.
To be 100% sure i will try to build ScummVM for LinuxPPC under MESA to see how it will reacts there. If bug still will be there, then it probabaly something about Endianes, if bug will be not there, then it will mean indeed bug in all the amigaos4 and morphos driver realisations.
follow-up: 6 comment:5 by , 3 years ago
I managed to reproduce the white screen bug using GL4ES and Mesa on Linux.
It's due to the fact that GL4ES doesn't mark its texture object as valid when using glCopyTexImage2D
.
A call to glTexImage2D
before corrects the problem although it shouldn't be needed.
What happens if you use the following patch?
Here, with GL4ES it works.
-
engines/myst3/gfx_opengl_texture.cpp
a b void OpenGLTexture::copyFromFramebuffer(const Common::Rect &screen) { 135 135 internalHeight = upperPowerOfTwo(height); 136 136 internalWidth = upperPowerOfTwo(width); 137 137 } 138 138 139 139 glBindTexture(GL_TEXTURE_2D, id); 140 glTexImage2D(GL_TEXTURE_2D, 0, internalFormat, internalWidth, internalHeight, 0, internalFormat, GL_UNSIGNED_BYTE, nullptr); 140 141 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); 141 142 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); 142 143 143 144 glCopyTexImage2D(GL_TEXTURE_2D, 0, internalFormat, screen.left, screen.top, internalWidth, internalHeight, 0); 144 145 }
comment:6 by , 3 years ago
@lephilousophe
What happens if you use the following patch?
Here, with GL4ES it works.
Thanks for taking more attention on it ! Much apprecated :) But we do test yesterday with you the same path and ut wasn't working :) But i tried just in case another time, exactly what you quote there : nope, no cross-fade effect visibly.
Maybe you reproduce different "white" bug ? My one as shown on video is more like missng cross-fade effect and instead one image just overwrte another one, but in the time where we should have cross-fade we have nothng (or mess/white/etc depends on the driver)
comment:7 by , 3 years ago
Description: | modified (diff) |
---|
comment:8 by , 3 years ago
PS. I tested it on MiniGL (opengl) and OGLES2 (opengl with shaders) both have issue even after path. But didn't tested with GL4ES at the moment.
comment:9 by , 3 years ago
Same here with path, no more glish during transition.. but no transition (same as Software render).
comment:10 by , 3 years ago
@BeWorld2018
Yeah, effect didn't works, just when it should happens in this time we randomly have stuff put on screen, and depends on drivers/memory layouts we have or trash, or white , or anyting else. But main point is that we have no cross-fade effect by some reassons.
comment:11 by , 3 years ago
@kas1e and @BeWorld2018
I don't understand how it renders now with the patch.
Is it possible to make a screenshot in the middle of the transition?
If it's too fast, you can change the setting in scummvm.ini file by setting transition_speed to something like -400 (note the minus sign).
Another test is possible although this looks more like a workaround.
By looking at MiniGL code, one can see that glReadPixels
calls W3D_FlushFrame
and W3D_WaitIdle
before reading pixels. This is not done in glCopyTexImage2D
.
The main problem with the workaround is that I am not sure MiniGL will issue the W3D_FlushFrame
when doing glFinish
.
-
engines/myst3/gfx_opengl_texture.cpp
diff --git a/engines/myst3/gfx_opengl_texture.cpp b/engines/myst3/gfx_opengl_texture.cpp index bae85ba2e7f..40f07c44dfe 100644
a b void OpenGLTexture::copyFromFramebuffer(const Common::Rect &screen) { 139 139 glBindTexture(GL_TEXTURE_2D, id); 140 140 glTexImage2D(GL_TEXTURE_2D, 0, internalFormat, internalWidth, internalHeight, 0, internalFormat, GL_UNSIGNED_BYTE, nullptr); 141 141 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); 142 142 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); 143 143 144 // Ensure everything is rendered before capturing framebuffer 145 glFinish(); 146 144 147 glCopyTexImage2D(GL_TEXTURE_2D, 0, internalFormat, screen.left, screen.top, internalWidth, internalHeight, 0); 145 148 } 146 149 147 150 } // End of namespace Myst3 148 151
comment:12 by , 3 years ago
@lephilousophe
Another test is possible although this looks more like a workaround.
Tried "glFlush()" patch : no, same issue.
Is it possible to make a screenshot in the middle of the transition?
If it's too fast, you can change the setting in scummvm.ini file by setting transition_speed to something like -400 (note the minus sign).
Done, there are video with -400 and both patches applied (glTexImage2D one and glFlush one):
OGLES2 (opengl with shaders): https://youtu.be/ojY0i2yvtXI
MiniGL (opengl): https://youtu.be/myh_5rZuL-o
See how interesting .. With OGLES2 we can see that between scenes swap, the whole texture is "flipped". Now, when effect should happens, flipped texture are shown for a while (for most of time of effect) and then, at the very end, i can see how cross-fade effect take place. But instead of full time, it take just 1/10 of time or something.
Then, if we check video with MiniGL rendering, there we instead have some different stuff, and not flipped texture, but shifted one, and being "purple", and then also we can see that for almost all time of cross-fade effect we have that "purple shifted texture" and at the end cross-fade effect taking 1/10 of the time it should take.
That make me think, that in both cases we like hit one issue : we use old/previous parts of video memory or something. The "mess" in minigl we have is that because we see that "shiftet purple stuff", just on fast-speed it looks like mess. And with OGLES2 we have no mess, because in the time we should have effect, texture just flipped, but no other color, so for us it like nothing happens.
It can be some issues with timing values or something, maybe some integer overflows somewhere ?
comment:13 by , 3 years ago
OK
OGLES2 rendering is OK except for the flipped surface.
I bet that it's the same bug as the one we reported with flipped FBO.
The rendering is slow but it's expected because of the (unusual) -400 setting. It doesn't seem bogus to me (I expect the transition to start as soon as the reversed texture is displayed).
Does it looks the same without the glFinish patch?
I take for granted that the bugfix in OGLES2 will fix the flipping.
For MiniGL, it's completely off. I don't know why but it's definitely a bug in MiniGL itself and we can't really fix this except by finding the root cause which may still be because glCopyTexImage2D
isn't flushing the pipeline before capturing image.
This would need an investigation with MiniGL author.
Another option possible is to comment the copyScreenshotToTexture
function in engines/myst3/gfx_opengl.cpp
and engines/myst3/gfx_opengl.h
.
This will use a fallback mechanism (the same used by TinyGL) where image is downloaded from GPU to CPU and reuploaded as a texture. This may work better.
comment:14 by , 3 years ago
But don't you feel that at the begining it not just slow, but no effect happens, and it happens only at the end of the whole time of effect ? I mean, if we take that effect should take 100%, then it can be seen, that for about 60-70% of that time, we have "nothing" (flipped texture on ogles2, mess on minigl), and only after, in the reamining 30%, we can see necessary effect (or just part of it) ?
Maybe we just need to wait for OGLES2 to be fixed in terms of flipping, and then we can see, if it anyhow was related to and revesit issue after ?
comment:15 by , 3 years ago
@lephilousophe
Rereading everything you wrote again, and i got what you mean : you mean that while textures is flipped , no effect happens (because of that flipping bug), and once texture flips to the normal, then effect starts, but seems that texture is flipped 70% if time, and because of that we have almost no effect visibly.
Interesting through how lucky we are to catch the same issue in 3 different GL implementation, and on MiniGL and on OGLES2 and on TinyGL on MorphOS :) But we will see once OGLES2 will be fixed.
comment:16 by , 3 years ago
I watched again you screenshot and, as soon as the texture is flipped, I find the transitions OK. I don't think it's different on any other platform.
Don't forget that it's really slowed down and it should never be that detailed. The aim is to do something smooth, not something accurate.
If you think the flipped image begins too late, it's maybe because the implementation has to capture source image, do an offscreen render of destination image and do the transition. It's maybe not optimized in the implementation (ang glFinish may not help at all).
For the OGLES2 flipping, we can wait. If it's not fixed, we will be able to create a new minimal bug reproducer. :)
For MiniGL, after another look, it seems that Red and Green channels are switched but I couldn't find the exact swap between all colors channels.
Maybe an endianness issue due to the fact that glCopyTexImage2D stores the pixels in an unexpected fashion for the rendering later.
In our code, we never manipulate the pixels for this effect. We tell to OpenGL: capture the screen and store it in texture 1, render another scene, capture the screen and store it in texture 2. Then, render texture 1 with full opacity and render texture with a varying opacity.
comment:17 by , 3 years ago
@lephilousophe
Ok, bug in ogles2 in terms of flipping fixed! It also fix for us GRIM with enabled FBO. But, it didn't fix fliping we have there in myst3 ! It still the same. I made a video to show that on the same ogles2 library i have no issues with test case now, no issues with grim+fbo (see window is resized), but still same issues with myst3:
At beginig i run test case in all possible modes, then run GRIM to show that resizable window (so FBO enabled) works too, and no issues with depth/etc, and then Myst3 showing same issue.
comment:18 by , 3 years ago
@lephilousophe
Another option possible is to comment the copyScreenshotToTexture function in engines/myst3/gfx_opengl.cpp and engines/myst3/gfx_opengl.h.
Commenting out this in both gfx_opengl.cpp and gfx_opengl_shaders.cpp and their headers make ogles2 rendering (opengl with shaders) works as expected, but missing effect on minigl.
comment:19 by , 3 years ago
@lephilousophe
Got the new beta of ogles2, with no more "flipped" texture when use glCopyTexImage2D(), and while effect kind of works there something very wrong. The effect with default transition_speed almost not visibly. While with transition_speed=0, its more or less ok, but also kind of .. small by time or something of that sort. On windows, with default transition_speed its just all fine and looks very good.
Maybe there some issues in terms of endianes when speed of transition effect is set by default ? Maybe we can somehow prinfs what value is used, so we can see what should be, and what we have. Maybe that value calculates somehow, and so on other than windows platform it acts different because of that ?
comment:20 by , 3 years ago
@lephilousophe
Added printfs and that what i have. By default (with no transition_speed option in myst3 at all), i have that when effect happens:
Drawing transition step 0/0.000000 Drawing transition step 6/0.060000 Drawing transition step 13/0.130000 Drawing transition step 20/0.200000 Drawing transition step 26/0.260000 Drawing transition step 33/0.330000 Drawing transition step 40/0.400000 Drawing transition step 46/0.460000 Drawing transition step 53/0.530000 Drawing transition step 60/0.600000 Drawing transition step 66/0.660000 Drawing transition step 73/0.730000 Drawing transition step 80/0.800000 Drawing transition step 86/0.860000 Drawing transition step 93/0.930000 Drawing transition step 100/1.000000
And i do not see effect at all, it happens too fast to notice anything.
If i add to myst3s config transition_speed=-10
(i.e. -10), then effect is visibly more or less as expected by speed (just like on win32), but in output i have instead that:
Drawing transition step 0/0.000000 Drawing transition step 3/0.030000 Drawing transition step 6/0.060000 Drawing transition step 9/0.090000 Drawing transition step 12/0.120000 Drawing transition step 15/0.150000 Drawing transition step 18/0.180000 Drawing transition step 21/0.210000 Drawing transition step 24/0.240000 Drawing transition step 27/0.270000 Drawing transition step 30/0.300000 Drawing transition step 33/0.330000 Drawing transition step 36/0.360000 Drawing transition step 39/0.390000 Drawing transition step 42/0.420000 Drawing transition step 45/0.450000 Drawing transition step 48/0.480000 Drawing transition step 51/0.510000 Drawing transition step 51/0.510000 Drawing transition step 51/0.510000 Drawing transition step 51/0.510000 Drawing transition step 51/0.510000 Drawing transition step 51/0.510000 Drawing transition step 51/0.510000 Drawing transition step 51/0.510000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 54/0.540000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 57/0.570000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 60/0.600000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 63/0.630000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 66/0.660000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 69/0.690000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 72/0.720000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 75/0.750000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 78/0.780000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 81/0.810000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 84/0.840000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 87/0.870000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 90/0.900000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 93/0.930000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 96/0.960000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000 Drawing transition step 100/1.000000
Not sure what all of this mean, but on win32 everything ok with default values, but for us only when i set speed to something else , but not default values.
comment:21 by , 3 years ago
@All
Ok , turns out that effect works as expected _ONLY_ when we enable VSYNC. Without enabled VSYNC we have effect working almost invisible , as it happens too fast. With VSYNC enabled all as expected. Through on win32 it seems ok with both enabled/disabled VSYNC, but at least we know to what it related.
comment:22 by , 2 years ago
Summary: | Myst III Exile: missing scene transition effect on PowerPC (big-endian) machines on all OSes → MYST3: missing scene transition effect on PowerPC (big-endian) machines on all OSes |
---|
I can confirm here, i have same with transition effect
I test with OpenGL/OpenGL but with Software mode, it's ok.
Platform : MorphOS