Quote:Original post by Dolf
ahh alright cool thanks.
So does every platform has it's own gl.h? because I think I see some references to windows in mine.
WINGDIAPI void APRIENTRY glFunction(params);
Or am I wrong?
That is correct.
Portability
That is correct.
Instead of including windows.h (which includes some pretty nasty macros) you can also do something like:
This should remove the header dependancy.
#if defined(_WIN32)# ifndef APIENTRY# if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED)# define APIENTRY __stdcall# else# define APIENTRY# endif# endif# ifndef CALLBACK# if (defined(_M_MRX000) || defined(_M_IX86) || defined(_M_ALPHA) || defined(_M_PPC)) && !defined(MIDL_PASS)# define CALLBACK __stdcall# else# define CALLBACK# endif# endif# ifndef WINGDIAPI# define WINGDIAPI __declspec(dllimport)# endif#endif#include <GL/gl.h>This should remove the header dependancy.
Quote:Original post by biggoronPlease, not anymore. GLUT has never been so bad, but there's no way to go for it over SDL.
Use GLUT for windowing. http://www.opengl.org/resources/libraries/glut/
Quote:Original post by IngraterThis is the solution. Preprocessor commands are executed before the code gets compiled.
Use preprocessor commands?
My favourite preprocessor commands:
#ifdef
#endif
#pragma once
Example:
#ifdef __WIN32
// compile this only in win32
// check out your compiler for the various tokens
// take care with win64, win64 is a superset of win32.
#include <windows.h>
#endif
#pragma once // include this file once. I suppose it's widely supported, check out your compiler.
Quote:Original post by Brother BobTrue, let me elaborate a bit. While #ifdefs are typically used, they can easily grow in a real code mess. There's a good deal of subjective opinion here but I hate to read code with #ifdefs.
OpenGL is platform independent. However, the layer between OpenGL and the operating system is not. For example, the layer between OpenGL and Windows, wgl, requires Win32-platform dependent code. The layer between OpenGL and X, glx, requires X-platform dependent code.
You need platform dependent code to setup a window, create frame buffers, create a rendering context and so on. Once that is done, OpenGL kicks in and your platform independent code begins.
Another solution I've found is to do that using OOP and specialized classes depending on the OS. The ifdef is then relegated to whole files and an object creation. I think it's nicer.
Quote:Original post by LtJaxAnd it works when you begin to use GDI, Winsocks and such? It doesn't seem to scale with complex apps...
Instead of including windows.h (which includes some pretty nasty macros)...
Quote:Original post by KrohmQuote:Original post by Brother BobTrue, let me elaborate a bit. While #ifdefs are typically used, they can easily grow in a real code mess. There's a good deal of subjective opinion here but I hate to read code with #ifdefs.
OpenGL is platform independent. However, the layer between OpenGL and the operating system is not. For example, the layer between OpenGL and Windows, wgl, requires Win32-platform dependent code. The layer between OpenGL and X, glx, requires X-platform dependent code.
You need platform dependent code to setup a window, create frame buffers, create a rendering context and so on. Once that is done, OpenGL kicks in and your platform independent code begins.
Another solution I've found is to do that using OOP and specialized classes depending on the OS. The ifdef is then relegated to whole files and an object creation. I think it's nicer.
Or separate the different platform implementations to separate files and just use the file for the platform being compiled. If there are different platform, chances are there are multiple projects and/or makefiles aswell, so just stick the proper file in the project and/or makefile. No need for compiler directives at all to determine what code to use.
Quote:Original post by Brother Bob
Or separate the different platform implementations to separate files and just use the file for the platform being compiled. If there are different platform, chances are there are multiple projects and/or makefiles aswell, so just stick the proper file in the project and/or makefile. No need for compiler directives at all to determine what code to use.
This is the method I take; it is utterly illogical to try and use inheritence for something which can be defined at compile time.
Having Win32OpenGLWindow, LinuxOpenGLWindow and OSXOpenGLWindow which all inherite from OpenGLWindow would be insanity as you know at compile time which window type you need.
Just use SDL: It performs a number of other game related functions, is able to get a window for openGL, and is cross platform. It's also more friendly than glut.
Yeah, if you want cross-platform code the best way is to use cross-platform libraries, like SDL or GLFW (and other depending on what functionality besides GL and input you need). There is not much point in writing your own low-level code unless you really need to do something the libraries can't provide you.
Quote:Original post by phantomSure, it looks way better when you have Win32glWindow, Win32d3d9Window_t and the possibility to change it at runtime!
This is the method I take; it is utterly illogical to try and use inheritence for something which can be defined at compile time.
Having Win32OpenGLWindow, LinuxOpenGLWindow and OSXOpenGLWindow which all inherite from OpenGLWindow would be insanity as you know at compile time which window type you need.
Quote:Original post by KrohmQuote:Original post by phantomSure, it looks way better when you have Win32glWindow, Win32d3d9Window_t and the possibility to change it at runtime!
This is the method I take; it is utterly illogical to try and use inheritence for something which can be defined at compile time.
Having Win32OpenGLWindow, LinuxOpenGLWindow and OSXOpenGLWindow which all inherite from OpenGLWindow would be insanity as you know at compile time which window type you need.
You cant change OS at runtime, that is the point they were trying to make. Some people are so obsessed with OO that they take it too far sacrificing convenience and efficiency and greatly increasing complexity. Anyone remember BufferedReader before Scanner appeared?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
