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

Status
Not open for further replies.
hovz said:
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
Physics will probably always be done on the CPU. It is tied in with collision detection, which ties into gameplay events and even AI. Technically this can be done on a separate processor, but when you look at what needs to be done, the processor that is best able to handle this is a CPU.
 
*sigh* It's just not worth replying any more. There's just no intelligence to be found in this Epic-bashing.
 
So very typical on many of the internet forums these days. Tell you what, if you can build a better engine, the do so.

Post in a couple years and let us know how you did...

/boggle
 
Ignorance more frequently begets confidence than does knowledge. It is those who know little, and not those who know much, who so positively assert that this or that problem will never be solved by science. - Charles Darwin
 
Does unreal have a JIT compiler for it's script virtual machine? If not, then you can guess that heavy usage of it (AI, physics, etc) will result in significant CPU usage.

Other games have the heavy game logic written in C/C++ libraries. Does FarCry do scripting or compiled approach?
 
off of the Unreal Tech page for UE2X:
We've made creative use of vertex shaders to decompress all geometry on the GPU, during run-time.

So is this not done on UE2.0?
 
DemoCoder said:
Does unreal have a JIT compiler for it's script virtual machine? If not, then you can guess that heavy usage of it (AI, physics, etc) will result in significant CPU usage.
I don't think so. When I was doing modding I had to compile code before it could be used. Don't misunderstand what it is used for, though. It's purely used for content. This includes gameplay and object behaviour including AI, but anything that absolutely needs to be fast (such as pathfinding and collision detection) is done in C/C++. I'm not sure about Unreal Engine 2's UnrealScript performance, but in Unreal and Unreal Tournament it was reported as being 20x slower than native C/C++ code. However, I'm guessing that it's been optimized, since then.

Other games have the heavy game logic written in C/C++ libraries. Does FarCry do scripting or compiled approach?
FarCry uses Lua, which AFAIK is also a compiled scripting language.

Another scripting language that's seen some use in games (though not much) is Python. It's an interpretted language.
 
Ostsol said:
FarCry uses Lua, which AFAIK is also a compiled scripting language.
A Lua chunk is "compiled" to bytecode, that is then executed/interpreted by a VM (still pretty fast).
But all the "hard work" in a game can be done by native functions, witch can be "registered" and then called by Lua code.

It's a bit like if the embedding application (Far Cry, for ex.) exposes a sort of API...

Bye!
 
hovz said:
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.

Actually, I believe the models are rendered by your mouse... thats why you get mouse lag when there is a few players on screen.

I don't have any evidence to back this up.... "cuz if u dont believe me i dont care"

Debating skills at its best!
 
well i lag too when im playing on a Dial up. I also have issues with frames when i run it at 1600/1200 6AA, it is a bit tuff with all the candy on :rolleyes: But the bad pings i get are the real reason for the "lag" when i play with guys in Finland and Korea whit my 125k connect..... sounds like a net code issue lol
 
I understand that "hard work" will be a native callout from the script code, but AI is "hard work" too. IMHO, and if the bots are executing alot of script, then bot-heavy stuff will be a much bigger CPU hog than a C++ version. In particular, if the script has to traverse data structures it's going to be much slower than a compiled or JIT'ed version.
 
DemoCoder said:
I understand that "hard work" will be a native callout from the script code, but AI is "hard work" too. IMHO, and if the bots are executing alot of script, then bot-heavy stuff will be a much bigger CPU hog than a C++ version. In particular, if the script has to traverse data structures it's going to be much slower than a compiled or JIT'ed version.
To be honest, the division of code doesn't seem to be decided by hard work vs easy work in the Unreal Engine. It's more of engine code vs game code. Engine code is the generic, underlying logic that is used regardless of the content or gameplay -- or game. Game code is code specific to a particular game. It just so happens that most of the "hard work" is generic engine code and therefore in C++. There are generic UnrealScript classes in the Unreal Engine, but they're mostly extendable interfaces to native code.

High-level AI code, bots' high-level decision making process, is most of the time game code. What to do in UT2004, for example, is dependant on the gametype. Depending on how smart the bot is, this could end up being "hard work", as you say, but putting it in C++ code would be breaking the standard for division of code. It would also make things much more difficult for mod-maker seeking to make a new, complex game-type with competent bots. In the original Unreal and UT, C++ code could have been used as Epic released the C++ header files to allow modders to use native code. However, Epic hasn't seemed to want to do this for UT2003 and beyond (probably in part to eliminate some of the more sophisticated cheat/hack possiblities). As such, specific bot AI must be coded in UnrealScript.

I'm not sure how the division of code is in FarCry. I used to have the demo installed, but I deleted it a while ago so I can no longer check. However, I do recall that mission scripting is coded entirely in Lua.
 
Alstrong said:
off of the Unreal Tech page for UE2X:
We've made creative use of vertex shaders to decompress all geometry on the GPU, during run-time.

So is this not done on UE2.0?
Since the 2x is for the XBox, it would make sense to not load the CPU up to much when you've got a pretty quick piece of dedicated hardware for vertex processing. A mid-to-top end PC will have a substancially more powerful CPU under the hood of course.
 
Ostol, I'm not suggesting rewriting all Bot AI in C++ code. I'm suggesting that UnrealScript needs a better virtual machine. One that can either run interpreted/p-code faster, or one that compiles to x86 code, like Java, MS CLR/C#, or Scheme/Lisp/OCaml/Perl, etc. Better yet, maybe Sweeney can just retarget it to a CLR backend. As good as Sweeney is, I don't expect him to be able to write a VM with performance on par with Microsoft or Sun compiler engineers and he shouldn't have to, since he should focus most of his talents on 3D.
 
UT (among other games) does software skinning.... leaving those lovely vertex shaders unused for the most part!
 
I wonder if it has anything to do wih the fact that the UT engine was initially developed in the DX7 era and any major developments such as this have gone into UE3. Given Tims recent comments, that appear to be congruent with the composition of the next gen console configurations, I wonder if this will still be the case with UE3 (or at least with an option to switch between VS and CPU processing).
 
Status
Not open for further replies.
Back
Top