SORE

So we have vertices that map to points, and these points are slaves to the primitive.
Order of vertices don’t really matter. (pos1, pos2, pos3) or (pos2, pos3, pos1), or (pos1, pos3, pos2) or any other position order doesn’t affect the fact that it’ll always just end up a triangle.

But when you have multiple triangles, and when a triangle has a side that is also the side of another triangle (think of conjoined twins), you got a problem.
(pos1, pos2, pos3), (pos2, pos3, pos5).

You used pos3 and pos2 twice.
What’s the solution?

(pos1, pos2, pos3)
(0,1,2).

That’s right, we’ve decoupled the indices.
Swap the indices around, and you swap how the vertices are ordered, without actually ordering the vertexes.

(deleted a whole paragraph thoroughly explaining EBOs cause words >2000..)
They’re much simpler than you think though, im just a yapper)

Vertex attributes. They basically give us position, color, and whatnot. They’re ‘attributes’ in a literal sense.

You have a VBO (vertex buffer object), which just aggregates vertices for optimization and quality of life. They’re nothing more than that. (at least I believe)

Then you have a VAO (vertex ARRAY object), which aggregates vertex attributes for quality of life. It’d be a hassle to set up vertex attributes for each and every single vertex in a vertex buffer, right?

You also have shaders, like vertex shaders and fragment shaders. These are like components of the graphics pipeline that take your (pos1, pos2, pos3) vertex data, and do stuff with it. For example, vertex shaders take the (pos1, pos2, pos3) and output a new thing (i forgot what the thing was), or fragment shaders that take primitives and give them a color.

You then have a shader program, which just attaches all these shaders above (vertex and fragment shaders in this case), and links them together. In the render loop, you run a function that ‘uses’ the shader program (literally called glUseProgram()).

Sorry, i was setting up hackatime on visual studio the past 2 days.
Alright!!

So, im getting the hang of opengl, glad, and glfw.

Here’s my rundown (i can be wrong, this is just my ‘knowledge thus far’):
Basically, you start by initializing glfw through glfwInit() and then ending with glfwTerminate();.
glfw handles the input, audio, and the actual window.

OpenGL is a specification, and an API, so im using glad because uhh it has the API i guess?

Anyways, we have a vertex shader. This little guy takes in a vertex one at a time, and outputs another vertex.

The vertex shader takes in an Vertex Array Object, which just holds the attributes of the vertex, and references to the vertex (ill get to attributes soon), alongside with the Vertex Buffer Object, which holds the actual vertex.

Attributes are, im guessing, properties? Like color, or position, or whatnot.

In OpenGL, we have to Bind things, and Unbind them. I’m guessing this is just like a lock, so you dont tamper with things?

Okay, so in OpenGL things go one frame at a time. Since we need actual streaming output, OpenGL just lets us set up a while loop to update the frame real quickly; this while loop repeats until the window is closed, basically a game loop data pattern :D

In here, you realize that we don’t just send things to the screen and they work. We need a double buffer, which i believe allows you to fully prepare things in the back buffer while the front buffer is working?

In this back-buffer, you set up everything–the background color, the elements, the triangles you want to display, all of it. Once you’re done, you SWAP the buffer, and now you got a perfect scene.

If you didn’t use two buffers, the user would have to watch each element get sequentially added, and that’s not good!

THIS IS ALL I’VE GOT TODAY, LETS SEE YOU NEXT TIME!
(dont know what that eye is, i’ll find out tomorrow!!!)