Announcement

Collapse
No announcement yet.

Unvanquished Is Rewriting, Modernizing The Quake 3 Engine

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

  • #16
    Originally posted by c117152 View Post
    Oh yeah I get that. What I didn't get is why not target the full LLVM. PNaCl seems to use a very specific subset of LLVM; trading off performance for sandboxing. I suppose it makes perfect sense if you want to run code inside a browser... Well, better then JavaScript that's for sure... But I was just wondering why an open source game engine would be interested in a virtual register machine? It's not like you need to conceal your code or anything. And you can always compile native...
    I guess it's mostly to avoid the need for a rebuild when you use a mod. Since scripts are in C/C++, you either need to recompile the whole engine for every mod you try to run, or rewrite everything in a scripting language, or just run them on a VM that can talk to the engine. I'm not against rebuilding, though, and anyway rebuilding should be needed for different architectures. Maybe it's just legacy and it's because Quake 3 worked this way.

    Comment


    • #17
      Originally posted by BO$$ View Post
      These days what is written in C++ when it comes to games could be written in Java with minimal loss of performance. And if absolutely necessary you can drop to native for high performance parts. Java is a C++ done better anyway and C++ programmers could pick it up in a weekend. They would also find that they have 10 times less bugs in the same number of LOC. But of course, Java is not hardcore enough for real men......
      Java would option in same cases if GCC would be able to compile every Java 7 code as native libraries and executables.
      Last edited by JS987; 09-16-2013, 11:50 AM.

      Comment


      • #18
        Originally posted by ciplogic View Post
        Are you serious? One guy when he was writing his sort, noticed that C implementation was faster and considered a bug, and he put it on StackOverflow
        How am I arguing about performance? There's no argument. I'm simply stating C is either as fast or faster then C++. I'm not making my case about it nor was I trying to.

        Originally posted by ciplogic View Post
        Also, your link shows that Go is simpler, so why are you arguing about performance, when the next phrase is just about simplicity?
        I said "for everything else". As in, everything except performance. I brought that article in the context of C++ not to discuss golang but rather to explain what's wrong with C++. I thought Pike covered that subject pretty well so I didn't feel like repeating his points... I'm sorry I wasn't more clear.

        Originally posted by ciplogic View Post
        As broken in which way? EcmaScript 1.0 was written maybe in two weeks (but the author was basing it on Scheme which he knew it for many years), and we talk today about EcmaScript 6, so you are a bit, like 15 years out-of-date.
        I refuse to discuss EcmaScript in the same spirit I refuse to discuss C++. Here's what a member of the EcmaScript committee had to say on the subject: https://gist.github.com/paulmillr/1208618 .

        Originally posted by ciplogic View Post
        Bytecode is the result of a compilation (for a virtual machine). A VM will run these bytecodes.
        PNaCl will take your C/C++ code and will write it into LLVM bytecodes. LLVM (VM) will compile them at the end. As you can probably see, there is no "interpreter", as everything at the end is compiled into binary code.

        Quake 3 VM is an interpreter (with a very simple JIT) that runs the output of the LLC compiler. The LLC compiler doesn't output exe by default, but a special interpreted code that QuakeVM consumes. As most scripts are written in C for the Quake game, the idea of this project is to use a mature compiler (like Clang++) which outputs LLVM bytecodes that PNaCl supports. At the end these LLVM bytecodes are optimized to actual CPU machine instructions by the PNaCl VM.

        Also PNaCl has the quality to run the code sandboxed (meaning it cannot modify your outside files, ofc excluding a bug), so is a great way to substitute QuakeVM without yourself maintaining all the code of security when you "rewrite" your "scripting engine VM".
        And all these advantages except for the sandbox apply to LLVM as well. Note I'm not arguing this or anything... We can just agree to disagree

        Originally posted by ciplogic View Post
        So, what's your comment about JVM? Java Virtual Machine you mean? "For Chrome this means you can now deploy real applications with a fraction of Java's performance lost. Perfect for Google's revenue model and without all the limitations of the JVM." - PNaCl (which is different from NaCl) means nothing for Unvanquished in Google's revenue in Google Chrome. Google Chrome can have PNaCl or not. Chrome can be rewritten in Java for example, and will not make any OSS games that depend on PNaCl to work better (or worse). May you explain which limitations you mean of the JVM? May you make a light in your mind first and split your ideas to be easier to follow? Thank you in advance.
        Seems we've struck the language barrier and you're not necessarily trolling... Well, PNaCl is a VM. LLVM itself is also a VM. Like the JVM (Java Virtual Machine), PNaCl takes bytecode and outputs machine code. PNaCl brand of bytecode is a subset of LLVM bytecode. JVM uses it's own Java bytecode. PNaCl is a register virtual machine unlike the JVM which is a stack machine. Stack machines have limitations vs. register machines since they're on a much higher order of complexity. It also means that you can technically write Java to LLVM but you can't write C\C++ to LLVM.

        So, the JVM's limitations are performance through explicit memory management. That's memory allocation (heap\stack malloc\free), pointer arithmetic and so on...

        Again, I wasn't making any arguments or anything. I was just noting that PNaCl is a subset of LLVM specifically written to sandbox code to execute it securely. And in light of that, I'm asking why not choose LLVM instead ?

        Originally posted by mrugiero View Post
        I guess it's mostly to avoid the need for a rebuild when you use a mod. Since scripts are in C/C++, you either need to recompile the whole engine for every mod you try to run, or rewrite everything in a scripting language, or just run them on a VM that can talk to the engine. I'm not against rebuilding, though, and anyway rebuilding should be needed for different architectures. Maybe it's just legacy and it's because Quake 3 worked this way.
        Legacy and compile time are good reasons. And I like the idea of avoiding a scripting language though I'm not sure why would an open source game would want one to begin with...
        Hmm, maybe it's also to authenticate the client for competitive gaming (against cheating?)...
        Well, if that's the case I suppose PNaCl isn't a bad choice if performance is a non issue

        Comment


        • #19
          Originally posted by c117152 View Post
          Legacy and compile time are good reasons. And I like the idea of avoiding a scripting language though I'm not sure why would an open source game would want one to begin with...
          Hmm, maybe it's also to authenticate the client for competitive gaming (against cheating?)...
          Well, if that's the case I suppose PNaCl isn't a bad choice if performance is a non issue
          I don't directly dislike scripting languages, and I don't think Unvanquished devs dislike them either, but rather they don't want to rewrite all of the game assets, at least right now. Personally, I do prefer binary native code, since this usually means I can run the game in older machines (not necessarily true, though, since the main bottleneck is probably on the GPU use), and being in C/C++ makes it fairly easy to modify to build natively if I eventually want to.

          Comment


          • #20
            Quake 3 engine is outdated. Xonotic has better engine.
            Last edited by JS987; 09-16-2013, 12:50 PM.

            Comment


            • #21
              Originally posted by n3wu53r View Post
              You say that as if they cannot do both and that they are mutually exclusive.
              Also, the amount of time people spend writing code is generally not going to affect the speed of game shipment since all the other parts (assets, sound..) are done by other people. Most of the work is not programming, which is why most FOSS games just suck.
              You kangz?

              Comment


              • #22
                The main reason we are using PNaCl is that we intend to encourage modding, like Quake 3 did. The Quake 3 virtual machine was designed to allows modified client-side game code to be downloaded when a player connects to a server, which makes distributing mods very easy and resulted in the creation of a large number of mods. In order to keep the ability to download mods, we need a sandboxed environment in which to run them, which PNaCl provides.

                Comment


                • #23
                  Originally posted by JS987 View Post
                  Quake 3 engine is outdated. Xonotic has better engine.
                  First of all Xonotic is derived from Quake1 (which itself is more outdated than Quake3), and Unvanquished is not derived from Quake3, but from ioquake3, ET:Real (another improvement over Q3 engine) and they want to make their own improvements. In my mind, are mostly on par, doesn't look so?

                  Originally posted by c117152 View Post
                  How am I arguing about performance? There's no argument. I'm simply stating C is either as fast or faster then C++. I'm not making my case about it nor was I trying to.
                  Why C is faster than C++? Give to me your source - when you have the source saying just the opposite. C++ (via STL) exposes more code to the compiler, hence the compiler has more opportunities to optimize. When C compilers let you say: "register" to say which variables you can put into registers, in C++ you can say which methods to inline. Also, for the sake of correctness, C++ code lets you write a loop like C code any time, but let you use any C++ constructs that are faster than their C equivalents:
                  - move semantics
                  - smart-pointers in language are faster than any C equivalent (like GObject's manual reference counting)
                  - STL and compile time templates
                  - const methods/parameters


                  Originally posted by c117152 View Post
                  I refuse to discuss EcmaScript in the same spirit I refuse to discuss C++. Here's what a member of the EcmaScript committee had to say on the subject: https://gist.github.com/paulmillr/1208618 .
                  Let me state why I answer to your quote with a proper answer about the history of JS:
                  Originally posted by c117152 View Post
                  A subset of a language that was written over two weekends is still as broken. There's plenty of good scripting language out there so insisting on the worst one is beyond me.
                  Stating that JS is not good for everything, we know this. To say is written in two weekends, is certainly a simplistic view, to not say is a slander for the hard work that JS and the runtimes around it have. Why would be JS the worst one? Reading your link states that JS has some parts that cannot be fixed, but never states that is the worst language, may you give a source where states that JS is the worst language?

                  Originally posted by c117152 View Post
                  And all these advantages except for the sandbox apply to LLVM as well. Note I'm not arguing this or anything... We can just agree to disagree
                  (...)
                  Seems we've struck the language barrier and you're not necessarily trolling... Well, PNaCl is a VM. LLVM itself is also a VM. Like the JVM (Java Virtual Machine), PNaCl takes bytecode and outputs machine code. PNaCl brand of bytecode is a subset of LLVM bytecode. JVM uses it's own Java bytecode. PNaCl is a register virtual machine unlike the JVM which is a stack machine. Stack machines have limitations vs. register machines since they're on a much higher order of complexity. It also means that you can technically write Java to LLVM but you can't write C\C++ to LLVM.
                  (...)
                  So, the JVM's limitations are performance through explicit memory management. That's memory allocation (heap\stack malloc\free), pointer arithmetic and so on...
                  (...)
                  Again, I wasn't making any arguments or anything. I was just noting that PNaCl is a subset of LLVM specifically written to sandbox code to execute it securely. And in light of that, I'm asking why not choose LLVM instead ?
                  Let me clarify: you seem to not understand what a register vs a stack based machine is, or if you do you have a very simplistic view about Java. Java is both a stack based and a register based VM. All local variables are registers. So based on this, you can write theoretically all LLVM to Java. In practice are some details which Java has limitations, like maximum 256 parameters, and I am not sure but I think it can have as much as 256 local variables (aka registers). .Net has the same design, but the limits are to 2^16 registers and parameters. Also Java doesn't support variable integer types, like integers on 31 bits or 123 bits, which LLVM does support from version 2.0 (.Net doesn't support them either), as Java doesn't support unsigned integers. How do I know all these details? Because I write in my free time a .Net virtual machine.

                  Second issue you don't seem to understand is sandboxing: sandboxing can be implemented in any language and the VM has little to say about it. For this reason, LLVM itself doesn't provide a sandbox model, when Java and .Net offer some sandbox models, and Mono offers a weaker sandbox model. On the other hand, WinRT and iOS, even are written in C++ offer a much stricter sandbox (or for that matter NaCl - not PNaCl). Sandboxing is a security model that have to be implemented, well thought, and so on. The VM can help sandboxing by writing its verifier of the bytecodes and it can block running code, but also the OS can do it, and so on.

                  At last, LLVM as VM what offers? LLVM as VM can JIT (create binary code that CPU runs) equivalent of the LLVM bytecode. As LLVM bytecode is the target of C/C++ compiler, it is not sandboxed in any way.

                  PNaCl is sandboxed, and it is a "safe subset" to compile C++ with. Q3VM is very similar in purpose with PNaCl but PNaCl can offer the same with less work for developers.

                  For people to "use LLVM instead" will mean to understand 100% the LCC compiler code, to rewrite the backend to generate LLVM IL, after that it will have to replace Q3VM to run LLVM instead of Q3VM bytecodes, and yes, you will have to implement the sandbox model around this code. Of course are variations to it, like "just" rewrite the Q3VM interpreter/JIT to use the LLVM JIT, and that's it, and to guarantee compatibility (which they plan to break it, as the Q3 tools are too limited).
                  Last edited by ciplogic; 09-16-2013, 03:41 PM.

                  Comment


                  • #24
                    Originally posted by ciplogic View Post
                    First of all Xonotic is derived from Quake1 (which itself is more outdated than Quake3), and Unvanquished is not derived from Quake3, but from ioquake3, ET:Real (another improvement over Q3 engine) and they want to make their own improvements. In my mind, are mostly on par, doesn't look so?
                    Does Unvanquished have much more detailed graphics than Xonotic Ultra?
                    Xonotic engine seems to be far more efficient than Unvanquished one.

                    Unvanquished - 33 fps
                    Xonotic Ultra - 76 fps

                    http://www.phoronix.com/scan.php?pag...s_galago&num=4
                    http://www.phoronix.com/scan.php?pag...s_galago&num=5

                    Comment


                    • #25
                      Originally posted by ciplogic View Post
                      Why C is faster than C++? Give to me your source - when you have the source saying just the opposite. C++ (via STL) exposes more code to the compiler, hence the compiler has more opportunities to optimize. When C compilers let you say: "register" to say which variables you can put into registers, in C++ you can say which methods to inline. Also, for the sake of correctness, C++ code lets you write a loop like C code any time, but let you use any C++ constructs that are faster than their C equivalents:
                      - move semantics
                      - smart-pointers in language are faster than any C equivalent (like GObject's manual reference counting)
                      - STL and compile time templates
                      - const methods/parameters
                      More opportunities to optimize?! I'm at a loss for words... Just, speechless...

                      Originally posted by ciplogic View Post
                      Let me state why I answer to your quote with a proper answer about the history of JS:

                      Stating that JS is not good for everything, we know this. To say is written in two weekends, is certainly a simplistic view, to not say is a slander for the hard work that JS and the runtimes around it have. Why would be JS the worst one? Reading your link states that JS has some parts that cannot be fixed, but never states that is the worst language, may you give a source where states that JS is the worst language?
                      Oh God. This is just...

                      Originally posted by ciplogic View Post
                      Let me clarify: you seem to not understand what a register vs a stack based machine is, or if you do you have a very simplistic view about Java. Java is both a stack based and a register based VM. All local variables are registers. So based on this, you can write theoretically all LLVM to Java. In practice are some details which Java has limitations, like maximum 256 parameters, and I am not sure but I think it can have as much as 256 local variables (aka registers). .Net has the same design, but the limits are to 2^16 registers and parameters. Also Java doesn't support variable integer types, like integers on 31 bits or 123 bits, which LLVM does support from version 2.0 (.Net doesn't support them either), as Java doesn't support unsigned integers. How do I know all these details? Because I write in my free time a .Net virtual machine.

                      Second issue you don't seem to understand is sandboxing: sandboxing can be implemented in any language and the VM has little to say about it. For this reason, LLVM itself doesn't provide a sandbox model, when Java and .Net offer some sandbox models, and Mono offers a weaker sandbox model. On the other hand, WinRT and iOS, even are written in C++ offer a much stricter sandbox (or for that matter NaCl - not PNaCl). Sandboxing is a security model that have to be implemented, well thought, and so on. The VM can help sandboxing by writing its verifier of the bytecodes and it can block running code, but also the OS can do it, and so on.

                      At last, LLVM as VM what offers? LLVM as VM can JIT (create binary code that CPU runs) equivalent of the LLVM bytecode. As LLVM bytecode is the target of C/C++ compiler, it is not sandboxed in any way.

                      PNaCl is sandboxed, and it is a "safe subset" to compile C++ with. Q3VM is very similar in purpose with PNaCl but PNaCl can offer the same with less work for developers.

                      For people to "use LLVM instead" will mean to understand 100% the LCC compiler code, to rewrite the backend to generate LLVM IL, after that it will have to replace Q3VM to run LLVM instead of Q3VM bytecodes, and yes, you will have to implement the sandbox model around this code. Of course are variations to it, like "just" rewrite the Q3VM interpreter/JIT to use the LLVM JIT, and that's it, and to guarantee compatibility (which they plan to break it, as the Q3 tools are too limited).
                      Why didn't you say you use Mono and C# voluntarily?! Here I was thinking this is some novel form of epic trolling. Or, at least, simply a severe case of miscommunication. Now I feel so silly trying so hard...

                      Here, this expresses everything you need to know about me while detailing my future commitment to this discussion:

                      Code:
                      #include <u.h>
                      #include <libc.h>
                      
                      void 
                      main()
                      {
                      	print("😶\n");
                      	exits(0);
                      }

                      Comment


                      • #26
                        Originally posted by c117152 View Post
                        More opportunities to optimize?! I'm at a loss for words... Just, speechless...
                        Yes, you seem to have a very short attention span, and you find puzzling words at random.

                        Yes, most C/C++ compilers, excluding the case you're using LTO (Link time optimizations) are not able to do many optimizations accross object files, so as in C++ you can write real implementation in headers, this implementation can be inlined by the compiler. If you will read more than tabloid blogs that people justify why they created their new language as a proof of dicharging an "old" one like C++, maybe you can look at this talk. This combines more details about VM, sandbox, "performance window", and luckily, it has a simple language. This is not a C++ optimizer talk.

                        You still failed to show your source of your assertion that C is faster (or equal) in all cases than C++ which is your initial claim


                        Originally posted by c117152 View Post
                        Oh God. This is just...
                        ... idiot, from your side as you throw words just to make sure that your beloved C is the single language it stands. You still did not address the idea that are real games using JS as their scripting engine (like 0AD), but you have simply said that is the worst scripting language.

                        Originally posted by c117152 View Post
                        Why didn't you say you use Mono and C# voluntarily?! Here I was thinking this is some novel form of epic trolling. Or, at least, simply a severe case of miscommunication. Now I feel so silly trying so hard...
                        This is the biggest difference between me and you: you are the "community" which produces nothing, and criticize developers because they don't align their code into the world of programming that was like 25 years ago: "write everything in C, a bit of assembly".

                        I use C# and Mono to make a virtual machine (to not say too much about my project already), what you seem to not see, that excluding some puzzling words like C# (read first line), you miss the part that the correction was a mistake in what you're saying: "JVM cannot implement LLVM because is a stack machine", isn't it so? Also you missed the part when you were educated that Mono includes some limited sandboxing, like it doesn't implement CAS. May you give your source where LLVM does sanboxing?

                        I feel fine for "smileys" written in C, even more when people live with their "ignorance is bliss" lifestyle.

                        I really appreciate that Unvanquished pick to write it into C++, and this is not because it will lose or win performance, but because at least they will be away of people like you. Also picking PNaCl seems a great design choice, I really hope they will succeed to finish it doing.

                        Comment


                        • #27
                          Originally posted by JS987 View Post
                          Does Unvanquished have much more detailed graphics than Xonotic Ultra?
                          Xonotic engine seems to be far more efficient than Unvanquished one.

                          Unvanquished - 33 fps
                          Xonotic Ultra - 76 fps

                          http://www.phoronix.com/scan.php?pag...s_galago&num=4
                          http://www.phoronix.com/scan.php?pag...s_galago&num=5
                          Please read what the article said also:
                          Sadly with Unvanquished there's still incorrect OpenGL rendering when using the GL3 renderer on the Intel Mesa driver
                          It may be simply a bug, or an edge case. For now particular reason, I see this screenshot from internet which shows Unvanquished played at 81 FPS (look on top-right screen):
                          http://media.moddb.com/images/articl...uto/z2KQch.jpg

                          Optimization takes time, and another generation game (this is not to say that game is Xonotic) can run faster just because it does less.

                          Performance (as in FPS) per-se doesn't mean necessarily it is less efficient, for example Crysis 2, a game I love, has low FPS for most machines (including mine), but it is because it adds many layers of physics and effects. On a similar note, Unvanquished has more scripts to run (necause it has RTS elements), so this may be the cause.

                          Comment


                          • #28
                            Originally posted by ciplogic View Post
                            Performance (as in FPS) per-se doesn't mean necessarily it is less efficient, for example Crysis 2, a game I love, has low FPS for most machines (including mine), but it is because it adds many layers of physics and effects. On a similar note, Unvanquished has more scripts to run (necause it has RTS elements), so this may be the cause.
                            It seems developers of Crysis 2 were bribed by some manufacturer of graphics card to use pointless effects and force people to buy high end graphics card as that game wasn't able to run at 90 fps with lowest details and average discrete graphics card at time of release (Geforce GTX 550 Ti only 47 fps).

                            Comment


                            • #29
                              Originally posted by ciplogic View Post
                              Yes, you seem to have a very short attention span, and you find puzzling words at random.

                              Yes, most C/C++ compilers, excluding the case you're using LTO (Link time optimizations) are not able to do many optimizations accross object files, so as in C++ you can write real implementation in headers, this implementation can be inlined by the compiler.
                              You can do just the same with C, it will just not be as clean as with C++, and you'll need to declare them static, also.
                              Also, the most used compilers can use LTO, so there's no point to do that thing, performance wise (there are valid reasons to use templates that have nothing to do with performance). Also, optimizing with C++ is said to be harder because of its increased complexity. I don't remember where I read it, so I'd take it with a grain of salt.

                              On the C versus C++ performance, I have an article where it is shown C++ performing better than C for the same algorithm, but I need to look it up.

                              Comment


                              • #30
                                Originally posted by mrugiero View Post
                                You can do just the same with C, it will just not be as clean as with C++, and you'll need to declare them static, also.
                                Also, the most used compilers can use LTO, so there's no point to do that thing, performance wise (there are valid reasons to use templates that have nothing to do with performance). Also, optimizing with C++ is said to be harder because of its increased complexity. I don't remember where I read it, so I'd take it with a grain of salt.

                                On the C versus C++ performance, I have an article where it is shown C++ performing better than C for the same algorithm, but I need to look it up.
                                So, let's clarify, C++ will give to you basically the same performance as C with a similar coding style. There is the concept of "zero-cost abstractions" of C++, that if you avoid the word "virtual", you will likely get for the same coding the same performance (this with or without LTO). There are tricks in C (like restrict keyword, which some C devels are using it, but too few C++ that do use it), and there is const in C++. Anyway, the const is a bit more powerful than restrict, in my view, as it give more code guarantees and give more chances for the compiler to optimize.

                                C++ has the power of optimizations because it allows more places to tune for performance and do it without a heavy burden over all codebase. Like you can override new operator.

                                Templates are powerful for performance (at least when we talk code without LTO) as the templates have to be parts of headers, so all compilers do have access both to type specialization (like using sort function) and to all code to make assumptions. STL (at least with unchecked iterators) have good performance algorithms which are a bit out of reach of the typical programmer: I talk here for example that the default std::map implementation is based on red-black trees which are balanced binary trees. Yes, you can write it in C, but is not made in a transparent way for users.

                                At last, C++ is harder to successfully write a compiler, but most compilers target the same intermediate reprezentation as their C counterpart (like LLVM, GCC's GIMPLE, or whatever way they are abstarcting the code does), so I see no reason that a C++ code would perform (if you switch the extension from C to C++ or vice-versa) worst or better.

                                Even I prefer Generic collections (from BCL/.Net world), std::vector gives basically the same performance of iterating with an indexer as a C array goes (again with unchecked iterators) and many STL algorithms are better than average programmer would write. C by default doesn't offer this, and here is also an area where I think that the performance disparity goes. Similarly std::string (or std::wstring) are really fast(er) equivalents of the C world. As many programs go, this is all is needed to make things run.

                                As for C world, I love Vala and other platforms which are using C for code generator (I mean about a lot of functional languages like Caml, Clojure), as C is a really close-to-metal stuff, and the guarantee that it doesn't throw exceptions, and if you don't use exceptions (C++ has std::nothrow so you can give the same code guarantee, if you want to help compilers analysis).

                                A great C++ talk about using some tricks (there is one very close to C world, and one where std::move semantic is flawed in today's compiler implementations), and one of them is using templates to optimize bit operations:
                                http://channel9.msdn.com/Events/Goin...in-Cpp-Quickly
                                (sorry that is a MS site channel, but the talk is about GCC/Facebook/C++/templates)

                                Comment

                                Working...
                                X