DescentBB

Ask and ye shall recieve. Well, I did run the same tests back-to-back, and I found out some pretty interesting results!

Reference system is an MSI KN-266 board running a Duron 1.3Ghz, 512MB of SDRAM, an MSI GeForce4 MX440 32MB vid card running in dualview at 1280x1024 on each screen. Windows is XP Pro with SP2, Linux is SuSE 9.1 (default 2.6 kernel) with KDE and nVidia drivers.

I couldn't get AA or AF to work in Linux, but no sweat. On a GF4 MX440 it's obviously slow as... molasses, as my first run proves.
All Windows runs were done with every conceivable unneeded service stopped, including all networking. I ran tests in DirectX and OpenGL, and DX performance was about HALF of what the OpenGL renderer could do with my drivers. They aren't the newest, but come on, neither is the game or the video card.

Linux runs were in KDE, with no particular attention to stopping anything. Even had several desktop widgets running. Swapfile usage in Linux was, as usual, 0% the whole time.

All graphics settings in-game were set to "highest" and I didn't use "-nosparkles -nomotionblur" because Durons don't support SSE2 anyway. The only practical thing I could have used in Windows and not Linux was bump mapping, which actually improves the looks a little bit (especially with water ripples) but has no impact on performance that I could tell (I tested both ways).

======== 1280x960===========

Windows, 1280x960, no AA or AF, using OpenGL render:
84.74 Descent3 v1.4
43 Min
132 Max
42 sec.

Linux, 1280x960, no AA or AF, OpenGL (of course):
88.78 Descent3 v1.4
41 Min
117 Max
40 sec.

Windows, 1280x960 WITH AA and AF, using OpenGL:
26.25 Descent3 v1.4
12 Min
31 Max
137 sec.

This was the "lets see if we can get my PC to crash" run. Looks decent, until I turned on Antialiasing, when my GF4 took a dump.
You can tell it's actually a warmed-over GF2 here. Only 32MB of textures didn't help. Each frame is 4.8MB at 32-bit, and you can see the GPU is the limiting factor once you see the rest of the resuls.

======== 1024x768===========

Windows:
89.24 Descent3 v1.4
36 Min
170 Max
40 sec.

Linux:
135.96 Descent3 v1.4
52 Min
191 Max
26 sec.

Here we see Linux starting to pull away from Windows, even though the mins and maxes aren't that far apart.
More than anything, I'd say the Linux run was less "bouncy" as is shown by the (much) higher average framerate and shorter runtime.

======== 640x480===========

Windows:
90.35 Descent3 v1.4
53 Min
170 Max
39 sec.


Linux:
151.16 Descent3 v1.4
103 Min
252 Max
23 sec.

Here's where we separate the men from the boys. About twice the framerate all around in Linux. 'Nuff said. Just to see what it would do in Windows, I dropped all the detail settings to "low" and set pretty much everything else I could find to "low" or "sucky" and even dropped desktop textures to 16-bit. The fastest FPS I got out of Windows, period, was 191, right on par with Linux at 2.5 times the screen real estate, plus maxed out detail settings and 24-bit color.

I hope you guys found this interesting. Was there some setting that I missed? The Linux version doesn't have all the -lowmem switches and stuff, I'm thinking that both version's defaults should be the same, though. If anyone knows differently, I'd love to hear about it.

All your Windows scores are nearly identical. Is anything capping the framerate?

Not that I'm aware of. Vsync is off, but I may test it again later tonight and see what I can uncover. I have no idea what else could cap the framerate (other than vsync and "-framecap x")

Yeah, there is definitely something up if windows didn't scale with the resolution, I've never seen a result like that without something seriously limiting the CPU, except for the obvious GPU limited one, all the windows tests were right around 40 seconds. It's not vsync because it is unlikely his refresh rate is as high as 170 at 1024x768, and it would show a constant 60 FPS at 640x480.

Also, D3 in windows flat out does not support 32bit color in OpenGL, it always runs in 16 bit color (32bit DOES work in DX, might be the cause of the performance loss in DX). Linux might be different, but judgeing from the framerates at 1280x960 I would tend to think it is the same.

Are you using -framecap 0 or -framecap 999 in windows?

I used -framecap 0 but I will have to test this again... once I reboot (again). Now I'm curious.

*EDIT*

I ran them all again in Windows, with the same params but with "-nosound". With sound, I get 170 max, without sound, I get:
198.47 Descent3 v1.4
131 Min
283 Max

So it's not framecapped as far as I can tell. Sucky drivers, possibly, but not framecapped. I'm going to upgrade my Windows nVidia drivers and see what happens.

Upgrading the video drivers in Windows didn't make a lick of difference, which is what I suspected. However, I noticed that with -nosound enabled in both OSs, FPS were close to each other all around. Kinda makes you wonder... trying it with -framecap 999 and -framecap 0 didn't make any difference on my system, in either OS.

So until I can get updated sound drivers, I'm sticking with my scores

Is windows using any kind of fancy 3D sound or EAX? Look in the launcher setup window and make sure it is only using directsound.

Also in windows, use dxdiag to turn the directsound acceleration down one notch from full.

Okay, I finally figured out how to enable Antialiasing in Linux.
(You have to open a terminal and type "export __GL_FSAA_MODE=x" where x is the mode of AA you want. When the terminal closes, you lose the environment)

I'll run some more tests tonight, and see how it stacks up.