Doomsday Engine

Logged In: YES
user_id=1103163

Did this just start for you with beta4? Because it sounds
like a long-standing problem that, as best as anyone can
figure, is an xorg driver problem with no known fix.

Best you can do is issue "skyrows 0" in the console, which
will replace the HOM with a mostly single-colored sky.

For further reading:
http://forums.newdoom.com/showthread.php?t=24012
http://forums.newdoom.com/showthread.php?t=26297

Logged In: YES
user_id=1248824

Could not reproduce this with nvidia binaries drivers. Will
try again on my ATI 7500 system after it compltes it's
dapper upgrade.

BTW, there are Ubuntu packages available at
http://eyagi.bpa.nu/eyagi/community-projects/yagisan-s-doomsday-for-debian-ubuntu/

Ubuntu Dapper + Nvidia Binary Driver. No HOM

• http://sourceforge.net/p/deng/bugs/_discuss/thread/b98ede5f/285e/attachment/doom1-ultimate-000-nvidia.jpg

Logged In: YES
user_id=1532965

I wouldn't know if this would be an issue in previous
versions, this is the first time I'm running it under linux
(and from source as well).

I should note that it DOES work fine in windows under OpenGL
and D3D, so it is not a hardware specific issue I think.

Logged In: YES
user_id=614730

In rend_sky.c, in function SkyVertex(int r, int c), replace

gl.Color4f(1, 1, 1, 0);

by

gl.Color4f(1, 1, 1, 1);

Part of the sky was rendered with alpha set to 0, which
means that it was totally transparent...

Logged In: YES
user_id=849456

RE: Part of the sky was rendered with alpha set to 0, which
means that it was totally transparent...

This is as intended. The top row of the sky is designed to
be transparent so that the sky texture blends into the sky
colour.

If your "fix" does indeed fix the problem for you then
something else is not working correctly.

Logged In: YES
user_id=614730

RE: If your "fix" does indeed fix the problem for you
then
something else is not working correctly.

Of course you're right, with my "fix" the sky texture
doesn't blend nicely into the untextured top of the sky. But
the original code is

if(r 0)
gl.Color4f(1, 1, 1, 0);
else
gl.Color3f(1, 1, 1);

gl.Color3f doesn't reset the alpha channel, and that appears
to be the problem, since the alpha channel is not reset
between drawing the r0 vertices and drawing the other rows
(or I'm too dumb to find the reset and something else is
wrong). I now changed it to

if(r == 0)
gl.Color4f(1, 1, 1, 0);
else
gl.Color4f(1, 1, 1, 1);

and the blending from texture to color works.

Logged In: YES
user_id=717323

From the OpenGL specification: "The Color command has two major variants:
Color3 and Color4. The four value versions set all four values. The three value
versions set R, G, and B to the provided values; A is set to 1.0."

So if glColor3f(r,g,b) is not functionally equivalent to glColor4f(r,g,b,1.0), the
OpenGL implementation in question does not conform to the specification.

What driver/graphics card are you using? (ATI?)

Logged In: YES
user_id=614730

My OS is Linux,

my graphics device:
Intel Corporation 82852/855GM Integrated Graphics Device
(rev 02)

OpenGL driver:
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM
20050225 x86/MMX/SSE2
OpenGL version string: 1.3 Mesa 6.4.2

Logged In: YES
user_id=1248824

This was reported as bug here
https://bugs.freedesktop.org/show_bug.cgi?id=8410

I'd suggest that perhaps we use only Color4 values in future
to avoid driver bugs like this (yes it's a workaround - but
one that should have no ill affects)

Logged In: YES
user_id=1248824

Reported fixed in MESA svn. Closing bug as technically it is
not Doomsday at fault. MESA bug
https://bugs.freedesktop.org/show_bug.cgi?id=8410