summaryrefslogtreecommitdiff
path: root/content/projects/bevy_dither_post_process/index.md
diff options
context:
space:
mode:
authorsoaos <soaos@soaos.dev>2025-08-12 23:17:55 -0400
committersoaos <soaos@soaos.dev>2025-08-12 23:17:55 -0400
commit3f114ebe5c4d3618504b0e623b52c22e262de854 (patch)
tree9a16dc198fa3140dcff62e997a285246f5f24059 /content/projects/bevy_dither_post_process/index.md
parent20c1ed2c45abf792ddc09e1aa757443bec2a1f92 (diff)
Moved public files to root
Diffstat (limited to 'content/projects/bevy_dither_post_process/index.md')
-rw-r--r--content/projects/bevy_dither_post_process/index.md29
1 files changed, 0 insertions, 29 deletions
diff --git a/content/projects/bevy_dither_post_process/index.md b/content/projects/bevy_dither_post_process/index.md
deleted file mode 100644
index 1357766..0000000
--- a/content/projects/bevy_dither_post_process/index.md
+++ /dev/null
@@ -1,29 +0,0 @@
-+++
-title = "bevy_dither_post_process"
-[taxonomies]
-categories = ["bevy plugin"]
-languages = ["rust", "wgsl"]
-[extra]
-github = ["soaosdev/bevy_dither_post_process"]
-crates = ["bevy_dither_post_process"]
-+++
-
-this plugin allows you to add a "monochromatic ordered dithering" post-processing effect to cameras in your bevy engine application
-
-![level 3](level_3.png)
-
-the dithering is monochromatic (black & white) and ordered (using the bayer method) (i'm gonna write a blog post about this soon)
-
-it can be configured with the "level" of dithering to perform (i.e. the size of the bayer matrix to use, where level *n* results in a matrix of size *2^(n+1)*)
-
-![level 2](level_2.png)
-![level 4](level_4.png)
-
-i wrote this plugin to enhance the performance of my ongoing game project
-
-originally i did all the dithering on the CPU, and while it was not a huge performance drain due to the screen size being relatively small in the terminal, i figured it would be a good idea to convert it into a shader to take advantage of the GPU and parallelism
-
-since i was using ordered dithering anyways it was pretty easy to port over, since that kind of dithering is super parallelizable on account of not needing to know anything about any other fragment on the screen unlike some methods that provide superior visual quality
-
-the reason i chose ordered dithering though was that other methods produced too much "jitter" when applied to moving objects which was pretty disorienting
-