a question about OpenGL in QB64pe:

[TempodiBasic]

Hi a question about OpenGL in QB64pe:

Reading a 2020 book about  OpenGl, at beginning it says to learn OpenGl 3.3 because it is the first of the new paradigm of OpenGl developing. Then it says that there are many libraries about OpenGl both for Immediate mode both for CoreProfile and it continues saying that among these OpenGL libraries the most popular ones are  GLUT, SDL, SFML and GLFW.

The question is:
nowadays (2025) are these affermitions  yet right? 
Is QB64pe's OpenGl  version 3.3 or more?
Is QB64pe's OpenGl using one of those popular libraries? Or whatother? 
Is available in QB64pe's OpenGl the CoreProfile mode? 

These questions can appear too ingenue but I have found no clear answer in QB64pe's wiki .

[Unseen Machine]

I cant tell you about whats bound and what isnt but if you are just setting out on learning GL...whilst the methods are old and slower than new ways...id push you/encourage you to start with legacy functions first like , glbegin, gllist and glvertex..then youll get an idea of whats actually going on. I only say this as theres no point trying to create a shader on your first day when you dont yet know how to position objects or change the background colour.

Chenck out NeHe legacy tutorials for a good foundation!

Have fun!

John

[SMcNeill]

I think we use version 1.1.   I don't think it's ever been upgraded beyond that point.  It's just not really been adopted in use enough for anyone to really ask about upgrading and adding the more advanced features.  At least, not as far as I know.

[Unseen Machine]

and AI says.....

Here's a breakdown of the commands and versions available in QB64:

OpenGL 1.1 fixed-function pipeline: Most of the _GL commands directly map to OpenGL 1.1 functions, such as glBegin, glEnd, glVertex2f, glColor3f, and glOrtho. This means you are generally limited to the rendering methods of the mid-90s, using commands to define vertices and draw primitives.

Compatibility contexts: While the commands themselves are from an older version, the QB64 compiler and its underlying libraries (like SDL) can request a "compatibility profile" context from the graphics driver. This allows code written for the older fixed-function pipeline to run on modern OpenGL drivers, which primarily support newer core profiles.

System-dependent capabilities: The specific OpenGL version and extensions your program can utilize ultimately depend on the user's graphics drivers and hardware. For example, if a user's graphics card supports OpenGL 4.5, your QB64 program can still run, as the driver will execute the older, backward-compatible commands.

No direct access to modern OpenGL: The core QB64 language does not provide native keywords for modern OpenGL features like shaders, Vertex Buffer Objects (VBOs), or Framebuffer Objects (FBOs). To use these features, you would need to use DECLARE statements to directly access the functions from an external DLL or shared object, effectively writing C++ style code within your BASIC program.

Hope that helps! (I learnt from it so happy days!)

John

[Unseen Machine]

Bad news (for me at least!)

from my research, it is possible to add some of GL 3.x to QB64 using a mixture of .dll's, windows api calls and declare library but its not an easy task by any means, and I mean, SOOOOO NOT easy! 

Light at the end...

RayLib supports modern OpenGl and an amazing person has wrapped and packaged it for Qb64 so if you want the modern approach then use that....

Me

[The Joyful Programmer]

Hi a question about OpenGL in QB64pe:

Reading a 2020 book about  OpenGl, at beginning it says to learn OpenGl 3.3 because it is the first of the new paradigm of OpenGl developing.

OpenGL v3.3 is the version that deprecated most of the fixed-function pipeline used in previous versions, and moved over to the programmable pipeline.  A "pipeline" is a sequence of processing stages that converts data an app gives to OpenGL to the final rendered image. The fixed-function stages can not be programmed by the user, as can the "programmable" pipeline.

OpenGL v1.1, which QB64, QB64pe, and QB64 Original (not the true original created by Galleon [Rob]) are powered by, uses the fixed-function pipeline. Here is a textual representation of both types of pipelines:


FIXED PIPELINE:

( ) = Fixed-Function Stage

(Vertex) --> (Primitive) --> (Rasterization) --> (Fragment) --> (Framebuffer)


As stated before, OpenGL v3.3 deprecated "most" of the fixed-function pipeline. OpenGL did not remove the fixed-function stages in the pipeline, but a lot of the functionality in them. OpenGL simply added the programmable stages to the pipeline to work along side the fixed-function stages. The programmable stages are coded with shaders, which is talked about below. Here's the textual representation of the complete pipeline with the fixed-function and programmable stages:


COMPLETE PIPELINE

( ) = Fixed-Function Stage
[ ] = Programmable Stage

(Vertex) --> [Vertex] --> (Tessellation) --> [Tessellation] --> [Geometry] --> (Primitive) --> (Rasterization) --> [Fragment] --> (Framebuffer)


The programmable stages shown above were not all implemented together. While the OpenGL shaders language, "GLSL" was implemented into OpenGL v2.0, the Fragement shader was added through an extension, "GL_ARB_fragment_shader", in OpenGL v1.4, which was released in July 2002. The official Fragment shader was implemented in OpenGL 2.0, which was released in September 2004, as was the Vertex shader and the GLSL shader language. The Geometry shader, for the Geometry stage, was implemented in OpenGL v3.0, released in August 2008. The Tessellation shader was introduced in OpenGL v4.0, which was released in March 2010, and the Compute shader was introduced into OpenGL in version 4.3, which was released in August 2012.

Just FYI, OpenGL 4.6 was released in July 2017, which makes it nearly 9 years old at the time of this writing, and is the last version to ever be released. However, per Khronos, the maintainers of OpenGL, stated that OpenGL v4.6 will remain viable for at least 20 more years for backwards compatibility. OpenGL was replaced with Vulkan.

Then it says that there are many libraries about OpenGl both for Immediate mode both for CoreProfile and it continues saying that among these OpenGL libraries the most popular ones are  GLUT, SDL, SFML and GLFW.

There are only two profiles for OpenGL. They are the "Core Profile" and the "Compatibility Profile". The compatibility profile provides both core features as well as all the deprecated fixed-function features. The core profile only provides the core features.

The "GLUT" library became obsolete in August 1998. Others have forked the project and created "FreeGlut", which was last updated in June 2024. I personally have never used either of them, so there is nothing to comment on.

I have created multiple demos with SFML, which one can be seen in the screenshot below, and it is an amazing 2D graphics library to use.

   

I recently started learning SDL3 and I primarily use it with the Vulkan graphics API. The main graphics demo I created with SDL3 and the Vulkan graphics API is a sphere with layers of cubes. The demo has many features including MSAA (MultiSample Anti-Aliasing), motion blurring, tinting, fly through, Orthographic, and others. I absolutely love Vulkan way more than OpenGL, even though it is extremely more verbose, meaning there is an extreme amount of coding that needs to be done to do render a single triangle. Roughly over 1k statements.

The question is:
nowadays (2025) are these affermitions  yet right? 
Is QB64pe's OpenGl  version 3.3 or more?
Is QB64pe's OpenGl using one of those popular libraries? Or whatother? 
Is available in QB64pe's OpenGl the CoreProfile mode? 

These questions can appear too ingenue but I have found no clear answer in QB64pe's wiki .

These have been answered already, so I will not respond.

Bad news (for me at least!)

from my research, it is possible to add some of GL 3.x to QB64 using a mixture of .dll's, windows api calls and declare library but its not an easy task by any means, and I mean, SOOOOO NOT easy! 

Light at the end...

RayLib supports modern OpenGl and an amazing person has wrapped and packaged it for Qb64 so if you want the modern approach then use that....

Me

It would be way more work, in my humble opinion, to code OpenGL v3.3 or later in QB64pe than it would be to do so in C++ with the SDL library.

RayLib is also an amazing graphics library.

I think we use version 1.1.   I don't think it's ever been upgraded beyond that point.  It's just not really been adopted in use enough for anyone to really ask about upgrading and adding the more advanced features.  At least, not as far as I know.

To upgrade the OpenGL version used by QB64/QB64pe would require a full rewrite in my humble opinion, as I have stated since 2012. But, that would mean getting into shaders.

Well... That's my 2 cents worth.

[Unseen Machine]

I recently started learning SDL3 and I primarily use it with the Vulkan graphics API. The main graphics demo I created with SDL3 and the Vulkan graphics API is a sphere with layers of cubes. The demo has many features including MSAA (MultiSample Anti-Aliasing), motion blurring, tinting, fly through, Orthographic, and others. I absolutely love Vulkan way more than OpenGL, even though it is extremely more verbose, meaning there is an extreme amount of coding that needs to be done to do render a single triangle. Roughly over 1k statements.

WOW! I looked into Vulkan but implementing it was never gonna happen! (For me at least!) Hats off to you sir! 

John

[The Joyful Programmer]

I recently started learning SDL3 and I primarily use it with the Vulkan graphics API. The main graphics demo I created with SDL3 and the Vulkan graphics API is a sphere with layers of cubes. The demo has many features including MSAA (MultiSample Anti-Aliasing), motion blurring, tinting, fly through, Orthographic, and others. I absolutely love Vulkan way more than OpenGL, even though it is extremely more verbose, meaning there is an extreme amount of coding that needs to be done to do render a single triangle. Roughly over 1k statements.

WOW! I looked into Vulkan but implementing it was never gonna happen! (For me at least!) Hats off to you sir! 

John

Hey, John (Unseen Machine)!

It's been a long time!

I've actually spoke about it here on this forum in the "Freedom to Speak" sub-forum, which is password protected (PW: "none"). You can find it here:
https://qb64phoenix.com/forum/showthread.php?tid=3945

The demo also uses OpenCL to gather some more information about the available processors (GPU) on the current device.

There are a lot of screenshots of it and I even share the source code to it as well. The source code I shared is not the current, but I do plan on sharing it on GitHub at some point, once I get some kinks out of it. However, here are three screenshots just to water your mouth:

   

   

   

Enjoy!

[The Joyful Programmer]

I recently started learning SDL3 and I primarily use it with the Vulkan graphics API. The main graphics demo I created with SDL3 and the Vulkan graphics API is a sphere with layers of cubes. The demo has many features including MSAA (MultiSample Anti-Aliasing), motion blurring, tinting, fly through, Orthographic, and others. I absolutely love Vulkan way more than OpenGL, even though it is extremely more verbose, meaning there is an extreme amount of coding that needs to be done to do render a single triangle. Roughly over 1k statements.

WOW! I looked into Vulkan but implementing it was never gonna happen! (For me at least!) Hats off to you sir! 

John

Finding QB64 in 2009 brought a great deal of euphoric nostalgia into my heart and I wanted to see how far I could push the BASIC programming language. Digging deep into QB64's source code in 2014 and figuring out how to add keywords into the language (I added a filled circle statement) was even more euphoric. This added euphoria caused me to start longing to get back into the more advanced coding arena, though all the coding languages I enjoyed were no longer viable, popular, and/or had nothing left for me to overcome (Assembly Language, Adobe Flash ActionScript 2.0 & 3.0, Visual Basic, Dark Basic, Web Development [HTML, CSS, JavaScript], etc...).

In 2018, after tinkering around with C++ a little bit, I was bitten. The realization hit that C++ was always the programming language for me, and I felt silly for pushing it away since 1995 when I first discovered it. However, truly learning it was rough starting out due to not knowing the best resources for learning it. One of the major things that C++ has taught me was how to find the most authoritative information on a technology for learning. This took me back to when I started learning 8-Bit Machine/Assembly Language on the Apple ][ back in 1985, where the most authoritative information came from the advanced books on it that everyone said I would never understand.

Learning the Vulkan graphics API is no different than learning Assembly Language. Instead of doing most everything for you, they require you to set everything up yourself. While this means an extensive amount of coding needs to be done to do the simplest thing, they do offer more access to the hardware so you can push them to the limit and beyond ("To infinite and beyond!"). Wielding great power requires great sacrifices, and the greatest sacrifice is verbosity with those two technologies.

OpenGL was falling way behind and simply could not keep up with the more modern GPUs due to their many differences. It had become more and more difficult to give users an easy and generic way to code while doing everything for the developer. Khronos realized it wasn't viable to keep increasing the size of the OpenGL graphics API, and that much of the responsibility should be off-loaded to the developer. Another complete rewrite of OpenGL to work for modern GPUs while providing the most power possible would break OpenGL's purpose statement. Thus, Vulkan was born. A new graphics API with a new purpose statement. Problem solved.

Now, to add salt to the wound: Intel's Software Developers manual, which includes information for all the x86 line of processors is around 5'100 pages. The Vulkan manual from Khronos is over 6'000 pages.

[TempodiBasic]

Hi
I thank all you for your answers...
so many interesting informations about QB64pe, OpenGL, Vulkan and GPU API!

And in summary:

Actually QB64pe has implemented OpenGL 1.1 with fixed function pipeline.
Actually QB64pe has no relation to main OpenGL graphic libraries: GLUT, SDL, SFML and GLFW 

Unseen Machine is working to port OpenGL 3.3 via RayLib to upgrade OpenGL in QB64pe

In OpenGL the use of fixed functions is deprecated preferring the new way of programmable pipeline versus compatible pipeline that allow the use of fixed function pipeline.
Last release of OpenGL is 4.6 in 2017.
Nowaday no more evolution of OpenGL that will be mantained for 20 years, but the future is Vulkan API for GPU.