Gered
eef0b4f7a4
the difference is important to note since most articles discussing implementations of barycentric triangle rasterization show a test for positive w0/w1/w2 to determine if you're inside the triangle or not. they also usually use a slightly different formula in the `cross` function if they assume counter-clockwise vertex winding. since i'll admit i still don't *fully* grasp the math behind the edge functions and that stuff that is used to calculate the a01/b01/a12/... values, i wasn't sure how to adjust these for counter-clockwise winding to keep a positive w0/w1/w2 check. so the simple solution is to use the `cross` function as it is now, calculate a01/b01/a12/b12/a20/b20 as we are now, and do a negative w0/w1/w2 check and we get to keep counter-clockwise vertex winding which i prefer. hooray! |
||
|---|---|---|
| .github/workflows | ||
| examples | ||
| ggdt | ||
| .gitignore | ||
| Cargo.toml | ||
| README.md | ||
| rustfmt.toml | ||
ggdt: Gered's Game Dev Tools
This is a purely for-fun project of mine. It's a personal set of retro-like/inspired game development tools for use in my own projects.
It started with a focus on DOS "VGA mode 13h"-style limitations, but is not going to be limited to just that into the future and will be expanded on as I need it to do other things. It should be noted that in this project I will do a lot of (poor) reinventing of the wheel ... because it's fun. Stringing together existing libraries all the time is dull after a while.
I'm not an expert in Rust and am probably still doing a great many things unidiomatically. But I'm learning, and that is at least half the point of this project in the first place.
See the /examples directory for some demo apps. These will be added to over time.