http://bugs.winehq.org/show_bug.cgi?id=7849
------- Additional Comments From dank(a)kegel.com 2007-28-03 17:36 -------
Hrm. Even with all your recent patches having made it into git,
I'm still seeing this with current git. Are there a few
patches left in the series?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5955
------- Additional Comments From stefandoesinger(a)gmx.at 2007-28-03 17:34 -------
First of all: You are right regarding the wine documentation. It is in a
pretty bad shape and is really outdated. Patches are welcome of course :-) . A
first step would be a patch to improve the ERR messages in ddraw, d3d8 and
d3d9 to suggest checking opengl.
I do not buy the newbie argument. All recent Linux distros do ship a working
opengl library by default. The only real exception is Gentoo, and I do not
consider Gentoo a newbie distro. Furthermore I don't think that running a game
over a remote link like the reporter did is something newbies do regularly.
Also I recommend you to read the Gentoo documentation, especially the thing
about "eselect opengl". The old system argument isn't really valid either. For
one part see below. And even if its because of opengl beeing needed for some
reason, there is no hardware out there which runs current beginner's distros
but does not have at least a basic 3d accelerator. (Yes, you can run things
like Gentoo on old hardware, I myself have an up to date Gentoo system on my
old 120 mhz notebook. But that isn't something people new to Linux will do
either)
Regarding the slowness: Is it really because of opengl? I suspect it is
because of the asynchronous surface updates(bug 5526). There used to be a hack
in the old ddraw implementation for that, but Alexandre didn't accept it back
as is. For properly synchronizing such surface updates the whole DirectX code
has to be synchronized - or at least before I see a point in trying to send
the patch again. Volunteers welcome.
I won't stop anyone from implementing lazy linking against libGL.so. Its just
that I personally won't do that anytime soon because there are other things to
do which I consider higher priority.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7247
sheeettin(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sheeettin(a)gmail.com
------- Additional Comments From sheeettin(a)gmail.com 2007-28-03 17:02 -------
Problem seems to be that the cursor is not re-centered in the window. You can
freely move the cursor out of the windows, stopping the character's rotation.
(It'll also stop if it hits the edge of the screen, if in fullscreen).
Sometimes, if you try and push the cursor past one boundary, you will be able to
get the cursor farther in the opposite direction.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5955
------- Additional Comments From J.Nicolaisen(a)gmx.net 2007-28-03 16:31 -------
OK I got it to "work."
Here's how to get Starcraft etc. to run with the x11 driver on a system without
OpenGL (remember, these games don't even need hardware acceleration.)
_In this order_:
- Make sure you have libGL on your system (this is just a crutch for wine's
detection process, which is obviously buggy.)
-Make sure libGL.so.1 is in your PATH. I had to create a symlink:
ln -s usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 /usr/lib/libGL.so.1
- Recompile wine with opengl support (Gentoo users must enable the opengl
useflag - it's no longer optional)
- Reinstall wine
- As the FIRST THING, run winecfg; this will tell you that OpenGL doesn't work
and thus it is "disabled" (I never found out what exactly this "disabling" did.)
This needs to be done before running any other apps.
- Set the aforementioned magic registry key
- Reinstall all apps (games) from scratch (full Baldur's Gate install + patching
etc, grr.)
Then it magically worked. Not very well (bad performance compared to wine
0.9.8), but the games run.
Regarding your comment Stefan, here's what I have to say.
a) It's just not working out of the box. It would not work for a newbie or
computer illiterate person with an old laptop.
b) It is not clear that you have to compile wine with openGL support (and thus
you need libGL.) There's no warning. No documentation.
c) I don't like to be told off with "It works for X percent of standard users,
so your complaint is invalid." That's not good practice, it's a cheap way out.
It's what Windows does.
Some things I would expect:
- Clearly state that libGL (or Mesa) is a dependency of Wine; declare that Wine
practically needs 3D acceleration even for 10 year old Direct Draw apps
- Clearly state that users who have no 3D capable hardware should keep using
wine 0.9.8 (or Windows.)
In my experience the Mesa software GL substitute is unbelievably slow, so that's
not an option.
A final remark: The hoops I had to jump through to get those ten-year-old DDraw
games working with wine 0.9.31 remind me of the typical Windows experience.
Congrats on emulating that as well.
You're eager to close this bug and move on; go ahead and do so. Mark it as WONT
FIX and declare it a feature.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7853
wine.dev(a)web.de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wine.dev(a)web.de
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
------- Additional Comments From wine.dev(a)web.de 2007-28-03 15:40 -------
I have the same Problem with a different App.
A while ago, I created a test for this Problem (needs a patched
"wine/tests.h" and was crosscompiled with OpenWatcom as win3.1-app),
but stdio is redirected to a GUI-Window by the OW-Runtime.
Any Ideas for a win3.1 - compatible redirection in our testsuite?
--
By by ... Detlef
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7887
Summary: Oblivion requires d3dx9_27.dll to run
Product: Wine
Version: 0.9.33.
Platform: PC
URL: http://appdb.winehq.org/appview.php?iVersionId=4596
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: vit.hrachovy(a)sandbox.cz
Installation is fine, but when trying to run the game program crashes with the
following info:
err:module:import_dll Library d3dx9_27.dll (which is needed by L"C:\\Program
Files\\Bethesda Softworks\\Oblivion\\Oblivion.exe") not found
err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program
Files\\Bethesda Softworks\\Oblivion\\Oblivion.exe" failed, status c0000135
Unfortunately, no demo is available.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7881
------- Additional Comments From focht(a)gmx.net 2007-28-03 15:11 -------
Hello,
from what i've seen looking at java jni code it basically boils down to
following (took the code directly from java impl. into a small C test program):
Java_sun_awt_Win32GraphicsDevice_getDefaultPixIDImpl calls
---> Java_sun_awt_Win32GraphicsDevice_isPixFmtSupported calls
---> int max = ::DescribePixelFormat(hDC, (int)pixFmtID,
sizeof(PIXELFORMATDESCRIPTOR), &pfd);
params:
hDC = ::GetDC( ::GetDesktopWindow()) (desktop hdc)
pixFmtId = 1
output:
--- native windows ---
DescribePixelFormat(): max=100, pfd.cColorBits=32, pfd.iPixelType=0,
pfd.dwFlags=0x34
Java_sun_awt_Win32GraphicsDevice_getDefaultPixIDImpl() returns 1
--- native windows ---
--- wine linux ---
DescribePixelFormat(): max=1, pfd.cColorBits=32, pfd.iPixelType=0, pfd.dwFlags=0x25
Java_sun_awt_Win32GraphicsDevice_getDefaultPixIDImpl() returns 0
--- wine linux ---
return "0" means no suitable Pixel Format id found -> exception thrown.
The problem is the "flags" field in pixel format descriptor.
Windows returns 0x34: PFD_SUPPORT_OPENGL | PFD_SUPPORT_GDI | PFD_DRAW_TO_WINDOW
Wine returns 0x25: PFD_SUPPORT_OPENGL | PFD_DRAW_TO_WINDOW | PFD_DOUBLEBUFFER
The "required" flags field in that JRE implementation is: PFD_SUPPORT_GDI |
PFD_DRAW_TO_WINDOW
Basically: ((pfd.dwFlags & REQUIRED_FLAGS) == REQUIRED_FLAGS) to satisfy
function call (valid pixel id)
For windows this condition is satisfied - for the wine case not (PFD_SUPPORT_GDI
bits missing).
The wine X11 driver doesnt honour this value in
wine/dlls/winex11.drv/opengl.c:X11DRV_DescribePixelFormat() and
X11DRV_ChoosePixelFormat().
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2398
------- Additional Comments From mail(a)science.su 2007-28-03 14:36 -------
> For instance, the image of a drop down menu remains on the opengl window
> after the menu is closed. Interacting with the program and triggering a
> redraw causes the artifacts to disappear.
This is actually what I call "a little dirty code". This happens as far as I
understand because child window doesn't update if it gets overdrawn. But in my
practice, including a lot of work with Lightwave and some other professional
software that uses Direct3D/OpenGL child windows this problem proved to be
minor and mostly cosmetic. Anyway, this is a lot better than working with
these programs in VMWare! Besides it shouldn't be very hard to fix this minor
bug later.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.