Footnotes

[1] 1:03 - Technically speaking, the GDI already enables you to be able to speak to the GPU quite directly. It's more fitting to say that I'm looking for an option that gives me finer control over GPU rendering other than some basic shapes.

[2] 3:18 - https://www.reddit.com/r/Citra/comments/yjhfxg/vulkan_vs_opengl_performance_comparison/

[3] 5:17 - My wording here kind-of implies that you can destroy a window in order to automatically destroy any of its OpenGL contexts, but this incorrect; destroying a window with an existing OpenGL context is undefined behavior.

[4] 23:12 - I use the term 'graphic system' instead of 'graphics API' to refer to it because I already defined the type 'muGraphicsAPI' in muCOSA. These terms are practically interchangeable.

[5] 31:25 - Not really. Win32 freezes the window while it's being resized, so it'll only be updated once the user stops resizing it; the window is frozen while the user drags to resize it. I tried finding an easy workaround for this back when I was making muCOSA, but couldn't find one that worked well, although I presume there is some way.

[6] 34:06 - Most graphics APIs use the term 'point' instead of 'pixel' primarily because they provide a way to customize how big a point is when being rendered, meaning that points can be rendered at a size larger than one pixel.

[7] 34:51 - Actually, if you want the point to be visible in the bottom-right, its coordinates would need to be the dimensions of the graphic minus one to squeeze it into frame. Setting their coordinates to the dimensions of the graphic would put it barely outside of the rendering space. 🤓☝️

[8] 35:22 - Quote this guy on Reddit for that: https://www.reddit.com/r/learnprogramming/comments/56fl0c/comment/d8iwgzq/

[9] 37:55 - It's quite difficult for the colors of a semi-transparent object to be blended with another object if the other object hasn't been rendered yet. https://www.sjbaker.org/steve/omniv/alpha_sorting.html

[10] 41:24 - ...until the GPU runs out of available memory, obviously.

[11] 43:27 - Obviously, the GPU doesn't execute your instructions totally directly, since that'd be unsafe.

[12] 44:29 - Shaders are not strictly the only way to draw things onto the screen in OpenGL, as OpenGL does provide some other simpler (although usually less efficient and/or customisable) ways.

[13] 48:43 - This is technically incorrect. The term 'fragment' is more accurate for describing what the fragment shade rfills in, which is different from what a pixel is. In the scope of this video, though, it's probably just best to pretend that a fragment and a pixel are the same thing. I mean, I guess I could've brought it up in the multisampling portion, but eh. https://stackoverflow.com/a/45373885

[14] 53:53 - This is technically incorrect. The way OpenGL allows you to transfer data from the CPU to a GPU buffer is by giving it the data on the CPU, which it directly transfers to the buffer; you need to have the data meant for the GPU buffer already on the CPU before transferring. This means that if the mugPoints array differed in how it was stored on the GPU buffer, I would first need to allocate new data on the CPU, copy over the data from the pre-existing mugPoints array to the newly allocated data in the format that the GPU buffer expects, and then copy it over to the GPU buffer. But this is too stupidly complicated (both in terms of how complicated it is and how much of a technicality it is) to explain in the video, in my opinion.

[15] 56:33 - Actually, since I've built mug to theoretically handle supporting multiple graphics APIs, each high-level mug function makes sure that the graphics API running for a given graphic is OpenGL before calling its corresponding OpenGL function.

[16] 1:08:26 - Again, not technically correct; 'gl_FragCoord', as the name suggests, represents the coordinates of the current fragment being processed.

[17] 1:13:18 - For the sake of simplicity, in the video, I say that I set the alpha to 0 or 1, but this isn't what's actually done in the GLSL code. For pixels that are supposed to be invisible, the alpha is set to 0, yes, but for pixels that are supposed to be visible, I just set the alpha to the vertex color's alpha, along with the red, green, and blue channels like usual. For the smoothing functions that come later whose alpha values can range between 0 or 1, I multiply the function's alpha by the vertex's alpha to blend the two. This isn't insanely relevant to the video, and is kind-of unreasonably hard to wrap your head around, though.

[18] 1:24:15 - Technically not true: negative exponent values can mess with it.

[19] 1:27:41 - Since the initial editing of this video, I have actually come up with a single formula that can define a rounded rectangle! This does make, like, the next following 5 minutes cover a formula that's actually worse than one than I'm aware of currently, so I may cover this in a follow-up video, or in any video that I come back to mug. If you're interested in the formula, copy and paste this into Desmos: \max\left(\left|x\right|-\frac{w}{2}+r,0\right)^{2}+\max\left(\left|y\right|-\frac{h}{2}+r,0\right)^{2}\le r^{2}

[20] 1:33:01 - This is where I start accounting for the center position despite me never mentioning it for the rounded rectangle. Sorry!

[21] 1:35:16 - The terms 'texture' and 'image' are used interchangeably within this video.

[22] 1:42:50 - The 1024x1024 example provided is adjusted to be to-scale if you're watching this 1280x1024 video on a 1920x1080 monitor, which you likely are, you poser.

[23] 1:43:48 - https://www.khronos.org/opengl/wiki/Array_Texture#Limitations allows you to do it theoretically, although there is a fair chance that there would be insufficient memory given just how large an image of that size is (over a gigabyte assuming RGBA).