http://bugs.winehq.org/show_bug.cgi?id=27243
Summary: Wiggles: All renderers are unsupported
Product: Wine
Version: 1.3.19
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lukasz.wojnilowicz(a)gmail.com
Created an attachment (id=34825)
--> (http://bugs.winehq.org/attachment.cgi?id=34825)
Wiggles Settings Window
Steps to reproduce:
1) remove ~/.wine
2) winetricks gecko
3) install Wiggles
4) patch Wiggles with Wiggles_Patch_1_0_844.exe
4) wine SetMode.exe
Behaviour:
All renderers are marked as unsupported which is not true. OK button is always
grayed out. (see attachment)
Expected behaviour:
All renderers should be marked as supported. OK button shouldn't be always
grayed out.
Terminal output:
fixme:ddraw:DirectDrawEnumerateExA flags 0x00000007 not handled
fixme:win:EnumDisplayDevicesW ((null),0,0x32e7a4,0x00000000), stub!
--
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=11999
Summary: Endless Online game window appears as white texture
Product: Wine
Version: CVS/GIT
Platform: PC
URL: http://files.endless-online.com/EOsetup028.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: nodisgod(a)yahoo.com
Created an attachment (id=11336)
--> (http://bugs.winehq.org/attachment.cgi?id=11336)
Terminal output with d3d traces.
Using Wine version wine-0.9.57-84-g9ab07d5, launching the application simply
results in a white screen without any UI elements shown. Attached are d3d
traces and additional terminal output.
--
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=34744
Bug #: 34744
Summary: Earth 2150: there's no music, but sounds seem to play
fine
Product: Wine
Version: 1.7.4
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: winebugs140(a)gmail.com
Classification: Unclassified
Created attachment 46320
--> http://bugs.winehq.org/attachment.cgi?id=46320
Earth 2150
+tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio
One can reproduce the problem in the demo (check out the link).
Tested with:
Windows Vista (without Wine), GeForce 9600M GS--the program works fine here
Ubuntu 13.04, GeForce 9600M GS (NVIDIA driver 313)
Mac OS X 10.7.5, ATI HD 2600 Pro, Mac Driver/X11
--
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.
https://bugs.winehq.org/show_bug.cgi?id=38581
Bug ID: 38581
Summary: Petka 1: some objects render without transparency
Product: Wine
Version: 1.7.42
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: otaku(a)rambler.ru
Distribution: ---
Created attachment 51474
--> https://bugs.winehq.org/attachment.cgi?id=51474
console output
Wine 1.7.42, 32-bit prefix, Debian Unstable amd64
Game works without these glitches under WinXP
There's interesting d3d-related fixmes in terminal (see attachment)
--
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=26579
Summary: TomTom Home 2 fails to open web links
Product: Wine
Version: 1.3.16
Platform: x86-64
URL: http://download.tomtom.com/sweet/application/home2late
st/TomTomHOME2winlatest.exe
OS/Version: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P3
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: kennybobs(a)o2.co.uk
TomTom Home 2 fails to spawn a browser (apparently) and instead a prompt opens
asking you to select a program to open "https files".
It probably wants to open a log-in window or something similar.
Could not find last connected device. Pref reading failed: [Exception...
"Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED)
[nsIPrefBranch.getCharPref]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"
location: "JS frame :: chrome://tthome/content/ui/mainwin/mainWin.js ::
anonymous :: line 449" data: no]
Stack:
0. chrome://tthome/content/ui/mainwin/mainWin.js:490
unimportantError(e);
1. chrome://tthome/content/ui/bindings/ttdashboard.xml:167
var tmpFunc = new Function(func);
2. function _execute chrome://tthome/content/ui/bindings/ttdashboard.xml:169
tmpFunc();
3. function onClickHandler
chrome://tthome/content/ui/bindings/ttdashboard.xml:150
this._execute();
4. function onclick chrome://tthome/content/ui/dashboard/mainDashboard.xul:1
<?xml version="1.0"?>
Installed the gecko-dbg package but it made no difference to the output.
Launch the app, click more, click "Read the manual for my device".
TomTom Home 2.8.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=39421
Bug ID: 39421
Summary: Majesty Gold HD runs very slowly
Product: Wine
Version: 1.7.52
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jonas.bugzilla(a)gmail.com
Created attachment 52535
--> https://bugs.winehq.org/attachment.cgi?id=52535
Clamp the glFlush rate in the Mac driver to 60Hz
The game Majesty Gold HD (http://www.gog.com/game/majesty_gold_hd ) runs very
slowly under Wine for me (Late 2013 iMac 21.5", quad 2.9GHz Core i5, GeForce GT
750M with 1GB GDDR5, OS X 10.9.5). There is an in-game slider to speed up the
game, but it has no effect.
The game is a DirectDraw 7 game. There are also some reports on Windows
regarding this problem, but most people can solve it by telling the game to use
DirectDraw for blitting (set BlitMode=1 in the MajXPrefs, or use the -useddblit
command line parameter -- see
http://forum.paradoxplaza.com/forum/index.php?threads/bug-fixes.601217/#pos…
)
The game performs its drawing commands in the same thread that runs the game
logic (I don't know whether anything else is even supported by by DirectDraw
7). From a trace I can see that game performs many small blits to update only
the parts of the screen that have changed. Example from a trace:
trace:ddraw:ddraw_surface7_Blt iface 0x16c160, dst_rect (0,0)-(24,38),
src_surface 0x16c9c8, src_rect (0,0)-(24,38), flags 0x1000000, fx 0x0.
[ repeats 8 times ]
trace:ddraw:ddraw_surface7_Blt iface 0x16c160, dst_rect (864,661)-(1009,803),
src_surface 0x16c9c8, src_rect (864,661)-(1009,803), flags 0x1000000, fx 0x0.
trace:ddraw:ddraw_surface7_Blt iface 0x16c160, dst_rect (806,999)-(986,1080),
src_surface 0x16c9c8, src_rect (806,999)-(986,1080), flags 0x1000000, fx 0x0.
trace:ddraw:ddraw_surface7_Blt iface 0x16c160, dst_rect
(1097,734)-(1277,914), src_surface 0x16c9c8, src_rect (1097,734)-(1277,914),
flags 0x1000000, fx 0x0.
trace:ddraw:ddraw_surface7_Blt iface 0x16c160, dst_rect (860,481)-(1040,661),
src_surface 0x16c9c8, src_rect (860,481)-(1040,661), flags 0x1000000, fx 0x0.
trace:ddraw:ddraw_surface7_Blt iface 0x16c160, dst_rect (860,481)-(1040,661),
src_surface 0x16c9c8, src_rect (860,481)-(1040,661), flags 0x1000000, fx 0x0.
trace:ddraw:ddraw_surface7_Blt iface 0x16c160, dst_rect
(1354,797)-(1534,977), src_surface 0x16c9c8, src_rect (1354,797)-(1534,977),
flags 0x1000000, fx 0x0.
...
I think Wine, however, always flushes a complete new screen via OpenGL, as the
game spends almost all of its time waiting for glFlush() to finish. I have
verified that this is the case by applying the attached patch to the Mac driver
code to unconditionally clamp the glFlush rate to 60Hz. This solves the speed
issue, even at 1920x1080 (without the patch, the game is glacial even at
800x600). Obviously, the patch cannot be integrated in wine, since it
occasionally discards the "last" blit to screen after a static scene change,
leaving old data visible and no longer updating.
I previously posted about this issue (a long time ago) on wine-dev:
https://www.winehq.org/pipermail/wine-devel/2015-February/106625.html . To
answer some questions/suggestions from the end of that thread:
a) the SkipSingleBufferFlushes registry key does not help (my system supports
the GL_APPLE_flush_render extension)
b) related to Henri Verbeet's suggestion that it may be related to wine
possibly not implementing asynchronous ddraw blits: it's true that wine does
not support this, but OTOH the game does not ask for them either: it calls
ddraw_surface7_Blt rather than ddraw_surface7_BltFast (BltFast is documented on
MSDN as always being asynchronous), and it does not set the DDBLT_ASYNC flag
The game offers a built-in ability to wait for vsync via its configuration file
(set the VSync variable in $HOME/Documents/My Games/MajestyHD/MajXPrefs to
"1"), but that only results in
trace:ddraw:ddraw7_WaitForVerticalBlank iface 0x146750, flags 0x1, event 0x0.
fixme:ddraw:ddraw7_WaitForVerticalBlank iface 0x146750, flags 0x1, event 0x0
stub!
I'm also not sure whether it would help, but looking at the ddraw log (which I
will also attach -- it's a trace+ddraw,trace+d3d_draw log), I think it may
since often there are several blits between the vsync waits.
Some possible approaches to tackle this issue may be:
* handle small direct rects more efficiently
* add support for waiting for VSync in ddraw
There is a demo of an older version of the game, but it can only run in 640x480
and there is no way to adjust the game speed via an in-game slider, and at
least on my system the difference with and without my patch is not very visible
there (http://www.cyberlore.com/Majesty/demo.htm )
--
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=36869
Bug ID: 36869
Summary: Chronology under wine-mono fails to start
Product: Wine
Version: 1.7.21
Hardware: x86
URL: http://store.steampowered.com/app/269330/
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mscoree
Assignee: wine-bugs(a)winehq.org
Reporter: madewokherd(a)gmail.com
Chronology fails to start and consumes 100% of a CPU when run under wine-mono
until killed.
Based on a log with WINE_MONO_TRACE=wrapper, the only thing it does is call
Steamworks.NativeMethods:SteamAPI_InitSafe, which is a cdecl function with no
arguments. That function then endlessly throws breakpoint exceptions.
InitSafe is a cdecl function with no arguments returning signed char. I have no
idea how we could be screwing this up.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=39761
Bug ID: 39761
Summary: MDK (MDKDEM95.EXE) graphics not drawn
Product: Wine
Version: 1.8-rc3
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jeffz(a)jeffz.name
Tested on OSX 10.9.5.
http://jeffz.name/mdkdemo_repack.tar.bz2
winecfg virtual desktop set to 640x480
cd ~/.wine/drive_c && tar xf ~/mdkdemo_repack.tar.bz2 && cd mdkdemo_repack
wine MDKDEM95.EXE
The game loads (as can be heard by the sounds after hitting enter a few times)
but nothing is ever drawn. There should be intro credits, main menu and
gameplay.
Confirmed that this bug does not happen on Windows 7. It works fine there.
Note: bug #39760 deals with the D3D version of the demo.
--
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=9583
Summary: CompareStringW gives incorrect result for some wide
strings
Product: Wine
Version: CVS/GIT
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: peter(a)cendio.se
It seems like CompareStringW does not work correctly, when using wide/unicode
strings. I first discovered this when I saw that listbox controls sorted
swedish characters (say, LATIN SMALL LETTER A WITH RING ABOVE) side by side
with the base character (LATIN SMALL LETTER A). An example is
http://www.cendio.se/~astrand/wine/40-listbox-sort/list.exe.
The cause seems to be that CompareStringW gives the wrong result. I've created
the small test example
http://www.cendio.se/~astrand/wine/40-listbox-sort/comparestring.exe, with
source available in the same directory. On Windows, the result is that the
string "äpple" is greater than "orange", which is correct. With the latest
Wine CVS version, the result is that "äpple" is lesser than "orange", which is
wrong.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.