I think it's really lame of a company to pull this crap. I play games for the sport and compition of it. Where's the fun if some no skill having noob is running around, able to anticipate your every move because he can see through solid objects. It's every real gamers responsibility to click on that link and sign that petition. Im going there now!

This comment was edited on Jul 13, 05:12.

Some savvy open source developers could release some server code for integration into games that tests client drivers for this feature (by whatever feasible methods) and disallows connections from clients using drivers that support it. If each developer makes this part of the official server code base then it would shut out anyone who wanted to cheat (could even be an option). People possessing these drivers would then have to disable the feature (if possible) or realise that they'll need to write their own servers if they want to cheat amongst themselves.

Seems like this would be the best route on a per game basis and would send a signal to companies that this type of driver is not acceptable for gaming, though clearly it might have uses in development.

Keep in mind that asus has actually pulled this stunt TWICE. The first time they did it they got a huge outcry a few years back, then they it it again more recently and held the poll on thier own website, and AGAIN got a big outcry. Now ECS is doing it. Unfortunately, I'm willing to bet that they will NOT do anything about it. ECS has the cheapest crappiest motherboards around and if they think people will purchase graphics cards from them to see through walls in counter strike, thye will probably leave it up.

FORTUNATELY this is not an nvidia card and isn't as much of a disaster that the previous Asus releases were.

I write 3D drivers, and once I had a bug that let me 'see through walls' in some games. The bug left alpha blending on. So everything turned into a sorta ghostly visage, another time it happened was when the Z test function was set incorrectly. Another way to see through walls would be to draw everything as wireframe. But that's an extreme I'd think.
I'll admit, I did try to exploit.. er test.. the bug in a few games of CS... but it didn't help. I sucked anyway, and it gave me a sense of false security which hurt my game even more.
No worries, I fixed the bugs. These drivers were never released, nor do I play CS anymore.

Wow, there's a shocker!

Someone said that "Q1 has zero overdraw" compared to CS. The fact is that CS is based on Q1 engine and uses the same method (pre-calculated PVS) to determine which areas of the level (and objects within) are visible to the player. So if you run GLQuake vs CS they're going to act pretty much the same. Software rendering in both games does use a different occlusion method, but it can't be done effectively on hardware or at high resolution, and only applies to world geometry anyway. (When drawing front to back, Z-buffer actually reduces true overdraw to zero and is quite fast.. That's why it's there)

Also, an idea was tossed around that the server should check if another character is visible to the player before sending the data to the client. This is good in theory, and is done to certain extent in these games already. However, it must be "relaxed" enough that lag between the server and client doesn't cause problems. For example, if a character is just around a corner and isn't shown to an approaching player... The player movement is done client-side, so he might in some cases turn around the corner and would see the character before the server knows he can see him. Certain anti-cheat apps that enforce a strict visibility rule cause these problems where you run through a doorway, see nobody in the room, and get shot a second later by the guy who was right in front of you but not displayed... And players who come out from behind obstacles only become visible when they're already 30 feet in the open.

So it's pretty clear that occlusion checks will have to be done on the client side unless you want to put up with those glitches. This of course makes games vulnerable to cheats. A game like Quake3 or CS could be slightly improved here, by doing a client side occlusion cull of some kind before sending the character models to the video card... But you're supposed to be able to TRUST the hardware to do that for you! (especially if it's usually faster than your "manual" culling.) OpenGL specs determine what a Z-buffer should do, and any OpenGL implementation is expected to follow those specs. Otherwise we might just as well ditch any standards and go back to software rendering...

I bet a good 3D engine programmer could find an efficient way to figure out if a character is fully occluded or not. Forget the complexity of the character model - a bounding box would be enough. Then it's a matter of the static world geometry.

A bounding box wouldn't make it all THAT much easier. You'd still have to test it against all environments polygons.

Besides, if you use a bounding box you get all sorts of weird effects, that you have to specifically test for. You think with a bounding box it is enough to test wether the corners are visible? Think again. Imagine a character behind a hole in a wall. It is possible that all corner points of the bounding box are occluded by the wall, but most of the character (maybe even the whole character) is visible. If you don't send the character to the video card based on the bounding box test, you're getting a wrong result.
This is far from being a trivial problem. And one that was already solved over a decade ago with hardware support for Z-Buffers.

#17, your input is appreciated. Perhaps lazy was the wrong word. I realize there is a tradeoff, and your example of the Unreal engine is very good. However, I'm not convinced that too many engines are CPU-bound these days. The tradeoff is a difficult one considering issues of diversity and scalability. I still don't like the attitude of "let's throw everything at the GPU" though.

I bet a good 3D engine programmer could find an efficient way to figure out if a character is fully occluded or not. Forget the complexity of the character model - a bounding box would be enough. Then it's a matter of the static world geometry.

If you model characters as points, you could probably use BSP trees for the scene geometry. You might get weird things with characters appearing entirely or not at all when they're peeking around corners, but it would be efficient.

This is all if you're crazy enough to want to do this.

Aidan

If you're refering to the ZBuffer, that's still somewhat slow even with hardware acceleration as it's done on a pixel by pixel basis. I believe that's what those driver settings are disabling.

Yes, ZBuffering is one method to perform hardware visibility testing.

So occlusion culling, that is done at the polygon or object level, is in fact an optimization technique.

Yes, it is. But it can only be done for static geometry because to do it efficiently you need some pre-calculated data structures like BSP trees and the like. However, cheaters are not interested in seeing occluded walls or buildings, they are interested in seeing game characters. And game characters are definitely not static :).

As for the dynamic/non-trivial parts: that's what Z-Buffering is for. You COULD replace Z-Buffering with a different technique for characters (possibly old-fashioned polygon clipping), but that would be dead slow. And what would be the point of having hardware acceleration if it isn't used?

#15, the reason more overdraw is "acceptable" is that video hardware is getting faster and CPUs aren't keeping up. If you want to balance your processing load, the answer is NOT to remove work from the GPU and add it to the CPU; it's just the reverse.

A good example is the Unreal engine. It used spanbuffer occlusion to prevent overdraw. This was great for a SW renderer because a spanbuffer "test-render" is much faster than an actual software surface render; so for occluded polies you save a lot of time, and for others you don't lose much. Unfortunately, the test can be _slower_ than just pumping surfs at the hardware. Until recently, the renderer was extremely CPU-bound.

So don't talk shit about the "easy way out" or being "lazy". Overdraw is an engineering tradeoff.

Sort of... except that in your world, a counterstrike server, in addition to managing the state of the game and handling communication with all 32 clients, now has to do a lot of the occlusion processing for each client.

That better be a pretty beefy server.

Aidan

lol #11!!

As for you, #12, you are dead wrong about having to ditch hardware acceleration. Before there was hardware acceleration, game developers tried much harder to eliminate overdraw because it took so long to rasterize 3D scenes without hardware acceleration! The original Quake had zero or near-zero overdraw. If you found a way to make the walls see-through, it wouldn't have bought you anything.

These days, game developers rely on z-buffering and relatively simple culling to solve the occlusion problem, which is really taking the easy way out. Ya, they'll do sectors and portals and stuff, but there's always an amount of "acceptable overdraw" which varies between developers. It ranges from say Quake, which actually tries hard to eliminate overdraw, to EverQuest, which doesn't try at all and just threw everything at the API and the hardware.

Don't get me wrong, zero-overdraw is a very difficult feat to accomplish. Most game developers aren't being TOO lazy about this, and they have enough other stuff to worry about anyway. Zero-overdraw would not help frame rate that much compared to having some overdraw, because z-buffering is very effective. It would solve the see-through drivers cheating problem though.

(I'm not an expert on this but I don't think I'm far off here.)

Wow... just occurred to me, maybe the Microsoft/AMD/Intel Palladium initiative could be used to force the use of authorized drivers while playing a game. Hmm....

Aidan
http://www.salon.com/tech/feature/2002/07/11/palladium/index.html

Finding out what is visible from the current point of view and what is not is actually one of the things that are "accelerated" by hardware acceleration.

If you're refering to the ZBuffer, that's still somewhat slow even with hardware acceleration as it's done on a pixel by pixel basis. I believe that's what those driver settings are disabling. So occlusion culling, that is done at the polygon or object level, is in fact an optimization technique. Now, maybe with all the fancy T&L stuff that new cards have, it's possible to use hardware acceleration for that too. But older games like CS, quake3 and such won't use that anyway. The problem is that occlusion culling is a difficult technique that can't be used in all cases.

Now, if the games have better occlusion algorithms, that won't be much of an issue as the drivers will never receive the data about that player hiding behind the corner.

The problem is that you'd have to ditch hardware acceleration if you don't want to send the "invisible" parts to the driver. Finding out what is visible from the current point of view and what is not is actually one of the things that are "accelerated" by hardware acceleration.

People who buy SiS-based products need all the help they can get.

I'm just kidding. ECS, and those who trivialize the legitimacy of these complaints are Nazi bastards and can go to hell.

#4
That attitude is exactly the kind of attitude that will ruin online gaming. If these drivers are continued to be pushed through and become marginally popular, it will force more and more legit players to either buy the card or download a hack in order to have fun. The game was not meant to have see-through walls, some of us would like to play this way but for every 100 times we got shot through a wall 400 meters away, 1 of us will get fed up with the game and quit or start cheating.

#4,

Let's pretend for a second that you aren't really trolling here and think about this. It is only a game, but it is a game that (most of us) have laid down real money for (either for HalfLife or CS retail). As such we have a right to play the game as it was designed.

Football is only a game, but do you think the NFL would allow teams to come up with their own rules? No. Its a game because everyone is playing by the same rules. If someone wants to "get a couple extra frags" then they should improve their skills.

I care getting shot through walls ruins the fun I have in the game. I don't take the game seriously but I like to have fun. Why else game?