And how is this useful for the large bulk of embedded applications?
C'mon- most people aren't going to be using Office on their Heart monitor or the traffic light controller. (Or, for that matter, your fly-by-wire avionics or drive-by-wire automotive controls!!)
I can assure you that there's patent coverage within that space that Microsoft holds ownership on.
Quickest way to see to it that you get sued over infringement, I'd say.
As it stands, having asset tool middleware isn't anything special- there's other toolchains for that available that everyone else seems to be using. I'll also note that unless you're talking a casual game or a specific range of games that would be good on a console, desktop, and handheld, you're unlikely to be concerning yourself with this sort of thing- and there's better tools that're cross platform in the way he was alluding that would do as good or better a job without being bound tightly to Microsoft.
A developer should realize that XBox isn't the only console, Windows isn't the only desktop- and there sure as hell aren't anywhere near as many WinMo devices that could ever take advantage of this. It's an attempt to show WinMo as "relevant" still- count the number of WinMo devices coming out and then contrast that with how many Android/Maemo(MeeGo?)/etc. devices are coming out with proper 3D support.
When you start adding it all up, doing XNA's limiting in ways you don't want to do unless you're explicitly targeting XBox and Windows alone with no aspirations whatsoever for other consoles or the bulk of the current smartphone space.
And there's the ability to make the application in.Net be pure native- something much like GCJ does for Java.
If you did a pure managed code version of a game with.Net/XNA, you'd have some of the same sorts of "fun" the Java stuff has. Keep in mind, though, you CAN make good games in Java- it's just harder and the limit ceiling on what you can/can't do is lower with it unless you build it to native with something like GCJ.
If you've written it right with the right abstractions for key pieces of the rendering, input, sound, etc. subsystems- YES.
If you've written it right by choosing OpenGL/OpenGL ES and then the other pieces picking things like FMOD, OpenAL, Miles, etc., you'll be able to target Windows, and probably the others- 3D would be "interesting" for the XBox (you'd need an OpenGL wrapper or abstract out the 3D rendering path...) but the rest would just drop on. Keep in mind, OpenGL ES is available in hardware accelerated fashion on any WinMo device that has a GPU on it and the rest is largely taken care of by the other 3rd party middleware.
Depending on the title, it may be realistic to make the game for all platforms, but in the end, most console titles aren't practical to put onto a handheld (I mean, c'mon, Infamous on a mobile phone? Fallout3?) and most handheld titles are only peripherally realistic to make for console and desktop. The only games I know of that'd be worth going that route would be things like Caster, Cortex Command, Osmos, etc.- all of those are indie titles and most of them did it with one of the above mentioned ways of going about things. It should be noted that Caster's already on the iPhone and on it's way to other mobile platforms. Caster3D for Linux will play on most of the Linux based netbooks, and the original eeePC 701 with the latest cuts of things like Ubuntu NBR.
You can't say the same thing about the XNA route. You're stuck with just Windows, XBox 360, and when the 3D stacks propagate to the SoC's, WinMo with that route. Doing it in one of the two previously mentioned routes will ensure being able to run on the following:
Windows MacOS Linux X86 Linux ARM (The following 3 are specialized versions of the above...) Android WebOS MeeGo PS3 Wii (If you're clever, you can even target XBox 360...)
Whereas if you use XNA, you'll be able to only target:
Windows XBox 360 WinMo
WinMo's struggling to stay relevant and this is a piece of MS trying to keep it so. Count how many WinMo devices are coming out and how many Android/MeeGo/WebOS devices are coming out or are already delivered for this season...
The "embedded" OS that they slapped their trademark on is rather not suitable for a large line of embedded tasks. Same goes for Embedded XP, etc. It's only sort-of useful on PDA's and somewhat painful at times on mobile phones. And, before you remark, I should point out that I do embedded development for a living.
I would have to concur with your assertion of "bias" on the GP poster's part, but I would say that the current crop of Maemo, Android, etc. phones do seem to work more along expected lines and seem to better match "just work" than most. The same could probably be said for the iPhone, but it's got it's own set of issues too.
As for "Outlook/Activesync integration", that may be a good thing for you, but for myself and a lot of other people, that's a negativ, not a positive- not that I think that any of the Android phones don't have conduits for that support, mind. It's also worth mentioning that there's an App Store for the Android, but it doesn't have a censorship board like the iPhone seems to have.
In the end, each is going to have their own opinions on this subject- and your ideas aren't going to mesh up with mine or most anyone else's on it.
Considering that you're not talking about a wrapper, per se, but rather an API layer that's similar enough to the Windows one that you can just drop an application on and run it.
Nice idea, but there's a minefield that won't get fixed unless the SCOTUS deep-sixes most software patents. You're going to touch on something that will most definitely infringe on one of MS' patents doing this sufficient to play games with. As such, it's kind of worthless to go there.
You've got PowerVR, Tegra, Imageon (whatever Qualcomm's calling it now...), and Mali, all of which are very credible GPUs for mobile 3D support, all of which have SoC's in play or about to be with them in there. The one thing common to all of them? They're all using OpenGL ES right now.
If you'd drop the "casual" from the statement, it'd also be fairly accurate.
I do know that in the large the casual/indie space are using OGG as the format- it's more to avoid the per-unit royalties that the "superior" formats charge, but if it were as all bad as the article author makes it out to be I can assure you that they'd not be using it.
They're already culturing meat tissues in the lab, so why not? The only thing would be that you'd need a starter culture of cells to do that- where would THAT come from?
It's true that it's a myth, after a fashion. You CAN get away (magic words there) with a lot more sugar than most people think when you say "diabetic".
But it makes management much, much easier for type I and type II if you avoid consumption of excess sugar in your diet. You'll need less insulin if you're a type I and you might even not need much in the way of meds if you're a type II. It should also be worth noting that just because you're compensating for things with the meds, it doesn't regulate your sugars as well as a properly functioning body would do- you have spikes and valleys in your blood sugar- eating a bunch of sugars will cause a spike. The more of those you do to yourself, the more likely you are to develop the co-morbidities that come with Diabetes and unchecked sugars. In the end, I'll regulate my sugar intake and do without things, thank you very much...
If you can print new ones, you should be able to scan things appropriately and print them. Many copiers now do things that way- scan with an imaging device and then print what was scanned.
In light of the facts behind how the Government has ran the public option it HAS had (Medicare) which is a source of many of the ills they're trying to fix...you might not want them doing what you think you do.
If I thought that they'd handle it right, I'd be all for the public option. As it stands, they've shown us for years that they CAN'T really handle it in a manner that would help the problems.
The administrative overhead imposed by Medicare and the private market health insurance in the USA is a big problem, indeed.
FTFY.
The private market insurance companies tend to only pay out 20-30% over what Medicare pays out. Sometimes Medicare does amazing things. Other times, they'll deny things that just don't make any sense whatsoever. A procedure that legitimately costs somewhere around $1500-2000 can expect to get paid out something like $300-500 at best from Medicare in most cases.
Remember my earlier remark? The private insurance companies pay out only about 20-30% more than than on most items.
While I'm all for a public option, I can't envision it being a good thing with the way we're currently running the public option for the elderly and the indigent (Medicaid...).
Actually, that would be closer than you'd think to the truth. They did a lot of all of this themselves and the upper management couldn't think past their core business, copiers, for the longest time.
As it stands, they can't seem to get the gem of print tech in the form of solid ink past a few models in their lineup- and while they've got a compelling story on it with price, ink, etc. such that it is actually largely better than color/b&w lasers and competitive with inkjets- you pretty much won't find one anywhere save online through them or through their reseller channel.
It's not their engineering, it's the upper management- and this lawsuit shows they still don't "get it".
They make the current incarnation of the solid ink printer tech that got bought off of Tektronix, amongst other things.
Solid ink produces much sharper results than color laser printers and seems like an overall win, but for some odd reason, while they've got units with price points that are reasonable (same basic pricing as comparable laser printers...), you just can't find them except through their reseller channels or online.
I'd have to concur with your and the GP poster's assessment on this.
I'm not cutting them any slack. Roughly 7+ years to determine if they're infringing and not enforcing their rights is a bit beyond the pale and is very probably subject to equitable estoppel out of the gate. They very probably shouldn't have ran this one up the flagpole in the first place- and it's very, very patent-trolly. Patent trolls do not get an out no matter what their past contributions might have been.
Actually, no, you can't sit on it and expect to be able to enforce it like you imply.
You don't lose the patent like you do with Trademark- but if you delay, the range of things that ends up happening goes from no damages to an inability to enforce against the infringers that you didn't enforce against during the time you "sat on it". Subsequent infringers can be enforced against during the life of the patent- but not the others if you delay any substantive time on it from the moment that the infringement becomes obvious to you or should have been so.
Actually... This is the same problem. The API's provide what was available in hardware support when it was there for that version. There's hardware that isn't present in the iPhone when compared to what the GS offers- do you expect something that the GS provides to work with the iPhone? No? What's the difference here?
In the end, some pundit's opening his mouth, not realizing that the "incompatibilities" are more due to hardware choices coming out and the fact that there's been a few rapid revs so there's "issues" with some of the apps out there. Something designed for 1.6 will work in 2.0, but not the other way around- and it's the same with WinMo, Maemo/MeeGo, iPhone, etc. It doesn't matter if it's open source or closed source.
Slashdot Mirror
It's not so much that they own them, it's that they're more likely to do STUPID things with them- more often than not with rather lethal consequences.
And how is this useful for the large bulk of embedded applications?
C'mon- most people aren't going to be using Office on their Heart monitor or the traffic light controller. (Or, for that matter, your fly-by-wire avionics or drive-by-wire automotive controls!!)
No, they can't.
I can assure you that there's patent coverage within that space that Microsoft holds ownership on.
Quickest way to see to it that you get sued over infringement, I'd say.
As it stands, having asset tool middleware isn't anything special- there's other toolchains for that available that everyone else seems to be using. I'll also note that unless you're talking a casual game or a specific range of games that would be good on a console, desktop, and handheld, you're unlikely to be concerning yourself with this sort of thing- and there's better tools that're cross platform in the way he was alluding that would do as good or better a job without being bound tightly to Microsoft.
A developer should realize that XBox isn't the only console, Windows isn't the only desktop- and there sure as hell aren't anywhere near as many WinMo devices that could ever take advantage of this. It's an attempt to show WinMo as "relevant" still- count the number of WinMo devices coming out and then contrast that with how many Android/Maemo(MeeGo?)/etc. devices are coming out with proper 3D support.
When you start adding it all up, doing XNA's limiting in ways you don't want to do unless you're explicitly targeting XBox and Windows alone with no aspirations whatsoever for other consoles or the bulk of the current smartphone space.
Heh...
CIL != Java's VM, just for starters.
And there's the ability to make the application in .Net be pure native- something much like GCJ does for Java.
If you did a pure managed code version of a game with .Net/XNA, you'd have some of the same sorts of "fun" the Java stuff has. Keep in mind, though, you CAN make good games in Java- it's just harder and the limit ceiling on what you can/can't do is lower with it unless you build it to native with something like GCJ.
I believe that Oddlabs would beg to differ with you on that score.
Tribal Trouble's actually a nifty and very playable game- and it's written in Java.
If you've written it right with the right abstractions for key pieces of the rendering, input, sound, etc. subsystems- YES.
If you've written it right by choosing OpenGL/OpenGL ES and then the other pieces picking things like FMOD, OpenAL, Miles, etc., you'll be able to target Windows, and probably the others- 3D would be "interesting" for the XBox (you'd need an OpenGL wrapper or abstract out the 3D rendering path...) but the rest would just drop on. Keep in mind, OpenGL ES is available in hardware accelerated fashion on any WinMo device that has a GPU on it and the rest is largely taken care of by the other 3rd party middleware.
Depending on the title, it may be realistic to make the game for all platforms, but in the end, most console titles aren't practical to put onto a handheld (I mean, c'mon, Infamous on a mobile phone? Fallout3?) and most handheld titles are only peripherally realistic to make for console and desktop. The only games I know of that'd be worth going that route would be things like Caster, Cortex Command, Osmos, etc.- all of those are indie titles and most of them did it with one of the above mentioned ways of going about things. It should be noted that Caster's already on the iPhone and on it's way to other mobile platforms. Caster3D for Linux will play on most of the Linux based netbooks, and the original eeePC 701 with the latest cuts of things like Ubuntu NBR.
You can't say the same thing about the XNA route. You're stuck with just Windows, XBox 360, and when the 3D stacks propagate to the SoC's, WinMo with that route. Doing it in one of the two previously mentioned routes will ensure being able to run on the following:
Windows
MacOS
Linux X86
Linux ARM
(The following 3 are specialized versions of the above...)
Android
WebOS
MeeGo
PS3
Wii
(If you're clever, you can even target XBox 360...)
Whereas if you use XNA, you'll be able to only target:
Windows
XBox 360
WinMo
WinMo's struggling to stay relevant and this is a piece of MS trying to keep it so. Count how many WinMo devices are coming out and how many Android/MeeGo/WebOS devices are coming out or are already delivered for this season...
And there's Caster3D on the iPhone and soon other mobile platforms...other than WinMo, that is... ;-D
The "embedded" OS that they slapped their trademark on is rather not suitable for a large line of embedded tasks. Same goes for Embedded XP, etc. It's only sort-of useful on PDA's and somewhat painful at times on mobile phones. And, before you remark, I should point out that I do embedded development for a living.
I would have to concur with your assertion of "bias" on the GP poster's part, but I would say that the current crop of Maemo, Android, etc. phones do seem to work more along expected lines and seem to better match "just work" than most. The same could probably be said for the iPhone, but it's got it's own set of issues too.
As for "Outlook/Activesync integration", that may be a good thing for you, but for myself and a lot of other people, that's a negativ, not a positive- not that I think that any of the Android phones don't have conduits for that support, mind. It's also worth mentioning that there's an App Store for the Android, but it doesn't have a censorship board like the iPhone seems to have.
In the end, each is going to have their own opinions on this subject- and your ideas aren't going to mesh up with mine or most anyone else's on it.
Considering that you're not talking about a wrapper, per se, but rather an API layer that's similar enough to the Windows one that you can just drop an application on and run it.
Nice idea, but there's a minefield that won't get fixed unless the SCOTUS deep-sixes most software patents. You're going to touch on something that will most definitely infringe on one of MS' patents doing this sufficient to play games with. As such, it's kind of worthless to go there.
The landscape's a bit more varied than that...
You've got PowerVR, Tegra, Imageon (whatever Qualcomm's calling it now...), and Mali, all of which are very credible GPUs for mobile 3D support, all of which have SoC's in play or about to be with them in there. The one thing common to all of them? They're all using OpenGL ES right now.
If you'd drop the "casual" from the statement, it'd also be fairly accurate.
I do know that in the large the casual/indie space are using OGG as the format- it's more to avoid the per-unit royalties that the "superior" formats charge, but if it were as all bad as the article author makes it out to be I can assure you that they'd not be using it.
They're already culturing meat tissues in the lab, so why not? The only thing would be that you'd need a starter culture of cells to do that- where would THAT come from?
It's true that it's a myth, after a fashion. You CAN get away (magic words there) with a lot more sugar than most people think when you say "diabetic".
But it makes management much, much easier for type I and type II if you avoid consumption of excess sugar in your diet. You'll need less insulin if you're a type I and you might even not need much in the way of meds if you're a type II. It should also be worth noting that just because you're compensating for things with the meds, it doesn't regulate your sugars as well as a properly functioning body would do- you have spikes and valleys in your blood sugar- eating a bunch of sugars will cause a spike. The more of those you do to yourself, the more likely you are to develop the co-morbidities that come with Diabetes and unchecked sugars. In the end, I'll regulate my sugar intake and do without things, thank you very much...
If you can print new ones, you should be able to scan things appropriately and print them. Many copiers now do things that way- scan with an imaging device and then print what was scanned.
ARM's not VLIW.
In light of the facts behind how the Government has ran the public option it HAS had (Medicare) which is a source of many of the ills they're trying to fix...you might not want them doing what you think you do.
If I thought that they'd handle it right, I'd be all for the public option. As it stands, they've shown us for years that they CAN'T really handle it in a manner that would help the problems.
FTFY.
The private market insurance companies tend to only pay out 20-30% over what Medicare pays out. Sometimes Medicare does amazing things. Other times, they'll deny things that just don't make any sense whatsoever. A procedure that legitimately costs somewhere around $1500-2000 can expect to get paid out something like $300-500 at best from Medicare in most cases.
Remember my earlier remark? The private insurance companies pay out only about 20-30% more than than on most items.
While I'm all for a public option, I can't envision it being a good thing with the way we're currently running the public option for the elderly and the indigent (Medicaid...).
How about both? I would take the beer over the bug report any day myself- but I'll take the beer and the people helping me find the flaws every day.
Actually, that would be closer than you'd think to the truth. They did a lot of all of this themselves and the upper management couldn't think past their core business, copiers, for the longest time.
As it stands, they can't seem to get the gem of print tech in the form of solid ink past a few models in their lineup- and while they've got a compelling story on it with price, ink, etc. such that it is actually largely better than color/b&w lasers and competitive with inkjets- you pretty much won't find one anywhere save online through them or through their reseller channel.
It's not their engineering, it's the upper management- and this lawsuit shows they still don't "get it".
They make the current incarnation of the solid ink printer tech that got bought off of Tektronix, amongst other things.
Solid ink produces much sharper results than color laser printers and seems like an overall win, but for some odd reason, while they've got units with price points that are reasonable (same basic pricing as comparable laser printers...), you just can't find them except through their reseller channels or online.
I'd have to concur with your and the GP poster's assessment on this.
I'm not cutting them any slack. Roughly 7+ years to determine if they're infringing and not enforcing their rights is a bit beyond the pale and is very probably subject to equitable estoppel out of the gate. They very probably shouldn't have ran this one up the flagpole in the first place- and it's very, very patent-trolly. Patent trolls do not get an out no matter what their past contributions might have been.
Actually, no, you can't sit on it and expect to be able to enforce it like you imply.
You don't lose the patent like you do with Trademark- but if you delay, the range of things that ends up happening goes from no damages to an inability to enforce against the infringers that you didn't enforce against during the time you "sat on it". Subsequent infringers can be enforced against during the life of the patent- but not the others if you delay any substantive time on it from the moment that the infringement becomes obvious to you or should have been so.
I don't see Xerox intending on doing an internet search engine...ever. So, you're kind of wrong on that count.
Oh, it trimmed my link out for some bizarre reason...
Here it is: http://www.casterthegame.com/
Actually... This is the same problem. The API's provide what was available in hardware support when it was there for that version. There's hardware that isn't present in the iPhone when compared to what the GS offers- do you expect something that the GS provides to work with the iPhone? No? What's the difference here?
In the end, some pundit's opening his mouth, not realizing that the "incompatibilities" are more due to hardware choices coming out and the fact that there's been a few rapid revs so there's "issues" with some of the apps out there. Something designed for 1.6 will work in 2.0, but not the other way around- and it's the same with WinMo, Maemo/MeeGo, iPhone, etc. It doesn't matter if it's open source or closed source.