I’ve heard Win XP will ship with Ogl 1.2, i.e. through software, not vendor specific implementations. Can anyone confirm this?
I’ve poked around on the M$ sight but could not find anything.
Many thanks for those who reply with pertinent information.
Actually I think it does not support software opengl like previous Windows OS’s. Instead XP supports OpenGL emulation through Direct3D, i.e. a wrapper. But still, even then it must emulate a particular version of OpenGL. I wouldn’t be surprised if it was still 1.1, though would like to know for sure myself.
Of course this not to say it does not also support hardware accelerated OpenGL by way of a vendor’s implementation, it does that too.
[This message has been edited by DFrey (edited 04-17-2002).]
Thanks for the reply. When I get a change, I’ll look harder on the M$ sight to find an answer. If I can find one, I’ll post my results. I going to contact tech support since XP came with my computer.
Information about MS’ abominable OpenGL->D3D Wrapper is here .
I wonder how much effort it took to create this wrapper vs. porting Openg32.dll to XP.
Keeping in mind XP is built on NT and NT has Opengl32.dll.
What a bunch of ****ing crap–just had to say it, please excuse.
The interesting thing is that they obviously made an effort in improving OpenGL under Windows XP (going from SW renderer to a possibly HW accelerated DirectX renderer), but still they didn’t find it fit to go for a newer version of OpenGL. (?!)
If they wanted to go with their motto (promote DirectX, kill OpenGL), they could just have kept the software OpenGL 1.1 renderer from Win2k.
Does anyone understand?
I think so, have Ogl make better use of hardware rendering through the use of DirectX.
If this is correct, then I take back my grrrrrr and foul language comment.
Originally posted by lobstah:
I think so, have Ogl make better use of hardware rendering through the use of Direct.
Better Hardware access through DirectX? You gotta be kidding, right? The best method would be just a vendor-supplied OpenGL driver and in fact tadaa, that’s how it works everywhere else.
Oh well, ‘upgrading’ to XP, hrhrhr.
My experience with “vender drivers” has not been good; they’re buggy. I can take the same code and run it on three different computers, each with a different video card and get three different bugs when hardware accelerated that are not present when sw accelerated.
If M$ approach can make this more bearable, i.e. reliable, then I’m for it. However, I’ve not had good experience with this either.
I have a multi-thread app that works fine with SW rendering and doesn’t work with HW rendering on an XP machine. What the hell?
So, does it really work everwhere else?
And why in the hell should a programmer have to be concerned with the hardware?
Sounds like programming in the 1980’s to me.
As you can tell, I like to concentrate on the app and what it can do instead speading my time working out details that don’t directly pertain to the task at hand.
Don’t be offended by my comments, an API should be an API.
I guess I’m a bit of a purist.
I just don’t see how DirectX is supposed to be any better. It’s just another vendor supplied hardware driver, layered under MS’ libraries. If a vendor makes unbearable OpenGL drivers, chances are that the DirectDraw/Direct3D drivers are just as bad.
Take your chances.
So, how much progress has been made for the programmer?
Hardware is making leaps and bounds.
Oh well, make do with what’s available.
A real bummer.
PS: I’m an opengl fan and don’t care to learn DirectX.
[This message has been edited by lobstah (edited 04-18-2002).]
Whoa, this is the first I’ve heard of this, and I have WinXP. OpenGL works fine for me, but it’s really Direct3D being called from opengl32.dll?
EDIT: Crap. Just looked at opengl32.dll, and there are indeed DirectX function names in there. The OpenGL code I’ve written on Win98 still works on WinXP, and vice versa, but it’s still annoying that I’m limited to Direct3D for execution.
[This message has been edited by CGameProgrammer (edited 04-18-2002).]
No you are not limited to D3D. The emulation is only used if you do not have an accelerated OpenGL implementation for your video card installed, but do have D3D drivers installed. Simply look at your vendor string when you get your render context to see if you are running with Microsoft’s wrapper, or your video card’s OpenGL implementation.
Oh, I see. whew (wipes forehead) I should have read the posts a bit more carefully. I saw DirectDraw functions in opengl32.dll and got worried
I don’t see what the problem is then. I’ve run the software OpenGL on Win98 and it was horrible. Not only was it like 3 fps for 5 triangles, but it looked awful. The backup OpenGL emulation seems like a good idea.
So what real difference does it make in the end for gl programs? If there is no HW help present, you may take a small performance hit with the gl calls rerouted to the d3d subsystem, and maybe some additional performance loss due to different underlying architecture (although I read MS was trying to make D3D more like gl).
With hardware help it seems to me that if the vendor supplies separate gl and d3d device drivers no harm no foul - but if they supply a single d3d driver you still get access to the full HW functionality via the emulation (with perhaps a small performance hit).
What i read out of all that is that gl code will be very slightly slower than d3d code in all cases, but not much - and a single device driver for a single api is a lot easier to debug and improve than two. In the end, it’s just another lame-ass ploy to take control of the 3d api market (“why use opengl when d3d is closer to the hardware” kinda thing), but it doesn’t really affect the code that much. If emulation is complete (which it must be) then we can still use all of the gl tricks i used in the past that d3d can’t do. It’s lame, but if it really bugs you you can get around it by using another gl implementation.
Or am i way out of line here and not seeing the picture clearly?