15 ms·

PortableGL: An implementation of OpenGL 3.x-ish in clean C

185 points by kk6mrp 5y ago

wk_end 5y ago
So reading this: > [Vulkan] really is overkill for learning 3D graphics...using modern OpenGL to introduce all the standard concepts, vertices, triangles, textures, shaders, fragments/pixels, the transformation pipeline etc. first is much better than trying to teach them Vulkan and graphics at the same time... ...got me wondering. I haven't really kept up with modern graphics programming, but my - possibly incorrect - understanding was that not only is Vulkan lower-level than OpenGL, it was also motivated by lots of questionable design decisions that OpenGL was kind of stuck with. So, with the above quote in mind, is it the case that: * Vulkan is good (?) but too low-level for most users. * OpenGL is a good environment to learn or do nuts & bolts 3D programming in - i.e. it's the right level of abstraction for that - but is kind of a mess. Is that correct? Is there anything that splits the difference? How's Direct3D these days? Metal? Has anyone built a library on top of Vulkan, targeted roughly around the abstraction level of OpenGL, but with a better design?
- qbasic_forever 5y ago
  IMHO check out Three.js for learning and beginners, it's a very nice abstraction and scene graph that you can just start hacking on right in your browser on any device.
- jms55 5y ago
  > Has anyone built a library on top of Vulkan, targeted roughly around the abstraction level of OpenGL, but with a better design? WebGPU more or less fills this gap. It's built on top Vulkan/Metal/DirectX12 primarily, and targeted as a WebGL2 replacement, but there's also major interest (and right now, better support) around using it natively for games and other programs. There are bindings for Rust, C++, C, and Javascript (either through the browser, or using deno for native). Here's an excellent tutorial that uses Rust, although the API is more or less identical across languages https://sotrh.github.io/learn-wgpu/ https://sotrh.github.io/learn-wgpu/.
- sandGorgon 5y ago
  https://docs.imgtec.com/Introduction_to_APIs/Vulkan_Migrating_from_OpenGLES/topics/vulkan_migrating_introduction.html https://docs.imgtec.com/Introduction_to_APIs/Vulkan_Migratin... This is a very nice comparison for people looking to explore Vulkan...even versus native frameworks like Metal (on OSX). P.S. I dont think OpenGL is supported on OSX anymore. However Vulkan has MoltenVK which works on OSX - https://github.com/KhronosGroup/MoltenVK https://github.com/KhronosGroup/MoltenVK MoltenVK is officially supported and is a big part of the Vulkan Portability initiative - https://www.vulkan.org/portability https://www.vulkan.org/portability MoltenVK is fully production ready. Multiple games use MoltenVK to run on OSX using Vulkan. Including the big one - DOTA 2 (https://www.gamingonlinux.com/2021/09/dota-2-to-drop-opengl-and-32bit-vulkan-default-on-linux-and-ti-21-tickets-on-september-22/ https://www.gamingonlinux.com/2021/09/dota-2-to-drop-opengl-...). The bug tracker for DOTA2/Vulkan is here - https://github.com/ValveSoftware/Dota-2-Vulkan https://github.com/ValveSoftware/Dota-2-Vulkan https://www.youtube.com/watch?v=xDGQcjqpYqI https://www.youtube.com/watch?v=xDGQcjqpYqI (M1 macbooks running moltenvk games)
  - valleyer 5y ago
    OpenGL is still supported on macOS, though its use is discouraged. (This is what Apple means when it says it's "deprecated".)
    - thatjoeoverthr 5y ago
      Last time I had to use it, it had an old version and was missing some features, disallowing use of compute shaders.
      - inDigiNeous 5y ago
        OpenGL on macOS has been stuck on 4.1 + some 4.2 extensions since 2012 IIRC.
    - barchar 5y ago
      Apple's OpenGL implementation has always been mediocre even when it was technically supported.
- Jasper_ 5y ago
  As a professional graphics programmer at a well-known game studio, who has taught and mentored a lot of people: Direct3D 11 is quite good. D3D12 is a bit more like Vulkan, but not too far in that direction. In order of recommendation for learners, just rating each API on its own merits without considering other factors like portability: D3D11, Metal, WebGPU, D3D12, OpenGL and Vulkan. OpenGL and Vulkan score last place for similar and opposite reasons: both their APIs are a mess, the debugging and tooling story is still underdeveloped. But while OpenGL has backwards API design that often gives users a wrong impression about how GPUs work, Vulkan instead is much more annoying, requiring the user to cross their T's and dot their I's, while still not giving good guidance towards how they should be structuring their rendering code. I am also eternally annoyed at things like VkFramebuffer which should have never existed (yes I do know it is not required in the latest version). I would rank WebGPU higher (disclaimer: I contribute to the WebGPU spec) since the API is a great intermediate, except WGSL is too new and too underbaked for me to seriously recommend it right now. The native implementations Dawn and wgpu are committed to supporting SPIR-V input, which is how I would recommend using it right now. Happy to answer questions or elaborate on this.
  - bsder 5y ago
    Your Windows bias is showing. :) Personally, I find the Vulkan API to be one of the best designed APIs ever, and the debugging tools on desktop are okay. On Android, I'd say the Vulkan tools are, in fact, quite excellent. I can't compare them to iOS though. The problem with Vulkan and DirectX 12 (which I find to be so close as to be indistinguishable) has nothing to do with their APIs. The main problem is that "modern" graphics is only tangentially related to rendering triangles--and rendering triangles is normally what beginners really want to do. A lot of beginners also want to render 2D paths--and graphics APIs for that are horrifically bad. "Modern" graphics is mostly about creating a bunch of low-resolution "geometry buffers" and then scanning every single pixel on the screen only once while building the pixel up from some mathematical combination of those lower resolution buffers. Yes, there are triangles involved at a Platonic level, but many of the triangles are smaller than a pixel. See the Unreal Engine 5 demos: https://www.youtube.com/watch?v=qC5KtatMcUw https://www.youtube.com/watch?v=qC5KtatMcUw It's reached a point that "modern" graphics almost doesn't even want a triangle renderer--it just wants pure access to the massively parallel memory and computation pipeline on the GPU and the ability to smash the results into a framebuffer. Vulkan and DX12 reflect this, so they don't really mesh well with beginners. (I'm being a bit glib, but there really is a massive chasm between "modern" game rendering techniques and the kind of 2D/3D that GUI/CAD/Application developers want to use.)
- deleted 5y ago
  [deleted]
mnurzia 5y ago
Not entirely related to the subject of OpenGL, but I really like how the author has decided to lay out this project. It's pretty hard to beat the convenience of a single header (or single header/single source) distribution for C libraries, but library development gets progressively harder as the project gets bigger as more code is added to the (usually hard to navigate) header file. Here, the author does their development with multiple files as one normally would, but when a new version is released they run the generate_gl_h[1] script that concatenates everything into a .h file for distribution. Simple yet flexible! This is also how SQLite[2] distributes its builds. It's a pattern that I'm using myself in some unreleased projects. [1] https://github.com/rswinkle/PortableGL/blob/master/src/generate_gl_h.py https://github.com/rswinkle/PortableGL/blob/master/src/gener... [2] https://www.sqlite.org/amalgamation.html https://www.sqlite.org/amalgamation.html
- blondin 5y ago
  the original stb libraries did the same. single header doesn't mean you have to develop in one file, although you totally can.
  - mnurzia 5y ago
    Just because I was curious, I did a little digging: A cursory look at Sean Barrett's website on the Internet Archive lists Dec. 2006 as the first date where stb_image was published (but looking at the file, versions go back much further than that) https://web.archive.org/web/20061205030342/http://nothings.org/ https://web.archive.org/web/20061205030342/http://nothings.o... That means for 15+ years, he's been iterating on the same file. It certainly works as a development style, but I personally feel that it's easier to edit a set of smaller files.
    - tom_ 5y ago
      Original forum thread suggesting the first release was in Nov 2006: http://web.archive.org/web/20120419172714/https://mollyrocket.com/forums/viewtopic.php?t=315&sid=1e1583d6149ac8698ea35e20a6333a91 http://web.archive.org/web/20120419172714/https://mollyrocke...
blondin 5y ago
isn't opengl3 not recommended anymore?
- FrostKiwi 5y ago
  I'd consider OpenGL 3.3 today's lowest common denominator, if you are after backwards compatibility. It removed the intermediate mode pipeline and introduced the Core profile, making it a good candidate for the lowest thing to target. In OpenGL 2.1 you can pull in essential features like shader4 and UBOs via extensions, but 3.3 made it core. New ways to interact with OpenGL like DSA are generally available via extensions as well. It's "not recommended" mainly because Apple is the odd one out in removing support for it.
  - _0ffh 5y ago
    Q: What is intermediate mode? Is it an accidental "autocorrect" of immediate mode or an actual thing?
    - FrostKiwi 5y ago
      Ohh, yeah! Supposed to be immediate mode. I swear I typed it correclty O.o
  - greggman3 5y ago
    OpenGL ES 3.3 is arguably not "lowest comment denominator" if you add in Android, iOS, iPadOS, AppleTV, Raspberry PI, and Web
oso2k 5y ago
Fabrice Bellard released an OpenGL 1.x/2.x software renderer 20 years ago [0]. There seems to others who have taken to updating it more recently [1][2]. It is direct mode or immediate mode but this is how we used to do graphics more than 15 years ago. Might help others to read this if you're interested. [0] https://bellard.org/TinyGL/ https://bellard.org/TinyGL/ [1] https://github.com/C-Chads/tinygl https://github.com/C-Chads/tinygl [2] https://github.com/ska80/tinygl https://github.com/ska80/tinygl
dimatura 5y ago
This is pretty cool, I've looked for libraries like this myself in the past. Sometimes I've needed to render a bunch of simple 3D graphics off-screen, without any real-time or high-throughput requirements (mostly for visualizing 3D stuff in robotics/computer vision). Setting up GPU-based pipelines for this is possible, but can be kind of kludgy and annoying. Mesa3D can do opengl software rasterization, but it's also a nontrivial dependency. I've ended up writing crappy rasterizers in the past just to avoid all that hassle. A single-header solution for this that's more up-to-date than TinyGL is welcome.
samwisehamgee 5y ago
> I took a 400 level 3D Graphics course in college in fall 2010 months after OpenGL 3.3/4.0 was released. It was taught based on the original Red Book using OpenGL 1.1. Fortunately, the professor let me use OpenGL 3.3 as long as I met the assignment requirements. Sadly, college graphics professors still teach 1.x and 2.x OpenGL today in 2020 This one hits home. I did my first (and only) graphics programming in college in 2019 and it was indeed OpenGL 1.1 to make matters even more stupid, it was a course where the opengl part was only half the course, the other half was about image processing using matlab... I dont know what it is about graphics programming, I've tried many times to learn it but its so different to any of the other programming I've done that it feels totally impenetrable.
- Archit3ch 5y ago
  > This one hits home. I did my first (and only) graphics programming in college in 2019 and it was indeed OpenGL 1.1 to make matters even more stupid, it was a course where the opengl part was only half the course, the other half was about image processing using matlab... Why is this so relatable? First (and only) graphics course in 2019, fixed (1.x) pipelines, down to memorising individual API calls for the (paper) exam. To their credit, the professor admitted it was out-of-date: "You're never going to use these in real work, it's only here to teach you rotations with matrices etc." I wonder what graphics programming looks like these days. DL anti-aliasing?
Shadonototra 5y ago
that's pretty nice! any plan for GLES 3.0? something that would allow to target WASM too
- greggman3 5y ago
  If you want GLES 3.0 why not use ANGLE? It works on top of OpenGL, Vulkan, Metal, DirectX 11 https://chromium.googlesource.com/angle/angle https://chromium.googlesource.com/angle/angle It's also fairly well tested given that it's used in Safari, Firefox, Edge, and Chrome
  - Shadonototra 5y ago
    angle is different, i don't want any of vulkan/metal/directx i want opengl i don't need bloat and carry what i don't need it just adds useless complexity also building angle is weird it is bloat driven culture, i am against that
    - greggman3 5y ago
      You say you don't want bloat but OpenGL by definition, is bloat. Then you apparently want a wrapper on top if it. Ok?!?!?
ReactiveJelly 5y ago
> Using modern OpenGL to introduce all the standard concepts ... is much better than trying to teach them Vulkan ... and obviously better than teaching OpenGL API's that are decades old. I disagree on teaching old APIs. This is a pet peeve of mine, and I thought the author of a software rasterizer would agree with me. GPU APIs are some of the only APIs where you have to pay to upgrade. Sure, Vulkan has been "out" for 4 years. But I haven't bought any hardware that supports Vulkan. My last purchase was a used laptop with an iGPU. I buy hardware as a last resort when I absolutely need it, I especially don't buy hardware for the APIs when my old hardware has enough GFLOPS. I like that programming is a cheap hobby. I don't see the point in anteing up every few years. Per-core CPU power has plateaued, and I can add more storage to old systems easily. I just don't want to buy new hardware until I see the GPU space settle down for a few years. And when will that happen? Vulkan 2? Vulkan 3? How many more perfectly functional TFLOPS of GPU chips will be branded e-waste before the APIs are stable? I don't like the implication among some gamedevs that your programming skill depends on how much tribute you've paid to NVidia. I don't make bad games because I use GLES 2, I make bad games because I'm a bad gamedev. GLES 2 is a sweet spot in the tradeoff between compatibility and features. It dates to about 2007, so even a kid with a cheap used Android phone could theoretically write GLES 2 code for it. It doesn't have geometry shaders, but with vertex and fragment shaders you can still learn things like environment mapping, gamma-correct per-pixel lighting, hardware skinning, post-processing effects, etc. It just works, almost everywhere, and I don't see the point in writing off old hardware as trash before the end of its natural life.
- vidarh 5y ago
  I'm not so sure you disagree that much with the author as you think. The API's they're arguing against teaching are OpenGL 1 and 2. OpenGL 2.0 dates to 2004. OpenGL 1.0 dates to 1992. OpenGL 3.0 was released in 2008. OpenGL ES 2.0 was released in 2007. This rasteriser is modeled on OpenGL 3.x. So your recommendation and what they consider [the start of] "modern OpenGL" are about a year apart.
  - flohofwoe 5y ago
    IMHO the OpenGL 1.x API style still has a place in many areas where rendering performance doesn't matter much. The matrix stack and begin/end functions are a very convenient way to get some 2D or 3D triangles and lines on screen (vs having to deal with buffers and shaders).
dlsa 5y ago
Aside about that README file: its laid out better than plenty of research papers I've been reading lately and the professors who ostensibly wrote those papers should know better. Kudos just for that.
- robertwinkler 5y ago
  Thanks! I put a lot of time into my initial draft/structure and I thought it turned out well so I appreciate the kudos. Still have to fix the inevitable typos though.

185 points by kk6mrp 5y ago

So reading this: > [Vulkan] really is overkill for learning 3D graphics...using modern OpenGL to introduce all the standard concepts, vertices, triangles, textures, shaders, fragments/pixels, the transformation pipeline etc. first is much better than trying to teach them Vulkan and graphics at the same time... ...got me wondering. I haven't really kept up with modern graphics programming, but my - possibly incorrect - understanding was that not only is Vulkan lower-level than OpenGL, it was also motivated by lots of questionable design decisions that OpenGL was kind of stuck with. So, with the above quote in mind, is it the case that: * Vulkan is good (?) but too low-level for most users. * OpenGL is a good environment to learn or do nuts & bolts 3D programming in - i.e. it's the right level of abstraction for that - but is kind of a mess. Is that correct? Is there anything that splits the difference? How's Direct3D these days? Metal? Has anyone built a library on top of Vulkan, targeted roughly around the abstraction level of OpenGL, but with a better design?

qbasic_forever 5y ago
IMHO check out Three.js for learning and beginners, it's a very nice abstraction and scene graph that you can just start hacking on right in your browser on any device.
jms55 5y ago
> Has anyone built a library on top of Vulkan, targeted roughly around the abstraction level of OpenGL, but with a better design? WebGPU more or less fills this gap. It's built on top Vulkan/Metal/DirectX12 primarily, and targeted as a WebGL2 replacement, but there's also major interest (and right now, better support) around using it natively for games and other programs. There are bindings for Rust, C++, C, and Javascript (either through the browser, or using deno for native). Here's an excellent tutorial that uses Rust, although the API is more or less identical across languages https://sotrh.github.io/learn-wgpu/ https://sotrh.github.io/learn-wgpu/.
sandGorgon 5y ago
https://docs.imgtec.com/Introduction_to_APIs/Vulkan_Migrating_from_OpenGLES/topics/vulkan_migrating_introduction.html https://docs.imgtec.com/Introduction_to_APIs/Vulkan_Migratin... This is a very nice comparison for people looking to explore Vulkan...even versus native frameworks like Metal (on OSX). P.S. I dont think OpenGL is supported on OSX anymore. However Vulkan has MoltenVK which works on OSX - https://github.com/KhronosGroup/MoltenVK https://github.com/KhronosGroup/MoltenVK MoltenVK is officially supported and is a big part of the Vulkan Portability initiative - https://www.vulkan.org/portability https://www.vulkan.org/portability MoltenVK is fully production ready. Multiple games use MoltenVK to run on OSX using Vulkan. Including the big one - DOTA 2 (https://www.gamingonlinux.com/2021/09/dota-2-to-drop-opengl-and-32bit-vulkan-default-on-linux-and-ti-21-tickets-on-september-22/ https://www.gamingonlinux.com/2021/09/dota-2-to-drop-opengl-...). The bug tracker for DOTA2/Vulkan is here - https://github.com/ValveSoftware/Dota-2-Vulkan https://github.com/ValveSoftware/Dota-2-Vulkan https://www.youtube.com/watch?v=xDGQcjqpYqI https://www.youtube.com/watch?v=xDGQcjqpYqI (M1 macbooks running moltenvk games)
- valleyer 5y ago
  OpenGL is still supported on macOS, though its use is discouraged. (This is what Apple means when it says it's "deprecated".)
  - thatjoeoverthr 5y ago
    Last time I had to use it, it had an old version and was missing some features, disallowing use of compute shaders.
    - inDigiNeous 5y ago
      OpenGL on macOS has been stuck on 4.1 + some 4.2 extensions since 2012 IIRC.
  - barchar 5y ago
    Apple's OpenGL implementation has always been mediocre even when it was technically supported.
Jasper_ 5y ago
As a professional graphics programmer at a well-known game studio, who has taught and mentored a lot of people: Direct3D 11 is quite good. D3D12 is a bit more like Vulkan, but not too far in that direction. In order of recommendation for learners, just rating each API on its own merits without considering other factors like portability: D3D11, Metal, WebGPU, D3D12, OpenGL and Vulkan. OpenGL and Vulkan score last place for similar and opposite reasons: both their APIs are a mess, the debugging and tooling story is still underdeveloped. But while OpenGL has backwards API design that often gives users a wrong impression about how GPUs work, Vulkan instead is much more annoying, requiring the user to cross their T's and dot their I's, while still not giving good guidance towards how they should be structuring their rendering code. I am also eternally annoyed at things like VkFramebuffer which should have never existed (yes I do know it is not required in the latest version). I would rank WebGPU higher (disclaimer: I contribute to the WebGPU spec) since the API is a great intermediate, except WGSL is too new and too underbaked for me to seriously recommend it right now. The native implementations Dawn and wgpu are committed to supporting SPIR-V input, which is how I would recommend using it right now. Happy to answer questions or elaborate on this.
- bsder 5y ago
  Your Windows bias is showing. :) Personally, I find the Vulkan API to be one of the best designed APIs ever, and the debugging tools on desktop are okay. On Android, I'd say the Vulkan tools are, in fact, quite excellent. I can't compare them to iOS though. The problem with Vulkan and DirectX 12 (which I find to be so close as to be indistinguishable) has nothing to do with their APIs. The main problem is that "modern" graphics is only tangentially related to rendering triangles--and rendering triangles is normally what beginners really want to do. A lot of beginners also want to render 2D paths--and graphics APIs for that are horrifically bad. "Modern" graphics is mostly about creating a bunch of low-resolution "geometry buffers" and then scanning every single pixel on the screen only once while building the pixel up from some mathematical combination of those lower resolution buffers. Yes, there are triangles involved at a Platonic level, but many of the triangles are smaller than a pixel. See the Unreal Engine 5 demos: https://www.youtube.com/watch?v=qC5KtatMcUw https://www.youtube.com/watch?v=qC5KtatMcUw It's reached a point that "modern" graphics almost doesn't even want a triangle renderer--it just wants pure access to the massively parallel memory and computation pipeline on the GPU and the ability to smash the results into a framebuffer. Vulkan and DX12 reflect this, so they don't really mesh well with beginners. (I'm being a bit glib, but there really is a massive chasm between "modern" game rendering techniques and the kind of 2D/3D that GUI/CAD/Application developers want to use.)
deleted 5y ago
[deleted]

mnurzia 5y ago

Not entirely related to the subject of OpenGL, but I really like how the author has decided to lay out this project. It's pretty hard to beat the convenience of a single header (or single header/single source) distribution for C libraries, but library development gets progressively harder as the project gets bigger as more code is added to the (usually hard to navigate) header file. Here, the author does their development with multiple files as one normally would, but when a new version is released they run the generate_gl_h[1] script that concatenates everything into a .h file for distribution. Simple yet flexible! This is also how SQLite[2] distributes its builds. It's a pattern that I'm using myself in some unreleased projects. [1] https://github.com/rswinkle/PortableGL/blob/master/src/generate_gl_h.py https://github.com/rswinkle/PortableGL/blob/master/src/gener... [2] https://www.sqlite.org/amalgamation.html https://www.sqlite.org/amalgamation.html

blondin 5y ago
the original stb libraries did the same. single header doesn't mean you have to develop in one file, although you totally can.
- mnurzia 5y ago
  Just because I was curious, I did a little digging: A cursory look at Sean Barrett's website on the Internet Archive lists Dec. 2006 as the first date where stb_image was published (but looking at the file, versions go back much further than that) https://web.archive.org/web/20061205030342/http://nothings.org/ https://web.archive.org/web/20061205030342/http://nothings.o... That means for 15+ years, he's been iterating on the same file. It certainly works as a development style, but I personally feel that it's easier to edit a set of smaller files.
  - tom_ 5y ago
    Original forum thread suggesting the first release was in Nov 2006: http://web.archive.org/web/20120419172714/https://mollyrocket.com/forums/viewtopic.php?t=315&sid=1e1583d6149ac8698ea35e20a6333a91 http://web.archive.org/web/20120419172714/https://mollyrocke...

blondin 5y ago

isn't opengl3 not recommended anymore?

FrostKiwi 5y ago
I'd consider OpenGL 3.3 today's lowest common denominator, if you are after backwards compatibility. It removed the intermediate mode pipeline and introduced the Core profile, making it a good candidate for the lowest thing to target. In OpenGL 2.1 you can pull in essential features like shader4 and UBOs via extensions, but 3.3 made it core. New ways to interact with OpenGL like DSA are generally available via extensions as well. It's "not recommended" mainly because Apple is the odd one out in removing support for it.
- _0ffh 5y ago
  Q: What is intermediate mode? Is it an accidental "autocorrect" of immediate mode or an actual thing?
  - FrostKiwi 5y ago
    Ohh, yeah! Supposed to be immediate mode. I swear I typed it correclty O.o
- greggman3 5y ago
  OpenGL ES 3.3 is arguably not "lowest comment denominator" if you add in Android, iOS, iPadOS, AppleTV, Raspberry PI, and Web

oso2k 5y ago

Fabrice Bellard released an OpenGL 1.x/2.x software renderer 20 years ago [0]. There seems to others who have taken to updating it more recently [1][2]. It is direct mode or immediate mode but this is how we used to do graphics more than 15 years ago. Might help others to read this if you're interested. [0] https://bellard.org/TinyGL/ https://bellard.org/TinyGL/ [1] https://github.com/C-Chads/tinygl https://github.com/C-Chads/tinygl [2] https://github.com/ska80/tinygl https://github.com/ska80/tinygl

dimatura 5y ago

This is pretty cool, I've looked for libraries like this myself in the past. Sometimes I've needed to render a bunch of simple 3D graphics off-screen, without any real-time or high-throughput requirements (mostly for visualizing 3D stuff in robotics/computer vision). Setting up GPU-based pipelines for this is possible, but can be kind of kludgy and annoying. Mesa3D can do opengl software rasterization, but it's also a nontrivial dependency. I've ended up writing crappy rasterizers in the past just to avoid all that hassle. A single-header solution for this that's more up-to-date than TinyGL is welcome.

samwisehamgee 5y ago

> I took a 400 level 3D Graphics course in college in fall 2010 months after OpenGL 3.3/4.0 was released. It was taught based on the original Red Book using OpenGL 1.1. Fortunately, the professor let me use OpenGL 3.3 as long as I met the assignment requirements. Sadly, college graphics professors still teach 1.x and 2.x OpenGL today in 2020 This one hits home. I did my first (and only) graphics programming in college in 2019 and it was indeed OpenGL 1.1 to make matters even more stupid, it was a course where the opengl part was only half the course, the other half was about image processing using matlab... I dont know what it is about graphics programming, I've tried many times to learn it but its so different to any of the other programming I've done that it feels totally impenetrable.

Archit3ch 5y ago
> This one hits home. I did my first (and only) graphics programming in college in 2019 and it was indeed OpenGL 1.1 to make matters even more stupid, it was a course where the opengl part was only half the course, the other half was about image processing using matlab... Why is this so relatable? First (and only) graphics course in 2019, fixed (1.x) pipelines, down to memorising individual API calls for the (paper) exam. To their credit, the professor admitted it was out-of-date: "You're never going to use these in real work, it's only here to teach you rotations with matrices etc." I wonder what graphics programming looks like these days. DL anti-aliasing?

Shadonototra 5y ago

that's pretty nice! any plan for GLES 3.0? something that would allow to target WASM too

greggman3 5y ago
If you want GLES 3.0 why not use ANGLE? It works on top of OpenGL, Vulkan, Metal, DirectX 11 https://chromium.googlesource.com/angle/angle https://chromium.googlesource.com/angle/angle It's also fairly well tested given that it's used in Safari, Firefox, Edge, and Chrome
- Shadonototra 5y ago
  angle is different, i don't want any of vulkan/metal/directx i want opengl i don't need bloat and carry what i don't need it just adds useless complexity also building angle is weird it is bloat driven culture, i am against that
  - greggman3 5y ago
    You say you don't want bloat but OpenGL by definition, is bloat. Then you apparently want a wrapper on top if it. Ok?!?!?

ReactiveJelly 5y ago

> Using modern OpenGL to introduce all the standard concepts ... is much better than trying to teach them Vulkan ... and obviously better than teaching OpenGL API's that are decades old. I disagree on teaching old APIs. This is a pet peeve of mine, and I thought the author of a software rasterizer would agree with me. GPU APIs are some of the only APIs where you have to pay to upgrade. Sure, Vulkan has been "out" for 4 years. But I haven't bought any hardware that supports Vulkan. My last purchase was a used laptop with an iGPU. I buy hardware as a last resort when I absolutely need it, I especially don't buy hardware for the APIs when my old hardware has enough GFLOPS. I like that programming is a cheap hobby. I don't see the point in anteing up every few years. Per-core CPU power has plateaued, and I can add more storage to old systems easily. I just don't want to buy new hardware until I see the GPU space settle down for a few years. And when will that happen? Vulkan 2? Vulkan 3? How many more perfectly functional TFLOPS of GPU chips will be branded e-waste before the APIs are stable? I don't like the implication among some gamedevs that your programming skill depends on how much tribute you've paid to NVidia. I don't make bad games because I use GLES 2, I make bad games because I'm a bad gamedev. GLES 2 is a sweet spot in the tradeoff between compatibility and features. It dates to about 2007, so even a kid with a cheap used Android phone could theoretically write GLES 2 code for it. It doesn't have geometry shaders, but with vertex and fragment shaders you can still learn things like environment mapping, gamma-correct per-pixel lighting, hardware skinning, post-processing effects, etc. It just works, almost everywhere, and I don't see the point in writing off old hardware as trash before the end of its natural life.

vidarh 5y ago
I'm not so sure you disagree that much with the author as you think. The API's they're arguing against teaching are OpenGL 1 and 2. OpenGL 2.0 dates to 2004. OpenGL 1.0 dates to 1992. OpenGL 3.0 was released in 2008. OpenGL ES 2.0 was released in 2007. This rasteriser is modeled on OpenGL 3.x. So your recommendation and what they consider [the start of] "modern OpenGL" are about a year apart.
- flohofwoe 5y ago
  IMHO the OpenGL 1.x API style still has a place in many areas where rendering performance doesn't matter much. The matrix stack and begin/end functions are a very convenient way to get some 2D or 3D triangles and lines on screen (vs having to deal with buffers and shaders).

dlsa 5y ago

Aside about that README file: its laid out better than plenty of research papers I've been reading lately and the professors who ostensibly wrote those papers should know better. Kudos just for that.

robertwinkler 5y ago
Thanks! I put a lot of time into my initial draft/structure and I thought it turned out well so I appreciate the kudos. Still have to fix the inevitable typos though.