Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 46

Thread: Unvanquished Is Rewriting, Modernizing The Quake 3 Engine

  1. #11
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by IanS View Post
    I am mildly disappointed that they are switching to C++ if only because I have been spending a fair bit of time learning C lately and was starting to look for decent game projects I could start to dig into and potentially help out with. As Unvanquished is one of the nicer and more polished open source games out there I was strongly considering getting to know the code base. But now? Not so much, as I really don't care for C++. I know it offers a lot of features missing from C, but none of them seem compelling enough to spend any significant amount of time wading through C++ code which almost always seems to tend towards the convoluted and unnecessarily over-engineered side of things. This is just personal preference though and obviously the devs have already made up there mind, I'll just have to keep looking around till I find a project that is a better fit for what I am after.
    To not be picky, this is the moment when you should come into the project. This makes it possible to you to have a voice to fix the parts are not working nice for you. Also is your chance to learn C++, which is not such of a bad deal. C++ is not over-engineered if is written "correctly" as C is not either. Bad C coding practices exist, and bad C++ ones also.

    At the end, you can contribute just a small part in C, and people will rewrite it in C++, so still is no issue for anyone (if you don't want to touch C++ at all).

  2. #12
    Join Date
    Jan 2013
    Posts
    209

    Default

    Quote Originally Posted by ciplogic View Post
    To not be picky, this is the moment when you should come into the project. This makes it possible to you to have a voice to fix the parts are not working nice for you. Also is your chance to learn C++, which is not such of a bad deal. C++ is not over-engineered if is written "correctly" as C is not either. Bad C coding practices exist, and bad C++ ones also.

    At the end, you can contribute just a small part in C, and people will rewrite it in C++, so still is no issue for anyone (if you don't want to touch C++ at all).
    What you say makes sense, but I do actually know a bit of C++ already. I first learned the basics of it back around '99 and have revisited it a few times since then. I know enough to read through code and generally know what is going on, I just find it to be an ugly language that takes far more effort than it is worth. Any language that needs several volumes of books covering common pitfalls that every serious develop needs to know is a language I would rather not invest in. I'd rather spend that 3-5 year time sink learning something more useful like refreshing and increasing my math knowledge rather than just fighting to get reasonably competent in a language I hate to read.

    Here's a great page that picks apart the issues with C++ better than I will ever be able to do; some folks here might find it an interesting and potentially enlightening read: http://yosefk.com/c++fqa/index.html

  3. #13
    Join Date
    Sep 2012
    Posts
    343

    Default

    Quote Originally Posted by IanS View Post
    Here's a great page that picks apart the issues with C++ better than I will ever be able to do; some folks here might find it an interesting and potentially enlightening read: http://yosefk.com/c++fqa/index.html
    C++ has some defects as all languages, but most of those exist because of backward compatibility with C, which probably exists because of need of use C libraries in C++ applications. C is even more defective than C++.

  4. #14
    Join Date
    Mar 2013
    Posts
    144

    Default

    Quote Originally Posted by mrugiero View Post
    The blog explains it in detail. PNaCl is supposed to get over the older VM that is in use right now. It's just a bytecode interpreter, the same as it's in use right now, but delegating the maintenance of its compiler to Google, and thus switching from a currently unmaintained and inefficient one to one widely supported.
    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...

    Quote Originally Posted by ciplogic View Post
    You love that style, but did you contribute back? If you don't and you are just saying: this developer should use this, what is the benefit?
    I have nothing to offer to this particular project. Since I haven't even played a computer game in years, I don't even get the chance to do any sort of debugging. Every once in a while I notice some bug in my stack, trace it back to a function and clue in someone in the IRC or mailing list... But it's very rare for me to do proper patches since most devs will prefer doing it their way anyhow.

    Quote Originally Posted by ciplogic View Post
    What is so bad of using C++ or C++ 11?
    I won't be dragged into a C++ debate again. Especially for game engines where C++ is ubiquitous.

    Quote Originally Posted by ciplogic View Post
    Using iterators or auto? Using a STL sort function that works faster than QSort?
    There are no performance gains to any C++ features over regular old C. For everything else: http://commandcenter.blogspot.com/20...ally-more.html
    If you want to debate C++ from the other side of the spectrum, try D. Unlike Go which disposes of the misfeatures, D is trying to do them properly. Their place is still highly questionable as far as I'm concerned, but if game developers who are 3 times the programmers I am on my best day say they need them, I won't argue.

    Quote Originally Posted by ciplogic View Post
    What would be the problem if they would use JS like V8 (they don't, as you did not read the blog post) as their portable scripting engine? Would it taint the project? Would it make it a web app? 0AD game is using a JS engine as the main scripting, and I don't see it working on the web, maybe you can clarify me.
    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.

    Quote Originally Posted by ciplogic View Post
    PNaCl is not a web technology, is a sandbox environment to execute C/C++ programs. PNaCl (Portable Native Client) is a C/C++ VM that executes everything in a sandbox. But is still C++. It is more C++ than Asm.JS is, as it can do all operations that C++ does, excluding some very weird pointer arithmetics, and even if a buffer overflow occurs, this would in the worst case break the VM (the runtime of the game logic), not the user's machine credentials and such.
    I have no idea what "web technology" is. What a bytecode vm does is to allow you to execute code sandboxed. Then "all" you have to do is port the interpreter. And your code is automagically running.
    If Google is incorporating their PNaCl interpreter inside Chrome - like Java Applets used to do - that's their business. 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.
    My only question was what is the benefit to a FOSS game in using PNaCl over LLVM? Won't the subset and extra memory management the interpreter does incur a performance lost? But I already clarified that in my first response...

  5. #15
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by c117152 View Post
    There are no performance gains to any C++ features over regular old C. For everything else: http://commandcenter.blogspot.com/20...ally-more.html
    If you want to debate C++ from the other side of the spectrum, try D. Unlike Go which disposes of the misfeatures, D is trying to do them properly. Their place is still highly questionable as far as I'm concerned, but if game developers who are 3 times the programmers I am on my best day say they need them, I won't argue.
    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

    Also, your link shows that Go is simpler, so why are you arguing about performance, when the next phrase is just about simplicity?

    Quote 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.
    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.

    Quote Originally Posted by c117152 View Post
    I have no idea what "web technology" is. What a bytecode vm does is to allow you to execute code sandboxed. Then "all" you have to do is port the interpreter. And your code is automagically running.
    If Google is incorporating their PNaCl interpreter inside Chrome - like Java Applets used to do - that's their business. 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.
    My only question was what is the benefit to a FOSS game in using PNaCl over LLVM? Won't the subset and extra memory management the interpreter does incur a performance lost? But I already clarified that in my first response...
    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".

    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.

  6. #16
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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.

  7. #17
    Join Date
    Sep 2012
    Posts
    343

    Default

    Quote 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 at 11:50 AM.

  8. #18
    Join Date
    Mar 2013
    Posts
    144

    Default

    Quote 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.

    Quote 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.

    Quote 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 .

    Quote 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

    Quote 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 ?

    Quote 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

  9. #19
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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.

  10. #20
    Join Date
    Sep 2012
    Posts
    343

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •