Is it any more so than anyone elses ramblings?
At least he explained his theory and it makes sense. If MS are going for "forward compatibility" like we've heard his theory is likely to be bang on the money.
There could very well be no direct hardware access, everything will be done through the API* and in the future all games will work on the next (next next etc,) nextxbox.
I understand that some people might not like that, but it's hardly nonsense.
* If it's nonsense, put your theory forward for how they will do it.
Selective reading. What you really are saying is you are ignoring what I said and are giggling at the thought of an Xbox with a bloated MS OS, API that doesn't expose the hardware features or special features (ftl 32MB memory space!), and you, too, cannot do math because you sure like the sound of 2x faster than 50%
Since you glossed over it, explain why taking Tim to task for saying 50% - 2x is nonesense?
Oh wait, you cannot. It was non-sense.
And since I am so dense, please explain why "forward compatibility" means (a) hardware features will not be exposed via the
API (see: Xenos) and (b) why the bloat of a PC API expected to span 3 vendors (AMD, NV, and Intel) and multiple architectures, configurations, and performance classes has any relevance on a console? See, again, Xenos: Thin API targetting one platform; future platforms could use the API calls with a wrapper or a simple API update (if Xbox3 then x; else Xbox4 then y).
In fact, I think the whole "no access to the hardware" and only access to the "API" you propose is pretty much in left field. Tim's own posts mention Orbis using APIs
Xenos and the PS3 use APIs. APIs can expose the hardware features AND be efficient like on the consoles OR on Windows add some overhead, be bloated, and cloak features of specific hardware.
The way you present APIs makes no sense to me; and how Tim presented the situation wasn't the issue of APIs but Tim suggesting Durango would be a full on Windows box with the antecedent bloat.
Which poses a problem in this regards: The 32MB is going to require hands-on programmer attention. That alone indicates it will have a unique API. Which, even if MS is thinking "forward compatibility" they are going to need to expose the 32MB of memory space. How do you defend your's and Tim's view of the API and access to the 32MB? MS dumped compute for a feature not exposed.
Because MS/AMD are idiots, got it.
Which leads to the memory in my previous post. And since you also skipped it, but want to defend his position, what of any benefits of embedded memory? Hmmm.
Yeah, my 3 complaints still stand and you are just throwing words at a wall.