Jump to content
  • Advertisement
Sign in to follow this  
ManaStone

OpenGL OpenGL 2.0 question

This topic is 5047 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Does anyone know the release date for this? Also, I've heard that Microsoft might support an API for it? What are the chances that this will happen?

Share this post


Link to post
Share on other sites
Advertisement
the best MS are saying is an update to 1.2 for Longhorn, which is still a good year or two away.

Everyone should just give up on MS ever updating its libraries/headers... infact, i'd love to know who starts these rumors that they are going to...

Share this post


Link to post
Share on other sites
It doesn't matter what MS does. It'll be supported via extension loading libs anyway. It's mostly already supported, just with an ARB postfix on all the functions.

GLee will have full support for 2.0 core functions as soon as SGI's glext.h is updated.

Share this post


Link to post
Share on other sites
Is is possible to have OpenGL deal directly and only with the graphics driver, and not require the MS OGL library? Like a sorta auto-loading library like GLEW and GLEE, except that it loads all the OpenGL commands, not just the extensions. Is there some hook in to the OS that OGL requires that prevents this?

Share this post


Link to post
Share on other sites
while it might be possible to find some way around the opengl32.dll dependancy its not really worth the hastle of doing so when all you need todo it use an auto-extension loader to deal with things anyways

Share this post


Link to post
Share on other sites
Plus, extensions provide a better means of checking individual caps than core version functions. By relying on say a hacked OpenGL32.dll and using core functions, you'd lose that benefit.

Share this post


Link to post
Share on other sites
You can't avoid OpenGL32.dll, because the driver needs to share the window and framebuffer resources with GDI.

I'd be really scared if Longhorn doesn't support efficient OpenGL surfaces, though, like forcing the driver to blit OpenGL data twice to present it, or something silly like that...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!