RobWatlingSF / hedgewars

Automatically exported from code.google.com/p/hedgewars
GNU General Public License v2.0
0 stars 0 forks source link

Game screenshots (using glReadPixels) do not render semi-transparency correctly on some cards/drivers. #701

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Start Hedgewars in windowed mode!
2. Start a game!
3. Move the camera so the water becomes visible to you!
4. Pause the game so the screen does not move!
5. Take a screenshot using Hedgewars!
6. Take a screenshot using an external program!
7. Compare both screenshots closely!

What is the expected output? What do you see instead?
I expect both screenshots to be roughly identical (the water waves and the 
flakes won’t be at the same position but this is okay). I also certainly 
expect that every pixel of both screenshots have 100% opacity.
In reality Hedgewars’ screenshot differs from the other one that it contains 
semi-transparent pixels. This becomes most obvious on the water, for example.

What version of the product are you using? On what operating system?
Hedgewars 0.9.19
GNU/Linux, Linux 3.9.4

Please provide any additional information below.
I give you two example files from the Fruit theme. GIMP’s screenshot is on 
<http://holzgolz.heliohost.org/data/games/hedgewars/images/screenshots/screensho
tbug0.9.19/GIMP.png> and Hedgewars’ is on 
<http://holzgolz.heliohost.org/data/games/hedgewars/images/screenshots/screensho
tbug0.9.19/GIMP.png>. If you analyze them with an image editor, you’ll notice 
that the water pixels in Hedgewars’ screenshot are semi-transparent. Also 
examine the upper pixels of the waves closely. Zoom in and compare (it can’t 
be seen at 100%).
An interesting case is also the theme “Cave” (no screenshots here) which 
uses semi-transparency on its own. The crystals are semi-transparent and the 
“border” of the background stalagmites, too. Both are rendered incorrectly 
on Hedgewars’ screenshots. Again you need to zoom in to see it.
Also examine the hedgehogs closely, because their “border” use 
semi-transparency, too. There’s a difference between the screenshots, too. So 
it looks like that Hedgewars’ screenshot code does not handle 
semi-transparency correctly.

Original issue reported on code.google.com by almikes@aol.com on 4 Sep 2013 at 7:19

GoogleCodeExporter commented 8 years ago
Oops, I accidently posted the same link twice. Here’s the real Hedgewars 
link: 
<http://holzgolz.heliohost.org/data/games/hedgewars/images/screenshots/screensho
tbug0.9.19/Hedgewars.png>

Original comment by almikes@aol.com on 4 Sep 2013 at 7:20

GoogleCodeExporter commented 8 years ago
This is a defect in your graphics driver.
http://www.hedgewars.org/node/5331#comment-28068

Same as this one I 'spose.

Pretty sure there is no sane way we can fix this.

Original comment by kyberneticist@gmail.com on 4 Sep 2013 at 7:26

GoogleCodeExporter commented 8 years ago
For people following this bug.  I've asked him to investigate building with 
video support.
Reason being, that video recording sets:
{$IF DEFINED(USE_S3D_RENDERING) OR DEFINED(USE_VIDEO_RECORDING)}                

procedure CreateFramebuffer(var frame, depth, tex: GLuint);  
which calls...

glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT, cScreenWidth, 
cScreenHeight);                                

If that didn't help, I was going to ask him to switch GL_DEPTH_COMPONENT for 
GL_RGBA8
and also the GL_RGBA in the screenshot function to GL_RGBA8.

My vague theory was different defaults in his driver.

Still waiting for him to do a build w/ USE_VIDEO_RECORDING though.

Original comment by kyberneticist@gmail.com on 6 Sep 2013 at 4:59

GoogleCodeExporter commented 8 years ago

Original comment by vittorio...@gmail.com on 8 Oct 2013 at 8:22

GoogleCodeExporter commented 8 years ago
Yeah, shame about the no activity close pending, but this is the kind of bug 
that is kinda hard to fix w/o access to hardware on which to replicate.  Not 
going to just blindly toss opengl calls in and hope.

Original comment by kyberneticist@gmail.com on 23 Oct 2013 at 6:14

GoogleCodeExporter commented 8 years ago
Okay, I finally managed to build 9fa0f67ff628 with video support, yay!

Thanks to sheepluva I found out that this also affects stereo top/bottom and 
left/right rendering in-game. This means, when I use one of these features, the 
water looks messed up as well. This is true for both 9fa0f67ff628 and 0.9.19.

When I take a screenshot from that in 0.9.19, the screenshot has the same 
transparency problems as initially reported.

When I take a screenshot from 9fa0f67ff628, all I get is just a fully black 
Bitmap although I activated PNG support. Sheepluva experienced the same black 
BMP problem as I did.

Original comment by almikes@aol.com on 3 Nov 2013 at 8:20

GoogleCodeExporter commented 8 years ago
related to https://code.google.com/p/hedgewars/issues/detail?id=234 maybe

Original comment by vittorio...@gmail.com on 22 Nov 2014 at 9:54

GoogleCodeExporter commented 8 years ago
I recently talked to koda about this bug and koda asked me wheather this bug 
still existed for me after rb8e6164a1a18.

I tested, and yes, it’s still there in my GNU/Linux build of r73545fd91efa. 
Koda told me to write this here.

My build had no video recording support this time. Feel free to talk to me in 
chat if you need more info/testing/whatever from me.

Original comment by almikes@aol.com on 17 Dec 2014 at 2:58

GoogleCodeExporter commented 8 years ago
I'm just here to report that I'm on Windows and as for newest beta 
(0.9.22-BETA1) this issue still exists. It applies to anything with alpha 
channel, even the circle from Girder Tool.
My solution would be to save screenshots without alpha channel, forcing 24-bit 
image (if it's possible).

Original comment by KoBeW...@gmail.com on 26 May 2015 at 9:46

GoogleCodeExporter commented 8 years ago
KoBeWi4E, the image doesn't actually have any transparent pixels.  The problem 
is a bug in the graphics driver on your machine, that is not sending us back 
the right data, for certain areas where translucency is used in textures.

A fix would require finding some opengl settings to tickle those machines into 
compliance, migration to a whole new layer for broken machines (such as ANGLE 
which is what Firefox and Chrome rely on to get semi-sane GLES2 under Windows), 
or rendering the whole thing ourselves to a surface.

That last one will probably never happen.

Original comment by kyberneticist@gmail.com on 26 May 2015 at 11:37

GoogleCodeExporter commented 8 years ago
You could try looking into driver changes on your side though...

Original comment by kyberneticist@gmail.com on 26 May 2015 at 11:38

GoogleCodeExporter commented 8 years ago

Original comment by kyberneticist@gmail.com on 26 May 2015 at 11:44