http://bugs.winehq.org/show_bug.cgi?id=7411
Vitaliy Margolen <vitaliy(a)kievinfo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomas.bozik(a)gmail.com
--- Comment #17 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-02-07 13:17:47 ---
*** Bug 17262 has been marked as a duplicate of this bug. ***
--
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=8030
--- Comment #21 from NSLW <lukasz.wojnilowicz(a)gmail.com> 2009-02-07 12:39:00 ---
Created an attachment (id=19314)
--> (http://bugs.winehq.org/attachment.cgi?id=19314)
log with directx9.0 installed (WINE 1.1.14)
I'm using Fedora 10 i386 , WINE 1.1.14 with 180.27 nvidia drivers. I installed
directx_nov2008_redist.exe through winetricks. Unpatched game shows black
screen then ends up with 640x480 resolution. I'm adding log.
--
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=421
--- Comment #114 from max(a)veneto.com 2009-02-07 06:03:15 ---
(In reply to comment #113)
> To repeat my opinion (See #52), using "winedib.drv" is the wrong direction.
>
..........................
> For this, the DIB implementation must move to GDI32
> (the GDI Rendering Engine: Eng* and friends).
>
That's obvious and that's also my opinion.
The problem is that including the DIB engine inside GDI32 (where it should
indeed belong) would require huge changes in gdi32 code itself.
So, IMHO, we wouldn't see the dib engine at least for a couple of years or
more.
Now, with the winedib.drv choice we could develop ALL dib engine code from
outside gdi32, with just some very small changes inside it, and have it
working.
With my latest code, the engine, if disabled, is totally transparent to gdi32
so it can't cause regressions, which is a good stuff, but can be tested by
people needing it.
Once we have the winedib.drv code fully functional, nothing blocks us to
integrate it in gdi32.
Another possible solution would be to make an "alternative" gdi32 bindable at
configure time in place of the actual one, on which the dib engine could be
developed. People could choose with configure if to have the old good gdi32 or
the new one with the engine embedded.
IMHO that solution has an advantage (the "new" gdi32, when ready, would require
no additional work to embed the engine) but an huge disadvantage, which is the
ability to quickly switch on or off the engine, which could ease greatly the
testing and debugging phase.
Ciao
Max
--
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=421
--- Comment #113 from Detlef Riekenberg <wine.dev(a)web.de> 2009-02-07 05:46:15 ---
To repeat my opinion (See #52), using "winedib.drv" is the wrong direction.
We should use the DDI (Device Driver Interface) between GDI32 and
the Drivers (DDI can be used parallel to our old API).
For this, the DIB implementation must move to GDI32
(the GDI Rendering Engine: Eng* and friends).
That way, we have only one physdev, our code can decide, when to use
Driver rendering, OpenGL acellerated rendering or software rendering.
This direction is required, when we want to support native drivers.
For simple Workstations, this would be printer drivers.
For Workstations in a company, this includes also Mirror Drivers
(for remote control)
We could have other Driver next to winex11.drv very easy
(winesdl.drv anyone ?)
--
By by ... Detlef
--
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=7643
Jérôme Gardou <jerome.gardou(a)laposte.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jerome.gardou(a)laposte.net
--- Comment #67 from Jérôme Gardou <jerome.gardou(a)laposte.net> 2009-02-07 04:42:28 ---
I can play this game for hours without any problem. Is anyone still having this
issue?
--
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=17280
Summary: MOHAA incorrectly checks working directory
Product: Wine
Version: 1.1.14
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: adam.eberlin(a)intellitechdesign.com
When opening the program from the home directory, the program tries to open
Z:\home\user\main, when it should be looking for
"Z:\home\user\.wine\drive_c\Program Files\EA GAMES\MOHAA\main" or "C:\Program
Files\EA GAMES\MOHAA\main". Below is the message returned in the mohaa console:
--- Common Initialization ---
Medal of Honor Allied Assault 1.11 win-x86 Mar 5 2002
----- FS_Startup -----
Current search path:
Z:\home\zen/main
----------------------
0 files in pk3 files
Couldn't load default.cfg
This prevents the program from locating various required configuration files
used when starting up the application.
A temporary workaround is to 'cd /home/zen/.wine/drive_c/Program\ Files/EA\
GAMES/MOHAA/' and run wine from inside the program files directory.
--
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=7042
Lauri Kenttä <lauri.kentta(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lauri.kentta(a)gmail.com
--- Comment #20 from Lauri Kenttä <lauri.kentta(a)gmail.com> 2009-02-06 16:07:25 ---
To reproduce the bug, try importing a character twice. To get another similar
crash in the loading screen before the game starts, import only one character
and try to start the game.
Some interesting comparison to other games that use Infinity Engine:
* BG does not have the bug (has older engine version)
* BG2 has the same bug (and probably the same engine version)
* IWD2 has almost same bug (has newer engine version), see bug 14267. Importing
many characters doesn't crash, but starting the game with them crashes just as
here.
Workaround: do not import characters. The games actually work reasonably well.
(Of course, there are some other bugs that cause random crashes for unknown
reasons.)
And no, I'm not going to do any regression testing here, as there's no evidence
that this would be a regression. ;)
--
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=4286
Ken Sharp <kennybobs(a)o2.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kennybobs(a)o2.co.uk
--
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=4286
--- Comment #18 from Ken Sharp <kennybobs(a)o2.co.uk> 2009-02-06 15:39:20 ---
Created an attachment (id=19290)
--> (http://bugs.winehq.org/attachment.cgi?id=19290)
wine-1.1.14-248-gcb57ebc console output
Tested in latest wine-git, problem persists. Still silently exiting.
--
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=13826
Summary: Everest Poker fails to load
Product: Wine
Version: 1.0-rc4
Platform: PC
URL: http://www.EverestPoker.org.uk
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: kennybobs(a)o2.co.uk
Created an attachment (id=13875)
--> (http://bugs.winehq.org/attachment.cgi?id=13875)
Bash printout.
Following advice for using a native gdiplus.dll in bug 12906, Everest Poker
gets to the startup screen, then fails to progress.
Without the native gdiplus.dll, Everest Poker does not progress this far.
--
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.