Re: 3dmark2000, 3dmark06 results on both Wine and Vista
On Sat, May 1, 2010 at 5:26 PM, Scott Ritchie sc...@open-vote.org wrote: One note of caution is that video card manufacturers have been known to blatantly cheat on these tests by rigging their drivers with special hacks when they detect 3dmark is running. As far as I know the code may still be there. Since the Linux drivers probably don't have these hacks, if they are indeed still enabled you wouldn't get an Apples:Apples comparison even on the same hardware. Scott, please bottom post on wine mailing lists. As for the driver hacks, you might try renaming the executable (e.g., 3dmark.exe -3dmarktest.exe). Some of those hacks only check the executable name, and renaming the executable restores the 'real' behavior. Quake 3 was well known for this.. -- -Austin
Re: 3dmark2000, 3dmark06 results on both Wine and Vista
On Sun, May 2, 2010 at 4:08 AM, Dan Kegel d...@kegel.com wrote: I did some apples-to-apples 3d benchmarking today on a dual boot system. It looks offhand like Windows is about twice as fast as Wine on these benchmarks on my system. cpu: e8400 ram: 4GB video card: nvidia GT 240 Ubuntu 32 10.04 video drivers: 195.36.15 Vista 64 video drivers: 8.17.11.9713 Do you happen to have a 4k/5k series ATI card to attempt this test set with as well? I'd find it interesting to see their relative performance as well as the notable short comings (things not rendered) ATI still have under Wine. Some one asked me the other day how well they'd fair with a new ATI card under Wine and Linux and I had no idea about an answer.
Re: 3dmark2000, 3dmark06 results on both Wine and Vista
When doing such benchmarks also try to write down the frame rates of the individual tests. The 3dmark score is some sort of weighted average (the result of the cpu test in it is also quite important). From what I remember the scores in 2000/2001/2003 were actually good but 2005/2006 used to be quite slow for some reason. Roderick On Sat, May 1, 2010 at 8:08 PM, Dan Kegel d...@kegel.com wrote: I did some apples-to-apples 3d benchmarking today on a dual boot system. It looks offhand like Windows is about twice as fast as Wine on these benchmarks on my system. cpu: e8400 ram: 4GB video card: nvidia GT 240 Ubuntu 32 10.04 video drivers: 195.36.15 Vista 64 video drivers: 8.17.11.9713 Test procedure: On Ubuntu, grab latest wine from git, apply patch from http://bugs.winehq.org/show_bug.cgi?id=9210 so 3dmark06 will run. On Windows, install cygwin and a few of its packages (cabextract, wget, svn, etc.) Then on both systems do svn checkout http://winezeug.googlecode.com/svn/trunk/ winezeug sh winezeug sh yagmarktest That will run the tests in a loop and save a report for each run in the current directory. Results at http://kegel.com/wine/yagmarkdata/e8400/ Summary: Ubuntu: 6 runs 3dmark2000: min 4145, median 4154, max 4170 3dmark2001: min 18884, median 19261, max 19520 3dmark2006: min 17315, median 18154, max 18498 Vista: 2 runs: 3dmark2000: 8206, 8219 3dmark2006: 30278, 32384 Notes: 1) 3dmark2001 hangs for me on vista 64 bits, so no results for that test on that OS, I had to edit yagmarktest to remove it from the loop. Does it work for anyone else? 2) nvidia drivers occasionally crash X when running or quitting 3dmark2000 or 3dmark06; it's happened to me three times. 3) test script is fragile, don't touch the mouse or keyboard while it's running 4) shadows appear to be missing on wine in firefly forest in 3dmark06 and giant mecha truck test in 3dmark01? 5) format of my log files is ugly and will change.
Re: 3dmark2000, 3dmark06 results on both Wine and Vista
On Sun, May 2, 2010 at 1:03 AM, Edward Savage epss...@gmail.com wrote: video card: nvidia GT 240 Do you happen to have a 4k/5k series ATI card to attempt this test set with as well? I have three nvidia cards: 8500gt, gt220, gt240. (I also have an old ati rage pro which probably isn't worth testing.) I'd find it interesting to see their relative performance as well as the notable short comings (things not rendered) ATI still have under Wine. Some one asked me the other day how well they'd fair with a new ATI card under Wine and Linux and I had no idea about an answer. Maybe someone with current ATI hardware can run yagmark following the steps I gave. It's pretty easy. - Dan
Re: 3dmark2000, 3dmark06 results on both Wine and Vista
On Sun, May 2, 2010 at 2:07 AM, Roderick Colenbrander thunderbir...@gmail.com wrote: When doing such benchmarks also try to write down the frame rates of the individual tests. The 3dmark score is some sort of weighted average (the result of the cpu test in it is also quite important). From what I remember the scores in 2000/2001/2003 were actually good but 2005/2006 used to be quite slow for some reason. OK, I'll try to parse out the subscores. - Dan
Re: 3dmark2000, 3dmark06 results on both Wine and Vista
Am 01.05.2010 20:08, schrieb Dan Kegel: Results at http://kegel.com/wine/yagmarkdata/e8400/ Summary: Ubuntu: 6 runs 3dmark2000: min 4145, median 4154, max 4170 3dmark2001: min 18884, median 19261, max 19520 3dmark2006: min 17315, median 18154, max 18498 Vista: 2 runs: 3dmark2000: 8206, 8219 3dmark2006: 30278, 32384 It looks like you've mixed up the results somewhere. The score should be higher on the lower 3Dmark version. (3dmark 2000 on vista has 30278 points - http://kegel.com/wine/yagmarkdata/e8400/gt240/vista/yagmark-e8400-Vista-2010-04-30-18:30.txt) Cheers Rico
Re: 3dmark2000, 3dmark06 results on both Wine and Vista
2010/5/2 Rico Schüller kgbric...@web.de: It looks like you've mixed up the results somewhere. The score should be higher on the lower 3Dmark version. (3dmark 2000 on vista has 30278 points - http://kegel.com/wine/yagmarkdata/e8400/gt240/vista/yagmark-e8400-Vista-2010-04-30-18:30.txt) That'll teach me to edit data tables manually. Next one will be automatically generated. - Dan
Unable to start WoW from git 1.1.29 while 1.1.29 tarball works.
Hello all. I am unable to start WoW when I compile release 1.1.29 from the git repo, while compiling the 1.1.29 release tarball allows me to play WoW. System info: % uname -a; isainfo -k SunOS asuka 5.11 snv_115 i86pc i386 i86pc amd64 Git compile steps taken: git checkout wine-1.1.29 git clean -x -f ./configure --prefix=/opt/myrkraverk/wine-git gmake depend gmake WoW now fails to start with some console output like: [joh...@asuka]~/src/external/git/wine/wine% Can't attach process 0011: error 6 wine: Call from 7fd69d43 to unimplemented function user32.dll.UserRegisterWowHandlers, aborting fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 8100 err:module:DelayLoadFailureHook failed to delay load user32.dll.LoadStringW More pastes here: http://paste.lisp.org/display/98679 I did not use any special flags or environment variables to compile the tarball, apart from the prefix. This is my showstopper to regression test bug 22033: http://bugs.winehq.org/show_bug.cgi?id=22033 Any help apreciated. Johann
Re: new wisotool 20100424: new verbs 3dmark2000, 3dmark2001, 3dmark03, 3dmark05, 3dmark06, baldursgate2, gta_vc, pcmark04, pcmark05, unigine_heaven
Patch updated.
Notes:
- Download urls and AHK scripts are *all* tested as of this patch (~5 hours to
install everything).
- BAT scripts are *not* tested.
Remaining issues:
- url escaping when posting login password (I'll work on this next)
- possibly BAT scripting mistakes (verb definition)
- possibly a yet unidentified auth bug which affected Dan Kegel
- missing BAT scripts for bundles (not sure what to do for those)
Changelog:
- add cookie support in download (required as GOG.com requires auth
to download games)
- add download support for gog verbs
- Refresh against current svn head
- _load_gog: added install_dir parameter (needed by a few games)
- double all \ meant to be literal backslashes
- fix download path for verbs:
ut2004_gog
abes_oddysee_gog
abes_exoddus_gog
descent_1_2_gog
- add verbs:
descent_3_gog
psychonauts_gog
ut_goty_gog
unreal_gold_gog
unreal_2_se_gog
battle_chess_gog
earth_2150_trilogy_gog
earth_2160_gog
empire_earth_gold_gog
earthworm_jim_1_2_gog
shogo_gog
settlers_2_gold_gog
robinson_requiem_collection_gog
redneck_rampage_gog
praetorians_gog
perimeter_gog
painkiller_black_gog
operation_flashpoint_goty_gog
neighbours_from_hell_compilation_gog
mdk_gog
mdk2_gog
ground_control_2_gog
ghost_master_gog
freespace_gog
freespace_2_gog
flatout_gog
earthworm_jim_3d_gog
fallout_gog
fallout_2_gog
fallout_tactics_gog
--
Vincent Pelletier
Index: wisotool
===
--- wisotool (révision 1220)
+++ wisotool (copie de travail)
@@ -340,7 +340,7 @@
}
# Download a file
-# Usage: package url [sha1sum [filename]]
+# Usage: package url [sha1sum [filename [cookie jar]]]
# Caches downloads in wisotoolcache/$package
download() {
if [ $4x != x ]
@@ -371,11 +371,11 @@
# [*] --read-timeout is useful on the adobe server that doesn't
# close the connection unless you tell it to (control-C or closing
# the socket)
- try wget -O $file -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate $2
+ try wget -O $file -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate ${5:+--load-cookies $5} $2
else
# curl doesn't get filename from the location given by the server!
# fortunately, we know it
- try curl -L -o $file -C - --header Accept-Encoding: gzip,deflate $2
+ try curl -L -o $file -C - --header Accept-Encoding: gzip,deflate ${5:+--cookie $5} $2
fi
# Need to decompress .exe's that are compressed, else cygwin fails
# Only affects cygwin, so don't barf if 'file' not installed
@@ -2182,7 +2182,7 @@
#
# Generic GOG.com installer
-# Usage: game_id game_title [other_files [reader_control [run_command [download_id
+# Usage: game_id game_title [other_files [reader_control [run_command [download_id [install_dir]
# game_id
# Used for main installer name and download url.
# game_title
@@ -2197,6 +2197,8 @@
# Used for bat script, relative to installation path.
# download_id
# For games which download url doesn't match their game_id
+# install_dir
+# If different from game_title
_load_gog()
{
# TODO: support SHA1 checks ? (installer verifies files)
@@ -2209,8 +2211,21 @@
reader_control=$4
run_command=$5
download_id=$6
+install_dir=$7
+if [ $download_idx = x ]
+then
+download_id=$game_id
+fi
+if [ $install_dirx = x ]
+then
+install_dir=$game_title
+fi
+
installer_path=$WISOTOOL_CACHE/$PACKAGE
+mkdir -p $installer_path
+auth_path=$WISOTOOL_CACHE/gog_auth
+mkdir -p $auth_path
installer=setup_$game_id.exe
cookie=$auth_path/cookie.txt
@@ -2220,7 +2235,32 @@
file_path=$installer_path/$file
if ! test -s $file_path
then
-die Please download $file to $installer_path
+if ! test -f $cookie
+then
+login_file=$auth_path/login.txt
+password_file=$auth_path/password.txt
+if ! test -f $login_file -a -f $password_file
+then
+die Please put your GOG.com login in '$login_file' and password in '$password_file' or put '$file' in '$installer_path'.
+fi
+base_url=https://www.gog.com;
+login_url=/en/login/ajax/
+next_url=$WISOTOOL_TMP/gog_redir_url
+post_data=$WISOTOOL_TMP/gog_post_data
+# Note: just write login password to a file so they don't appear in ps
+echo a=checkt=oldu=`cat \$login_file\ | sed 's//%26/g'`p=`cat \$password_file\ | sed 's//%26/g'`r=frontpage $post_data
+if test -x `which wget 2/dev/null`
+then
+try
Re: Unable to start WoW from git 1.1.29 while 1.1.29 tarball works.
Hi all, On Sun, May 2, 2010 at 4:55 PM, Johann Myrkraverk Oskarsson joh...@myrkraverk.com wrote: I am unable to start WoW when I compile release 1.1.29 from the git repo, while compiling the 1.1.29 release tarball allows me to play WoW. With help from #winehq: An out of tree build works. Johann
Fullscreen Borderlands at Desktop Resolution
I've been playing the game Borderlands at less than my desktop resolution
due to a strange bug and finally decided to try and track it down. The
issue is that whenever the resolution of Borderlands is set to the same
resolution as the desktop then the game window does not appear in the upper
left hand corner and the size of the window is about 1/2 of the display size
for both the width and the height. After some exploration, this appears to
be two separate issues with the Wine's X11 driver.
1) sync_window_position() will not move an iconified managed window, so the
window is never repositioned to the upper left corner.
2) set_size_hints() checks to see if a window is the size of the display (or
larger) and does not resize the window if that is the case.
Another interesting point is that these issues only occur when using compiz,
when using metacity the following warnings are displayed:
---
Window manager warning: Window 0x425 (Borderland) sets an MWM hint
indicating it isn't resizable, but sets min size 1 x 1 and max size
2147483647 x 2147483647; this doesn't make much sense.
Window manager warning: Treating resize request of legacy application
0x425 (Borderland) as a fullscreen request
---
I've attached a patch that overcomes these issues, but I'm suspicious that
there are unintended consequences. I would appreciate it if someone could
take a look.
Erich Hoover
ehoo...@mines.edu
diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c
index 8cd3bf3..96f758e 100644
--- a/dlls/winex11.drv/window.c
+++ b/dlls/winex11.drv/window.c
@@ -1003,6 +1003,18 @@ static void set_size_hints( Display *display, struct x11drv_win_data *data, DWOR
size_hints-min_height = size_hints-max_height;
size_hints-flags |= PMinSize | PMaxSize;
}
+
+if (data-whole_rect.left == 0 data-whole_rect.right == screen_width
+data-whole_rect.top == 0 data-whole_rect.bottom == screen_height)
+{
+size_hints-x = 0;
+size_hints-y = 0;
+size_hints-max_width = screen_width;
+size_hints-max_height = screen_height;
+size_hints-min_width = size_hints-max_width;
+size_hints-min_height = size_hints-max_height;
+size_hints-flags |= PPosition | PMinSize | PMaxSize;
+}
}
XSetWMNormalHints( display, data-whole_window, size_hints );
XFree( size_hints );
@@ -1442,8 +1454,6 @@ static void sync_window_position( Display *display, struct x11drv_win_data *data
XWindowChanges changes;
unsigned int mask = 0;
-if (data-managed data-iconic) return;
-
/* resizing a managed maximized window is not allowed */
if (!(style WS_MAXIMIZE) || !data-managed)
{
Re: Francois Gouget : winedbg: Fix compilation with gcc 2. 95 and non-GNU compilers.
On Wed, 21 Apr 2010, Eric Pouech wrote: Francois Gouget a écrit : There were two problems: * the semi-colon was missing for non-GNUC compilers as you mentioned * gcc 2.95 does not support __attribute__() on function pointers Unfortunately your patch does not fix the second issue. A solution that would not require dbg_vprintf() would be to check the gcc version before trying to use __attribute__(). [...] does the attached patch works better ? (I tried your suggestion starting at gcc 3.0) Yes, that works. It means that we won't get the benefit of printf format checking on gcc 2.95 but that does not matter since pretty much everyone will do these checks already. And your patch is simpler than mine (and more importantly works). -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Stolen from an Internet user: f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !
Re: quartz: Properly return E_POINTER when ppFilters is null
On 5/3/2010 02:17, Jerome Leclanche wrote: Fixes bug 22563. Also fix broken indent right below. J. Leclanche Please, add a test for this, it looks trivial to test.
Re: Minor dlls/dbghelp/dwarf.c simplification
Eric Pouech wrote:
this is wrong: dwarf_parse family set makes the pointer in the cxt
advance by the size of the object which is being parse
You're right. I had, in fact, checked this very question, but doing
so just again I see where I missed the += in the code. Thanks for
catching this, Eric!
and actually, the correct fix would be to make use of those variables
(like checking if the version is a known one), instead of throwing
things away
Are you planning to go into that direction? If not, I'd suggest the
patch below. (I'm not sure whether checking for the DWARF version is
going to help -- do we want to abort for newer versions when these
actually should be compatible?)
Gerald
From: Gerald Pfeifer ger...@pfeifer.com
Date: Sun, 2 May 2010 22:05:20
Subject: dbghelp: Remove two variables which are not really used in
dwarf2_parse_line_numbers.
---
dlls/dbghelp/dwarf.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c
index 4be0f6a..99960d8 100644
--- a/dlls/dbghelp/dwarf.c
+++ b/dlls/dbghelp/dwarf.c
@@ -1920,7 +1920,7 @@ static BOOL dwarf2_parse_line_numbers(const
dwarf2_section_t* sections,
{
dwarf2_traverse_context_t traverse;
unsigned long length;
-unsignedversion, header_len, insn_size, default_stmt;
+unsignedinsn_size, default_stmt;
unsignedline_range, opcode_base;
int line_base;
const unsigned char*opcode_len;
@@ -1939,8 +1939,8 @@ static BOOL dwarf2_parse_line_numbers(const
dwarf2_section_t* sections,
length = dwarf2_parse_u4(traverse);
traverse.end_data = sections[section_line].address + offset + length;
-version = dwarf2_parse_u2(traverse);
-header_len = dwarf2_parse_u4(traverse);
+dwarf2_parse_u2(traverse);
+dwarf2_parse_u4(traverse);
insn_size = dwarf2_parse_byte(traverse);
default_stmt = dwarf2_parse_byte(traverse);
line_base = (signed char)dwarf2_parse_byte(traverse);
--
1.6.6.2
Re: Remove variable doRecursive which is not really used from WCMD_for.
On Sun, 2 May 2010, Nikolay Sivov wrote: Please use consistent naming for patches and mail subjects. It's described in http://wiki.winehq.org/SubmittingPatches. I'm not sure it makes sense to resend all these, but GERALD: as a start word is unacceptable of course. Indeed, four or so patches with that in the Subject sneaked through. This simply was a mistake on my side last month (and Alexandre was so kind to fix it up). As for prepending what basically seems to be `pwd | xargs basename` (but not exactly), I updated my script to take that into account. Thanks for the advise! Gerald PS: It's somewhat funny that after contributing for elven years, the first time someone complains about my mail subjects is a week or two _after_ I switch over to using git format-patch. ;-)
Re: Minor dlls/comctl32/tests/listview.c simplification
On Thu, 22 Apr 2010, Nikolay Sivov wrote: You can't do this, subclassing is important thing here. And you will see it if you run a test (that you should do before sending patch actually). Thanks, Nikolay. You're perfectly right, that was a silly mistake of mine, no way to put this differently. I've had problems running the tests on my machine I primarily use for Wine work, but now managed to address this (which involved patching mmap.c, but seems to work now). Gerald
Re: Minor dlls/localspl/tests/localmon.c simplificiation
On Sat, 1 May 2010, Nikolay Sivov wrote:
ChangeLog:
Remove variable res which is not really used from test_XcvClosePort.
We should better test for return value than remove it.
This is a primitive thing, try it if you didn't before.
All you need is to add some lines like:
---
ok(res == ERROR_SUCCESS /*a proper code here*/, expected ERROR_SUCCESS, got
%d\n, res);
---
After that run a test on Windows and Wine (using a bot for example) and make
corrections if needed.
Aaactually, now that I was going to look into this, I recall why I didn't
consider this originally: The entire code in that function is inside an
if (0) { }... :-o
But, since you asked for it, I added such tests across the board, made one
simplification, verified that it actually (if enabled) passes properly on
Wine and will submit this in a minute. Then we have things in place when
the FIXME is addressed. Plus a learned a thing or two in the process. ;-)
Thanks for your continous feedbac, Nikolay!
Gerlald
Re: localspl/tests: Improve the tests in test_XcvDataPort_AddPort by properly checking return values and avoiding a duplicat
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=1881 Your paranoid android. === WINEBUILD (build) === Patch failed
