Unvanquished Is Rewriting, Modernizing The Quake 3 Engine

[ciplogic]

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?

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.

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.

[c117152]

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

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.

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.

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.

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.

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

[JS987]

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

[IanS]

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

[ciplogic]

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

[IanS]

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.

[kwagga]

Well done!

Great work Unvanquished Team.

I do not play the type of FPS you guys produce, however I like to follow your updates and see a determined team make a great game.
Amazing visuals and may you guys reach your goals in not time.

All the best!

[ciplogic]

I had a look at some of your latest source code and it's looking really clean and heavily document. Well done.
I'm just loving that C89 style. So neat and proper. It's no wonder so many quake3 ports have been made over the years.
C might get tedious and boring but well written C just makes me happy in ways no C++ hack could. I suspect the lack of interest in Doom3 indicates others feel the same way as I do.

I haven't noticed any C++ stuff so I'm hoping your C++11 transition will be very strict and limited.
Using PNaCl is interesting. I really dislike JavaScript so I think, while not optimum, it's probably the best way to get a web app going. Though I'm not quite sure why you guys are interested in PNaCl. Is an FPS really a web app now?

Anyhow, I hope you guys can merge the Jedi Outcast\Academy modifications so that there will truly be one fork to rule them all

Good-luck!

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?

What is so bad of using C++ or C++ 11?
Using iterators or auto? Using a STL sort function that works faster than QSort?

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.

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.

[mrugiero]

I haven't noticed any C++ stuff so I'm hoping your C++11 transition will be very strict and limited.
Using PNaCl is interesting. I really dislike JavaScript so I think, while not optimum, it's probably the best way to get a web app going. Though I'm not quite sure why you guys are interested in PNaCl. Is an FPS really a web app now?

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.

[c117152]

I had a look at some of your latest source code and it's looking really clean and heavily document. Well done.
I'm just loving that C89 style. So neat and proper. It's no wonder so many quake3 ports have been made over the years.
C might get tedious and boring but well written C just makes me happy in ways no C++ hack could. I suspect the lack of interest in Doom3 indicates others feel the same way as I do.

I haven't noticed any C++ stuff so I'm hoping your C++11 transition will be very strict and limited.
Using PNaCl is interesting. I really dislike JavaScript so I think, while not optimum, it's probably the best way to get a web app going. Though I'm not quite sure why you guys are interested in PNaCl. Is an FPS really a web app now?

Anyhow, I hope you guys can merge the Jedi Outcast\Academy modifications so that there will truly be one fork to rule them all

Good-luck!