http://bugs.winehq.org/show_bug.cgi?id=8051
--- Comment #110 from Henri Verbeet <hverbeet(a)gmail.com> 2011-04-26 07:03:42 CDT ---
Well, the way to fix this is to implement support for software shaders. That
shouldn't be terribly hard, but still at least a couple of months of work for
vertex shaders, and probably more than that for fragment shaders. You'd
probably want to use LLVM.
--
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=8051
Abraham <stormbolter(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stormbolter(a)gmail.com
--- Comment #109 from Abraham <stormbolter(a)gmail.com> 2011-04-26 06:57:47 CDT ---
(In reply to comment #108)
> (In reply to comment #107)
> > Last I checked, Wine hardcodes the constant instead of actually checking the
> > hardware.
> Where would that be? Wined3d reads the constants from the opengl library. It
> subtracts a number of constants from the available ones on certain drivers(e.g.
> fglrx and OSX) where we know that the driver needs some for its own purposes.
> This doesn't change the number of constants that is advertised to the d3d app
> though. The driver reserved constants are there to avoid GLSL compile errors
> with shaders that use indirect addressing(and thus potentially use all
> available constants)
>
> We do limit the hardware shader constants to 256 in d3d9 and d3d8 because there
> are some games that break if more constants are supported.
> d3d9:Set*ShaderConstantF rejects constants >= 256 as well. This seems incorrect
> with software vertex processing and we should probably change the check a bit.
> (e.g. check against the HW capabilities, and if hardware VP is used cap the
> constants at 256, otherwise 8192)
>
> > But what I've never understood about this bug is, lots of bugs are
> > filed that prevent an application or game from starting, and they might be the
> > only affected app/game, but people pay attention and usually attempt to fix the
> > problem. This bug for some reason has been demoted its entire life as
> > unimportant.
> There are three things in play here: (a) the effort needed for a proper fix,
> (b) the limited effect on other games(we'd probably just fix a single game) and
> (c) that implementing a proper fix requires a lot of knowledge how wined3d
> works.
>
> (a)+(b) prevent the main wined3d developers from working on this bug, (c) makes
> it unlikely that a new volunteer shows up and writes a patch.
I think (B) is not very relevant. There are a lot of fixes made to run a single
piece of software (ex: WOW or Microsoft Word), that probably affects only the
single app or just a simple subset.
I know I'm just voicing my frustration here. There is little save putting a
small reward that I can do to help this bug fix, but is the single bug that
refrains me from migrating my girlfriend's computer to ubuntu, as she is a very
avid sims 2 gamer (and doesn't like sims 3 -too many micropayments, and too
much money invested on previous game-). I can replace office, and teach her to
use shotwell to manage her photo collection, but if she has to reboot to play
the sims 2, is no use.
Many sims 2 players are like my girlfriend, avid fans, but no tech skills (I'm
no programmer myself).
A suggestion... There's any mechanism for offering bounties for bugfixing?
Maybe, while we cannot offer tech expertise, we can offer a monetary
compensation...
--
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=8051
--- Comment #108 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-04-26 05:28:42 CDT ---
(In reply to comment #107)
> Last I checked, Wine hardcodes the constant instead of actually checking the
> hardware.
Where would that be? Wined3d reads the constants from the opengl library. It
subtracts a number of constants from the available ones on certain drivers(e.g.
fglrx and OSX) where we know that the driver needs some for its own purposes.
This doesn't change the number of constants that is advertised to the d3d app
though. The driver reserved constants are there to avoid GLSL compile errors
with shaders that use indirect addressing(and thus potentially use all
available constants)
We do limit the hardware shader constants to 256 in d3d9 and d3d8 because there
are some games that break if more constants are supported.
d3d9:Set*ShaderConstantF rejects constants >= 256 as well. This seems incorrect
with software vertex processing and we should probably change the check a bit.
(e.g. check against the HW capabilities, and if hardware VP is used cap the
constants at 256, otherwise 8192)
> But what I've never understood about this bug is, lots of bugs are
> filed that prevent an application or game from starting, and they might be the
> only affected app/game, but people pay attention and usually attempt to fix the
> problem. This bug for some reason has been demoted its entire life as
> unimportant.
There are three things in play here: (a) the effort needed for a proper fix,
(b) the limited effect on other games(we'd probably just fix a single game) and
(c) that implementing a proper fix requires a lot of knowledge how wined3d
works.
(a)+(b) prevent the main wined3d developers from working on this bug, (c) makes
it unlikely that a new volunteer shows up and writes a patch.
--
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=3930
--- Comment #45 from Damjan Jovanovic <damjan.jov(a)gmail.com> 2011-04-26 02:23:39 CDT ---
(In reply to comment #44)
> Are those patches going to be integrated? I don't really like to compile wine
> by myself, then I'd have to repeat the process each time upgraded package pops
> up. (especially that I have some weird problems with wine1.3, so I prefer to
> use wine1.2)
MCI is complex system, with 16 and 32 bit interfaces and drivers, dating back
to at least Windows 3.1. The only way any patch is going to be integrated is if
it does the right thing, and the patches here are just hacks that work around
the problem. An investigation into what exactly Windows does is necessary, and
nobody has done it yet: you'd probably have to test each Windows version
individually. It is worth noting that Heroes of Might and Magic doesn't work on
eg. Windows 2000.
In the meanwhile, Heroes of Might and Magic is a long game with a high replay
value. IMHO it is well worth the time you put into patching and compiling a
separate Wine prefix just for it.
--
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=25792
Summary: Warhammer 40k Dark Crusade single player campaign
issue
Product: Wine
Version: 1.3.11
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: alexandrbezenkov(a)gmail.com
Game crashes right after the global map of the single player campaign is
showed.
--
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=26929
Summary: Self compiled wine is crashing planescape torment,
with stacktrace
Product: Wine
Version: 1.3.18
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: i30817(a)gmail.com
Hello, as the title says, a self compile is crashing planescape torment. I
believe this happens on intro video, and i thought it might be useful for the
"crash on rest" bug (that is still reproducible on ppa supplied wine).
I opened a new bug since this is happening always, whether i install the
fixpack or not, so it appears another bug. Hopefully it is not just a compile
error, and it is useful.
wine head compiled with
"CC="ccache gcc -m32" LDFLFLAGS="-L./lib32" CFLAGS="-g -O0" ./configure
--verbose --disable-tests && make depend -j 3 && make -j 3"
Removed ~/.wine.
wineconfig settings different from default are virtual desktop 800x600 and
Directsound hardware acceleration set to Emulation.
Here is the log of the exe
~/wine-git/wine Torment.exe > bug.txt 2>&1
--
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=8051
--- Comment #107 from Robert Showalter <rshowalter0520(a)verizon.net> 2011-04-25 18:50:02 CDT ---
(In reply to comment #105)
> * it is not clear if the graphic bugs are caused by the hack or is entirely
> unrelated. The hack is not in wine because it is an incorrect hack, not because
> Sims 2 doesn't render properly with it. Even if Sims2 worked perfectly with
> that hack it would not be committed.
Yup. Who implied that this hack should be committed? It was purely to
demonstrate what causes the game to fail to start.
> * DirectX 10 capable nvidia cards(geforce 8+) support 1024 vertex shader
> constants, so they should work around the SW vertex processing bug. This does
> not apply to AMD dx10 cards.
Last I checked, Wine hardcodes the constant instead of actually checking the
hardware. But what I've never understood about this bug is, lots of bugs are
filed that prevent an application or game from starting, and they might be the
only affected app/game, but people pay attention and usually attempt to fix the
problem. This bug for some reason has been demoted its entire life as
unimportant. Is it because of the complexity of it or just because it just
doesn't seem as important as a missing reference in a DLL? I would think any
known deficiency, whether a popular one or not, should be fixed simply to keep
Wine's performance as close to its targeted imitation as possible. I don't
mean this as an attack or anything, and I appreciate the HUGE undertaking of
Wine as a whole, I'm just trying to understand the politics.
Can't say that Sims 2 is too old and out of date... a lot of people still play
Sims 2 over Sims 3, if for no other reason than the massive amount of custom
content available to it, with still more being made.
Although I will admit, I don't think this bug alone will solve all the
problems. Last time I tried to implement the hack in Wine, there were reports
of some operation on stencils not being supported. This may have to do with
the visibility issues. The final glaring problem of Sims being spread eagle
and glowing I can't even begin to guess... although a similar thing happen when
a texture fails to load on an object, although that's a glowing blue effect.
--
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=3930
--- Comment #44 from Michał Z. Gołębiowski <m.goleb+winehq.org(a)gmail.com> 2011-04-25 18:12:20 CDT ---
Are those patches going to be integrated? I don't really like to compile wine
by myself, then I'd have to repeat the process each time upgraded package pops
up. (especially that I have some weird problems with wine1.3, so I prefer to
use wine1.2)
--
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=26910
Summary: Can't install RealFlight G5 demo: KEError 32318
Product: Wine
Version: 1.3.18
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mail(a)3v1n0.net
Created an attachment (id=34316)
--> (http://bugs.winehq.org/attachment.cgi?id=34316)
Output using WINEDEBUG=warn+all
When installing RealFlight G5 demo (or not), as soon as you run the setup.exe
you get an error message with:
KEError 32318: Unable to determine certain information about your computer.
This software may or may not work properly.
Demo download at: http://www.realflight.com/free-g5-demo.html
Dump attached.
--
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=1544
Austin English <austinenglish(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #11 from Austin English <austinenglish(a)gmail.com> 2011-04-25 10:35:24 CDT ---
Let's mark it fixed then.
--
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.