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 - 'Slime Stabbing Simulator' Demo
A fairly more involved demo which was originally written to test out and learn how good/bad ggdt's entity, events and state management support is to use in practice. I learnt a lot from it, and have many ideas to improve things now.
Graphics from the awesome Tiny 16 by Lanea Zimmerman.
With some Tiny 16 extensions by:
Plus a very small handful of additional graphics by unknown artists because the image files have been sitting on my hard drive for years and I've forgotten who they were originally from!
Warning! There is quite a bunch of slow/sloppy code in here!
Simply do cargo run
from this directory to try it out.