Gered
a0c1199264
in truth, there's a lot of per-pixel color munging going on in these triangle renderers. maybe too much? we're doing a lot of operations that are constantly deconstructing argb32 colors and then reconstructing, and then deconstructing+reconstructing again. and some of the time we were doing this as floats, via the "normalized" conversion functions. this seemed to be adding a bit of "color jitter" that could be visible at run-time when triangles were being animated somehow (e.g. resized). also, the whole "inverse area" thing, while probably a bit of a micro-optimization at best, was causing its own little bit of visible "color jitter" sometimes, probably due to an increased level of floating-point inaccuracy when representing the area as a fraction like that. |
||
|---|---|---|
| .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.