UT2004, Far Cry - CPU and VPU (nv40, R420)

[hovz]

so again where is all the physics work?

I believe there's something called collision detection !

well every game has that? and the collision detection in 2k4 is VERY simplfied.

 

[see colon]

Carmacks engines far best, which is why I expect doom3 to maintain a consistent frame rate...

"Carmacks engines" seam to be simpler than the Unreal engine. he tends to make engines that concentrate on one or two features and accomplish them very quickly. games based on "Carmacks engines" tend to run slower, with "random" slowdown and hitches. just look at enemy territory or even jedi knight 2, huge fluxuations in framerate.
c:

 

[mastermind]

Oooh games slow down when lots is occurring, Wow I wonder what could be causing that?

Exactly they would know damn well what is causing the slow down, maybe then they should try and make it do less instead of creating something that they know will struggle on top end hardware. Its just that most PC games don't have the same attention/testing put into them to make sure insanely large frame rate drops don't occure.

If you look at panzer dragoon orta on the Xbox you will see that the game maintains a liquid smooth appearance throughout no matter how packed the screen gets. Sega have obviously taken the most intensive scene possible within the game, and made sure that engine is adjusted in such a way that it doesn't slow to a crawl at that point.

Its ok to make sacrifices in the visual department to maintain a smooth gameplay experience in my book. Instead of going overboard with the DX feature set they should instead invest the same time and effort into optimizations. Its too easy to think that the problem will go away when newer hardware comes out.

I'm not talking about unreal tournament here.

 

[KimB]

With all of these complaints, you still haven't told us what your system is, hovz.

 

[Ostsol]

well in far cry theres alot of physics and geometry. for whatever reason all polygons are still proccesed on the cpu, and then the details are added in the gpu. ud think by this point in time the gpu would be able to do more of the work but :/.

What do you mean, exactly, by "all polygons are still processed on the CPU"?

all polys are first rendered on cpu, they are sent to the gpu to be textured, lit, and everything else.

That still doesn't make any sense at all. I can imagine vertices being transformed on the CPU -- in the days before T&L, but not any more. There's simply no point. Also, polygons cannot simply be set up on the CPU and then sent to the GPU to be texture, lit, etc. The video card processes vertices and performs triangle setup itself. Do you have a link or document to support your claim?

the fact that on such a relativly simple game technically speaking your cpu bottlenecked on an athlon 64? u get what, 50 fps average? that means the lows are around 30? explain to me again how good this engine is!!!!

Consider what's happening in-game when the framerate drops so low. There's alot of AI and physics algorithms in action, ya know. Also you must realize that virtually all gameplay and game content is coded not in C++, but in UnrealScript. UnrealScript, like Java, is probably compiled down to byte-code of some type and run on a virtual machine -- almost like a CPU in software. This makes it faster than interpretted high-level code, but always much slower than compiled C++ code. As such, I don't find it at all surprising that the Unreal Engine gets CPU bound.

theres no ai in multiplayer, and karma is only applied to player deaths and vehicles. so again where is all the physics work?

Karma and vehicles do not make up for all the the physics in the game. Physics is always in action. Every move you make, every jump, every flak shard. The path of each bullet you fire from a chaingun, lance from a shock rifle, and bolt from the lightning gun must be traced across the geometry, checking for collisions. Assuming the use of octrees, the engine must iterate down through to the smallest octree nodes to find out where an object is and then test against all polygons and collision hulls to test for collision. Unless everyone is standing still and not doing anything, physics is always a big thing.

that also doesnt explain why far cry never stutters and drops like unreal does.

The only time I get stuttering in the UT2004 is when I have a bunch of stuff running in the back ground, taking up CPU cycles and memory. Actually, even then it's more of a general loss in framerate, but how can that not be expected?

 

[see colon]

...and karma is only applied to player deaths and vehicles. so again where is all the physics work?

water, but not in some 2k4 maps.
c:
edit- quote

 

[ShePearl]

Ah.... now, I have opened a can of worms.

 

[LeGreg]

unlike HL2 which looks like a great game, but if you watch any of the bink videos you can observe the same seemingly "random" and downright annoying frame rate drops, particularly when the screen turning..

It's funny..
I would have thought HL2 bink videos were recorded at a constant frame rate so it's doubtfull you'll see the framerate drop...

 

[Ostsol]

unlike HL2 which looks like a great game, but if you watch any of the bink videos you can observe the same seemingly "random" and downright annoying frame rate drops, particularly when the screen turning..

It's funny..
I would have thought HL2 bink videos were recorded at a constant frame rate so it's doubtfull you'll see the framerate drop...

They certainly are. The videos themselves are probably at a standard 24-29 fps. However, that doesn't mean that the game itself never went down below that.

 

[hovz]

well in far cry theres alot of physics and geometry. for whatever reason all polygons are still proccesed on the cpu, and then the details are added in the gpu. ud think by this point in time the gpu would be able to do more of the work but :/.

What do you mean, exactly, by "all polygons are still processed on the CPU"?

all polys are first rendered on cpu, they are sent to the gpu to be textured, lit, and everything else.

That still doesn't make any sense at all. I can imagine vertices being transformed on the CPU -- in the days before T&L, but not any more. There's simply no point. Also, polygons cannot simply be set up on the CPU and then sent to the GPU to be texture, lit, etc. The video card processes vertices and performs triangle setup itself. Do you have a link or document to support your claim?

the fact that on such a relativly simple game technically speaking your cpu bottlenecked on an athlon 64? u get what, 50 fps average? that means the lows are around 30? explain to me again how good this engine is!!!!

Consider what's happening in-game when the framerate drops so low. There's alot of AI and physics algorithms in action, ya know. Also you must realize that virtually all gameplay and game content is coded not in C++, but in UnrealScript. UnrealScript, like Java, is probably compiled down to byte-code of some type and run on a virtual machine -- almost like a CPU in software. This makes it faster than interpretted high-level code, but always much slower than compiled C++ code. As such, I don't find it at all surprising that the Unreal Engine gets CPU bound.

theres no ai in multiplayer, and karma is only applied to player deaths and vehicles. so again where is all the physics work?

Karma and vehicles do not make up for all the the physics in the game. Physics is always in action. Every move you make, every jump, every flak shard. The path of each bullet you fire from a chaingun, lance from a shock rifle, and bolt from the lightning gun must be traced across the geometry, checking for collisions. Assuming the use of octrees, the engine must iterate down through to the smallest octree nodes to find out where an object is and then test against all polygons and collision hulls to test for collision. Unless everyone is standing still and not doing anything, physics is always a big thing.

that also doesnt explain why far cry never stutters and drops like unreal does.

The only time I get stuttering in the UT2004 is when I have a bunch of stuff running in the back ground, taking up CPU cycles and memory. Actually, even then it's more of a general loss in framerate, but how can that not be expected?

thats how it works tho, the polygons calculation is almost all done on the cpu. far cry and many other games have those same underling physica, an dmuch much more. they dont fluctuate in fps nearly as much.

 

[hovz]

With all of these complaints, you still haven't told us what your system is, hovz.

p4 2.6c, 1gb ddr400, 9800 pro, audigy2

 

[LeGreg]

They certainly are. The videos themselves are probably at a standard 24-29 fps. However, that doesn't mean that the game itself never went down below that.

Hmm if I wanted to write a video grabber..

Oh well never mind, I'm not Valve after all

 

[Ostsol]

well in far cry theres alot of physics and geometry. for whatever reason all polygons are still proccesed on the cpu, and then the details are added in the gpu. ud think by this point in time the gpu would be able to do more of the work but :/.

What do you mean, exactly, by "all polygons are still processed on the CPU"?

all polys are first rendered on cpu, they are sent to the gpu to be textured, lit, and everything else.

That still doesn't make any sense at all. I can imagine vertices being transformed on the CPU -- in the days before T&L, but not any more. There's simply no point. Also, polygons cannot simply be set up on the CPU and then sent to the GPU to be texture, lit, etc. The video card processes vertices and performs triangle setup itself. Do you have a link or document to support your claim?

thats how it works tho, the polygons calculation is almost all done on the cpu. far cry and many other games have those same underling physica, an dmuch much more. they dont fluctuate in fps nearly as much.

Once again, do you have a link or document to support your claim? There is zero reason for a game that uses vertex shaders to do this. I suppose that some animation may be performed on the CPU, but most of the heavy work in animation is generally done on the GPU (when support is there) in all modern engines. For static geometry there is absolutely no reason for software vertex processing.

 

[hovz]

vertext shaders help, but they dont offload all the work to the gpu.

 

[Ostsol]

vertext shaders help, but they dont offload all the work to the gpu.

You really don't have anything to support your claims, do you? You don't explain anything, either. Exactly what work does the CPU have to do that the GPU can't do?

 

[Neeyik]

I believe the following thread is worth a quick read before continuing any more discussions in this one:

http://www.beyond3d.com/forum/viewtopic.php?t=10943

 

[KimB]

vertext shaders help, but they dont offload all the work to the gpu.

Most of the polygons that are rendered are not even touched by the CPU. The game just calls a few display lists, and renders most of the scene at once. If you pay attention to the flyby vs. botmatch results, it should become obvious that it's the AI and character animation that's taking most of the CPU power.

 

[hovz]

i havent looked for a link. cuz if u dont believe me i dont care. im just answering the posters question.

basically the cpu renders all the models. all the verticies and polygons are drawn on the cpu. vertex shaders modify and animate the models. pixel shaders add effects to them.

 

[Ostsol]

I believe the following thread is worth a quick read before continuing any more discussions in this one:

http://www.beyond3d.com/forum/viewtopic.php?t=10943

Heh! All the good info is on the first page. Then it turns to bashing Epic. The conclusion seems to be that T&L does pretty much all vertex processing, when the video card supports the specific features.

i havent looked for a link. cuz if u dont believe me i dont care. im just answering the posters question.

basically the cpu renders all the models. all the verticies and polygons are drawn on the cpu. vertex shaders modify and animate the models. pixel shaders add effects to them.

How can it be considered an answer to be taken seriously when you don't make an effort to back it up? You don't even say where you might have read or heard such information. . .

 

[hovz]

vertext shaders help, but they dont offload all the work to the gpu.

Most of the polygons that are rendered are not even touched by the CPU. The game just calls a few display lists, and renders most of the scene at once. If you pay attention to the flyby vs. botmatch results, it should become obvious that it's the AI and character animation that's taking most of the CPU power.

almost every polygon is orginally rendered by the cpu. thats why peopel always say in the future theyd liek to see graphics card take more of the physics an dpolygon calculation off the cpu