WineHQ Bugzilla – Bug 15738 – Max Payne 2: Ingame windows rendered incorrect with nvts pipe

Bugzilla

Last modified: 2014-01-10 14:46:15 UTC

Max Payne 2: Ingame windows rendered incorrect with nvts pipe

Bug 15738 - Max Payne 2: Ingame windows rendered incorrect with nvts pipe


Summary:	Max Payne 2: Ingame windows rendered incorrect with nvts pipe

Status:	CLOSED FIXED

AppDB:	Show Apps affected by this bug
Product:	Wine
Classification:	Unclassified
Component:	d3d
Version:	1.1.3
Hardware:	x86-64 Linux

Importance:	P2 minor
Target Milestone:	---
Assigned To:	Mr. Bugs

URL:	http://www.rockstargames.com/maxpayne...
Keywords:	download

Depends on:
Blocks:
	Show dependency tree

Reported:	2008-10-23 16:30 UTC by Tobias Jakobi
Modified:	2014-01-10 14:46 UTC (History)
CC List:	4 users (show)

See Also:
Regression SHA1:
Fixed by SHA1:	a14793f50ba3acb0b99bb166b8534b255ff09ca2
Distribution:	---
Staged patchset:

Attachments
Max Payne 2: nvts_fragment_pipeline forced (9.04 KB, text/plain) 2008-10-26 03:53 UTC, Tobias Jakobi	Details
First room / hospital room: windows (fully) transparent (44.07 KB, image/jpeg) 2008-10-26 04:24 UTC, Tobias Jakobi	Details
Another window: direct view and rendered correct (50.42 KB, image/jpeg) 2008-10-26 04:26 UTC, Tobias Jakobi	Details
Another window: Look from the side and it's rendered wrong (38.24 KB, image/jpeg) 2008-10-26 04:26 UTC, Tobias Jakobi	Details
View All Add an attachment (back traces, logs, proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Tobias Jakobi 2008-10-23 16:30:00 UTC

When using (or forcing) the nvts_fragment_pipeline implementation (directx.c), ingame windows are rendered incorrectly. Going to attach screenshots later.

With the arbfp pipe rendering is correct, I didn't yet try with other pipes.

Effect can be reproduced with the demo version. Start game and let cutscenes finish (wait until you gain control of the character), then take a look at the windows in the hospital room.
With nvts they're completly transparent, nearly like they weren't even there. Recheck with arbfp and see how they should look like (you should see a "sprinkled-by-rain-from-outside" effect on them).

Exit first room and look left for another window. It has the same issues, however I found out that it was possible to trigger correct rendering when the scene is rendered from a certain position (again going to do screenshots).

Comment 1 Austin English 2008-10-23 16:33:43 UTC

Please attach terminal output.

Comment 2 Tobias Jakobi 2008-10-23 16:41:04 UTC

What do you expect to find?

Comment 3 Austin English 2008-10-23 16:55:37 UTC

Hopefully a clue as to where to look. Terminal output is (almost) always the first step in debugging.

Comment 4 Tobias Jakobi 2008-10-23 17:19:26 UTC

OK... I can post the output tomorrow.

But I can already tell you that there is no interesting output from wined3d nor from d3d8. In fact the only thing I remember popping up here and there are the usual EvictManagedResources fixmes. Really nothing critical there.

As soon as I have the screenshots and the console output ready I'm also going to CC stefand since he wrote the arbfp pipeline.

Comment 5 Tobias Jakobi 2008-10-26 03:53:10 UTC

Created attachment 16891 [details]
Max Payne 2: nvts_fragment_pipeline forced

This is Max Payne 2 demo on a recent wine git master checkout (last commit is 503972980e150f9eda348962f437484d7c9daa43), further patched with:
http://bugs.winehq.org/attachment.cgi?id=16829

Wine settings:
ORM=fbo
GLSL=off

Ingame settings:

Video Settings:
resolution=800x600, 32bits
AntiAliasing=off
TextureColorDepth=high
TextureResolution=high
TextureFiltering=trilinear
TripleScreenBuffers=off
AllowWindowsKeys=off

Content Scalability:
First 5 settings: all medium
Checkbox: all switched on except "Mirrors" and "Pixel Shader Skins"

Comment 6 Tobias Jakobi 2008-10-26 04:24:49 UTC

Created attachment 16892 [details]
First room / hospital room: windows (fully) transparent

Comment 7 Tobias Jakobi 2008-10-26 04:26:01 UTC

Created attachment 16893 [details]
Another window: direct view and rendered correct

To find this window leave the first room and look right

Comment 8 Tobias Jakobi 2008-10-26 04:26:53 UTC

Created attachment 16894 [details]
Another window: Look from the side and it's rendered wrong

Comment 9 Tobias Jakobi 2008-10-26 04:27:37 UTC

Comment on attachment 16894 [details]
Another window: Look from the side and it's rendered wrong

Same window like in http://bugs.winehq.org/attachment.cgi?id=16893, only rendered from a different point of view

Comment 10 Tobias Jakobi 2008-10-26 04:29:09 UTC

And last but not least...

Comment 11 Tobias Jakobi 2008-11-22 16:17:04 UTC

Reconfirming with wine-1.1.9

Comment 12 Tobias Jakobi 2009-01-29 16:38:46 UTC

Reconfirming with wine-1.1.13

Comment 13 Tobias Jakobi 2009-04-26 09:05:01 UTC

Reconfirming with wine-1.1.20

Comment 14 Stefan Dösinger 2009-04-26 10:24:19 UTC

I remember that this game made troubles with the ARB pipeline at first, just in an opposite way, by showing completely opaque windows. The problem back then was incorrect clamping behavior. Ie, the game uses D3DTOP_ADD, then D3DTOP_MODULATE. The ADD could produce a temporary result > 1.0. The FFP pipeline always clamps values to [0.0; 1.0]. So I changed the operations that could go above 1.0 or below 0.0 to use the _SAT version of the instruction, which fixed the bug.

As far as I know NVTS doesn't support values > 1.0. However, one might have to make sure that values stay > 0.0(I think the supported range is [-1.0;1.0]). I don't know for sure what happens if an ADD produces something > 1.0, maybe it is undefined.

Comment 15 Tobias Jakobi 2009-04-26 11:56:26 UTC

From the extensions docs:
"The spec is written as if the computations are
done on floating point values ranging from -1.0 to 1.0 (clamping is
specified where this range is exceeded).  The fact that NV10 does
the computations as 9-bit signed fixed point is not mentioned in
the spec.  This permits a future design to support more precision
or use a floating pointing representation."

Looks like you only need to clamp to zero here, if that really is the problem.

Comment 16 Tobias Jakobi 2009-04-26 11:59:50 UTC

The docs (in case someone wants to take a look):
http://www.opengl.org/registry/specs/NV/register_combiners.txt
http://www.opengl.org/registry/specs/NV/register_combiners2.txt
http://www.opengl.org/registry/specs/NV/texture_shader.txt
http://www.opengl.org/registry/specs/NV/texture_shader2.txt

My previous quote is from the RC1 specs.

Comment 17 joaopa 2011-07-08 03:32:07 UTC

still a bug in current wine?

Comment 18 Alexander Dorofeyev 2013-10-21 09:10:12 UTC

(In reply to comment #17)
> still a bug in current wine?
Yes, with NVidia card & prop. drivers and nvts pipeline forced by a hack in wined3d/directx.c, this bug can be reproduced in wine 1.7.4

Comment 19 Alexander Dorofeyev 2013-11-05 19:07:22 UTC

Bugfix is in: http://source.winehq.org/git/wine.git/commit/a14793f50ba3acb0b99bb166b8534b255ff09ca2

Comment 20 Alexandre Julliard 2013-11-08 12:32:30 UTC

Closing bugs fixed in 1.7.6.

Comment 21 Alexandre Julliard 2014-01-10 14:46:15 UTC

Removing 1.6.x milestone from bugs included in 1.6.2.