Announcement

Collapse
No announcement yet.

A question for Epics's game engine programmers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by deadman_uk
    I found out the hard way about UT being CPU bound...

    I had a geforce 4ti4200 and when i upgraded to a 9800pro i saw virtually no difference. I could turn AA and AF on but ii still got poor frame rates.

    Its my CPU... the Athlon palamino 2000+ is old technology, it just doesnt cut it and does no favours for me in UT. I will be getting an Athlon 64bit 3500 939 very soon, and if UT2004 doesnt run smooth then, i'll be confused.
    Thats the same proc I am running, works great :up: Although different graphics card.

    Leave a comment:


  • replied
    I found out the hard way about UT being CPU bound...

    I had a geforce 4ti4200 and when i upgraded to a 9800pro i saw virtually no difference. I could turn AA and AF on but ii still got poor frame rates.

    Its my CPU... the Athlon palamino 2000+ is old technology, it just doesnt cut it and does no favours for me in UT. I will be getting an Athlon 64bit 3500 939 very soon, and if UT2004 doesnt run smooth then, i'll be confused.

    Leave a comment:


  • replied
    That's what I love about VM-based game engines. You only have to port the VM, not the game content to get it working on another platform.


    To answer the question about the next engine being more GPU bound than now, I think it will be very so...

    I remember watching a video preview on the Unreal engine 3, and they were saying that at the time, only the upcoming (*at the time*) GeForce 6800 would be able to render it in real time (or something like that), due to the high ploy count and other various 3D rendering effects.

    See it for yourself:
    http://www.ozforcesfiles.com/pafiled...n=file&id=1570

    Leave a comment:


  • replied
    Originally posted by 3v1£jesú§
    If the game was designed completely in C/C++, it my have been much faster, yet development of the game content would be painstakingly harder. That would also take away what makes the game and engine so great. There would not be much user made mods out there. Unreal is the most open game development architecture I've ever seen, and it's all because of the way it was built.
    Epic does a great job with there stuff, and make it easily modable. Id does a fair share to, although in a different way. http://www.iddevnet.com/ id actually releases a fair amount of the actually engines code (writen in C++ for DooM3) and you make your mods based on that. The main problem here, is when they support different OS's (Windows and Linux) you have to compile for each one. The way Epic does things are much better in one way, in the fact that is crossplatform without recompiles(like you said). Both have there respective beneifits. Epic is a great company, equal to id, and they have done some things which allows modding to be easier then with other game engines. :up:

    I previously forgot to mention, DooM3 also has a scripting system, but I don't think its compiled to byte code like Uscript, instead its interpreted at runtime, this probably adds some over head, but also means any changes you make, don't need to be compiled before every test. Its a runtime over head.

    Leave a comment:


  • replied
    Maestr0 is right about the virtual machine thing. The Unreal engine itself _IS_ a virtual machine. Vitrual machines interpret byte code and execute instructions through translation to then be processed at a lower level. This is bound to bring CPU overhead.

    If you are running any benchmark other than a flyby, it will be CPU bound due to the following:

    In developing Unreal engine game content, every .uc file (Unrealscript code) is compiled into .u file (byte code). When you run the engine (which is made with C/C++ code, and thus compiled into fast machine language), it interpets the .u files' bytecode during gameplay.

    Every single object in a game is executed in it's own script, or byte code. Given the hundreds of objects in any given game, they all have to be executed in its own thread through the VM. VM's are almost like hardware/system emulators, providing an environment and a level of abstraction for the byte code which executes within.

    Quoted from the official UnrealscriptLanguage reference (located at http://unreal.epicgames.com/UnrealScript.htm):

    "UnrealScript is a slow language compared to C/C++. A typical C++ program runs at about 50 million base language instructions per second, while UnrealScript runs at about 2.5 million - a 20X performance hit."

    This documentation may be old, but I believe most of it still applies to the modern Unreal engine. Reading the document sheds a lot of light on how the engine works and why it was designed to be the way it is.

    If the game was designed completely in C/C++, it my have been much faster, yet development of the game content would be painstakingly harder. That would also take away what makes the game and engine so great. There would not be much user made mods out there. Unreal is the most open game development architecture I've ever seen, and it's all because of the way it was built.

    Leave a comment:


  • replied
    Originally posted by El_Muerte_[TDS]
    luckily new CPUs are cheaper than new graphic cards
    Remember when it was the other way around?

    Unless you are crazy enough to want the top of the heap.

    Leave a comment:


  • replied
    I would have to agree that UT2004 is very CPU bound to the degree you're running 1024x768 playing. Running 1600x1200 is when your video card starts to show it's true colors.

    Leave a comment:


  • replied
    luckily new CPUs are cheaper than new graphic cards

    Leave a comment:


  • replied
    MonsterMadness
    now trolling spree again. pretty low, your friend-in-love Sasuke at least had style

    Leave a comment:


  • replied
    Gaal = Idiot

    Leave a comment:


  • replied
    Re: A question for Epics's game engine programmers

    Originally posted by Folk
    The Unreal engine is CPU bound. Big time.
    Nope. If all results are same it just shows that performance it limited by something. With todays cards its indeed often the CPU but there is nothing to point to the guiltiness of the engine. btw that link you posted shows that the GT6600 is 2,5 times faster than the FX5750 .. Makes perfectly sense. What does not is to run the tests on P3-500 and logically see no difference then between R9800 and X800. If the results are same even on Athlon64 whatsoever, it only means that X800 is still too fast for it.

    EPICPLZFIX your game my CPU is too slow :bulb:

    Leave a comment:


  • replied
    cpu bound = unreals virtual mashine.

    Leave a comment:


  • replied
    Perhaps having an awesome video card won't improve framerates in all maps, but it certainly will in high-poly maps such as ONS-Tricky that choke on anything less than a 9800.

    Also, while a fast vid card may not improve FPS, a mediocre card like the FX5200 will do a wonderful job of killing framerates, especially in ONS where I can barely pull 30 FPS.

    Leave a comment:


  • replied
    Re: Re: Re: A question for Epics's game engine programmers

    Originally posted by suibhne
    I think you missed the point of Folk's post.
    <Folk bows to suibhne>

    Leave a comment:


  • replied
    Re: Re: A question for Epics's game engine programmers

    Originally posted by SonicBlaster200
    I have an ATI Radeon X800 XT Platinum, and I do notice a considerable difference between my ATI Radeon 9800 XT. I'm running a resolution of 1600x1200, and on the best possible settings for ingame settings. My AA is at 8x and AF 16x. Catalyst 4.9 Drivers.

    Either your running a CPU that cant handel the needed clocks per second, or you have something seriously wrong with your graphics card, because the next thing if the graphics card doesn't work is your CPU.

    EDIT: BEFORE posting a topic that makes assumptions take a look at the scores (benchmarks) for the unreal tournament 2004 (on any grahics card review that has been conducted within 2004) with the ATI Radeon X800 series, and Nvidia Geforce 6800 series, which compare them to the ATI Radeon 9800 series and the Nvidia Geforce 5950 series.
    I think you missed the point of Folk's post. There's no question that UT is CPU-bound, and you'll see this point demonstrated perfectly if you consult benchmarks for UT2K4 on an X800 vs. a 9800 Pro; the question is why the game is so CPU-bound and whether it will be able to scale differently in future incarnations. That's what Folk is asking.

    Saying a game is "CPU-bound" doesn't mean your X800 won't run it at 1600x1200 with all the bells 'n' whistles. Basically, it means that your X800 will run it at 1600x1200 with all the bells 'n' whistles at essentially the same fps as your 9800 Pro will run it (without the bells 'n' whistles, since AA and AF are a hit on the graphics card rather than the CPU).

    Leave a comment:

Working...
X