City of Villains (Beta) Tests

Update: We would like to clarify that the beta version of City of Villains was stated as non-optimized in the release notes. The test server is open to any CoV subscriber and it does support PhysX hardware, but it is very possible for performance improvements to be made to the implimentation before their production release of the Issue 7 patch. In fact, we have been told by AGEIA that performance on the final code will absolutely be better than on the test server. We look forward to testing and reporting on PhysX support under production CoV code/servers as soon as possible.

As with any MMOG, City of Villains has been difficult to test. The fact that PhysX hardware is only supported in a very specific area of gameplay makes it even more complicated. Luckily, we found a way around these issues. As City of Villains makes use of instanced areas for missions (multiple parties entering a single zone will each play the game in their own copy of that area), we were able to eliminate any outside influence from other players and go on a mission solo. Also key in our ability to test the Mayhem Missions (the part of City of Villains in which the PhysX hardware is used) is the fact that it is currently on the test server.

Normally, before a gamer gets a Mayhem Mission, he or she will have to do a bunch of other missions, level up a bunch of times, and unlock a contact called a "broker." The broker gives you access to "newspaper missions." After doing 3 of the newspaper missions, a broker will offer you a special job: a heist. In the future, and on the test server, this is where mayhem missions will be available. Each mayhem mission, once begun, has a 15 minute time limit. This limit can be extended by destroying things in the city, but there is no way to get enough time to actually benchmark multiple configurations of hardware. Doing 3 other newspaper missions and getting another mayhem mission isn't an option because this takes a huge amount of time (the missions can be different every time as well).

Fortunately, NCSoft offers the ability to copy your character to the test server at any time, multiple times. Our solution was to do enough missions to get to a point where we could be offered a mayhem mission (even though the missions are currently only on the test server). Then we copy our character over to the test server a bunch of times. Now we are able to accept the same mission any time we want.

This is great for testing a feature like PhysX, but doing a full test of the game is still hard. Working with a team fighting a huge number of enemies is a key element in the game. It's something that just can't be reliably repeated barring the assembly of an AnandTech guild built solely for choreographing, reenacting, and benchmarking scenes hundreds of times. For now, this is all we need. We included a screenshot of the game options with and without a PhysX card installed:




We created a couple videos to show the difference between hardware accelerated and software physics. Here are the numbers that resulted from our tests.

City of Villains

City of Villains

What we see clearly shows that the PhysX card is putting quite a strain on performance. Yes we get more mail or packing peanuts spewing forth from our rampant destruction. Yes, we do think it looks great with more stuff going on. But we are really not happy with the performance we are seeing here. It appears that our GPU is not overly loaded at these resolutions, as the difference between 800x600 and 1600x1200 gives very little in the way of performance gain without PhysX hardware installed. This implies that the bottleneck in performance is in the rest of the system. This is confirmed by the fact that performance drops considerably when running the test on a much slower CPU.

Whether on a low resolution with a fast CPU or a high resolution with a slow CPU, the PhysX hardware gives us low average framerates, very low minimum instantaneous framerates, and adds a bit of stutter to the movement of the game. Unlike the Ghost Recon test we showed last week, playing the game with the PhysX card feels much less satisfying. Multiple frames seem to take a long time to render (rather than just one or two) giving movement a choppy feel to it.

That being said, it is very important that we point out the fact that we are benchmarking code running on a test server. NCSoft makes it clear that code running on this server is not optimized and players may see degraded performance. We hope very sincerely that the performance issues will be resolved; right now it just isn't worth it.

So why include these numbers at all if it's on a test server? Well, the fact that they back up the results we saw in GRAW last week do lend some credibility the tests. What we seem to be seeing is that games which use the PhysX processor to tack on special effects physics take a performance hit when those effects are triggered. Of course, that only holds if the driver didn't fix the performance issues we saw in Ghost Recon.

Benchmarking Physics Ghost Recon Advanced Warfighter Tests
Comments Locked

67 Comments

View All Comments

  • AndreasM - Wednesday, May 17, 2006 - link

    In http://www.xtremesystems.org/forums/showthread.php...">some cases the PPU does increase performance. The next version of Ageia's SDK (ETA July) is supposed to support all physics effects in software, ATM liquid and cloth effects are hardware only; which is why some games like Cellfactor can't really run in software mode properly (yet). Hopefully Immersion releases a new version of their demo with official software support after Ageia releases their 2.4 SDK.
  • UberL33tJarad - Wednesday, May 17, 2006 - link

    How come there's never a direct comparison between CPU and PPU using the same physics? Making the PPU do 3x the work and not losing 3x performance doesn't seem so bad. It puts the card in a bad light because 90% of the people who will read this article will skip the text and go straight for the graphs. I know it can't be done in GRAW without different sets of physics (Havok for everything then Ageia for explosions) why not use the same Max Physics Debris Count?
  • Genx87 - Wednesday, May 17, 2006 - link

    I am still in contention it is a GPU limitation of having to render the higher amount of objects.

    One way to test this is to setup identical systems but one with SLI and the other with a single GPU.

    1. Test the difference between the two systems without physics applied so we get an idea of how much the game scales.
    2. Then test using identical setups using hardware physics and note if we see any difference. My theory is the amount of objects that need to be rendered is killing the GPU's.

    There is definately a bottleneck and it would be agreat if an article really tried to get to the bottom of it. Is it CPU, PPU or GPU? It doesnt appear that CPU is "that" big an issue as the difference between the FX57 and Opty 144 isnt that big.

  • UberL33tJarad - Wednesday, May 17, 2006 - link

    Well that's why I would be very intersted if some benchmarks could come out of http://pp.kpnet.fi/andreasm/physx/">this demo. The low res and lack of effects and textures makes it a great example to test CPUvsPPU strain. One guy said he went from http://www.xtremesystems.org/forums/showpost.php?p..."><5fps to 20fps, which is phenomenal.

    You can run the test in software or hardware mode and has 3k objects interacting with each other.

    Also, if you want to REALLY strain a system, try http://www.novodex.com/rocket/NovodexRocket_V1_1.e...">this demo. Some guy on XS tried a 3ghz Conroe and got <3fps.
  • DigitalFreak - Wednesday, May 17, 2006 - link

    Good idea.
  • maevinj - Wednesday, May 17, 2006 - link

    "then it is defeating its won purpose"
    should be one

  • JarredWalton - Wednesday, May 17, 2006 - link

    Actually, I think it was supposed to be "own", but I reworded it anyway. Thanks.
  • Nighteye2 - Wednesday, May 17, 2006 - link

    2 things:

    I'd like to see a comparison done with equal level of physics, even if it's the low level of physics. Such a comparison could be informative about the bottlenecks. In CoV you can set the number of particles - do tests at 200 and 400 without the physx card, and tests at 400, 800 and 1500 with the physx card. Show how the physics scale with and without the physx card.

    Secondly, do those slowdowns also occur in Cellfactor and UT2007 when objects are created? It seems to me like the slowdown is caused by suddenly having to route part of the data over the PPU, instead of using the PPU for object locations all the time.
  • DerekWilson - Wednesday, May 17, 2006 - link

    The real issue here is that the type of debris is different. Lowering number on the physx cards still gives me things like packing peanuts, while software never does.

    It is still an apples to oranges comparison. But I will play around with this.
  • darkdemyze - Wednesday, May 17, 2006 - link

    Seems there is a lot of "theory" and "ideal advantages" surrounding this card.

    Just as the chicken-egg comparison states, it's going to be a tough battle for AGEIA to get this new product going with lack of support from developers. I seriuosly doubt many people, even the ones who have the money, will want a product they don't get anything out of besides a few extra boxes flying through the air or a couple of extra grenade shards coming out of the explosion when there is such a decrament in performance.

    At any rate, seems like just one more hardware component to buy for gamers. Meh.

Log in

Don't have an account? Sign up now