No announcement yet.

OpenGL in PB

  • Filter
  • Time
  • Show
Clear All
new posts

  • OpenGL in PB

    I am trying to use OpenGL in PB, but the inc is only available on Jose Roca's site and for some reason he has blocked registration, so there is no way for me to access anything on his site. This is pretty ridiculous. Why is everything so locked down? Can I get this inc file somewhere else?

  • #2
    Hey Paul,
    Did you try to email Jose with a request for the files? I'm sure he will respond.


    • #3
      I actually found it easier to build my own OpenGL includes by downloading the header files from the OpenGL web site and then converting them to PowerBasic. This allowed my to just select the key API's I required without all the rest, plus it allowed me to define the declares the way I like. For example many OpenGL calls have multiple versions of themselves based on the data type you want to use. Rather than have all the data type declares, I just used the ones which best fit my own coding style.

      Also you need to determine which version of OpenGL you plan on using, since 3.0 and 4.0 'supposedly' deprecate many 2.0 functions. In reality though you will find that most mass market computers today with onboard video chips only support OpenGL 1.5 or 2.0, rather than the more current 3.0 or 4.0. Also major video card makers, while supporting OpenGL 3.0 or 4.0 have found it advantageous to still support 2.0 on their cards, so 2.0 is still quite viable. Now if you target high end video cards, they may actually support 2.0. The only time I have heard of this so far though was one of my customers had $1800 (approximately) video cards which supported 4.0, but not 2.0.

      I don't really like all the effort of making lots of low level OpenGL calls, so it makes sense to build some kind of library to work with. That is what was done with GLUT (I think that is what the called it).

      As a reference for OpenGL calls supported even by Microsofts software only version of the runtimes (which dates back to Win95/98) I like to use the Windows SDK API docs (older ones). They actually had a lot of info about the basic opengl calls.
      Last edited by Chris Boss; 24 Dec 2011, 05:42 PM.
      Chris Boss
      Computer Workshop
      Developer of "EZGUI"


      • #4

        If you want become a member of my forum, send me an personal message with a valid email address.

        However, my translation of the OpenGL headers are not individual files, but part of my Window API headers. If you are looking for individual files, you can find an old translation here:


        • #5
          I use and fully recommend José's translation of headers. This way you have the full arsenal available.

          Chris, do you think you could find out which card did supported 4.0 and not 2.0? It seems to me more like difference of creating context the old and new way (compatibility/core profile), but I may be wrong. It is interesting information for me...

          Also you need to determine which version of OpenGL you plan on using, since 3.0 and 4.0 'supposedly' deprecate many 2.0 functions
          This is again question of creating the context.

          When you create it in compatibility mode, none of the functions is deprecated. So yes, you can use glBegin/glEnd and all old OpenGL code without single change with OpenGL 4.x context.

          When you create it in core mode, usage of some older functions generates OpenGL error.



          • #6

            I don't know the brand video card, but the customer of mine has CAD stations with very, very expensive graphic cards which supports OpenGL 4.0. My software simply did not work on those graphic cards.

            According the OpenGL specifications the older OpenGL versions 1.0, 2.0 have a number of functions which have been "deprecated". What does that mean ?

            It means at some point OpenGL will not support them any more. Fortunately most video chip/card makers recognize the problems associated with deprecated API's, so they personally made the choice to maintain support for deprecated API's. They don't have to though, if they want to impliment OpenGL 4.0. Its a choice, not a requirement.

            It appears though in practical experience that OpenGL 1.0 to 2.0 will have a decent life span at least for the foreseeable future. Most mass market PC's come with onboard graphic chips (or even GPU's built into the CPU) and it is quite normal for them to support OpenGL 1.5 or 2.0 (no 3.0 or 4.0 support). It appears gaming computers or PC's which people build where they install a much higher end (more expensive) graphic cards commonly support OpenGL 3.0 and 4.0, but they still are backward compatible with 1.0 and 2.0.

            At some point though, video chip/card makers may start dropping support for the deprecated APIs of 1.0 and 2.0 (only portions of these API's are deprecated), which will require software developers to start using the newer API's or at least what is left of 1.0 and 2.0.

            The two key areas which OpenGL programmers need to hone in on are writing their own Matrix code and using arrays of triangles, rather than drawing them one at a time. At lot of the common APIs we currently use will become obsolete.

            This brings up the point of backard compatibility.

            Fortunately many hardware makers (and even Microsoft) realize the practical benefits of backward compatibility. It makes no business sense to deprecate stuff which has worked for years, because it would break too much code. Sadly, this could change in the future. We just have to wait an see. But for now it is best to start learning more current API's.

            One other point which is very important for writing code which will last, but still be backward compatible. The use of dynamic API calling. I use this a lot and I personally feel it is critical to write code this way.

            What is dynamic API calling ?

            Over dependence upon using include files with PowerBasic where all the API's we use are predeclared, which force the executable (EXE or DLL) to be dependent upon a specific API call. If the app is run on a system where that API (or a DLL) does not exist, then the app fails ro be run by Windows.

            The solution is to consider whether an API is something which may not exist on all end users systems. While many APIs are almost guaranteed to exist, some may not, especially with OpenGL or DirectX or some of the fancy features of Windows Vista/7/8. If any API may not exist say on Vista, but does with Windows 7 (or an OpenGL call with version 4.0, but not 2.0 or visa-versa) then you have to deal with it differently.

            If the OS DLL is already loaded then you simply call the GetProcAddress API to get the actual address of the API and then make the call using CALL DWORD.

            If the OS DLL is not guaranteed to be loaded by the app, then one must call the LoadLibrary API to load the DLL (or even an OCX) and then call the GetProcAddress API to get the function address and then make the call.

            When I write code like this using dynamic calling, I don't like to use the API declares as is, because I like to use a different syntax for such declares.

            For example if an API name was:


            if I use it dynamically I change the declare (also no reference to what DLL it is associated with) name to :


            I put a capital X at the end of all dynamic declares so they stand out in my code. Also such declares are written differently (no DLL name) than normal declares, which is why the standard header files (includes with PB) are not always sufficient when I code.

            While my current OpenGL library code does not use dynamic calling (because OpenGL 2.0 is currently well supported), my plans are to start porting over the code to an OpenGL 3.0 or 4.0 syntax and then I will have to use a lot of dynamic calls to make the software backward compatible and forward compatible.

            I do use dynamic calling a good bit in EZGUI 5.0's main runtimes right now. It calls GetProcAddress 15 times and LoadLibrary some 16 times. This is why the runtime can work even on Windows 95/98, while still supprting some unique features of XP,Vista and Windows 7. There is no forced obsolesence with my runtimes because they dynamically load different API's when needed.

            The same will likely be necessary when I start supporting OpenGL 3.0 and 4.0.
            Chris Boss
            Computer Workshop
            Developer of "EZGUI"