Introduction
Sinds it seems to be a curse tradition to have somebody asking for DirectX 10/11 renderers atleast every 2 months did I decide to put these renderers to the test to see if these "futuristic" renderers (and I put that in quotes because DX12 is already around the corner) really make a difference in our over 15 year-old game. And sinds I'm benchmarking anyway might I aswell test the other ones while I'm at it.

Smirftsch was so nice to send me a copy of 227J_20 with a (clearly) unfinished version of DirectX 10. So if you also want to enjoy the awesome graphics of the future then you have to ask him. although, at the moment, you won't miss out on much, believe me :

Fog rendering doesn't work correct in DX10. Especially in combination with semi-transparency.

Benchmark setup
For benchmarking I decided to make two maps on top of the one that came with the 227J_20 package. The first one mainly test simple geometry with tons of standard fog while the second one focuses on excessive amounts of particles (although I'm not sure if these differ much from meshes sinds that is pretty much what they are). The one that came with the patch mainly tests on meshes and is by far the most demanding because of this.

All tests are done using the default configuration for each rendered except with any Vsync and framerate limit disabled. I also disabled Anti-aliasing where necessary and set anisotropic filtering to 16 when possible (only D3D didn't have this option which didn't matter as you will see) and I enabled DetailTextures on every renderer. Other settings like FOV and Brightness where left untouched. Shadows where set to Blob and all systems ran the game at a resolution of 1920x1080.

I wrote down the average and lowest FPS. I ignored the maximum FPS because that would be like saying you can run Crysis 3 smoothly at max settings but only when you are looking at the ground .

Tested hardware
These are the systems I ran the benchmarks on:

My rusty old laptop:
OS: Windows XP Professional
CPU: Intel Mobile Core Duo T2300E
RAM: 2,5GB
GPU: Nvidia Geforce Go 7400 256MB

My school laptop:
OS: Windows 7 x64 Professional
CPU: Intel i5-3230m @ ~3Ghz
RAM: DDR3L 8GB
GPU: Nvidia Geforce GT740m 2GB

My trusty (but dated) game Pc:
OS: Windows 7 x64 Home Premium
CPU: Intel i5-2500k @ 3.3Ghz
RAM: DDR3 8GB
GPU: Asus Radeon HD 6870 1GB

My dad's Pc:
OS: Windows 7 x64 Home Premium
CPU: Intel Xeon E3-1230V2
RAM: DDR3 8GB
GPU MSI Twin Frozr GTX660 3GB

The benchmarks
Alright then, lets get started :

Benchmark-sewers.unr (Fog benchmark):

you might notice how the Go 7400 has 0 fps on D3D10. This is simply because that thing doesn't support D3D10. As for the score: Pretty much every decently modern card likes D3D9 the most with OpenGL as a nice alternative option. Interestingy does the 6870 have lower minimun FPS than the weaker GT 740m although this one seems to hate D3D8 quite alot. The Go 7400 is already struggling with getting an average of 60 so that is a good start. But if you look at the chart you will see that this old piece of hardware favors D3D8 over D3D9 even though D3D9 is fully supported. D3D is pretty much useless to benchmark though. I refuses to go above 60fps even with vsync and framerate limiters disabled. Even turning Vsync off using Nvidia Control Panel yields no result. This problem occurs on every chart so just ignore it unless I tell you otherwise . D3D10 doesn't perform bad but there is no reason to use it above D3D9.

Next: particles.

Benchmark-particles.unr (particle benchmark):

And again, D3D10 doesn't quite live up to the hype. It's also good to notice how the 6870 and GTX 660 don't differ that much from each other. It seems that there is another bottleneck at work here. The Go 7400 has trouble choosing between OpenGL and D3D8 while D3D9 is lagging behind again. The 740M and D3D8 are still having problems in their relationship and D3D still doesn't cooperate.

Now lets mesh this up .

Benchmark.unr (meshes benchmark):

Alright then, It seems OpenGL gets some time to shine . Although only on system with Nvidia hardware . The Go 7400 is still not sure if it will be OpenGL or D3D8 but it doesn't seem alone anymore in this matter as its younger Nvidia brothers (or sisters?) join in this dilemma aswell. The 6870 still likes his D3D9 too much to let it get beaten by any of the other renderers but D3D8 does make a desperate attempt in the minimum FPS department but to no succes. D3D10 still does what it does best: chilling in the middle between D3D9 and D3D8. This is also then only chart where D3D never reached above the 60 FPS (on the Go 7400 ofcourse) so it gives a nice idea how it performs. Which it does pretty badly.

Conclusion
Just use D3D9. Can I go home now?

Ok, to be fair: The D3D10 rendered is not finished so its performance might increase (or decrease ) but when it gets down to it, it really doesn't matter. If your hardware is so old it needs more FPS then newer renderers won't help you and it might be better to just use older ones. Modern Pc's with decent hardware should have no problem running the game with the GTX 660 even reaching over 600 FPS on average on a fog filled map using D3D9. Unless Windows 10 drops support for DirectX 9 is there really no point in rushing a new rendered out the door.

It's also good to point out there was another renderer called XopenGL in 227J_20. But I decided to ignore it sinds it is supposed to be in an even LESS finished state than D3D10.

Other stuff
Most renderers look pretty similair but D3D seems to have issues with rendering TrailEmitters on every one of my tested pc's except the one with the Go 7400.


Ofcourse does D3D also has no support for fog on meshes. But that is something already known.

Another thing to notice is that the game seems to speed-up when the FPS goes above something around 150-200. Which causes issues with music playback aswell.


If there are any ideas on how I can improve my benchmarks then please tell me. I also have the idea there are more settings that need to be changed to create a completely fair battlefield.

To Smirftsch: I got it to work by using the DX webinstaller. I think the pc was missing the DirectX SDK files which could explain the error on compiling the FX.

From the look of it, smirftsch, you either took the time to make a benchmark or found someone to make one for you. I'm glad of that, I hope you're not too agnry/dissapointed I gave up.

Well, DX9 should be capable of doing bumpmapping but I haven't seen anything about that either. So don't get you hopes up for DX10. Although there exist tools like ENBseries that hooks themselfs to the DirectX renderer and allows new effects to be added to games. I believe there is some version out there that works with Unreal but only bloom and color correction are working at the moment. Still looks pretty neat in combination with a High-res texture packs.

The thing I want the most (that I think is reachable) is better support for meshes. If these would run a little better I would have already made a bunch of jungle-ish maps with tons of vegetation all over the place. Performance really holds back the potential of static-meshes.

Didn't know you where actually looking for people making benchmark maps though. I just did this out of curiosity for the most part . The map Smirftsch send me is really nothing special though. Just the Unreal flyby modified by someone who loves vegetation a little too much (although I would love to know where these meshes come from sinds they look really nice). But it does do the job very well so I'm not complaining for one bit.

And forgot to add a download link to the used benchmark maps so here it is (doesn't include the one that came with the 227J patch sinds I'm not sure if Smirftsch is ok with me uploading that): https://www.dropbox.com/s/6l1bpjdaw8cj4ps/Benchmark%20Maps.7z?dl=0

Doc, its: SmirftSch

The problem with Bumpmapping is, that it relies on lighting. For DX10 Kentie used some sort of hack to make it work although Unreal doesn't provide this information (at least not yet in older versions) and doesn't use hardware lights either- which I find a very cool idea how he did it btw. But that's mostly the reason it was never implemented before although already in 224 it was obviously planned.

Victor Delacroix wrote on Oct 15^th, 2014 at 6:37pm:

Pfft.

Dr.Flay™ wrote on Oct 17^th, 2014 at 3:46am:

Good one - I like that, very funny!

Quote:

that made my day!!  *ROFL* very good one

Skywolf wrote on Oct 9^th, 2014 at 2:35pm:

In D3DDrv UseVSync option is broken, need set to true for disable vsync.