http://bugs.winehq.org/show_bug.cgi?id=7284
--- Comment #34 from H. Verbeet <hverbeet(a)gmail.com> 2009-03-29 07:38:57 ---
FWIW, I think clamping makes sense for 1.x pshaders. Shader constants for
example are clamped there as well, and it'd be consistent with the hardware
capabilities at the time.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7284
--- Comment #33 from Rico <kgbricola(a)web.de> 2009-03-29 05:40:30 ---
Created an attachment (id=20185)
--> (http://bugs.winehq.org/attachment.cgi?id=20185)
Screenshot from crysis with the glsl patch
I tried the glsl patch with crysis and there it makes the scene too bright!
Probably it depends on the shader version. I also checked the attached test
case on a laptop with an ati card.
Crosstest + xpsp3 + ati radeon mobility 9600
without "rcp of 0 testcase" patch:
d3d8_crosstest.exe visual
visual.c:934: Tests skipped: D3DFMT_P8 textures not supported
visual: 292 tests executed (0 marked as todo, 0 failures), 1 skipped.
with "rcp of 0 testcase" patch:
d3d8_crosstest.exe visual
visual.c:1014: Tests skipped: D3DFMT_P8 textures not supported
visual: 300 tests executed (0 marked as todo, 0 failures), 1 skipped.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3781
tyle7(a)hotmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tyle7(a)hotmail.com
--- Comment #7 from tyle7(a)hotmail.com 2009-03-29 00:38:33 ---
(In reply to comment #6)
> The website redirects to http://iriverinc.com/, so the download link provided
> by Pavel Troller is no longer valid.
>
The link in comment 4 is working fine. Problem still present in wine 1.1.18.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8093
--- Comment #9 from Gaofeng Huang <gaofeng.huang(a)balliol.ox.ac.uk> 2009-03-28 21:33:09 ---
How can I change the locale of wine?
and if you mean LANG/LC_CTYPE, yes, I have done that.
Is the current code supposed to add a "keyboard/IME/region"-like icon in the
tray such that I can switch IME?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7284
--- Comment #32 from Alexander Dorofeyev <alexd4(a)inbox.lv> 2009-03-28 19:57:35 ---
Created an attachment (id=20180)
--> (http://bugs.winehq.org/attachment.cgi?id=20180)
hack for rcp in glsl backend
As an experiment, this simple hack for glsl shader backend seems to actually
fix lighting in the game, it clamps result of rcp.
Though proper fix probably will need to be done conditionally (need to check my
theory that this is influenced by shader model version) and if indeed 1.x
differs from 2.x and later in such ways (generating and propagating Inf and NaN
vs clamping to some border value), then it's probably a broader issue and may
also be affecting other opcodes like rsq.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7284
--- Comment #31 from Alexander Dorofeyev <alexd4(a)inbox.lv> 2009-03-28 18:48:46 ---
I found this paper:
http://http.download.nvidia.com/developer/Papers/2005/FP_Specials/FP_Specia…
That seems to suggest 0 * +Inf = NaN.
But, it also mentions that this applies to hardware/implementation that
supports floating point operations and floating point special numbers like Inf
and NaN. I'm not sure, but maybe in the old d3d8 days there was no floating
point and thus no NaNs or Infs, so, basically, divide by zero was clamped to
max value like "1.0" or something like that?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5935
Jean-Louis Dupond <info(a)dupondje.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |info(a)dupondje.be
--- Comment #18 from Jean-Louis Dupond <info(a)dupondje.be> 2009-03-28 18:22:15 ---
It still exists in 1.1.18 ... Running Ubuntu Jauny (9.04).
It would be nice if it was fixxed soon :(
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7284
--- Comment #30 from Tobias Jakobi <liquid.acid(a)gmx.net> 2009-03-28 18:12:09 ---
Sorry, I just read the post again.
The problem seems to be in MUL, right?
I mean the D3D rcp behaviour is probably right, since the D3D8 docs mention
that RCP(0.0) produces +INFTY. It's not so clear for ARB_vp and GLSL, at least
I don't find anything in the docs (yet).
But what's +INFTY times ZERO? I found no clue about that in the D3D8 docs.
The ARB_vp docs only mention this:
---------------------------------------------------
The following rules apply to multiplication:
1. <x> * <y> == <y> * <x>, for all <x> and <y>.
2. +/-0.0 * <x> = +/-0.0, at least for all <x> that correspond to
representable numbers (IEEE "not a number" and "infinity" encodings
may be exceptions).
3. +1.0 * <x> = <x>, for all <x>.
Multiplication by zero and one should be invariant, as it may be used to
evaluate conditional expressions without branching.
---------------------------------------------------
So we're experiencing case 2 here?!
I can't say I understand the last part properly. To me this sounds like
multiplying by ZERO should always produce ZERO, regardless of the other factor.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7284
--- Comment #29 from Tobias Jakobi <liquid.acid(a)gmx.net> 2009-03-28 17:52:16 ---
Hey Alex, long time no see!
I'm going to ask Jan to test this on his ATI Mobility card.
Concerning the RCP instr, you probably wanna take a look at this bug:
http://bugs.winehq.org/show_bug.cgi?id=17832
There seems to be more problems with RCP apart from the one you describe.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7284
--- Comment #28 from Alexander Dorofeyev <alexd4(a)inbox.lv> 2009-03-28 17:34:41 ---
Created an attachment (id=20174)
--> (http://bugs.winehq.org/attachment.cgi?id=20174)
rcp of 0 testcase
A while ago I spent some time debugging this, and as far as I can tell the
problem originates in the vertex shader, and it has something to do with taking
a reciprocal of zero (supposed to produce infinity afaik) then multiplying it
by zero. On windows this seems to result in a black color (i.e. zero) on wine -
white. And least this contributes a part of the problem, I believe.
Unfortunately I got busy / lazy and never finished fixing this. I'm trying to
look into it again now, put together a testcase for this. Renders a black quad
on windows and white quad on wine, on my machine. But this needs to be tested
on non-nvidia machines. This stuff with divide by zero - I'm not sure it's
well-defined behavior at all.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.