Open GoogleCodeExporter opened 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
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
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
Original comment by vittorio...@gmail.com
on 8 Oct 2013 at 8:22
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
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
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
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
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
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
You could try looking into driver changes on your side though...
Original comment by kyberneticist@gmail.com
on 26 May 2015 at 11:38
Original comment by kyberneticist@gmail.com
on 26 May 2015 at 11:44
Original issue reported on code.google.com by
almikes@aol.com
on 4 Sep 2013 at 7:19