Jump to content
  • Advertisement
Sign in to follow this  
Prune

OpenGL OpenGL without windows.h

This topic is 3641 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

How by the rat's ass can I avoid getting windows.h included in every .cpp that uses OpenGL, when building for a Windows system?

Share this post


Link to post
Share on other sites
Advertisement
A couple of the extension loaders do it as well, although I can't remember which ones exactly. I almost always use GLEE though, so that one probably skips Windows.h as well. I think SDL_OpenGL.h might, and I am pretty sure the GLUT header contains all the required definitions. It's not much.

Share this post


Link to post
Share on other sites
SDL_opengl.h: line 32, #include <windows.h>
GLee.h: line 57, #include <windows.h>

GLUT doesn't load most extensions.

For some reason both SDL and GLee use DWORD and VOID etc. crap in the GL function prototypes instead of standard types.

Share this post


Link to post
Share on other sites
Well, yes. If your library communicates directly with the operating system, as OpenGL does, you're pretty much stuck with using the OS. Why do you want to avoid windows.h being included?

Share this post


Link to post
Share on other sites
I'm stuck with using the OS, but since I don't call Windows API functions directly but through the driver, the driver should wrap them and hide such internals.

Including windows.h slows down noticeably compilation speed with Intel's compiler in release builds, even with WIN32_LEAN_AND_MEAN and VC_EXTRALEAN defined. So now I'd have to turn on precompiled headers, and there are various disadvantages to them.

Share this post


Link to post
Share on other sites
Looking for something like that?
Quote:
from: glfw.h
// The following three defines are here solely to make some Windows-based
// <GL/gl.h> files happy. Theoretically we could include <windows.h>, but
// it has themajor drawback of severely polluting our namespace.

Share this post


Link to post
Share on other sites
Looks like GLee.h uses a bunch of Windows defines itself. Here's everything needed in there in place of #include <windows.h>:

// For gl.h
#define APIENTRY __stdcall
#define WINGDIAPI __declspec(dllimport)
// For glu.h
#define CALLBACK __stdcall
//typedef unsigned short wchar_t;
// For GLee.h
typedef void VOID, *LPVOID, *HANDLE;;
typedef unsigned int UINT;
typedef int BOOL;
typedef float FLOAT;
typedef unsigned __int16 USHORT;
typedef unsigned __int32 DWORD;
typedef signed __int32 INT32;
typedef signed __int64 INT64;
#define DECLARE_HANDLE(name) struct name##__ { int unused; }; typedef struct name##__ *name
DECLARE_HANDLE(HDC);
DECLARE_HANDLE(HGLRC);

Share this post


Link to post
Share on other sites
you dont use them directly but opengl does mostly the win32 type's like BOOL and VOID but im sure it does and also how do you think you get a context to draw on? thats win32 also so there no way. Why is that a problem? you could add a header that call both gl and windows.h then call it

Share this post


Link to post
Share on other sites
gl.h doesn't use BOOL, VOID, etc. Only the two top lines are needed for gl.h The others are because the GLee author decided to use those instead of basic types.

What functions may get called internally is irrelevant, since you're linking to the .lib anyway. Header-contained #includes, on the other hand, end up making a compile-time (as opposed to link-time) dependencies that are generally exponential because one include file includes other include files and so on, and these all get processed and that adds up even if it's just up to the first line #if defined SOME_H... (see Lakos' "Large-Scale C++ Software Design"). Intel C++ compiler with maxed out optimization options is especially slow.

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!