light7734/dazzle
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

wip
Some checks failed
continuous-integration/drone/push Build is failing
Details

Browse source
This commit is contained in:
light7734 2025-05-14 01:31:12 +03:30
parent be1fcf49bc
commit 6697a24c6d
Signed by: light7734
GPG key ID: 8C30176798F1A6BA
5 changed files with 181 additions and 64 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
src/routes/articles/Note.svelte
View file

@ -1,19 +1,50 @@
<script lang="ts">
import { Info } from '@lucide/svelte';
export let title;
import { Info, BookCopy, Eye, Network, Sigma } from '@lucide/svelte';
let { title, type = 'info' } = $props();
</script>
<div class="note">
<div class="head">
<div class="icon">
<Info />
{#if type == 'info'}
<Info />
{:else if type == 'diagram'}
<Network />
{:else if type == 'math'}
<Sigma />
{:else if type == 'review'}
<Eye />
{:else if type == 'resource'}
<BookCopy />
{/if}
</div>
<div class="horiz_line"></div>
{#if type == 'info'}
<div class="horiz_line" style:background-color="#8ec07c"></div>
{:else if type == 'diagram'}
<div class="horiz_line" style:background-color="#d3869b"></div>
{:else if type == 'math'}
<div class="horiz_line" style:background-color="#fe8019"></div>
{:else if type == 'review'}
<div class="horiz_line" style:background-color="#cc241d"></div>
{:else if type == 'resource'}
<div class="horiz_line" style:background-color="#458588"></div>
{/if}
</div>
<div class="content">
<div class="line"></div>
{#if type == 'info'}
<div class="line" style:background-color="#8ec07c"></div>
{:else if type == 'diagram'}
<div class="line" style:background-color="#d3869b"></div>
{:else if type == 'math'}
<div class="line" style:background-color="#fe8019"></div>
{:else if type == 'review'}
<div class="line" style:background-color="#cc241d"></div>
{:else if type == 'resource'}
<div class="line" style:background-color="#458588"></div>
{/if}
<div class="slot">
<p>{title}</p>
<slot />
@ -46,7 +77,6 @@
}
.line {
background-color: #8ec07c;
width: 0.1em;
margin-left: 0.85em;
margin-bottom: 1em;
@ -54,7 +84,6 @@
}
.horiz_line {
background-color: #8ec07c;
height: 0.1em;
margin-left: 0.5em;
@ -73,7 +102,7 @@
font-family: 'IBM Plex Mono', monospace;
display: inline-block;
margin: 0;
font-weight: bolder;
font-weight: bolder;
}
.icon {

8
src/routes/articles/Tip.svelte
View file

@ -15,7 +15,7 @@
font-weight: 600;
font-style: italic;
color: #fabd2f;
border-bottom: .5px solid #d79921;
border-bottom: 1px solid #fe8019;
}
/* Tooltip text */
@ -32,7 +32,7 @@
text-align: justify;
padding: 1em;
border-radius: 6px;
border: 1px solid #928374;
border: 1px dotted #fe8019;
top: 100%;
left: 50%;
@ -46,4 +46,8 @@
.tooltip:hover .tooltiptext {
visibility: visible;
}
.tooltip:hover {
color: #fe8019;
}
</style>

62
src/routes/articles/article.css
View file

@ -1,38 +1,52 @@
* {
color: #ebdbb2;
font-family: 'Inter';
font-optical-sizing: auto;
font-weight: 400;
font-style: normal;
color: #ebdbb2;
font-family: 'Inter';
font-optical-sizing: auto;
font-weight: 400;
font-style: normal;
}
strong {
font-weight: 600;
font-style: italic;
color: #fabd2f;
font-weight: 600;
font-style: italic;
color: #fabd2f;
}
strong:hover {
color: #fe8019;
}
h1 {
display: block;
font-size: 2em;
margin-top: 0.0em;
margin-bottom: 0.0em;
margin-left: 0;
margin-right: 0;
font-weight: bold;
display: block;
font-size: 2em;
margin-top: 0em;
margin-bottom: 0em;
margin-left: 0;
margin-right: 0;
font-weight: bold;
}
h2 {
display: block;
font-size: 1.5em;
margin-top: 0.83em;
margin-bottom: 0.0em;
margin-left: 0;
margin-right: 0;
font-weight: bold;
display: block;
font-size: 1.5em;
margin-top: 0.83em;
margin-bottom: 0em;
margin-left: 0;
margin-right: 0;
font-weight: bold;
}
a {
display: block;
text-decoration: none;
color: #83a598;
}
a:hover {
color: #458588;
}
.katex {
width: max-content;
margin-left: 0;
width: max-content;
margin-left: 0;
}

25
src/routes/articles/technical-debt/+page.svx Normal file
View file

@ -0,0 +1,25 @@
---
title: C++ Technical Debt
date: "April 20 - 2025"
---
<script>
import Paragraph from '../Paragraph.svelte';
import HorizontalBreak from '../HorizontalBreak.svelte';
</script>
<HorizontalBreak/>
<Paragraph>
Have you ever had your project grow too messy that the idea of **total-rewrite** started haunting your
dreams? In this article I'll teach you how to avoid that state forever :)
</Paragraph>
## Technical Debt
<Paragraph>
What causes such a state?
</Paragraph>

105
src/routes/articles/the-graphics-pipeline/+page.svx
View file

@ -11,28 +11,39 @@ import Tip from "../Tip.svelte"
Ever wondered how games put all that gore on your display? All that beauty is brought into life by
a process called **rendering**, and at the heart of it, is the **graphics pipeline**.
In this article we'll dive deep into the intricate details of this beast.
In this article we'll dive deep into the intricate details of this powerful beast.
We'll cover all the terminologies needed to understand each stage and have many restatements so don't
worry if you don't fully grasp something at first. I'll make sure you understand everything at the
end of our journey. If you still had questions, feel free to contact me :)
So without further ado---
## Overview
Like any pipeline, the **graphics pipeline** is comprised
of several **stages**, each of which can be a pipeline in itself or even parallelized.
Each stage takes some input (data and configuration) to generate some output data for the next stage.
<Note title="A coarse division of the graphics pipeline">
<Note title="A coarse division of the graphics pipeline", type="diagram">
Application --> Geometry Processing --> Rasterization --> Pixel Processing --> Presentation
</Note>
Before the heavy rendering work starts on the <Tip text="GPU">Graphics Processing Unit</Tip>,
we simulate and update the world through systems such as physics engine, game logic, networking, etc.
we simulate and update the world through **systems** such as physics engine, game logic, networking, etc.
during the **application** stage.
This stage is mostly ran on the <Tip text="CPU">Central Processing Unit</Tip>,
therefore it is extremely efficient on executing <Tip text="sequentially dependendent logic">
therefore it is extremely efficient on executing <Tip text="sequentially dependent logic">
A type of execution flow where the operations depend on the results of previous steps, limiting parallel execution.
In other words, **CPUs** are great at executing **branch-heavy** code, and **GPUs** are geared
towards executing a TON of **branch-less** or **branch-light** code in parallel. </Tip>.
The updated scene data is then prepped and fed to the **GPU** for **geometry processing**; which is
where we figure out where everything ends up on our screen. We'll cover this stage in depth very soon so don't panic (yet).
// NOTE: twice "where..."
The updated scene data is then prepped and fed to the **GPU** for **geometry processing**. Here
we figure out where everything ends up on our screen by doing lots of fancy matrix math.
We'll cover this stage in depth very soon so don't panic (yet).
Afterwards, the final geometric data are converted into <Tip text="pixels"> Pixel is the shorthand for **picture-element**, Voxel is the shorthand for **volumetric-element**. </Tip>
and prepped for the **pixel processing** stage via a process called **rasterization**.
@ -40,7 +51,7 @@ In other words, this stage converts a rather abstract and internal presentation
into something more concrete (pixels). It's called rasterization because end the product is a <Tip text="raster">Noun. A rectangular pattern of parallel scanning lines followed by the electron beam on a television screen or computer monitor. -- 1930s: from German Raster, literally ‘screen’, from Latin rastrum ‘rake’, from ras- ‘scraped’, from the verb radere. ---Oxford Languages</Tip> of pixels.
The **pixel processing** stage then uses the rasterized geometry data (pixel data) to do **lighting**, **texturing**,
and all the sweet gory details of a murder scene.
and all the sweet gory details of a scene (like a murder scene).
This stage is often, but not always, the most computationally expensive.
A huge problem that a good rendering engine needs to solve is how to be **performant**. And a great deal
of **optimization** can be done through **culling** the work that we can deem unnecessary/redundant in each
@ -61,9 +72,9 @@ Ever been jump-scared by this sight in an <Tip text="FPS">First Person (Shooter)
/>
In order to display a scene (like a murder scene),
In order to display a (murder) scene,
we need to have a way of **representing** the **surface** of its composing objects (like corpses) in computer memory.
We only care about the **surface** since we won't be seeing the insides anyway---Not that we want to.
We only care about the **surface** since we won't be seeing the insides anyway---Not with that attitude.
At this stage, we only care about the **shape** or the **geometry** of the **surface**.
Texturing, lighting, and all the sweet gory details come at a much later stage once all the **geometry** has been processed.
@ -128,16 +139,20 @@ Also, it is a common practice in computer science to break down hard problems in
This will be a lot more convincing when we cover the **rasterization** stage :)
Bonus point: present-day **hardware** and **algorithms** have become **extremely efficient** at processing
triangles (sorting, rendering, etc) after eons of evolving around them.
<Note title="Bonus point: evolution", type="info">
present-day **hardware** and **algorithms** have become **extremely efficient** at processing
triangles by doing operations such as sorting, rasterizing, etc, after eons of evolving around them.
</Note>
## Primitive Topology
So, we got our set of vertices, but having a bunch of points floating around wouldn't be so
interesting, we need to form **triangles** out of them, or more specifically, **triangle strips**.
So, we got our set of vertices, but having a bunch of points floating around wouldn't make a scene very lively
(or even deadly), we need to form **triangles** out of them to compose **models**.
We communicate to the computer what type of primitives we want to generate from our vertices by
configuring the **primitive topology** of the **input assembler**.
We'll get into the **input assembler** in a second, but what is a **primitive toplogy**?
We'll get into the **input assembler** bit in a second, but what is a **primitive toplogy**?
<Tip text="Toplogy">The way in which constituent parts are interrelated or arranged.--mid 19th century: via German from Greek topos ‘place’ + -logy.---Oxford Languages</Tip>
basically defines the way we connect our vertices together, it would be more clear to provide examples than drown you in theory.
@ -145,16 +160,22 @@ basically defines the way we connect our vertices together, it would be more cle
As stated previously, we got 3 main types of primitives, **triangles**, **lines**, and **dots**.
(There's also a **patch primitive** which we won't get into for now). Let's quickly run through all
the possible ways we can make these 3 types of primitives alongside some visual cues.
In the following equations, **p** stands for **primitive** and **v** stands for **vertex**.
**Point list**:
When the topology is **point list**, each consecutive vertex defines a single point primitive, according to the equation:
<Note title="Point list equation", type="math">
```math
p_i = \{ v_i \}
p_i = \{ v_{2i},\ v_{2i+1} \} \\
n_p = \left\lfloor \frac{n_v}{2} \right\rfloor
```
As there is only one vertex, that vertex is the provoking vertex. The number of primitives generated is equal to vertexCount.
</Note>
**Line list**:
@ -223,10 +244,10 @@ which processes the data we feed to it based on the configurations we set on it.
The **vertices** and **indices** are provided to this stage via something we call buffers.
So technically we have to provide **two** buffers here, a **vertex buffer** and a **index buffer**.
To give you yet-another ovreview, this is the diagram of the "Geometry Processing" section of
To give you yet-another ovreview, this is the diagram of the **geometry processing** section of
our pipeline:
<Note title="Geometry Processing Pipeline">
<Note title="Geometry Processing Pipeline", type="diagram">
Draw --> Input Assembler -> Vertex Shader -> Tessellation Control Shader -> Tessellation Primitive Generator -> Tessellation Evaluation Shader -> Geometry Shader -> Vertex Post-Processing -> ... Rasterization ...
</Note>
@ -259,17 +280,41 @@ Draw --> Input Assembler -> Vertex Shader -> Tessellation Control Shader -> Tess
## Conclusion
## Sources
[Tomas Akenine Moller - Real-Time Rendering 4th Edition](https://www.realtimerendering.com/intro.html)
<br/>
<Note title="Reviewers", type="review">
[LearnOpenGL - Hello Triangle](https://learnopengl.com/Getting-started/Hello-Triangle)
[LearnOpenGL - Face Culling](https://learnopengl.com/Advanced-OpenGL/Face-culling)
[Wikipedia - Polygonal Modeling](https://en.wikipedia.org/wiki/Polygonal_modeling)
[Wikipedia - Non-uniform Rational B-spline Surfaces](https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline)
[Wikipedia - Computer Aided Design (CAD)](https://en.wikipedia.org/wiki/Computer-aided_design)
[Wikipedia - Rasterization](https://en.wikipedia.org/wiki/Rasterisation)
[Wikipedia - Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry)
[Stackoverflow - Why do 3D engines primarily use triangles to draw surfaces?](https://stackoverflow.com/questions/6100528/why-do-3d-engines-primarily-use-triangles-to-draw-surfaces)
[Vulkan Docs - Drawing](https://docs.vulkan.org/spec/latest/chapters/drawing.html)
[Vulkan Docs - Pipeline Diagram](https://docs.vulkan.org/spec/latest/_images/pipelinemesh.svg)
Mohammad Reza Nemati
</Note>
<Note title="Books", type="resource">
[Tomas Akenine Moller --- Real-Time Rendering 4th Edition](https://www.realtimerendering.com/intro.html)
[JoeyDeVriez --- LearnOpenGL - Hello Triangle](https://learnopengl.com/Getting-started/Hello-Triangle)
[JoeyDeVriez --- LearnOpenGL - Face Culling](https://learnopengl.com/Advanced-OpenGL/Face-culling)
</Note>
<Note title="Wikipedia", type="resource">
[Polygonal Modeling](https://en.wikipedia.org/wiki/Polygonal_modeling)
[Non-uniform Rational B-spline Surfaces](https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline)
[Computer Aided Design (CAD)](https://en.wikipedia.org/wiki/Computer-aided_design)
[Rasterization](https://en.wikipedia.org/wiki/Rasterisation)
[Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry)
</Note>
<Note title="Youtube", type="resource">
...
</Note>
<Note title="Stackoverflow", type="resource">
[Why do 3D engines primarily use triangles to draw surfaces?](https://stackoverflow.com/questions/6100528/why-do-3d-engines-primarily-use-triangles-to-draw-surfaces)
</Note>
<Note title="Vulakn Docs", type="resource">
[Drawing](https://docs.vulkan.org/spec/latest/chapters/drawing.html)
[Pipeline Diagram](https://docs.vulkan.org/spec/latest/_images/pipelinemesh.svg)
</Note>