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. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
| screenshot.png | ||
ggdt - ImGui Integration Demo
Borrows a lot of elements from the "slimed" demo, available in the /examples folder that this same demo is located
within, to run a somewhat simpler world and entity system from that demo while showing some bits of entity state
in realtime using an ImGui-based display of this state information.
The primary point of this demo is to show usage of the ggdt ImGui integration in a bigger application that somewhat resembles a "real" project (that is, using the application state management subsystem, the entity subsystem, etc) to show how this integration can be done.
The main points of interest in this demo are found in the main.rs module.
Simply do cargo run from this directory to try it out.
