Announcement

Collapse
No announcement yet.

A question for Epics's game engine programmers

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

    #16
    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.

    Comment


      #17
      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.

      Comment


        #18
        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.

        Comment


          #19
          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.

          Comment


            #20
            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

            Comment


              #21
              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.

              Comment


                #22
                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.

                Comment

                Working...
                X