http://bugs.winehq.org/show_bug.cgi?id=1158
elad <el.il(a)doom.co.il> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |el.il(a)doom.co.il
--- Comment #9 from elad <el.il(a)doom.co.il> 2010-07-13 04:20:00 ---
it is still a problem in wine 1.2-rc6.
--
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=1163
--- Comment #23 from elad <el.il(a)doom.co.il> 2010-07-13 04:18:16 ---
i think this bug should be reopened.
--
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=23630
Summary: do not scan all font metrics on application startup
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdi32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jstpierre(a)mecheye.net
With a good set of fonts, about 800-1200 families, wine is not very good at
starting up fast, and it doesn't even respond to signals. The only way I've
found to kill it is with a wineserver -k.
I was told that wine currently scans font metrics on each application startup.
I feel that this could be improved, either by scanning the information needed
from the font file lazily or once, on wineserver start.
Approximate time, it takes around 3-4 minutes for a cold start of winecfg
before effects are visible.
--
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=23599
Summary: Texture problems in Deus Ex 2: invisible war
Product: Wine
Version: 1.2-rc7
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: duck(a)duckcorp.org
Created an attachment (id=29510)
--> (http://bugs.winehq.org/attachment.cgi?id=29510)
log (+d3d,+seh)
I can launch the game, view the intro scene, the rest of the game loads fine
and the loading screen is proper, but then the display is incomplete, both in
the menu and in the game: only part of the interface is displayed well, no
background and images in menu, no objects in game. It is absolutely unplayable.
I'm using Debian unstable on i386, with a Mobility Radeon X300 and the Free
driver (v6.13.1), and opengl+fbo (but other combinations of opengl/gdi and
backbuffer/fbo didn't help).
As can be seen in the log, the problem seems related to:
fixme:d3d:state_wrap (WINED3DRS_WRAP0) Texture wrapping not yet supported
which is supposed to have been fixed in #8176 (but opening a new report as
requested).
--
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=23624
Summary: Streets of Moscow completely ignores keyboard and
mouse input
Product: Wine
Version: 1.2-rc7
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-dinput
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: gyebro69(a)gmail.com
Created an attachment (id=29556)
--> (http://bugs.winehq.org/attachment.cgi?id=29556)
console log
Streets of Moscow (a car racing game) doesn't accept any keyboard or mouse
input after starting, thus it's unplayable. The issue exists both in fullscreen
and virtual desktop mode.
So far I've tried the following but none of them worked:
- setting the win version to W2k
- the XI2_input patch from bug #6971 (my X.Org version is 1.8.2)
- the patch from bug #8854
- the rawinput3 patch from bug #10318 > the game crashed on startup in
RegisterRawInputDevices()
- installing native dinput/dinput8.dlls
Unfortunately, no demo is available.
Fedora 13 x86
X.Org 1.8.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=20160
Summary: ieplore: automatic gecko installer crashes
Product: Wine
Version: 1.1.30
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jsims2359(a)gmail.com
Created an attachment (id=23759)
--> (http://bugs.winehq.org/attachment.cgi?id=23759)
terminal output of wine iexplore
In wine-1.1.30, with a clean wine prefix, run "wine iexplore" and the automatic
wine_gecko installer will crash while downloading.
--
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=23607
Summary: High CPU usage with idle NewsLeecher
Product: Wine
Version: 1.0-rc5
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: patrick_stokman(a)hotmail.com
Since the last two, maybe three RCs, NewsLeecher uses a lot of CPU when it
starts and sits idle. No matter what you do, it keeps using one core
completely. This wasn't the case with rc1 and rc2 for sure (and before).
Sending NL to tray reduces CPU to a better level, but still above normal.
Average use on my 2.8 GHz AMD dual core:
Tray: ~20%
Normal: ~40%-80%, changing every second or so (up/down)
Due to this 'abuse', the GUI updates are very slowly, repaints are clearly
visible and scrolling is very slow because of 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=3028
--- Comment #19 from Austin English <austinenglish(a)gmail.com> 2010-07-12 10:52:22 ---
The testcase still fails:
austin@midna:~$ wine ./a.exe
FindFirstFile cache/*.*
failed with error 3: Path not found
FindFirstFile cache/Browser/*.*
failed with error 3: Path not found
FindFirstFile cache/foo.bar
failed with error 3: Path not found
CreateFile c:\foo\bar.txt
failed with error 3: Path not found
CreateFile c:\foo\
failed with error 2: File not found
CreateFile c:\foo\*.*
failed with error 123: Invalid name
--
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=9030
--- Comment #30 from Boran Car <boran.car(a)gmail.com> 2010-07-12 07:50:03 ---
(In reply to comment #28)
> Created an attachment (id=29544)
--> (http://bugs.winehq.org/attachment.cgi?id=29544) [details]
> Armymen menu - with faked palette
>
> I had created a simple faked palette just in CreatePalette, so I recieved some
> usable pictures. I had stepped through army men initialization process and i
> had discovered that this program gives a pretty odd palette to CreatePalette
> call - 256-times R:0 G:0 B:0. Maybe Armymen relies on a default palette, maybe
> not. Once more interesting article i found is that army men does all the
> rendering through GetDC and ReleaseDC, so the palette is not probably needed.
> Then the problem is in X11DRV_DIB_MapColor, because the search for acceptable
> color fails and the function returns zero index - allways black color. This is
> probably more general problem with translating colors between palette and DC.
Yes, you are completely right. I had abandoned this for a while, promising to
return to it later. I remember using hw breakpoints to see if anything gets
copied to the surface memory, and indeed, zeros were copied all the time so I
dismissed it as no copying. This might prove the fact that all rendering is
done through GetDC and ReleaseDC which in fact call Lock and Unlock and do the
translation themselves, hence, we get 24-bit RGB (0,0,0) = 0. Maybe this
palette gets input as a result of another function call and game logic. I was
planning to make a proxy ddraw.dll on windows and trace the calls to ddraw to
get more insight. Can you please provide me with that article?
It's possible to obtain the correct default palette from windows and use it in
wine. One more thing that might prove this is an odd result while playing Air
Tactics on Windows XP. Sometimes, the screen turns into a color noise (probably
as a result of a palette change). If we can fix this on Wine, we might provide
a ddraw.dll that will make the game (and similar games to it) runnable once
more on Windows.
--
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.