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

wip
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse source
This commit is contained in:
light7734 2025-04-30 18:15:19 +03:30
parent 9689025934
commit edde7d66cc
Signed by: light7734
GPG key ID: B76EEFFAED52D359
14 changed files with 11242 additions and 91 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
mdsvex.config.js Normal file
View file

@ -0,0 +1,18 @@
import { defineMDSveXConfig as defineConfig } from 'mdsvex';
import remarkMath from 'remark-math';
import rehypeKatex from 'rehype-katex-svelte';
import rehypeMermaid from 'rehype-mermaid'; // Import rehype-mermaid
const config = defineConfig({
extensions: ['.md', '.svx'],
layout: "./src/routes/articles/Layout.svelte",
smartypants: {
dashes: 'oldschool'
},
remarkPlugins: [remarkMath],
rehypePlugins: [rehypeKatex, rehypeMermaid]
});
export default config;

5668
package-lock.json generated Normal file
View file

File diff suppressed because it is too large Load diff

7
package.json
View file

@ -38,6 +38,7 @@
"prettier": "^3.5.3",
"prettier-plugin-svelte": "^3.3.3",
"prettier-plugin-tailwindcss": "^0.6.11",
"rehype-mermaid": "^3.0.0",
"svelte": "^5.28.2",
"svelte-check": "^4.1.6",
"tailwindcss": "^4.1.4",
@ -50,5 +51,11 @@
"onlyBuiltDependencies": [
"esbuild"
]
},
"dependencies": {
"mermaid": "^11.6.0",
"playwright": "^1.52.0",
"rehype-katex-svelte": "^1.2.0",
"remark-math": "^6.0.0"
}
}

5330
pnpm-lock.yaml generated Normal file
View file

File diff suppressed because it is too large Load diff

15
src/app.css
View file

@ -1,3 +1,12 @@
@tailwind base;
@tailwind components;
@tailwind utilities;
body {
margin: 0;
padding: 0;
}
* {
color: #ebdbb2;
font-family: 'Inter';
font-optical-sizing: auto;
font-weight: 400;
font-style: normal;
}

6
src/app.html
View file

@ -7,6 +7,12 @@
href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap"
rel="stylesheet"
/>
<link
rel="stylesheet"
href="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.css"
integrity="sha384-MlJdn/WNKDGXveldHDdyRP1R4CTHr3FeuDNfhsLPYrq2t0UBkUdK2jyTnXPEK1NQ"
crossorigin="anonymous"
/>
<meta name="viewport" content="width=device-width, initial-scale=1" />
%sveltekit.head%
</head>

14
src/routes/articles/+layout.svelte
View file

@ -1,14 +0,0 @@
<script lang="ts">
import './article.css';
let { children } = $props();
</script>
<div class="body">
<div class="article_padding"></div>
<div class="article_body">
{@render children()}
</div>
<div class="article_padding"></div>
</div>

29
src/routes/articles/Heading.svelte Normal file
View file

@ -0,0 +1,29 @@
<script lang="ts">
import './article.css';
export let title;
export let date;
</script>
<div>
<h1>{title}</h1>
<p>{date}</p>
</div>
<style>
div {
width: 100%;
}
h1 {
display: inline-block;
}
p {
float: right;
padding-left: auto;
padding-right: auto;
margin-left: auto;
margin-right: auto;
}
</style>

13
src/routes/articles/HorizontalBreak.svelte Normal file
View file

@ -0,0 +1,13 @@
<script lang="ts">
</script>
<div>
</div>
<style>
div {
margin-top: 1em;
background-color: #928374;
height: 1px;
}
</style>

49
src/routes/articles/Layout.svelte Normal file
View file

@ -0,0 +1,49 @@
<script lang="ts">
import './article.css';
import Heading from './Heading.svelte';
export let title;
export let date;
</script>
<div class="container">
<div class="padding"></div>
<div class="body">
<Heading {title} {date} />
<slot></slot>
</div>
<div class="padding"></div>
</div>
<style>
@import url('https://fonts.googleapis.com/css2?family=Inter:ital,opsz,wght@0,14..32,100..900;1,14..32,100..900&display=swap');
.container {
background-color: #1d2021;
display: flex;
}
.body {
flex: 3;
padding: 1em;
background-color: #282828;
text-wrap-mode: wrap;
min-width: 80ch;
max-width: 80ch;
border-left: 1px solid #928374;
border-right: 1px solid #928374;
text-align: justify;
}
.padding {
flex: 1;
}
</style>

13
src/routes/articles/Paragraph.svelte Normal file
View file

@ -0,0 +1,13 @@
<script lang="ts">
let { children } = $props();
</script>
<div>
{@render children()}
</div>
<style>
div {
margin-top: 1em;
}
</style>

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

@ -1,47 +1,33 @@
@import "tailwindcss";
@import url('https://fonts.googleapis.com/css2?family=Inter:ital,opsz,wght@0,14..32,100..900;1,14..32,100..900&display=swap');
* {
color: #ebdbb2;
font-family: "Inter", sans-serif;
font-family: 'Inter';
font-optical-sizing: auto;
font-weight: 400;
font-style: normal;
}
br {
margin-bottom: 1em;
strong {
font-weight: 600;
font-style: italic;
color: #fabd2f;
}
h1 {
display: block;
font-size: 2em;
margin-bottom: .3em;
margin-top: 0.0em;
margin-bottom: 0.0em;
margin-left: 0;
margin-right: 0;
font-weight: bold;
}
h2 {
font-size: 1.7em;
margin-bottom: .3em;
margin-top: .6em;
}
.body {
background-color: #1d2021;
display: flex;
}
.article_body {
flex: 3;
margin-left: 10em;
margin-right: 10em;
padding: 1em;
background-color: #282828;
text-align: justify;
max-width: 80ch;
border-left: 1px solid #7c6f64;
border-right: 1px solid #7c6f64;
}
.article_padding {
flex: 1;
display: block;
font-size: 1.5em;
margin-top: 0.83em;
margin-bottom: 0.0em;
margin-left: 0;
margin-right: 0;
font-weight: bold;
}

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

@ -1,56 +1,93 @@
# The Graphics Pipeline
Ever wondered how games put all that gore on your display? Well you're about to find out!
---
title: The Graphics Pipeline
date: "April 20 - 2025"
---
<br/>
At the heart of rendering, is the "Graphics Pipeline". And like any pipeline, it's comprised
of several "stages", each of which can be a pipeline in itself or even parallelized.
<script>
import Paragraph from '../Paragraph.svelte';
import HorizontalBreak from '../HorizontalBreak.svelte';
</script>
<HorizontalBreak/>
<Paragraph>
Ever wondered how games put all that gore on your display? Well you're about to find out :)
At the heart of rendering, is the **Graphics Pipeline**. And like any pipeline, it's 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 for the next stage.
</Paragraph>
<br/>
We can coarsely divide the entire pipeline into 4 stages:
Application -> [Geometry Processing] -> Rasterization -> Pixel Processing
The pipeline will then serve a "rendered image" to your pretty eyes using your display.
<Paragraph>
<br/>
We can coarsely divide the **Graphics Pipeline** into 4 stages:
**Application -> Geometry Processing -> Rasterization -> Pixel Processing**
The pipeline will then serve the output of the **Pixel Processing** stage, which is a **rendered image**,
to your pretty eyes using your display.
</Paragraph>
<Paragraph>
But to avoid drowning you in overviews, let's jump right into the details of the "Geometry Processing"
stage and have a recap afterwards to demystify our 4-stage division!
stage and have a recap afterwards to demystify this 4-stage division.
</Paragraph>
## Vertices (points in space)
In order to render a murder scene, we need to have a way of representing the deceased in computer memory.
We only care about the "surface" since we won't be seeing the insides anyways--We don\'t want to either.
At this stage, we only care about the "shape" or the "geometry" of the "surface",
texturing, lighting and all the sweet gory details comes at a much later stage once all the "geometry" has been processed.
<Paragraph>
<br/>
There are several ways to "represent 3d objects" for a computer to understand.
For instance, _NURB_(Non-uniform rational B-spline) surfaces are great for representing "curves"
and it's all about the "high-precision" needed to do _CAD_(computer assisted design).
We could also do "ray-tracing" using fancy equations for rendering photo-realistic images.
## Surfaces
In order to display a murder scene, we need to have a way of **representing** the deceased in computer memory.
We only care about the **surface** since we won't be seeing the insides anyways---Not that we want to.
At this stage, we only care about the **shape** or the **geometry** of the **surface**.
Texturing, lighting and all the sweet gory details comes at a much later stage once all the **geometry** has been processed.
But how should we represent surfaces in memory?
</Paragraph>
## Vertices
<Paragraph>
There are several ways to **represent 3d objects** for a computer to understand.
For instance, **NURB surfaces** are great for representing **curves**
and it's all about the **high-precision** needed to do **CAD**.
We could also do **ray-tracing** using fancy equations for rendering **photo-realistic** images.
</Paragraph>
<Paragraph>
<br/>
These are all great--ignoring the fact that they would take "an eternity" to process.
But what we need is a hardware-friendly approach that can do this for an entire scene with
hundereds of thousands of objects for at least 60 times undr a second. What we need is "polygonal modeling".
But what we need is a **hardware-friendly** approach that can do this for an entire scene with
hundereds of thousands of objects for at least **60 times undr a second**. What we need is **polygonal modeling**.
</Paragraph>
<br/>
"Polygonal modeling" allows us to do "real-time rendering". The idea is that we only need an
"approximation" of a surface to render it "realisticly-enough" for us to have some fun killing time!
We can achieve this approximation using a collection of "triangles", "lines" and "dots" (primitives),
which themselves are composed of a series of "vertices" (points in space).
<Paragraph>
<br/>
A "vertex" is simply a point in space.
Once we get enough of these "points", we can conncet them to form "primitives" such as "triangles", "lines" and "dots".
And once we have enough "primitives" together, they form a "model" or a "mesh" (that we need for our corpse).
With some interesting models, we can compose a "scene".
**Polygonal modeling** allows us to do **real-time rendering**. The idea is that we only need an
**approximation** of a surface to render it **realisticly-enough** for us to have some fun killing time!
We can achieve this approximation using a collection of **triangles**, **lines** and **dots** (primitives),
which themselves are composed of a series of **vertices** (points in space).
</Paragraph>
<br/>
But let's not get ahead of ourselves. The primary type of "primitive" we care about during "polygonal modeling"
is a "triangle". But why not squares or polygons with variable number of edges?
<Paragraph>
A **vertex** is simply a point in space.
Once we get enough of these **points**, we can conncet them to form **primitives** such as **triangles**, **lines** and **dots**.
And once we have enough **primitives** together, they form a **model** or a **mesh** (that we need for our corpse).
With some interesting models, we can compose a **scene**.
</Paragraph>
<Paragraph>
But let's not get ahead of ourselves. The primary type of **primitive** we care about during **polygonal modeling**
is a **triangle**. But why not squares or polygons with variable number of edges?
</Paragraph>
## Why Triangles?
"Always Planar":
<Paragraph>
Triangles can never be __non-planar__(reside in more than 1 plane)! In Euclidean geometry, any
</Paragraph>
"Normal surface:"

8
svelte.config.js
View file

@ -1,4 +1,6 @@
import { mdsvex } from 'mdsvex';
import mdsvexConfig from './mdsvex.config.js';
import adapter from '@sveltejs/adapter-static';
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';
@ -8,10 +10,8 @@ const config = {
// for more information about preprocessors
preprocess: [
vitePreprocess(),
mdsvex({
extensions: ['.md', '.svx'],
})
],
mdsvex(mdsvexConfig)
],
kit: {
// adapter-auto only supports some environments, see https://svelte.dev/docs/kit/adapter-auto for a list.