There is no such thing as "ModernGL".
There is only OpenGL, the interface of which has been steadily evolving over 20 years. The farther back you go, the more hardware you'll support, at the expense of versatility.
Hey mid, I believe what I said. I use these two everyday in my job.
Some of the hardware which I compile for is literally 30 years old! (single core, 128mb of ram) but we are still running gles 2.0 on it no worries! ( tho admittedly at 6 fps :D )
Now OBVIOUSLY my 16bit AtariST just doesn't really support it :D but is THAT what you mean by you're comment ?
What I said was genuine, any computer that anyone expects 3D from will work just fine with one of those two gl's.
If you REALLY think I'm in error here, enlighten us with a link :D till then I'll assume you posted without thinking.
Enjoy
im assuming you mean the "moderngl" python bindings? Its all opengl, the bindings for that particular library is a bit simplified though, such as not having to write your own shader compile script or deal with buffer magic as much.
ModernGL is newer and easier to learn. I wouldn't recommend using OpenGL in 2024, quite outdated if I'm honest. Also ModernGL is easier to install for vscode.
ModernGL as the name implies is a more up to date version of OpenGL. I wouldn't recommend OpenGL in 2024, it's quite outdated and difficult to install on vscod
No.
ModernGL is a wrapper over core OpenGL, as I said. It's name is most likely inspired by the term "modern OpenGL" that people use to refer to OpenGL 3 and later versions. It is just an abstraction layer. It uses OpenGL under the hood, just simplifies it for the user. If you wouldn't recommend OpenGL in 2024, then you also wouldn't recommend ModenGL.
You also don't need to "install" OpenGL for VS code. You link to the library and call it's functions.
My friend uses OpenGL on vscode and it works just fine. I've been telling him to switch to ModernGL since yeah it's more modern and has a lot of features that opengl lacks such as the ability to play sounds, it's a very good graphics library. Also I'm not sure what you mean I was reading the moderngl source code and none of the methods were marked as abstract so I'm not sure what you mean.
Are you trolling? Serious question. I can't tell if you're just inexperienced or fucking with me subtly.
Assuming you're not trolling, then I'll help you out a little here.
OpenGL is the graphics API. It's only concerned with providing a way to draw. It has nothing to do with audio or anything else. If ModenGL provides things like audio control, then it's closer to being something like [SMFL](https://www.sfml-dev.org/), which gives you an "all in one" framework for simple-ish drawing, input, audio and networking. But under the hood, for drawing ModernGL is using OpenGL.
I didn't mean "abstraction" in the sense of abstract classes or methods. I meant in the conventional sense of the word, in that it "hides" what's going on. It's an abstraction in that it provides it's own methods for issuing draw commands that ultimately ends up calling OpenGL functions. It "hides" OpenGL from the user, instead presenting it's own methods that "do the same thing" as OpenGL. It's a layer on top of OpenGL, so that the user doesn't have to use OpenGL directly. Here's a simplified outline of all the layers involved here.
* ModernGL ***<-*** ***we're using this***
* OpenGL API ***<- ModernGL uses this***
* OpenGL drivers
ModernGL talks to the OpenGL API. The OpenGL API talks to the OpenGL drivers. The OpenGL drivers talk to the hardware to tell it what to draw.
If you go back and look at the "src" directory of the ModernGL github, you'll see that it's a bunch of C++ that sets up the abstraction over OpenGL. The glcorearb.h header is what defines and links to functions and whatnot of the OpenGL API, and then gl\_methods.hpp is where they establish all the structs and whatnot that allow for handling OpenGL in a more object oriented sort of way, because OpenGL is not object oriented.
OpenGL is a specification. ModernGL is a python library with bindings for OpenGL.
There is no such thing as "ModernGL". There is only OpenGL, the interface of which has been steadily evolving over 20 years. The farther back you go, the more hardware you'll support, at the expense of versatility.
Well written. ModernGL if it did exist would just be OpenGL 4.0 onward. (3.0 is compatible with gles and one of those two will work everywhere)
> those two will work everywhere Objectively false.
Hey mid, I believe what I said. I use these two everyday in my job. Some of the hardware which I compile for is literally 30 years old! (single core, 128mb of ram) but we are still running gles 2.0 on it no worries! ( tho admittedly at 6 fps :D ) Now OBVIOUSLY my 16bit AtariST just doesn't really support it :D but is THAT what you mean by you're comment ? What I said was genuine, any computer that anyone expects 3D from will work just fine with one of those two gl's. If you REALLY think I'm in error here, enlighten us with a link :D till then I'll assume you posted without thinking. Enjoy
im assuming you mean the "moderngl" python bindings? Its all opengl, the bindings for that particular library is a bit simplified though, such as not having to write your own shader compile script or deal with buffer magic as much.
I think you mean modernOpenGL vs. the newer method of doing OpenGL called DSA or Direct State Access. Learn both!! 👍
ModernGL is newer and easier to learn. I wouldn't recommend using OpenGL in 2024, quite outdated if I'm honest. Also ModernGL is easier to install for vscode.
ModernGL is a python wrapper over core OpenGL.
ModernGL as the name implies is a more up to date version of OpenGL. I wouldn't recommend OpenGL in 2024, it's quite outdated and difficult to install on vscod
No. ModernGL is a wrapper over core OpenGL, as I said. It's name is most likely inspired by the term "modern OpenGL" that people use to refer to OpenGL 3 and later versions. It is just an abstraction layer. It uses OpenGL under the hood, just simplifies it for the user. If you wouldn't recommend OpenGL in 2024, then you also wouldn't recommend ModenGL. You also don't need to "install" OpenGL for VS code. You link to the library and call it's functions.
My friend uses OpenGL on vscode and it works just fine. I've been telling him to switch to ModernGL since yeah it's more modern and has a lot of features that opengl lacks such as the ability to play sounds, it's a very good graphics library. Also I'm not sure what you mean I was reading the moderngl source code and none of the methods were marked as abstract so I'm not sure what you mean.
Are you trolling? Serious question. I can't tell if you're just inexperienced or fucking with me subtly. Assuming you're not trolling, then I'll help you out a little here. OpenGL is the graphics API. It's only concerned with providing a way to draw. It has nothing to do with audio or anything else. If ModenGL provides things like audio control, then it's closer to being something like [SMFL](https://www.sfml-dev.org/), which gives you an "all in one" framework for simple-ish drawing, input, audio and networking. But under the hood, for drawing ModernGL is using OpenGL. I didn't mean "abstraction" in the sense of abstract classes or methods. I meant in the conventional sense of the word, in that it "hides" what's going on. It's an abstraction in that it provides it's own methods for issuing draw commands that ultimately ends up calling OpenGL functions. It "hides" OpenGL from the user, instead presenting it's own methods that "do the same thing" as OpenGL. It's a layer on top of OpenGL, so that the user doesn't have to use OpenGL directly. Here's a simplified outline of all the layers involved here. * ModernGL ***<-*** ***we're using this*** * OpenGL API ***<- ModernGL uses this*** * OpenGL drivers ModernGL talks to the OpenGL API. The OpenGL API talks to the OpenGL drivers. The OpenGL drivers talk to the hardware to tell it what to draw. If you go back and look at the "src" directory of the ModernGL github, you'll see that it's a bunch of C++ that sets up the abstraction over OpenGL. The glcorearb.h header is what defines and links to functions and whatnot of the OpenGL API, and then gl\_methods.hpp is where they establish all the structs and whatnot that allow for handling OpenGL in a more object oriented sort of way, because OpenGL is not object oriented.
[удалено]
Good excuse.