Forem: NoticeableSmeh

Learning DirectX 12 - Part 1 Boring boring Math stuff

NoticeableSmeh — Sat, 16 May 2026 13:05:20 +0000

Hello and welcome to this little blog where I will be going through Frank D Lunas book on DirectX 12 "Introduction to
3D Game Programming
with DirectX® 12"

This is is supposed to be a blog for helping me gettig a deeper understanding for DirectX 12 however since it might be of interest to some other person out there, feel free to continue reading along this if you too want to get a better understanding of Directx12.

The first section of the book covers Math stuff you need to know, so why not dive into that. I will ofcourse be reading the entire chapters of the book and work my way through it but I will not be providing a detailed walkthrough of the the entire book as that would just take too much time ofcourse. What you will see here is a birdseye view / summary of how directx12 works. First section of the book deals with Vectors so lets start with that.

Vectors:

DirectX12 uses a left handed coordinate system, this is important to note because OpenGL used a right handed coordinate system, and thats what I am used to by now. A left handed coordinate system means that the positive Z axis is pointed away from you, not towards you. Now lets delve in to define more of what a vector is.

I think of a vector as a point in a coordinate system and we compare that point to the origin point to see what direction and length the vector has. So lets say our 2D vector is 1, 1. This would mean that the vector points up and to the right completely diagonally. Now people will tell you that "oh you shouldn't think of vectors as a point in space they can contain / mean other stuff" And to that I say --.

Magnitude
The magnitude of a vector is simply the length of a vector, or more acrrately the length of the directed line. To denote this we put ||u||, | bars around the vector "variable". And to get the magnitude we simply apply pythagoras theorom to our entire vector. So if its a 3D vector thats Sqrroot(x^2 + y^2 + z^2). This would be the magnitude of the vector.

Normalization
You might have heard about this if you have ever done any type of game programming. A common problem with 2D movement diagonally is that its faster than moving just purely left or right. This is because defining a vector as up and to the right would look like this right (1, 1, 0). Whereas moving just purely right would just look like this (1, 0, 0). As you can see were essentially moving another whole extra unit of our vector each time we move diagonally. We can explicitl see this if we calculate the magnitude of our vectors here. The vector moving diagonally would be equal to squareroot of 2 which is aproximately 1,4. We should ideally have the same speed no matter the direction in which we are moving. The way to do this is by normalizing Vectors. This would mean that the vectors magnitude alwas equals to 1. The way to do this is by taking every x , y and z component of the vector and dividing it by the the ssquareroot of the magnitude.

Dot product
A dot procut is the result of multiplying two vectors with eachother. The result is a scalar value. This scalar value we can use to determine the angle between two vectors. Essentially if the result is equal to 0 we the vectors are perpendicular to eachother. If its bigger than 0 then the angle is sharp, pointy. And if its less than 0 then its stubby or obtuse. We have to involve cos Theta into our calculations whihc means we take the scalar product and divide it by the magnitude of vector 1 times the magnitude of vector 2.

The Cross Product
Cross product is used to produce another vector perpendicular to the two vectors. Taking each element (x, y ,z) and multiplying that element with the othr two. So to calculate X you multiply x with y and z. The only exception here is the middle coordinate Y which you change the sign before the number to the opposite, so positive becomes negative and vice versa. This is all sort of abstract right now but will make more sense as we delve into it deeper.

Matrices
Matrices are what allow us to move, rotate and scale objects in 3D space. Think of them as a tool used to transform vectors.

A matrix is grid of umbers, in graphics programming typically you just use 4x4 matrices. Why is that? Because they allow us to handle all transformations in a consistent way when working with 3D vectors.

Vertices
Vertices are what store the actualy data containing our object we import. So a vertex array is an array of point which will paint up a bunch of traingles forming for example a sick dinosaur, matrices are what we apply to those vertices to translate and or transform that vertex array.

Matrix x Vector
Multiplying a matrix with a vector is one of the most important operations. It looks like this v' = M * v. What this means in practice is we take a vertex (a point in our object) and apply a transformation to it. v is the original position, M is the transformation itself and v' is the transformed position or the result.

Transformation
We will cover this more deeply in the next chapter but matrices are used to perform transformations such as moving an object, scaling an object and rotating an object. Instead of manualy changing every vertex we can just multiply them with a matrix.

You can combine multiple transformations into one, rotate then scale then move for example. We can define the matrix via for example M = T * R * S, then just apply that matrix to our vertices like v' = M * v. Efficent right we do not have to calculate each part everytime!

Order matters
Very important to note that the order in which matrix multiplications are done is very important. Rotating an object then moving it is not the same as moving an object and then rotating it! It wouldn't be the same result!

Directx12 Coordinates
You constantly work with the big three in Directx12. These are:

World matrix = Positions of the object in the world
View amtrix = represents the camera
Projection matrix = converts the 3D world into 2D screen space to be drawn on your computer screen.

Homogenous Coordinates
If you have a point (x, y, z) you can scale it, rotate it all using a matrix. But if you want to move it, you cant do that with a normal matrix.

Matrix multiplication is like
new = numbers * old

translation however is
new = old + something

Matrix math doesnt handle the + part.

So we cheat by adding a 1 at the end of our vector / point
(x, y, z, 1)

That extra 1 lets the matrix sneak in a constant value, which allows us to actually translate the location. Without the 1 there would be nothing for the matrix to multiply with to add to those values. So the 1 turns multiplication into addition so to say.
This is also essentially why we use 4x4 matrices in graphics instead of 3x3.

I have a headache now so I'm gonna end the math stuff here and cover more the directx initialization theory in the next part. See you there!

Rasterizer Project - The end? is published

NoticeableSmeh — Fri, 07 Nov 2025 22:11:43 +0000

NoticeableSmeh

Nov 7 '25

Rasterizer Project - Part: BASIC_END

#cpp #graphics #learning #gamedev

Comments

4 min read

Rasterizer Project - Part: BASIC_END

NoticeableSmeh — Fri, 07 Nov 2025 22:11:30 +0000

Hello folks lets continue working on this rasterizer, lets get the rasterization going and then were putting this project on hold for a while. I will be making the DoingOpenGL series after this part were I will get a graphics demo going for OpenGL stay tuned for that but heres what were doing today.

So to avoid going too into detail and just making this just completely unreadable I will be trying to keep my explanations more concise and quicker with fewer images just so we can get through this stuff together folks

Here is our triangle fill function, this essentially takes coordinates for 3 different points and fills the area between them. This is finally were barycentric coordinates finally get more useful but more on that in just a second.

Anyways we stard by defining our max and minimum on our 2D plain view for both the X and Y coordinate, this is simply just to ensure that we never paint outside the actually triangle.

So to figure out if a pixel should be painted or not (in other words if its inside the triangle) You use barycentric weights. These are essentially three numbers that symbolize how close that pixel is to each vertex of the triangle hence why we have three numbers. Inside the triangle those numbers always stay between 0 and 1 so we are essentially just making sure that none one of them are negative and all of them added together sum up to 1.
That is what this if statement checks here

For the more meaty math lets take a look more here

denom here is jus tone big number that represents the triangles size and if its zero that means the points are all on one line, nothing to fill essentially. The way to calculate it is from the differences between the triangles points, how far apart they are on each respective axis. Were counting the area here folks essentially we just dont care about dividing it with 2 because it doesnt really serve a purpose in knowing the exact area size, we care about ratios.

So in our code we define our direction of calculating the side that is inside (good side) or outside (bad side) from clockwise direction, which is different from how a lot of other program use it. This however is still fine but this means that if we were to orient our Edges upright it would mean the right side is the side that is inside the triangle and the left side is the one that is outside.

Phew, I am not very good at math but thats my best attempt at explaining this for you as simple as I could.

Time to break down this function. This function has my favorite type of for loop (yay) and it loops through our face count (our amount of triangles inside of our model.

Each face in our model has three vertices, of course, and we then project those vertices into a 2D view, since we’re currently rendering in 2D space. Although the model itself exists in 3D, we’re essentially flattening it onto the screen, turning it into a 2D representation we can draw.

We retrieve each vertex based on the current face index in our loop (since faceCount gives us how many total faces we have). From that index, we can access the first vertex (our A coordinate), then the second (B), and finally the third (C).

Note: Remember that in programming, we start counting at 0, not 1!

Then that backface culled skips triangles that are facing away from the triangle, more on that in a second. And the color of the triangle each gets a random RGB value so via a modulo variation that makes it always unique thanks to our facecount index. I say random in the sense that I have no clue what colour it will be when you run it but really it will always be the same colour on compile.

Alright so this function essentially checks if the triangle is facing toward or away from the camerea. So the first part abx and acx we make towo edge vertex, vertex from a to b and a vertex from a to c. These vectors describe the direction of the triangle in 2d space. Then we are computing the 2D cross product via area2. If the tirangle area is zero or facing the wrong direction dont draw it! Simple. Anyways lets load this cow! That I found on the internet.
https://www.cs.cmu.edu/~kmcrane/Projects/ModelRepository/

So we declare the model and the name of the file as we did in the previous part and then we call our function drwa model filled and pass in the model and our framebuffer and voila

There we go folks,

Thank you for reading and here are some useful links aswell as sources

https://haqr.eu/tinyrenderer/
https://www.cs.cmu.edu/~kmcrane/Projects/ModelRepository/
@article{crane2013robust,
title={Robust fairing via conformal curvature flow},
author={Crane, Keenan and Pinkall, Ulrich and Schr{\"o}der, Peter},
journal={ACM Transactions on Graphics (TOG)},
volume={32},
number={4},
pages={1--10},
year={2013},
publisher={ACM New York, NY, USA}
}

https://3d.si.edu/object/3d/triceratops-horridus-marsh-1889:d8c623be-4ebc-11ea-b77f-2e728ce88125

https://github.com/nothings/stb

The git repository for this project is also avalible at: https://github.com/NoticeableSmeh/Rasterizer_Project

Rasterizer Project - Part 4: Its out featuring Dinosaurs (rawr)

NoticeableSmeh — Wed, 05 Nov 2025 13:49:59 +0000

Rasterizer Project - Part 4: Triceratops Wireframe

NoticeableSmeh ・ Nov 5

#gamedev #cpp #graphics #learning

Rasterizer Project - Part 4: Triceratops Wireframe

NoticeableSmeh — Wed, 05 Nov 2025 00:15:36 +0000

Okay so its time to define our model class both its .h file and cpp file. Lets start with the .h file.

First lets define a vector list made of of different vec3 that our model consists of and then lets.

Then we store each face inside the int list. What is a face? Well every 3 vertexpositions we can draw a triangle, that triangle is the face.

Then for our public class stuff. Our constructor takes a string path (constant so we dont fuzz about with it accidentally later on). Then our functions, quite simple. Constant get functions because we dont intend to change models after they have loaded in right now so our vertex count and face count will not change. Lets take a look at the cpp file now

Lets start simple with this little helper function that takes a reference to str and the reference we have to check if equivalence. Our .obj files for models are essentially text files with data stored in rows, each row starts with v or f and if the program sees those it knows what type of data the numbers after are. Heres an example:

those are the vertex positions for example that we have to read.

Anyways the helper function checks if the str size is larger or equal to the reference, then we actually check if our firstletter is correct with the compare function.

The compare function works like this, takes this string we have and start from this position in the string (0) and continue until the end of this index (firstLetter.size(), then if its equal to this string (firstLetter) then its correct and therefor == 0. 0 Means they are equal.

So lets go through this constructor.
We create a ifstream that takes our filepath and tries to find it, if it cant fidn it it throws an error.

Then we go line by line and read the line and if the line starts with the letter v we use a istringsteam to be able to manipulate the string, essentially we skip the first two positions in the string with substr(2) (More acurately we start at 2.
Then we feed in our coordinates with istringstream dynamically because istringstream are super usefull and we place them in our vector list but we use emplace_back to create a new vec3 in our vector list.

We do the same thing if the line starts with "f", which means it defines a face.
Each face line in an .obj file contains multiple vertex references separated by spaces — for example:

f 1/2/3 2/3/4 3/4/5

We split the line into separate sections (like "1/2/3", "2/3/4", etc.).
Each section contains vertex information, where the first number before the slash refers to the vertex index.

To extract that, we look for the first / in the section using find('/').
Then we take everything before that slash thats the vertex index we care about using substr(0, slashPos).
We convert it to an integer with stoi() and subtract 1, because .obj files use 1-based indexing, but us programmers like to start at 0.

Then we just store that int in our int list.

getVertexCount we return the size of our vertexPositions list.
Facecount we return how many faces our object has, its the amount of faceVertexIndices / 3 because 3 vertices make up a triangle duh.
getVertex gets you the vertex from the index you send in.
getVertexFromFace() This method takes a face index (yknow triangle) and a corner number which represents a vertex of that triangle then looks up which vertex that corner refers to and returns its 3D position. So for this to make sense we have to remember that our faces are defined in our .obj file as "f 1/2/3/" etc etc, so were essentially saying, gimme the second vertex (in plain english)! It would return the number 2 in that.

Next lets head back into our main c++ file. So our models are in 3d right but we are presenting our models on a 2D plain, we have to have a function that converts 3d space into 2d space projection.

Alright so what this function does is take our 3D vertex coordinates that go from -1 to +1 (you know, model space) and remap them to 0 to screen size. We basically stretch our model to fill the whole screen.
Then we just return those two values (x and y) so we can use them as pixel coordinates when drawing lines between points.

Here we see were we instantiate our model and declare its file path but also how we draw it out!

So once our model has loaded we create my favorite type of for loop which i use for like everything lol. But we declare a starting int variable and then we add + everytime we complete the loop and it finished when the model runs out of faces. So we retrieve the vertexes from their face respectively, this is where we get to use our getVertexFromFace function finally and here we also confusingnly get to use programming language with our index "Start at 0 for the 1 position this time!". We assign those vertices and then we project those vertices via our project function in order to figure out where they should be on our screen.

Then finally we draw our beautiful lines, and by the end we will have this beautiful triceratops that totally does not look like a big blob.

Rasterizer project - Part 3 is up! Its all about 3D math. It was actually quite a fun thing to write about.

NoticeableSmeh — Sat, 01 Nov 2025 23:16:07 +0000

NoticeableSmeh

Nov 1 '25

Rasterizer Project - Part 3: Geometry

#cpp #learning #graphics #gamedev

Comments

5 min read

Rasterizer Project - Part 3: Geometry

NoticeableSmeh — Sat, 01 Nov 2025 23:15:16 +0000

So lets create a geomtry.h so we can actually calculate the 3d math we need for our rasterizer to work.

Lets start with this struct. This is ofcourse a vector 2, 2 coordinates. Default constructor is asserting 0, 0 on them, otherwise you can declare them.

The operator functions return asign so you can return a value of either the x of y via an integer. What helped me understand this is to think of like OpenGl VertexAttrib, or assigned textures in Opengl. You assign them to an int and via that reference you can access that component in the array.

The vec3 struct works the same but with 3 components instead of 2! Excitng. What is assert? Well it checks wether or not a condition is true and if it isnt lets crash the program and display a problem so we can see what went wrong.

Now lets do math magic, this is math guys this is all math.

Except this one here this is just an overrided function that allows us to write out a vec2 as a string with our cout, its like @override in java for toString().

heres our + operator, adding two vectors together is essentially just adding together each x and y with the coresponding x, y of the other vector. So 1, 2 + 2, 1 = 3, 3. Its quite simple really. if we just want to add to like for example the X coordinate, we just make do 0 on the Y like 1, 0.

Now were done with establishing the basic math of vec2. Lets start doing the vector 3 stuff!

minus - works the exact same way as + just with -.

heres how the * functions if we multiply a vector by a scalar. Pretty simple I mean you know this. I dont really know how to explain it honestly we take it each coordinate times the scalar, and if we reverse the order we take the scalar first times the vec- you get it.

Division works just the same as the first multiplication method we defined but with /. You might be thinking, huh how come we need 2 different methods for * but only 1 for /? Well its simple dummy, You cant divide like this Scalar / Vector. Like what are you trying to accomplish here?

Now its time for some slightly harder math

Here is how we calculate our beautiful dot product. The dot proct lets us calculate how aligned two vectors are. The closer to 1 they are the more aligned and the closer to 0 the closer they are to being perpendicular. So if its 0 its completely perpendicular as in 90 degrees. However the dot product can also be negative, if this is the case it goes past those 90 degrees and faces away from the other vector. So the closer to -1 the closer the lines are to being opposite. The way to calculate a dot product is by multiplying each component of the vectors by one another and then + the x and y results of that.

So to calculate the length of a vector we use pythagoras theorem, that classic square root of (a^2 + b^2), I knew I had a reason to learn that in school!

Now this is a helper function to our normalized function which looks like this.

Normalizing means keeping a vectors direction in accordance to the origin point but making the it length of 1. We figure out the length of the vector via pythagoras theorem. We then divide the X and Y coordinate by that length. Now we get 1 length of the vector! Worth to note that if a vector is 0, 0 we return that vector but otherwise run that calculation of dividing.

Now the vec2 math stuff is done and we can move onto the vec3 stuff.

Addition with vectors is still pretty easy and its the same for minus on the vectors aswell.

Multiplication works the same as vector2 you just add another coordinate to multiply.

division works the same essentially just with an added z.

Heres our dot product, it is also the same as before essentially we just need to add each vectors z value and multiply those together and add them to our total.

Calculating length is the same principle we just gotta add the z value, this is getting quite repetetive right.

And our normalize function is exactly the same we just take a vec3 instead of a vec 2!.

Finally we have this juicer of the cross product.
We are using a right handed cross product system which means that our perpendicular vector created by comparing two vectors will be positive facing us and negative going away from us. I like to think of cross products as you are taking two lines and adding them ontop of eachother, where they both intersect you stick a needle through and thats where your new vector is. This new needle is perpendicular to both our other vectors, and depending on if its a right handed system or not were sticking the needle through the front (if left handed) or through the back so the needle is facing us (right handed).

The way to calculate the cross product in math is i like to picture it as you have to multiply all different combinations of each vectors x, y and z values and then subtract it by another. Excluding if they have the same coordinate designation, like you wouldnt multiply A.y and B.y together. It is honeslty though probably the hardest formula to remember of the top of your head, so I always google it but hey it works.

That does it for this part, really excited to actually dive deeper and draw some wirefram models but this has been very rewarding on the math aspect as that is were I am definitely lacking the most.

Part 2 is up on the Rasterizer Project, were actually drawing a triangle now! Exciting!

NoticeableSmeh — Fri, 31 Oct 2025 14:23:23 +0000

NoticeableSmeh

Oct 31 '25

Rasterizer Project - Part 2: Lines and Optimization (Excited reaction)

#learning #graphics #cpp #gamedev

Comments

5 min read

Rasterizer Project - Part 2: Lines and Optimization (Excited reaction)

NoticeableSmeh — Fri, 31 Oct 2025 14:20:39 +0000

Hello there beautiful people, lets continue on this rasterizer.

So now we want to draw lines between points inside of our image. How do we do this? Well firstly lets talk about linear interpolation. It works like this

You take point A (origin point) and your point B (goal point), whats a point? well in 2D that comprises of a X and a Y coordinate.

You calculate the X and Y cooridnate seperately in functions. What you do is you take A's x coordinate + (Bx - Ax) and * it by a scalar between 0 and 1. So in our example we use 0.02f which is 2% of the total lines length. So what this formula does is that we essentially calculate, what is 2% of the X value in the distance between our two Points (A and B). Then we store that and apply the same logic for our Y calculation. Its important to note that we round to nearest our result for each X and Y value we achieve. Then we paint that pixel, then we move on until that scalar gets fully to 100%.

This is the result, it has faults. Because just declaring a 0.02f scalar will not accurately paint out pixels perfectly, I mean that makes sense right you can't just decide that a random number will work perfectly for every instance of drawing a line. So lets try and fix this.

here we are changing the code to loop over the X values instead of the scalar we were using before. This ensures us that were going from the x coordinate of point A to the x coordinate of point B.

so the t float represents how far along the line we are, same as before 0.02 is 2% of the length of the line, were casting our A point and B points x valeus to floats because that's we don't want to lose any data on our calculations. Then were just doing the LERP calculation of Ax + (bx - Ax) * t);

However you might have noticed that we will get a bug here? I managed to evade the bug by the nature of which i decided to draw my triangle in my code as you can see here

So the green Line actually draws but lets say that bx is not bigger or equal to ax, then the condition for this loop would be false and that line wouldn't be drawn, we can fix this with a simple swap function before checkign with the loop.

with this we should get this image.

well that blue line doesn't look good, were missing a lot there. Sometimes a line is more vertical than it is horizontal and this could cause problems with our code, the way to fix this is by transposing the y value to an x value and then doing the calculation essentially treating our y value as our x value in our set function.

and with that we get our very nice loooking triangle here.

I changed our image files to bmp files instead because it was easier to get those uncompressed but the code is basically the same.

now it is time to do some otpimization, why you might ask? Because I want to learn.

so lets define some random lines in our code that set a random x and y paint and paints lines between them.

Our first optimization is to just statically add 1 to the y axis and or subtract 1 on the y axis depending on if the direction is up and down, since thats how th y line is always calculated, there is no reason to manually calculate the y position everytime with our scalar.

That divide part at the very end of y += is what gives us that either positive or negative number.

Time for our second optimization.

So before we declared a float for our y, this is however a little bit of wasted memory. This should make it so that we only use an int to store our y value but we correct it via a float that keeps our y aligned to the ration in which its increasing on the y. It does this by checking if the error is bigger than 0.5, this essentially means should it move up one more pixel and it does so accordingly.

were still however using a float for this so lets ditch that.

were essentialy doing the same thing here but instead of dividing were multiplying because thats easier to do with integers right. So were performing the same mathematical calculation but just arriving their via integer instead.

So this code is actually slower on paper than what we began with beacause were using an if statement. Since this is coded on the CPU if statements with a conditional like > essentially slows down and boggs down the pipleline. Since the CPU has to check wether or not this statement is correct and does so repeatedly for every loop it guesses everytime it is run, however if it guesses wrong it has to flush its pipeline and reset from 0, this ofcourse takes a little bit mor time, this is unlike the GPU which can run multiple paths but masks the incorrect one. So lets do this code without any if statements.

That does it for this part, in the next part we will implement our own geometry.h file. The one tinyrenderer uses I find confusing and not very c++ beginner friendly so I will make my own one that still works the same (essentially hopefully), then maybe if we have time we will finish the wireframe loading aswell.

Rasterizer project - Lets get this ball loading

NoticeableSmeh — Mon, 27 Oct 2025 16:47:17 +0000

NoticeableSmeh

Oct 27 '25

Rasterizer Project - Part 1: Getting started

#graphics #cpp #gamedev #learning

Comments

4 min read

Rasterizer Project - Part 1: Getting started

NoticeableSmeh — Mon, 27 Oct 2025 16:47:00 +0000

Were making a Rasterizer folks, exciting really. I would like to credit: I will be using these resources in my journey in making this rasterizer. https://lazyfoo.net/tutorials/SDL/
https://haqr.eu/tinyrenderer/bresenham/

What is a Rasterizer?
Its a part of the graphics pipeline that turns all that magical mathematical geometry, points lines and tirangles into colored pixels on a 2D image.

Everything you see in a rendered game or 3D scene comes down to rasteriztion. The program has to decide which pixels on the screen correspond to which parts of what triangles, what colour they should be (how bright etc etc).

So the basic idea is that you start with triangles defined by vertices in 3D space, you transform those into 2D coordinates on your screen, after you have applied your perspective and projection and once they are in 2D the rasterizer does three things.

Determines which pixels fall inside each triangle

Interpolates values (Color, depth, texture coordinates, normals) across the pixels

Writes the results into a framebuffer, which is the image in our memory that eventually gets display.

It is like a coloring book for children although were talking to a computer which is even stupider than a child. Essentially we have to tell the program "Draw inside of this triangle shape, and do it with this color".

So why am I building one by myself?
It's fun, and it will look great on a CV. Unironically though it is really something you should learn a lot from and that is (mostly) why I am doing it. It is really helpful to do before you delve deeper into 3D graphics as we will see behind the curtains of the graphics API and really get down there in the mud and shape things up. It is important to note that were doing this all on the CPU because... Why not. Anyways lets delve deeper.

I will be Using SDL 2.0 and STB_Image as I have worked with these before and I find them convenient.

So this is what we want to make to start with, an image printed out into a file that we can open and displays three vertices so we can draw lines between them, lets take a look at the code.

lets begin with this little struct here. Here we are essentially defining a pixel. A pixel has a RGBA value. What is RGBA? well it stands for Red, Green, Blue, Alpha silly. Each channel is stored in as an 8-bit unsigned integer. So each channel holds a value between 0 and 255, that is 256 total intensity levels per color channel. uint8_t stands for unsigned 8-bit integer (also known as a byte) and is imported via the include. So essentially this struct represents a pixel.

WOooo heres our Framebuffer struct. What is a framebuffer? well its a tiny CPU "canvas": holdsa width and heigh t plus a flat byte buffer holding the RGBA pixels.

Now our constructor for our Framebuffer struct takes the width and height, we fill the entire thing with our data vector with a black color.

That little for loop in our clear walks through pixel by pixel and paints all pixels one colour.

Alright now lets walk through the set function.
First we check the bounds, this is just a safety thing so we dont accidentally write out of the bounds of the screen.

the int i = (y * w + x) * 4; is translating our 2d space into a 1D byte index inside of our data vector. Each row has W pixels, each pixel takes up 4 bytes so y*w jumps down y rows, the +x moves x pixels across that row and the * 4 converts the pixel inedx into a byte offset (because we have RGBA values).

Then we have this little section
data[i + 0] = c.r;
data[i + 1] = c.g;
data[i + 2] = c.b;
data[i + 3] = c.a;
This copies the 4 color components of our Color struct into the right spot of our data vector.

Now heres the function for actually writing out or data into a file. First things first we flip the image since were writing from the top left (unlike tinyrenderer who counts from bottom left) and then we yknow write it out. We provide the path directly to where our code is at yknow, provide the width and height. The number of channels, a pointer to our raw pixel data and the number of bytes per row.

heres where we actually define our program. So we create the 64x64 framebuffer, fill it with black and paint three white pixels.

Thats it for this part, we have now set up this program and we will continue with drawing lines in the next part

learning OpenGl - My journey through LearnOpenGL website is done, now its time to make something.

NoticeableSmeh — Sun, 26 Oct 2025 21:25:34 +0000

NoticeableSmeh

Oct 26 '25

Learning OpenGL Part: The End - Model loading

#learning #graphics #cpp #gamedev

Comments

8 min read