If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

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

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

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

Originally Posted by ciplogic

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.

Originally Posted by ciplogic

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.

Originally Posted by ciplogic

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.

Originally Posted by ciplogic

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.

Originally Posted by ciplogic

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

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?

Originally Posted by c117152

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.

Originally Posted by c117152

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.

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.

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.

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

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

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.

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

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.

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

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

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.