Porting is a lot more than graphics. If you can change to Linux audio/keyboard/mouse support or screen/viewport configurations by the click of a button, I want that button.
Get Unity 4 when it comes out, and you will have that button. Unity abstracts all of what you listed, so you won't have to deal with any of it when developing games in Unity.
But Unity (the game engine) is actually just called "Unity", and not "Unity3d". The latter is commonly used to refer to it, because the website is unity3d.com, but the product is simply called "Unity", so the headline is correct in that sense. I guess it could have been more explicit by mentioning the words game engine in the title, though.
Unity on Linux will be a native Linux binary. For games designed to run on desktop systems, the porting "effort" should be no more then clicking a button -- unless you use custom C++ libraries. All the game logic in Unity is implemented in mono bytecode, and the graphics already use OpenGL on OSX (you generally don't need to write platform specific shaders in Unity, as shaders are cross compiled to the target platform).
In any case, if I were you... and I'm not... I would find a field in which you are challenged and valued. Obviously don't go working for demons, but possibly tone down your standards to something a bit more practical. You are not living in a world of saints. We're simply people. We're not entirely good or bad. We simply are. Try to accept that without holding people to unreasonable standards.
The question is, however, what are "reasonable standards"? Where do you draw the line? And this is very hard to tell because the lines are always blurry. The submitter said he does not want to work for the defense industry and you argue that defense is net positive. The thing is, it's hard to tell, and totally pov. Is working for a weapons smuggler selling weapons to Taliban fighters ethical? If you believe that the Taliban are the good side, then probably. Is doing software consulting as a contractor for any western army ethical? Equally if you believe that they are the good side, then probably. But what if you're not sure which side is the good side - or if you doubt that there is such a thing as the "good side" at all? And even if you are sure about that, there are plenty of areas which are more blurred. What if you work for a for profit company building weapons, and selling to anyone they can legally sell to (and then still profiting from money trickling through from illegal sales through weapon smuggling)? Which of these is ethical? I find it very hard to tell for myself, which is why I'd rather opt not to make these decisions, and prefer to stay out of that industry altogether (which turns out not to be as easy as it sounds - I work in game development, and these days there is a very big market in selling game tech the defense industries for simulation purposes).
I was just having a look at the *official" North Korean website and did a whois on it. Interestingly the domain was registered in Spain:
Registrant:
korea-dpr.com #29996
Alejandro Cao de benos de Les Perez (vientian@hotmail.com)
This Alejandro Cao de benos de Les Perez guy is apparently one of very few foreign supporters of North Korea, who has been enthusiastic enough to work his way up to having an official position of representing the country online, and running the official web site. He used to have a forum on that site, where they five other foreign supporters of DPRK could write about their love for the dear leader, but it has been closed down a couple of years ago. Maybe it was too much work keeping it clean from critical voices and trolld.
Look at the smartcar, in Europe it sold NEW for the base model for $5500-6500US when it hit here it sold for $17,500 for the base model and it's gas mileage dropped drastically because they had to add "safety features" that are useless.
Uhm. I'd be very surprised if you can get a new smart car in Europe for $5500-6500US. I just checked the web site, the list price in germany is 10190 EUR for the base model (= USD 14043).
NaCL is no good because it is tied to x86. The web is about openness and platform-independence, and NaCl is a step backwards. In this respect it is worse than Java and worse than Flash; it is more like slightly improved ActiveX.
NaCl is not tied to x86, even in it's current form. Currently, NaCl comes with compilers for x86, AMD64 and ARM. However, this should only be seen as an intermediate step, as the long term plans for NaCl is PNaCl ("Portable NaCl"), which uses LLVM bit code instead of architecture specific machine code. I think this makes much more sense then either WebGL or JavaScript in terms of openness of the web, as it will essentially allow developers to create web apps in any language of their choosing, instead of forcing JavaScript as "the one language of the web" onto everyone.
On the technical side, NaCl code is generally more performant then ActionScript, as it does not have to go through high-level language constructs, plus the Stage 3D API does not offer all the functionality of OpenGL ES 2.0 offered in NaCL (more limited shader complexity).
NaCl is also open source, which makes it a standard I'd much rather like to see on the web then Flash (especially with Adobe needing to find ways to actually monetize this, as third-party game engines will not actually generate sales for Adobe's authoring tools).
The thing right now is that neither WebGL nor NaCl can beat the current availability of Flash (98% browser penetration on desktops is hard to beat). I'm hoping to see that change, but Adobe is in a strong position right now.
That said, I definitely see a big potential and momentum in HTML5/WebGL, but it will not replace Flash in quite some time. Even though you can argue that HTML5/WebGL is roughly comparable in features to Flash, there will be a few more years until the toolsets and frameworks on top of it has matured. Here, I would be surprised if Adobe didn't play a role as well - gradually supporting HTML5 more and more in their products.
WebGL looks promising, but is not nearly as far as flash in terms of performance and compatibility right now. Right now Flash's offering looks very promising indeed, but also gets me worried about keeping a significant part of the web experience under proprietary control. I have more hopes for Google Native Client then for WebGL to become a serious competitor for the time being. NaCl is fast, open source, and ultimately, with the prospect of PNaCl which runs LLVM byte code, more open then any of the other solutions, as it basically allows developers to use any tools they like to create software, as long as there is an LLVM frontend for the language of your choice. Yes, you can also use an LLVM backend to cross compile other languages into JavaScript or Flash, but it seems much more sensible to use the lowest common denominator to build your platform on, instead of cross compiling into high-level-languages.
If you write a browser based HTML5 game then there is nothing you can do, it's open source. All your content, code, everything is available to anyone and everyone.
I just can't see how that model can survive. If you write a popular game there will be 50 Chinese clones popping up within days.
Whatever your build process is, you'd always have some post processing of the JS code. Both, to obfuscate it, and to make the size smaller - there is no need to keep whitespace, line breaks, and multi-character function or variable names in shipping code. That makes your code not much more readable then machine generated code from other languages.
You can go a step further and actually machine generate your java script from other languages. Makes sense when you have existing code to support. Check out Emscripten or Mandreel for JavaScript LLVM backends, which can be used to output javascript from your C++ code.
Basically, a German authority for privacy rights has recently claimed that embedding a Facebook "Like" button on your web site is a violation of german privacy rights, because it allows tracking of all users of the web site by a third party. According to the article, having a "Like" button on your site can yield in fines up to EUR 50k. This is probably technically and legally correct, I doubt that anyone would actually be sued any time soon, though. But the headline has made a big splash on the german internet in the last weeks, and I'd assume that heise's move is a direct reaction to this (which is mentioned in the document as a possibly legal way to have a Like button on your web site).
I second that. Here in Germany, and probably also in any university elsewhere in Europe, a CS course will be about CS. It may contain classes from related subjects as Maths, or Economics (if the course is more business oriented), but no such "general" Education as you mentioned. Also it probably won't teach you to be a good programmer, as many people pointed out.
5 years? A desktop hard drive maybe. Apple's laptop hard drives die fairly reliably like 2ish years out. I've never seen one last longer than 3 years, although I've seen some fail in year 1.
You seem to be having bad luck there, or just mistreating your computers very badly. I've been using Apple notebooks for 17 years now, and only once had to replace a hard disk during all those years. In fact that 17 year old PowerBook 520 still runs just fine (if connected to the power supply).
I did have several other hardware issues though, like the screen falling off on the Titanium Powerbook, etc, etc, so the machines are certainly not flawless.
Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one. That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.
While it may look like this short term, fragmentation is not the goal. Currently, NaCl has compilers for x86, x64 and arm, and in most cases code working on one should compile and work on the others without changes. Long term, the idea is to use LLVM bytecode to solve this problem for all architectures. As for browser compatibility, Google is actively encouraging other browser makers to pick up the tech, which is all open source.
While JavaScript may have it's use, it's going to be a while before the next high performance killer app/game/whatever is written in it. Since Chrome OS will be browser only, they need some lower level tech to run apps on it.
NaCl in it's current implementation is not JIT compiled. It is actual compiled native x86 (or x64 or arm) code running in a secure sandbox. What causes a delay is the Validation of the code, ie, the code has to meet certain requirements to be secure. That said, Google has plans for PNaCl, "portable" nacl, which indeed uses LLVM bytecode, making it a JIT implementation. Why not just use JavaScript? Having access to a lower level language and to being able to reuse tons of existing code is a big plus. Think porting existing game engines to the web.
It usually is km/l in Europe. The only notable exceptions i've heard was with the VW Lupo and this, i guess their marketing department thinks it sounds better.
Actually, it varies by country. While some european countries may use km/l, Germany has traditionally always used l/100km. In any case, it's all just conventions, and any of them is as convenient as another one, it's just a matter of what you are used to.
Have you been to Germany? Yeah, try 8% or 9% depending on whether your Luthern or Catholic.
Uhm. It's actually 8-9% on the amount of income tax you pay, not on the income. So, depending on your income, it can still be significantly higher then the rate quoted for Finland, but not as much as you make it sound.
This is correct - and it is the reason (or at least a reason) that our passports have had the mentioned RFID chips for a handful of years now. However, what is new is that the national ID cards will have the same RFID chip implanted. These will not let you travel to the US anyways, and are much more commonly carried around by people in everyday situations.
Apple's TOS for the iPhone don't care what language you write your app in just so long as it compiles to native machine code for the A4 processor.
From the TOS:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
even I don't have time to answer all the emails I get... Just sayin'.
Because some people report their emails get replied to by Steve, that does not mean that he takes the time to answer all the emails he gets, either. It's just that all those stories where people sent an email to Steve and did not get a reply never made it to slashdot.
It's clearly said that you can't just do a == on floating point numbers, why would you think this does not apply to your unit tests just as much?
I never said so. However, rounding errors may add up, and an epsilon test which passes on one platform may fail on another. Or operations which use floating points and convert results to integers may yield different results. One case where we ran into this where the DXT texture compression libraries from ATI, which use some floating point math internally, resulting in (slightly) different output textures on mac and windows.
(Not to mention that your unit tests are obviously not testing what you want, because if they did a failing test means: you _can't_ use floating point for your problem and you have to rewrite your code to not use it).
No, it just means that the tests needed to accept a wider range of valid results.
Slashdot Mirror
Porting is a lot more than graphics. If you can change to Linux audio/keyboard/mouse support or screen/viewport configurations by the click of a button, I want that button.
Get Unity 4 when it comes out, and you will have that button. Unity abstracts all of what you listed, so you won't have to deal with any of it when developing games in Unity.
But Unity (the game engine) is actually just called "Unity", and not "Unity3d". The latter is commonly used to refer to it, because the website is unity3d.com, but the product is simply called "Unity", so the headline is correct in that sense. I guess it could have been more explicit by mentioning the words game engine in the title, though.
Unity on Linux will be a native Linux binary. For games designed to run on desktop systems, the porting "effort" should be no more then clicking a button -- unless you use custom C++ libraries. All the game logic in Unity is implemented in mono bytecode, and the graphics already use OpenGL on OSX (you generally don't need to write platform specific shaders in Unity, as shaders are cross compiled to the target platform).
In any case, if I were you... and I'm not... I would find a field in which you are challenged and valued. Obviously don't go working for demons, but possibly tone down your standards to something a bit more practical. You are not living in a world of saints. We're simply people. We're not entirely good or bad. We simply are. Try to accept that without holding people to unreasonable standards.
The question is, however, what are "reasonable standards"? Where do you draw the line? And this is very hard to tell because the lines are always blurry. The submitter said he does not want to work for the defense industry and you argue that defense is net positive. The thing is, it's hard to tell, and totally pov. Is working for a weapons smuggler selling weapons to Taliban fighters ethical? If you believe that the Taliban are the good side, then probably. Is doing software consulting as a contractor for any western army ethical? Equally if you believe that they are the good side, then probably. But what if you're not sure which side is the good side - or if you doubt that there is such a thing as the "good side" at all? And even if you are sure about that, there are plenty of areas which are more blurred. What if you work for a for profit company building weapons, and selling to anyone they can legally sell to (and then still profiting from money trickling through from illegal sales through weapon smuggling)? Which of these is ethical? I find it very hard to tell for myself, which is why I'd rather opt not to make these decisions, and prefer to stay out of that industry altogether (which turns out not to be as easy as it sounds - I work in game development, and these days there is a very big market in selling game tech the defense industries for simulation purposes).
Problem with that is that I'd be able to get any web site taken down by paying people to send around a little spam linking to it :)
I was just having a look at the *official" North Korean website and did a whois on it. Interestingly the domain was registered in Spain:
Registrant:
korea-dpr.com #29996
Alejandro Cao de benos de Les Perez (vientian@hotmail.com)
This Alejandro Cao de benos de Les Perez guy is apparently one of very few foreign supporters of North Korea, who has been enthusiastic enough to work his way up to having an official position of representing the country online, and running the official web site. He used to have a forum on that site, where they five other foreign supporters of DPRK could write about their love for the dear leader, but it has been closed down a couple of years ago. Maybe it was too much work keeping it clean from critical voices and trolld.
Wikipedia: http://en.wikipedia.org/wiki/Alejandro_Cao_de_Benos_de_Les_y_Pérez
Look at the smartcar, in Europe it sold NEW for the base model for $5500-6500US when it hit here it sold for $17,500 for the base model and it's gas mileage dropped drastically because they had to add "safety features" that are useless.
Uhm. I'd be very surprised if you can get a new smart car in Europe for $5500-6500US. I just checked the web site, the list price in germany is 10190 EUR for the base model (= USD 14043).
NaCL is no good because it is tied to x86. The web is about openness and platform-independence, and NaCl is a step backwards. In this respect it is worse than Java and worse than Flash; it is more like slightly improved ActiveX.
NaCl is not tied to x86, even in it's current form. Currently, NaCl comes with compilers for x86, AMD64 and ARM. However, this should only be seen as an intermediate step, as the long term plans for NaCl is PNaCl ("Portable NaCl"), which uses LLVM bit code instead of architecture specific machine code. I think this makes much more sense then either WebGL or JavaScript in terms of openness of the web, as it will essentially allow developers to create web apps in any language of their choosing, instead of forcing JavaScript as "the one language of the web" onto everyone.
On the technical side, NaCl code is generally more performant then ActionScript, as it does not have to go through high-level language constructs, plus the Stage 3D API does not offer all the functionality of OpenGL ES 2.0 offered in NaCL (more limited shader complexity).
NaCl is also open source, which makes it a standard I'd much rather like to see on the web then Flash (especially with Adobe needing to find ways to actually monetize this, as third-party game engines will not actually generate sales for Adobe's authoring tools).
The thing right now is that neither WebGL nor NaCl can beat the current availability of Flash (98% browser penetration on desktops is hard to beat). I'm hoping to see that change, but Adobe is in a strong position right now.
That said, I definitely see a big potential and momentum in HTML5/WebGL, but it will not replace Flash in quite some time. Even though you can argue that HTML5/WebGL is roughly comparable in features to Flash, there will be a few more years until the toolsets and frameworks on top of it has matured. Here, I would be surprised if Adobe didn't play a role as well - gradually supporting HTML5 more and more in their products.
WebGL looks promising, but is not nearly as far as flash in terms of performance and compatibility right now. Right now Flash's offering looks very promising indeed, but also gets me worried about keeping a significant part of the web experience under proprietary control. I have more hopes for Google Native Client then for WebGL to become a serious competitor for the time being. NaCl is fast, open source, and ultimately, with the prospect of PNaCl which runs LLVM byte code, more open then any of the other solutions, as it basically allows developers to use any tools they like to create software, as long as there is an LLVM frontend for the language of your choice. Yes, you can also use an LLVM backend to cross compile other languages into JavaScript or Flash, but it seems much more sensible to use the lowest common denominator to build your platform on, instead of cross compiling into high-level-languages.
If you write a browser based HTML5 game then there is nothing you can do, it's open source. All your content, code, everything is available to anyone and everyone.
I just can't see how that model can survive. If you write a popular game there will be 50 Chinese clones popping up within days.
Whatever your build process is, you'd always have some post processing of the JS code. Both, to obfuscate it, and to make the size smaller - there is no need to keep whitespace, line breaks, and multi-character function or variable names in shipping code. That makes your code not much more readable then machine generated code from other languages.
You can go a step further and actually machine generate your java script from other languages. Makes sense when you have existing code to support. Check out Emscripten or Mandreel for JavaScript LLVM backends, which can be used to output javascript from your C++ code.
Some missing context: http://www.kreativ-ackern.de/2011/08/20/gefaellt-mir-facebook-dienste-illegal/ (In German).
Basically, a German authority for privacy rights has recently claimed that embedding a Facebook "Like" button on your web site is a violation of german privacy rights, because it allows tracking of all users of the web site by a third party. According to the article, having a "Like" button on your site can yield in fines up to EUR 50k. This is probably technically and legally correct, I doubt that anyone would actually be sued any time soon, though. But the headline has made a big splash on the german internet in the last weeks, and I'd assume that heise's move is a direct reaction to this (which is mentioned in the document as a possibly legal way to have a Like button on your web site).
I second that. Here in Germany, and probably also in any university elsewhere in Europe, a CS course will be about CS. It may contain classes from related subjects as Maths, or Economics (if the course is more business oriented), but no such "general" Education as you mentioned. Also it probably won't teach you to be a good programmer, as many people pointed out.
5 years? A desktop hard drive maybe. Apple's laptop hard drives die fairly reliably like 2ish years out. I've never seen one last longer than 3 years, although I've seen some fail in year 1.
You seem to be having bad luck there, or just mistreating your computers very badly. I've been using Apple notebooks for 17 years now, and only once had to replace a hard disk during all those years. In fact that 17 year old PowerBook 520 still runs just fine (if connected to the power supply).
I did have several other hardware issues though, like the screen falling off on the Titanium Powerbook, etc, etc, so the machines are certainly not flawless.
Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one. That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.
While it may look like this short term, fragmentation is not the goal. Currently, NaCl has compilers for x86, x64 and arm, and in most cases code working on one should compile and work on the others without changes. Long term, the idea is to use LLVM bytecode to solve this problem for all architectures. As for browser compatibility, Google is actively encouraging other browser makers to pick up the tech, which is all open source.
While JavaScript may have it's use, it's going to be a while before the next high performance killer app/game/whatever is written in it. Since Chrome OS will be browser only, they need some lower level tech to run apps on it.
NaCl in it's current implementation is not JIT compiled. It is actual compiled native x86 (or x64 or arm) code running in a secure sandbox. What causes a delay is the Validation of the code, ie, the code has to meet certain requirements to be secure. That said, Google has plans for PNaCl, "portable" nacl, which indeed uses LLVM bytecode, making it a JIT implementation. Why not just use JavaScript? Having access to a lower level language and to being able to reuse tons of existing code is a big plus. Think porting existing game engines to the web.
Facebook has been credited for helping organize regime-ending protests in the country.
How could she have helped organize protests when she has just been born?
It usually is km/l in Europe. The only notable exceptions i've heard was with the VW Lupo and this, i guess their marketing department thinks it sounds better.
Actually, it varies by country. While some european countries may use km/l, Germany has traditionally always used l/100km. In any case, it's all just conventions, and any of them is as convenient as another one, it's just a matter of what you are used to.
Have you been to Germany? Yeah, try 8% or 9% depending on whether your Luthern or Catholic.
Uhm. It's actually 8-9% on the amount of income tax you pay, not on the income. So, depending on your income, it can still be significantly higher then the rate quoted for Finland, but not as much as you make it sound.
Still funny: http://www.youtube.com/watch?v=rjDSY8LczFw
This is correct - and it is the reason (or at least a reason) that our passports have had the mentioned RFID chips for a handful of years now. However, what is new is that the national ID cards will have the same RFID chip implanted. These will not let you travel to the US anyways, and are much more commonly carried around by people in everyday situations.
Apple's TOS for the iPhone don't care what language you write your app in just so long as it compiles to native machine code for the A4 processor.
From the TOS:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
The killbots have a preset kill limit - so he'll just send wave after wave of his men, until they are defeated (as learned from Zap Brannigan).
even I don't have time to answer all the emails I get... Just sayin'.
Because some people report their emails get replied to by Steve, that does not mean that he takes the time to answer all the emails he gets, either. It's just that all those stories where people sent an email to Steve and did not get a reply never made it to slashdot.
It's clearly said that you can't just do a == on floating point numbers, why would you think this does not apply to your unit tests just as much?
I never said so. However, rounding errors may add up, and an epsilon test which passes on one platform may fail on another. Or operations which use floating points and convert results to integers may yield different results. One case where we ran into this where the DXT texture compression libraries from ATI, which use some floating point math internally, resulting in (slightly) different output textures on mac and windows.
(Not to mention that your unit tests are obviously not testing what you want, because if they did a failing test means: you _can't_ use floating point for your problem and you have to rewrite your code to not use it).
No, it just means that the tests needed to accept a wider range of valid results.