Gered
c7d6bd8aef
ultimately, cargo workspaces are kind of weird. you can do things like `cargo run` from the top-level cargo.toml file and run an individual sub-module via `--bin`, or you can go to that sub-module's directory where it's own cargo.toml is, and `cargo run` directly from there. the current working directory will be different in each case, and this difference can be very annoying when you want to do seemingly-logical things like organize sub-module "asset" files (e.g. images, and other types of data files that aren't code) within that sub-module's directory. in this case, how do you write code in that sub-module that can load those asset files in a way that will work in BOTH of the aforementioned scenarios for `cargo run`? you can't really! some people use the `CARGO_MANIFEST_DIR` environment variable that cargo sets when running any given cargo module, but this is only a valid method for obtaining the module's root directory when running from a cargo command ... which you won't be doing when running within a debugger! likely you or your IDE invoked the debugger process against the already built executable directly, so `CARGO_MANIFEST_DIR` will not be set and you're back to square one! super annoying! as such, i am now giving up and am just doing what it seems like most other cargo projects that utilize workspaces do ... place all the assets for all sub-modules together in the same directory, relative to the workspace root. why go with this approach? because it works under the most common scenarios (but NOT all!): - running via `cargo run --bin` from the workspace root - debugging via gdb/lldb etc using the workspace root as the cwd these seem to be the most common ways to do each type of task from any rust-equipped editor/IDE that i've seen so far. |
||
|---|---|---|
| .github/workflows | ||
| assets | ||
| examples | ||
| ggdt | ||
| ggdt_imgui | ||
| .gitignore | ||
| Cargo.toml | ||
| README.md | ||
| rust-toolchain.toml | ||
| 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.