Yes. A significant number of early adopters are gamers wanting dx10 graphics. Hard to believe, but you should see the garbage being talked about “dx10 graphics” on the gaming sites and magazines.
Well, if OpenGL 3.0 was released two years ago, such that current engines would make use of it and thus allow DX10 features on XP, Vista adoption (among gamers) might indeed be slower.
But no matter whether OpenGL 3.0 will be out in a week or in six months or even later, it won’t have any effect anymore.
Jan.
Then microsoft’s delaying tactics have succeeded.
what has MS got to do with this? o.O
Nothing bob, nothing at all.
Are you looking forward to the easter bunny delivering your eggs?
…
now how about you answer my question as to what delaying tactics?
ok, you appear to have a sense of humour block.
it’s just conjecture bob, there’s no evidence of delaying tactics, just as there’s no evidence for any other suggestion made in this thread. It’s a guessing game, but microsoft have more motivation to delay the spec than anyone else. If I were them I’d be delaying it, just as if I were a multi-millionaire paedophile like Michael Jackson I’d build a fairground in my garden.
It was supposed to be a short and perfectly serious topic, but that didn’t work.
Probably because there was nothing to say in this topic. Nothing at all.
So now we’re pretty much off-topic.
So sense of humor is the basic requirement for anyone who wants to post in this thread. We gonna keep posting nonsense untill we produce so many posts that we all rise to ranks of “OpenGL Gurus” and “OpenGL Lords”. Maybe then we will be taken more seriously.
Right now there’s not much to talk about - no new extensions recently and no new OpenGL version.
So back to pointless talk:
No they won’t. The’ll never buy the ACME corporation.
Right, because it has already been bought by Mr. Burns…
sigh
My sense of humor is just fine, however when someone mentions ‘delaying tactics’ with regards to a company who have nothing todo with the OpenGL spec having pulled out of the ARB some time ago AND given the previous post were about Vista asking what MS had to do with it would seem a logical question… now, if you had just said ‘nothing, it was just a (poor) joke’ then no problem, as it was you posted that and THEN followed it up with a remark designed, imo, to indicate I was living in a fantasy world of a child and would never suspect MS of such a thing, thus my request for clafication.
All this proves is that ‘joking’ without smilies or any of the other clues which you get IRL is just a bad idea…
sigh
Bob, the fact the microsoft is not a member of the ARB is irrelevant. They basically have nvidia, ati and intel by the balls. They have us all by the balls, truth be known. If microsoft wanted to delay the GL3 spec, they could without any difficulties at all. I just proposed that they had, as a possible explanation for this otherwise unexplainable delay in a spec (let alone implementations).
Yeah, I know we’re way off topic and I don’t mind, but why is it that every time we go off-topic somebody mentions Microsoft? 
I’d rather plunge head first into a vat of whale dung than have another tit-for-tat Microsoft conspiracy theory debate (unless complimentary cheese and crackers are served).
Though I suppose it’s true… MS could have us all hopping around on one leg, if they were so inclined.
Concievably, MS could be doing the same thing they’re trying to do to Linux - claiming they have patents, then not saying exactly what those are. Khronos probably takes those sorts of threats more seriously than Linus Torvalds, so they might be doing a search of MS’s entire patent portfolio in order to make sure everything’s in the green.
And for the record, I don’t think that’s actually happening.
No?
http://news.bbc.co.uk/1/hi/business/7266629.stm
They are pretty underhand y’know.
Mapping a lightweight API onto existing DX10 driver entry points shouldn’t take this long.
Maybe it’s because one of the big CPU manufacturers spend all resources fixing a TLB bug and don’t have any time for other things. hehehe Or maybe it’s the other CPU manufacturer torpedoing GL3 because of their cappy on-board accelerators and drivers. hompfh
Hmmm, as regards to my first post I must say, the render-to-texture show was more entertaining… at least, from time to time there was an update. Okay, got somthing to do… starting Duke Nukem Forever install.
the render-to-texture show was more entertaining… at least, from time to time there was an update.
I sat through the “render-to-texture” show, and it was not more entertaining. It was quite a bit worse.
Here, at least we had a full year of information, in 4 newsletters. There, we had maybe a couple of presentations, at most. Here, it’s a totally new API; there, it was just figuring out a way to render to a texture. Here, we still have GL 2.1 to use in the meantime; there, we had pbuffers, which cannot reasonably be called a RTT solution.
The “RTT” show was 10x more embarrassing for the ARB and much more infuriating for those who were waiting on it.
Please cool down 
I was just kidding.
The problem I have with current GL2 is that I spend 20% of my time programming, and 80% of my time in trial and error sessions how a specific driver and card combo behaves…
Take buffer objects we got since 1.5. I have the strong feeling that someone in the ARB thought: “Okay, let’s take a look at D3D… they have working static and dynamic arrays for years, the vendors have working code in the drivers - so let’s build something completely different and reinvent the wheel.” Rendering from buffers and laying out buffers is currently guesswork.
Another sucker are those damn software fallbacks. Guesswork again. Okay, we have render to “something” now… but there is no chance to find out exactly what works, and what works not.
At least for me the guesswork is over… I’m currently switching to D3D. Will give GL (and multiplatform sniff) another try in the next engine version, so maybe in three or four years. [censored] happens.
if I could get quad buffered stereo from d3d, I’d be right with you evilone. Like a shot.
“Okay, let’s take a look at D3D… they have working static and dynamic arrays for years, the vendors have working code in the drivers - so let’s build something completely different and reinvent the wheel.” Rendering from buffers and laying out buffers is currently guesswork.
You’re looking at the problem from the wrong angle. The problem isn’t buffer objects. It’s the mechanism by which they are used. The decision was made to make VBO code resemble as closely as possible regular vertex array code. So they didn’t create a new set of entrypoints for setting up vertex data (unlike ATi’s Vertex Array Object extension). This had the benefit of being able to automatically work with new vertex pointer calls like glVertexAttribPointer.
But it had the problem of forcing an IHV to basically accept, at a low level, any arbitrary set of array bindings. It also forced IHVs to do a lot of setup code on gl*Pointer calls, which would have been more reasonably implemented as an object to store them.
So the problem is mostly that the legacy API kept tripping up what the ARB really wanted to do. Which is what GL 3.0 is all about dealing with.