LearnOpenGL VS CppCoreGuidelines

Learning OpenGL. https://gamemath.com/ is free and a great way of explaining most of the math in an intuitive way without getting handwavy or imprecise. https://learnopengl.com/ is also free!

At the end of the day, it's all just maths and physics.

You didn't specifically ask about game development, but that domain is where the majority of graphics, mathematics, lighting, physics, etc, knowledge is distributed. And it can be difficult to find information solely about (e.g.) cloth simulation and other niche topics without it being coupled into game development resources.

I happened to read https://alextardif.com/LearningGraphics.html today, which might give you some pointers in various directions. https://learnopengl.com/ gets a consistently good rap, even today when there are newer APIs like Vulkan and Metal. Consider the API as 5% of the problem to solve though (less tbh, though Vulkan is proving even heavier than I was warned).

If you don't want to learn C/C++, I understand there's a large community around WebGL, so finding their subreddits and other forums could be a good starting point too.

However, again, the API and platform is really just a wrapper around the actual physics simulation (the impressive part).

Learn OpenGL - A free OpenGL tutorial suitable for learners looking to deepen their understanding of graphics APIs, visit http://learnopengl.com.

Me and a friend build our own Graphics engines based on https://learnopengl.com I can highly recommend this to everyone who gets started with computer graphics. It is a lot of new information but not the most modern Graphics library, but the information will help you understand the field and pickup any other graphics library quicker. Once I had a small project up and running I started looking at https://emscripten.org/ to combine it with some web experiments and more easily share my work with other over the web. I also started looking at https://vulkan-tutorial.com/ and https://webgpufundamentals.org/ to experiment with geometry shaders.

Next to Realtime Graphics you could also dabble into the world of Ray-Tracing. Personally I'm still quite new to this field but my master thesis supervisor also gave lectures at an other university where they recoded a lot of lectures during Covid. Advanced Computer graphics at the UU for example https://ics-websites.science.uu.nl/docs/vakken/magr/2021-202... The course recommends https://raytracing.github.io/ as a resource to students, and I can also recommend this.

As a small note to end with, the website(s) of professors giving computer graphics are a true tressure trove of information: https://jacco.ompf2.com/ https://www.3dgep.com/cpp-fast-track-1-getting-started/

Somewhat related, I'm trying to convert the Learn OpenGL tutorials [0] to LÖVR [1]. The main goal is to understand the changes needed to convert the Open GL shaders to the LÖVR version, as there are some changes.

---

[0]: https://learnopengl.com/

[1]: https://github.com/wolf81/lovr-learnopengl

Wvhile browsing over the net, one website stands out learnopengl.com. It looks very well-structured, have covered a variety of different topics and have links to the source code. And that is not only about the code, but building an important understanding what is going on behind those lines. I'm pretty sure I will go over the articles over and over again to refresh certain aspects when I actually need them.

Also recommended: LearnOpenGL [1] and Vulkan Guide [2]

[1]: https://learnopengl.com/

"C++ Core Guidelines" by Bjarne Stroustrup and Herb Sutter Read the guidelines

I've found both explicit future/promise management and coroutines difficult (even irritating) to reason about. Co-routines look simpler at the surface (than explicit future chaining), and so their the syntax is less atrocious, but there are nasty traps. For example:

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

I liked "Effective Modern C++" although that is a little bit out of date by now. Stroustrup's recent article "21st century C++" https://cacm.acm.org/blogcacm/21st-century-c/ . There are also the C++ core guidelines though maybe those are also out of date? https://github.com/isocpp/CppCoreGuidelines

I've been looking at Rust and it's an improvement over C, but it still strikes me as a work in progress, and its attitude is less paranoid than that of Ada. I'd at least like to see options to crank up the paranoia level. Maybe Ada itself will keep adapting too. Ada is clunky, but it is way more mature than Rust.

I haven't read much from Bjarne but this is refreshingly self-aware and paints a hopeful path to standardize around "the good parts" of C++.

As a C++ newbie I just don't understand the recommended path I'm supposed to follow, though. It seems to be a mix of "a book of guidelines" and "a package that shows you how you should be using those guidelines via implementation of their principles".

After some digging it looks like the guidebook is the "C++ Core Guidelines":

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

And that I should read it and then:

> use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).

Which seems to be this (at least Microsoft's implementation):

https://github.com/microsoft/GSL

And I'm left wondering, is this just how C++ is? Can't the language provide tooling for me to better adhere to its guidelines, bake in "blessed" features and deprecate what Bjarne calls, "the use of low-level, inefficient, and error-prone features"?

See this: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

Technically, headers are just copy-paste, obviously. However, there's value to keeping them as standalone as possible.

> close a file (which ironically is the poster child for RAII)

Yes, I call this "RAII is a lie" (T-shirt pending).

Closing file descriptors is univerally used to showcase RAII, but it should never be used for that.

C++ has the same problem:

https://github.com/isocpp/CppCoreGuidelines/issues/2203

In there, it is acknowledged that a manual Close() should always be provided, and used if you want guarantees.

> is a bad pattern

Good that Rust at least figured it out early that it's a bad pattern!

Never use RAII in situations where the cleanup can fail!

The standard library types are guaranteed to be in a useful state after being moved from (the term "valid state" is used for this). Of course, that doesn't mean that your own types have to, but the C++ Core Guidelines suggest doing so [1].

1: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

It’s in the cpp core guidelines: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

std::reference_wrapper still can’t save you from yourself, but its slightly better.