Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Andre the Giant

OpenGL Newbie: 2 fundamentally different types of openGL programs?

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

Hello. Im a beginner to OpenGL. Ive been downloading sample programs with source code to read through them and Ive noticed that there seems to be 2 distinctly different ways to create an opengl program. One way seems to require less source code and opens a "dos box" along with the opengl window itself. Looking at the source code, the main function is defined as "int main()". This type of opengl program relies on functions such as these: glutDisplayFunc(Display); glutReshapeFunc(reshape); glutKeyboardFunc(KeyDown); to handle displaying, reshaping the window, and pressing a key, respectively. The other method involves more source code and does not create the "dos box" as mentioned above. I think that for this reason alone it is a better method. The main function is defined like this "int WINAPI WinMain(..." instead of just "int main()". There doesnt seem to be glut*() functions to handle events. Instead, the WndProc() function uses a SWITCH statement to catch events like: WM_KEYDOWN WM_MOUSEMOVE WM_SIZE What I would like to know is: which method is better? If the answer to that question is "it depends", then what does it depend on? Which method should I use in which situation. Being a beginner, all this stuff is confusing enough as it is, and I would prefer to only have to learn one method if possible. Thanks in advance! Its not my fault I''''m the biggest and the strongest; I don''''t even exercise.

Share this post


Link to post
Share on other sites
Advertisement
I personally prefer the Win32 method. This is because not only is it free of that annoying dos window but it also leaves you already set to accept input from the keyboard and mouse. Don''t be intimidated by the amount of code (its more simple Win32 than it is OpenGL). Once you learn it and write your own class to put it in you''ll never have to write the code to open the dos-less window again.

If it ain''''t broke, your not testing it hard enough

Share this post


Link to post
Share on other sites
Thanks! I was hoping someone would say something along those lines. So just to be sure, there could never be a situation where I would need the other method instead of win32 right?

thanks again!

Its not my fault I''''m the biggest and the strongest; I don''''t even exercise.

Share this post


Link to post
Share on other sites
The direct Win32 method is generally not good. It can be used, but it will totally break platform independance, and it can be hard to maintain.

GLUT is better for small projects. It''s easy, clean, and totally portable, since it hides platform specific code. In fact, it also does the ''Win32 stuff'', it''s just not visible.

The best method is a wrapper class. You basically use the Win32 initialization, but instead of using it directly, you put a compatibility layer between it and your code. That way, it''s easier to maintain, and you can add different platforms as you go on.

If you can, stay with GLUT. If you can not (because glut doesn''t offer the functionality you need), then use the Win32 method, but make sure to isolate the Win32 code. Don''t spill it all over your program. Put it into a separate class or function.

Share this post


Link to post
Share on other sites
When you say that it will break platform independance, do you mean that if i use the Win32 method, that my program will only run on Win32 machines? Or only my machine? or what? Ive always been curious about what people meant when they say "platform independance". What exactly is a platform? Do they mean operating system?

Is there any way to get rid of that "dos box" when using the GLUT method? I feel that it makes my project look very unprofessional (not that it looks very good on its own anyway, but you know

Could you please point me to some more information about this wrapper class you speak of? I only vaguely understand what you mean by that, and have no idea how to actually go about implementing it.

Thank you so much !

Its not my fault I''''m the biggest and the strongest; I don''''t even exercise.

Share this post


Link to post
Share on other sites
Platform independance is usually a term to define source code that will compile and run under different Operating systems (like Windows, Linux etc...). The easiest way in my opinion to accomplish this is with #define''s and #ifdef''s. For example, lets say that you want to write a "platfrom independance" function that creates a window under Win32 and under Linux :

void MyCreateWindow (int width, int height)
{
#ifdef _WINDOWS_BUILD_
... code to create a window using WIN32...
#endif

#ifdef _LINUX_BUILD_
... code to create a window under Linux...
#endif
}

when you compile the above code with the "_WINDOWS_BUILD_" definition, it will create the Win32 code and with "_LINUX_BUILD_" compiler will create linux code.

As for getting rid of the dos box, I don''t know a method to avoid it. Use Win32.

Someg.

Share this post


Link to post
Share on other sites
quote:

When you say that it will break platform independance, do you mean that if i use the Win32 method, that my program will only run on Win32 machines? Or only my machine? or what? Ive always been curious about what people meant when they say "platform independance". What exactly is a platform? Do they mean operating system?


Operating system (Windows, Linux, BeOS, ...) and machine architecture (x86, Mac, SGI, ...). True platform independance means, that your code will compile without changes and run on all computers that support the language and API (in your case OpenGL), regardless of OS, CPU and graphics system.

Eg. if you write a portable and platform independant game, then it will compile and run under a Windows PC, a Macintosh, and even a SGI or Cray supercomputer.

GLUT is portable. Win32 is not, it will only run on Windows PCs (and depending on what Win32 functions you call, it might even only run on a specific version of Windows).

quote:

Could you please point me to some more information about this wrapper class you speak of? I only vaguely understand what you mean by that, and have no idea how to actually go about implementing it.


A wrapper is a kind of container. It isolates platform specific code (ie. code than can only run on a certain OS or computer, in your case all the Win32 code). GLUT is a wrapper, but your can write your own, if GLUT doesn't fit your needs.

Think of it as a black box. Once it is implemented, you don't care about it inner workings. It is totally separate from the rest of your game or application. To open a window, for example, you would call a function like 'OpenWindow( ... )'. The blackbox (the wrapper) will then open a window, using a method that is appropriate for the OS and CPU that your game is currently running on. You don't need to care about that anymore in your game.

In straight C, this wrapper is commonly implemented as a collection of functions in a seperate source file, often even in a library. You have functions to open and close windows, to handle keyboard and mouse, etc. The details are done the way that Someg demonstrated above, with #ifdef's.

In C++, it is often implemented using a special class hierarchy with a common standard interface. Thus the name 'wrapper class'.

If you don't want to implement your own, there are lots of third party wrapper classes and libraries available. A very good one is SDL. It's much more sophisticated than GLUT. Besides graphics related functions, it also contains wrappers for input (keyboard, mouse), music/sound handling and others. It's easy to use, platform independant and free. You should check it out.

/ Yann

[edited by - Yann L on August 29, 2002 8:36:10 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Yann L
True platform independance means, that your code will compile without changes and run on all computers that support the language and API (in your case OpenGL), regardless of OS, CPU and graphics system.

[offtopic]
"True platform independence" doesn''t exist - at least not for applications that do anything remotely useful. It is approximated by writing libraries and abstraction layers that contain conditionally-compiled platform-specific code.

Furthermore, platform independence is of no use to some. Advocating certain methods because they solve problems the user doesn''t have complicates the matter unnecessarily. In this case, Andre the Giant should be encouraged to abstract his Win32 (and OpenGL!) code because it is maintainable, compact and good programming practice. That it is also portable is not (yet) of any benefit to him, and only serves to confuse him.
[/offtopic]

Share this post


Link to post
Share on other sites
True low level binary platform independance is of course impossible - different machine level opcodes and system architecture will ruin it in the first place.

But I was referring to the popular use of the term 'platform independance' (even if it might not be the exact literary one): independance on source level, using wrapper libraries.

I would classify a C/C++ program using OpenGL and GLUT as totally platform independant (not the required libraries, of course). In this context, 'total' refers to platforms supporting the required language (C/C++), the graphics API (OGL) and the interface wrapper (GLUT). Almost all systems in usage today do that.

Platform independance is not required by everyone, that's a fact. But since he asked about it, I replied

Besides the used platform or OS, abstracting system level functions is always a good idea. The code will be cleaner, and much easier to maintain. The worst thing is having code that is intermixed with system calls every few lines. That's a mistake lots of beginning programers do, and I think it is a good idea to practice abstraction from the beginning on. It simply is good coding style.

And if abstraction brings portability for free, then this can only be a positive side effect.

[offtopic 2]
This might be a bit personal philosophy, but choosing OpenGL in the first place advocates platform independance, IMO. Not even necessarily architecture independance, but also interoperability between different Windows versions, regarding backwards compatibility (eg. with NT, which is still widely used in the graphics domain). If that is of any importance for Andre the Giant, is questionable, of course
[/offtopic 2]

/ Yann

[edited by - Yann L on August 29, 2002 9:55:03 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Yann L
[offtopic 2]
This might be a bit personal philosophy, but using OpenGL in the first place advocates platform independance, IMO. Not even necessarily architecture independance, but also interoperability between different Windows versions, regarding backwards compatibility (eg. with NT, which is still widely used in the graphics domain).
[/offtopic 2]

[offtopic 3]
OpenGL is rooted in platform independence (an open, accessibly high-level graphics abstraction "language" that resulted from IrisGL, but that''s by the side). Unfortunately, OpenGL is also mired in platform independence. Platform-specific extensions, windowing kits (wgl, glx, etc) and resource acquisition methods (PFDs, etc) contradict this objective, though admittedly to a lesser extent.

The other big problem with OpenGL''s platform independent objectives - not an integral API problem, but rather a shortcoming in the design process - is that the ARB moves slowly to update the API (which necessitated extensions in the first place, which leads to inconsistencies in syntax and functionality per platform, which contradicts the initial objective).

OpenGL is mad cool, though. If and when 2.0 hits, and if it provides solutions (or at least decent attempts at solutions) to these problems, then people like me (read: lazy programmers who don''t care about platform independence) might give it a very serious look. Until then...
[/offtopic 3]

Share this post


Link to post
Share on other sites

  • 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!