PDA

View Full Version : Converting code from Linux to Windows



pvncheck
05-06-2011, 04:37 PM
This is a very broad question, and I know it's probably been asked before, but I couldn't find it after searching for about half an hour on various websites and on this one for a few minutes as well. Anyway, I have some code written using OpenGL that I wish to convert from Linux to Windows and I was wondering if there was any clear "guide" on converting OpenGL code to Windows from Linux, or even just a list of functions that are different. I do know that Windows has its own code for opening and closing windows, but I remembered seeing something about OpenGL not being supported on Windows past version ?.? and thus it was necessary to have function pointers to tell Windows where the various functions were located. Anyway, I'm just sort of ranting now, but does anyone know of a good starting place / list of functions that are platform dependent, etc? I'm really quite confused about where to begin and how to go about converting the code. I would really rather not have to rewrite it all, if I don't have to, as it's roughly 5,000 lines spread throughout several files. (A large portion of that doesn't have much to do with OpenGL as well).

Oh, also, final question, is GLSL the same on Windows, or is there anything I need to do to convert my vertex and fragment shaders as well?

Thank you for your help.

Alfonse Reinheart
05-06-2011, 05:03 PM
First thing: nothing about OpenGL itself is platform dependent. How you go about initializing it is, and how you setup your OpenGL environment differs. But once you have everything set, nothing should need to change. The functions you call, the parameters you pass them, the results of those functions, they are all the same (driver quality notwithstanding of course).

So there will be no "converting" of the code. You simply need to do proper initialization.

Let's start with OpenGL itself. Not WGL or GLX, just OpenGL functions and #define enumerations.

To load OpenGL on Windows, you link your code with a static library called "OpenGL32.lib." (technically, there are ways to link directly to the driver, but that would only muddle the discussion.) The "32" does not mean version 3.2, nor does it really mean 32-bit anymore. It has no meaning.

OpenGL32.lib defines all of the functions for OpenGL version 1.1. If you #include the Windows version of gl.h, it will only have GL 1.1 functions and defines in it.

Therefore, if you want any functions other than these, you must query them yourself with wglGetProcAddress.

As this is a very simple, if incredibly tedious, process, people have created libraries to handle this for you. Every extension loading library that I know of is also designed to get OpenGL core function pointers where necessary.

So if you're using GLEW for example, all you need to do is include the GLEW headers, initialize the library after creating an OpenGL context, and everything works.

So your first step should be to get such an extension library, assuming you do not have one already. Get your code working with that extension library on Linux. At that point, the extension loader will do all of the stuff you need for Windows.

At least as far as getting access to OpenGL function pointers is concerned. Creating, managing, and destroying the Win32 window is another story entirely.

mhagain
05-06-2011, 06:39 PM
I second the recommendation to use something like GLEW.

For the OS-specific parts you have 2 options. Option 1 is to introduce a load of platform-specific code, option 2 is to initially port to one of the cross-platform frameworks on Linux (SDL would be an example), then tidy it up if required for running on Windows.

If you're familiar with Windows programming (and I don't just mean grinding out code, I'm talking about using the native tools properly, debugging on Windows, and all the little nooks and crannies you need to watch out for) then option 1 might be the best - the OS-specific code should be a very small portion of your overall program anyway, and Microsoft's development tools really are the best in the business (their debugger is particularly awesome).

On the other hand, option 2 is very nice as it will give you a portable code-base that you can build on and potentially reuse in other programs. You can also do the initial hard work in an environment you're more comfortable with, which is naturally going to be both easier and less error-prone.

Your choice from there. ;)

V-man
05-07-2011, 09:00 AM
Yes, windows has its own API for creating a Window. You couldn't find anything? There is the ever popular NeHe website http://nehe.gamedev.net/

It is old, but you will find some code for creating and destroying your "Windows" window.


OpenGL not being supported on Windows past version ?.?
Instead of repeating that kind of thing over and over, we have the Wiki. Getting started explains that stuff
http://www.opengl.org/wiki/Getting_started

and "Accessing OpenGL functions" explains what to do.


Oh, also, final question, is GLSL the same on Windows, or is there anything I need to do to convert my vertex and fragment shaders as well?

You are joking, right?

mhagain
05-07-2011, 10:19 AM
And just a clarification that OpenGL is fully supported on Windows up to the most recent version, and that there is no reason why future versions will also be less than fully supported.

The key difference is that the headers and libs that come with MS development tools don't support versions beyond 1.1, but that does not mean that higher OpenGL versions are not supported on Windows.

nickels
05-17-2011, 07:13 AM
wxGLCanvas (http://docs.wxwidgets.org/trunk/classwx_g_l_canvas.html)

Just another approach that may or may not work for you.
wxWidgets has already done all the cross platform work for you, mapping key hits, mouse hits, window creation, etc....
worth considering....