Nvidia users, immediate testing required

[stikkypixie]

Originally posted by KNac:

The deccission to go with OpenGL instead of DirectX wast cause Mac support right? And I think there is not a Mac game incoming? Now, that's a paradox.

There are always more than one reason.

For what it's worth, the two previous nVdia driver releases has considerably improved the fps of my 8600 laptop card. Too bad CMBB still doesn't work though.

[Battlefront.com]

stikkypixie is correct

KNac,

The decission to go with OpenGL instead of DirectX was cause Mac support, right? And I think there is not a Mac version incoming? Now, that's a paradox.

It would be if we said that there was no Mac version coming. Since we've said the opposite, there is no paradox

OpenGL was selected for the same reason many other FPS type games, Quake for example, use OpenGL. It's more flexible and it isn't held hostage to Microsoft. However, it is held hostage to the quality of support from the video cards. This is also true of DirectX, so from our perspective it's a neutral factor. Check out the nVidia driver updates and you'll see that they have plenty of problems with DirectX as well as OpenGL.

So what's the problem with tying ourselves to a Microsoft product? Well, first off that means we can never, ever do a Mac product. That's a bad idea to start with. Second, when Microsoft makes a decision we have to live with it, like it or not. Look at what's happened to DirectX now that Vista is released. Basically they are using DirectX as a way to push people into upgrading to Vista since DirectX 10 won't work on Windows XP. This causes problems for us, development wise, because to support the massive numbers of people who still have XP we have to make sure we work correctly for two different version of DirectX. This has generally proved difficult to do in the past so it's not something we would willingly subject ourselves to.

Remember guys... all this hubris is about one particular card, not our entire installed base. The OpenGL decision was the correct one for us to go with for a number of reasons, and despite the problems with the 8800s we have no regrets about this decision. Eventually we'll figure a way to work around the nVidia bugs or nVidia will fix them. So even this issue will go away. But the other things I mention wouldn't go away if we had instead gone with DirectX.

peleprodigy asked why should he care if a game is OpenGL or DirectX. It's a good question. The answer is obvious... the end user shouldn't care. Unfortunately, the reality is that nVidia and ATI have made this into an issue that the customer notices. We're trying to cover up for their less-than-great OpenGL support, but we haven't been able to do this yet.

Steve

[Dirtweasle]

You have identified the actual cause then of the issue with the way CMSF is working with GeForce cards? If not what are the next steps you are going to take to get closer to finding it?

Have you for instance identified any differences in how your texture coding, drawing or whatnot is different from those whose products are working OK? From what I can tell reading into this just a little there are different ways to skin a cat so to to speak, so I wonder if you've got to the sort of nuts and bolts detail level and figured out what exactly is the problem?

[mazex]

Originally posted by Battlefront.com:

Again, I do not expect you customers to be happy with the performance of CM:SF on your 8800 cards. I do not expect you to stop complaining about it until we get it fixed. What I do expect you to do, however, is cut us some slack and understand the basic facts without being dinks about it. The 8800 is buggy and we're doing our best to work around it. Those are the facts, please don't insult your own intelligence by disputing them.

Steve

Thats a tone I like more than the "It's the drivers fault". Being a bit pissed off like above is fine with me as long as you don't blame the whole problem on the 8800GTX drivers which was the undertone I felt in some earlier posts. Sure, it's damn annoying trying to track down bugs like this but It can be done! The problem is always the least expected and almost always extremeley easy to correct when found. That does not make it a bit less annoying A side note, do not forget blaming M$ as they where the ones that put the axe in OpenGL by crippling the OGL API in Vista...

Good luck! /Mazex

[Battlefront.com]

Dirtweasle,

You have identified the actual cause then of the issue with the way CMSF is working with GeForce cards?

No, though it appears to be the problem nVidia has admitted exists between the GPU, VRAM, and some other factor not working correctly sometimes. By lessening the strain on the card we appear to be able to improve the overall performance. Charles is now getting what appears to be "just about right" performance now, but some of our testers are still suboptimal for sure.

If not what are the next steps you are going to take to get closer to finding it?

By ignoring everything else that needs to get fixed in favor of spending concentrated time on fixing this one issue that affects a fairly small percentage of our customers. Which is why we haven't done that until now. Remember, if Charles spends 8 hours in a row trying to figure out what is going wrong with some nVidia users, that means a half dozen game fixes that can't be made available for everybody.

Have you for instance identified any differences in how your texture coding, drawing or whatnot is different from those whose products are working OK?

There is no way to tell this without looking at their source code for a couple of months. This is really low level stuff and it is probably not an obvious difference.

From what I can tell reading into this just a little there are different ways to skin a cat so to to speak, so I wonder if you've got to the sort of nuts and bolts detail level and figured out what exactly is the problem?

You are correct that it does boil down to Charles doing something in a way that other games aren't. The problem is it could be any one of a thousand things. It could also be a unique combination of things. Tons of possibilities, unfortunately. That's why things like this are so difficult to track down. Check out my example of the ATI problem we discovered yesterday (previous page).

The API call Charles made was perfectly legit and worked fine on nVidia. However, it didn't work as advertised on ATI cards because ATI in reality doesn't support that call. They can say they do, but since it isn't practical to use they effectively don't. So how did Charles figure this out? A couple of hours spent looking over a specific section of new code. Since the problem didn't exist before he wrote it, it was easy to focus on that one section and not on the thousands of lines of code built up over 3 years of development. Even then it took hours to figure it out. He disabled that call and swapped in something less efficient (VRAM wise) and bingo... worked fine again.

Trying to figure out, blindly, why some nVidia cards have problems is a whole different kettle of fish. It's burried in the code somewhere, it has inconsistent results from system to system, and isn't apparently tied to any particular manipulatable variable from the end user (card settings, scenario features, etc.).

In short... the type of problem we have with some nVidia cards is the worst scenario for us. Which is why it hasn't been fixed yet.

Steve

[Dirtweasle]

...nevemind

[Battlefront.com]

mazex,

Thats a tone I like more than the "It's the drivers fault".

It's the tone we've had the entire time. It is the driver's fault, but we have to deal with it and figure a way around it. We understand that. However, some people have been saying that we shouldn't be blaming nVidia at all. Screw that... call a spade a spade. Their product is buggy and we are left to try and figure out a way around their mess. If they did their job to correctly support the API we're using, we'd not be having this discussion.

A side note, do not forget blaming M$ as they where the ones that put the axe in OpenGL by crippling the OGL API in Vista...

If there is an open API, Microsoft is sure to find some way to screw it up. They probably have an entire department working on it. The engineers who work in that department likely have titles such as "Lead Monkeywrench" and "Manager of Sabotage". Makes me not at all surprised that the European Union this week put the smackdown on MS yet again.

Steve

[mazex]

Originally posted by Battlefront.com:

Oh, and Mazex posting a pictures of a DirectX game is rather lame. Might as well show a picture of a game on X-Box or Wii for all that it matters. Or how about I show a picture of what CM:SF looks like on my system compared to World in Conflict? So let's stop with the childish and utterly pointless posts like that, OK? It won't make us work any harder to find a solution, but it does make us think VERY poorly of the customer intelligence.

Steve

Well, I posted an image from WiC as I have a close relationship with the development team I know it's Dx but it's kind of an interesting comparison as the units used are very similar even though the games are very different in style... Have tried to convince the CEO that a serious turn based version of WiC would be interesting but it's hard to get funding for that as you know...

Here's one from an OGL game from my rig taken a few minutes ago if you like that better. An interesting side note is that ET:QW has been "capped" at 30fps. Never goes above it at any settings and almost never drops below it at any settings on the 8800GTX. When the whole world explodes around you it dips to 25-26 at max/max setting.

Enemy Territory : Quake Wars OpenGL 1280x1024 ALL settings max (16x aniso, 16x AA)

It's rather refreshing to be called unintelligent. Don't remember the last time actually

/Mazex

[Dirtweasle]

Thanks Steve, that is making sense to me written that way.

Did you happen to see the results of the OpenGL testing I did on my card? It's in a different thread. Reason I ask is when you wrote;

The API call Charles made was perfectly legit and worked fine on nVidia. However, it didn't work as advertised on ATI cards because ATI in reality doesn't support that call. They can say they do, but since it isn't practical to use they effectively don't. So how did Charles figure this out? A couple of hours spent looking over a specific section of new code. Since the problem didn't exist before he wrote it, it was easy to focus on that one section and not on the thousands of lines of code built up over 3 years of development. Even then it took hours to figure it out. He disabled that call and swapped in something less efficient (VRAM wise) and bingo... worked fine again.

It reminded me of something I found that to me seemed like a potential area to look. If you already looked at those test results and it's not anything to worry about that's fine. It was something to the effect of the call was not supported in the version of OpenGL but in version 2.1 or some such thing it was. If you think it potentially interesting I'll find it and paste it here for you.

[Battlefront.com]

To show that I have a little sympathy for the card driver programmers...

Remember that a computer system is just that... a system. The more complex it is, the more likey things won't work right. The more that happens the greater the chance that you, as an individual, might do the right thing but have it go wrong due to someone else's problem. And if someone needs to use your stuff, then that person is affected by the problems further on down the foodchain.

The inherent problem with Windows based systems is that the hardware is extremely variable. This makes Windows less reliable than it otherwise could be. It makes EVERYTHING less reliable than it otherwise could be. How do I know that? Look at the Macintosh's nearly 20 year history. Less choice for the consumer is not necessarily a bad thing because it does allow for tighter engineering and greater accountability. This is largely acheived by one entity designing and manufacturing the hardware as well as the software. It's not perfectly executed, but it is vastly more predictable and likely to be fixed if there is a problem. "Wintel" is the exact opposite, which means problems are the norm instead of the exception.

So it could be that the nVidia engineers did everything they should have, but some company made a component for a particular motherboard that doesn't work within required specs. Therefore nVidia's card doesn't work right and neither does our game.

We, Battlefront, have just as much right to demand that nVidia fix this problem instead of passing the buck back to us. We developed for their product and it is failing us. Big difference is that you, the end consumer, bought their product and not us. You have your choice of complaining about Combat Mission or nVidia. The real problem is nVidia, but you choose to complain to us because we (ironically) are more likely to improve things for you the end user. Contemplate the deepering meaning of that a bit

Steve

[Battlefront.com]

Mazex,

Well, I posted an image from WiC as I have a close relationship with the development team I know it's Dx but it's kind of an interesting comparison as the units used are very similar even though the games are very different in style... Have tried to convince the CEO that a serious turn based version of WiC would be interesting but it's hard to get funding for that as you know...

Yeah... good luck with that

Here's one from an OGL game from my rig taken a few minutes ago if you like that better. An interesting side note is that ET:QW has been "capped" at 30fps. Never goes above it at any settings and almost never drops below it at any settings on the 8800GTX. When the whole world explodes around you it dips to 25-26 at max/max setting.

As stated before, when Quake has a problem with a card the card gets fixed. Carmack probably has the lead engineers at nVidia and ATI on speed dial. I'm not kidding either. Look at the new drivers that came out specifically for QuakeWars. This means that before them QuakeWars didn't run correctly. Our problem is we don't have that sort of clout. We also don't have as many tricks to pull as a FPS does because our games are open ended to user designs. We could do so much more with framerate if we could cap the number of polygons, map size, number of units, etc. to a level that we felt worked best for framerate instead of the game itself.

BTW, capping the framerate is a good thing for a game like this. It makes for smoother gameplay when the game can otherwise go from light to heavy strain within a nano-second. That's because the system doesn't have to worry about speeding up and slowing down stuff.

It's rather refreshing to be called unintelligent. Don't remember the last time actually

Well, if you don't make another post like the one I responded to you won't see a repeat from me

Steve

[Battlefront.com]

Dirtweasle,

It reminded me of something I found that to me seemed like a potential area to look. If you already looked at those test results and it's not anything to worry about that's fine. It was something to the effect of the call was not supported in the version of OpenGL but in version 2.1 or some such thing it was. If you think it potentially interesting I'll find it and paste it here for you.

Yeah, I seem to remember that post of yours. If you can find it great, otherwise it probably isn't of practical use. The reason is that if Charles was using a call that wasn't supported in hardwaremode, like the ATI issue, then *all* nVidia users would be getting the problem. Or at least all 8800 nVidia users. And the effect should be about the same for all. Since we don't have that sort of consistency, it is unlikely that the thing you found is relevant.

Steve

[Dirtweasle]

Too many threads with similar topics, and the search button is not helping... I'll try later from home.

[Battlefront.com]

Like I said, I wouldn't go through much trouble on this. Logic indicates that whatever that call is we aren't using it, otherwise all nVidia people would be hosed and not just some and not to varying degrees.

Cheers,

Steve

[Kawabonga]

To all,remember that the low fps is not the only GF 8xxx problem !. On my GF 7600 are also low FPS !! .

[Dirtweasle]

Do you, or does CMSF rather expect some version of OPgenGL to already be installed or does it install it;s own like some games do for directx?

What I'm wondering is if when I've got the wrong version loaded.

[wolf66]

Steve, is that a rather polite and eloquent way of saying 1.04 will fix nothing for the 8800 ....??

[Cpl Steiner]

Steve,

Do you recall telling AMD users to install the AMD Optimizer in order to get Theatre of War to work? Do you also recall telling those same AMD users to remove the AMD Optimizer from their systems to get CM:SF to work? So now users such as myself, who own both games, are expected to install the optimizer whenever we want to play TOW and then uninstall it every time we want to play CM:SF. That is supposed to be a sensible approach to customer support is it? That insults my intelligence.

[Dirtweasle]

Steve here are the OpenGL test results I though may be of some interest;

GL_EXT_copy_texture was not found, but has the entry point glCopyTexSubImage3DEXT

GL_EXT_subtexture was not found, but has the entry point glTexSubImage3DEXT

GL_NV_half_float has the entry point glVertexWeighthNV missing!

GL_NV_half_float has the entry point glVertexWeighthvNV missing!

WGL_NV_vertex_array_range was not found, but has the entry point wglAllocateMemoryNV

WGL_NV_vertex_array_range was not found, but has the entry point wglFreeMemoryNV

GL_HP_occlusion_test was not found, but is available in driver version 2.1.0

GL_NV_framebuffer_multisample_ex was not found, but is available in driver version 2.1.0

GL_NV_texture_compression_latc was not found, but is available in driver version 2.1.0

GL_OES_conditional_query was not found, but is available in driver version 2.1.0

[Battlefront.com]

Kawabunga,

To all,remember that the low fps is not the only GF 8xxx problem !. On my GF 7600 are also low FPS !! .

Correct. The 8xxx appears to have been a progression of the 76xx card technology, so there seems to be the same issue of some OK and some not OK. We have a tester with a 7600 who has problems with framerates, so we've got that covered too.

Dirtweasle,

Do you, or does CMSF rather expect some version of OPgenGL to already be installed or does it install it;s own like some games do for directx?

What I'm wondering is if when I've got the wrong version loaded.

Yes, like any API there are different versions. Some are more backwards compatible than others. DirectX has traditionally had difficulty with backwards compatibility, but OpenGL is quite good. IIRC CM:SF is looking for OpenGL 2.0, but will work with OpenGL 1.0.

Thanks for finding that list. Again, I don't think it will mean much, but one never knows.

Wolf66,

Steve, is that a rather polite and eloquent way of saying 1.04 will fix nothing for the 8800 ....??

Not at all. I said we haven't found the problem and therefore haven't come up with a solution. However, everybody should see a speed improvement from v1.04, even the people worst affected by whatever this problem is. It's just that if you're getting 10fps now you might get 15fps with v1.04. Substantial improvement, but if you should be getting 35fps+ for that particular scenario then 15fps is obviously not enough.

Cpl Steiner,

Do you recall telling AMD users to install the AMD Optimizer in order to get Theatre of War to work? Do you also recall telling those same AMD users to remove the AMD Optimizer from their systems to get CM:SF to work? So now users such as myself, who own both games, are expected to install the optimizer whenever we want to play TOW and then uninstall it every time we want to play CM:SF. That is supposed to be a sensible approach to customer support is it? That insults my intelligence.

Two different games, two different requirements having to do with a completely different issue (single vs multi-processors). So what's your point?

BTW, CM:SF v1.04 should be plenty happy with AMD with or without the Optimizer.

Steve

[LeBlaque]

If not what are the next steps you are going to take to get closer to finding it?

By ignoring everything else that needs to get fixed in favor of spending concentrated time on fixing this one issue that affects a fairly small percentage of our customers. Which is why we haven't done that until now. Remember, if Charles spends 8 hours in a row trying to figure out what is going wrong with some nVidia users, that means a half dozen game fixes that can't be made available for everybody.

This comment is extremely disconcerting to me. I'll be frank, I do NOT own an Nvidia card and thus cannot really sympathize. However, I wonder why this excessive amount of "patch time" is being spent on a small percentage of the user base? It was stated in a recent thread by BF that it would not be productive (at the present time) to port and focus on the "5% of the customer base that uses the Mac OS." Then why, for pete's sake, are we focusing so much effort on circumventing a bug created by the hardware/software of one Nvidia card series that doesn't even occur on every platform? Given the outstanding patch issues noted throughout these boards, is this not a misappropriation of valuable time, particularly given the MacOS comments?

I recently re-installed Silent Hunter III and noted in the beginning of their manual that the 'software protection may not work on some DVD/CD drives' and it was left at that. Glad I didn't own one of those drives! Yes, BF did not provide such warning for the 8800 as they were unable to identify this issue (that is really not theirs). But if other companies can so readily abandon perhaps a larger customer base because of faulty drives, why can't BF re-focus efforts on the bulk of the community as opposed to chasing something that may never be fully resolved until Nvidia solves their problem??

Flame away...

Regards,

LeBlaque

[CommC]

Its not just one card or just nVidea. I have an ATI x1950 pro 256 exhibiting almost the exact behavior as the 8800 cards: low framerates, 9-10 fps at the beginning of Allah's Fist and others.

It looks a lot like a bug, because as soon as the camera dips below the horizon, framerates jump up to 30 to 40 fps.

[Battlefront.com]

LeBlaque,

However, I wonder why this excessive amount of "patch time" is being spent on a small percentage of the user base?

Well, it's the reason why we haven't done more than poke at the problem until now. There have been much bigger fish to fry, so to speak. But the problem hasn't gone away despite two new driver releases, nor have we been able to figure out any other sort of work around. The 8800 card is becoming one of the standards (it isn't yet) as the price comes down and the older cards are dropped. So whatever problems we have with it now are only going to get worse, not better.

Then why, for pete's sake, are we focusing so much effort on circumventing a bug created by the hardware/software of one Nvidia card series that doesn't even occur on every platform?

Because it is a larger problem than you are giving it credit for being. As much as we hate having to be distracted by this, and much the opposite of the few that claim we're trying to "pass the buck", we have to at least spend the time to see if there is something we can work around or not. Up until now we have been too distracted by larger issues to really dig into it. As I've said, we've tried some things and didn't get any results so we had to move onto other things. Now we have to just dig in and see what we can see, then make some sort of pronouncement about what can or can't be done.

CommC,

Its not just one card or just nVidea. I have an ATI x1950 pro 256 exhibiting almost the exact behavior as the 8800 cards: low framerates, 9-10 fps at the beginning of Allah's Fist and others.

Hmmm... fist I think I've heard of this. The ATI x1950 256, however, isn't comperable to the 8800. It's more like the 79xx, but a bit slower (I just checked some reviews), which was the lower end card of nVidia's previous generation of cards. Depending on what you have for a system 9-10fps for Allah's Fist (a stress test) might be what you should be getting in v1.03. However, it should be MUCH higher in v1.04.

Steve

[Knaust1]

I'm going to make up my mind to buy a new computer, on which CMSF will run fast and furious.

What combination of processor and graphic card do you advise me to get?

[peleprodigy]

I would wait, because you can build the fastest, most up-to-date rig imaginable, and still get terrible performance in combat mission.