Main repository for Will -- 2.5D moddable action adventure game
A game made by the Amethyst team for Ludum Dare 42
Rust macro to implement a struct and corresponding builder
azriel91/amethyst_engine_engine 1
Slides for Amethyst talk. 2019-02-25 Auckland Rust Meetup
Naive benchmark to show how the *struct of arrays* data layout benefits from caching to improve performance.
A cd command that learns - easily navigate directories from the command line
Abstract algebra for Rust.
Data-oriented game engine written in Rust
azriel91/amethyst-drone-config 0
Done CI configuration template for building Amethyst games
azriel91/amethyst_gl_segfault 0
Minimal segfault reproduction
startedazriel91/srcerr
started time in 4 days
startedazriel91/srcerr
started time in 5 days
startedazriel91/srcerr
started time in 5 days
startedazriel91/srcerr
started time in 5 days
startedazriel91/srcerr
started time in 5 days
pull request commentamethyst/shred
Add `ci.yml` github actions workflow.
Timed out.
comment created time in 5 days
push eventamethyst/shred
commit sha 3f4e2a097d349112eccd8442157d8cdfbd08b37e
Merge #201 201: Add `ci.yml` github actions workflow. r=azriel91 a=azriel91 Switch CI to use github actions, as bors isn't getting past travis (always times out). Co-authored-by: Azriel Hoh <[email protected]>
push time in 5 days
push eventamethyst/shred
commit sha cfa1dbfdf83ce86bcb79cd78eda5f406389a87e8
Add `ci.yml` github actions workflow.
commit sha 2e18e0de109f4efa6ee67a87dee89e7500263988
Switch `bors.toml` to read `ci` workflow status.
commit sha 79a98abe8c51f372e53d624ecc821cf5cc3276b1
Remove `.travis.yml` and `ci-script.sh`
commit sha f01359c7a655625ab691c38000382ced3b50c64d
Update `README.md` CI badge to point to Github Actions.
commit sha 860251e29c69fd939d3041f040e709b898ef6de5
Remove Rustfmt job from CI.
commit sha cee30c1fc6e8e887a859c64d6a27b692b3fde73d
[ci skip][skip ci][skip netlify] -bors-staging-tmp-201
push time in 5 days
pull request commentamethyst/shred
Add `ci.yml` github actions workflow.
Timed out.
comment created time in 5 days
push eventamethyst/shred
commit sha cfa1dbfdf83ce86bcb79cd78eda5f406389a87e8
Add `ci.yml` github actions workflow.
commit sha 2e18e0de109f4efa6ee67a87dee89e7500263988
Switch `bors.toml` to read `ci` workflow status.
commit sha 79a98abe8c51f372e53d624ecc821cf5cc3276b1
Remove `.travis.yml` and `ci-script.sh`
commit sha f01359c7a655625ab691c38000382ced3b50c64d
Update `README.md` CI badge to point to Github Actions.
commit sha 860251e29c69fd939d3041f040e709b898ef6de5
Remove Rustfmt job from CI.
commit sha a6d309be5c8fb641767f1b1de216a3518da17b20
Merge #201 201: Add `ci.yml` github actions workflow. r=azriel91 a=azriel91 Switch CI to use github actions, as bors isn't getting past travis (always times out). Co-authored-by: Azriel Hoh <[email protected]>
push time in 5 days
push eventamethyst/shred
commit sha cfa1dbfdf83ce86bcb79cd78eda5f406389a87e8
Add `ci.yml` github actions workflow.
commit sha 2e18e0de109f4efa6ee67a87dee89e7500263988
Switch `bors.toml` to read `ci` workflow status.
commit sha 79a98abe8c51f372e53d624ecc821cf5cc3276b1
Remove `.travis.yml` and `ci-script.sh`
commit sha f01359c7a655625ab691c38000382ced3b50c64d
Update `README.md` CI badge to point to Github Actions.
commit sha 860251e29c69fd939d3041f040e709b898ef6de5
Remove Rustfmt job from CI.
commit sha 808c3cbc4296ee373c8a9a4022335720d7194cf2
[ci skip][skip ci][skip netlify] -bors-staging-tmp-201
push time in 5 days
push eventamethyst/shred
commit sha f3fe487275628816251ca1978eee37f3882f2f2c
Merge #198 198: WIP/PoC: Batch api ergonomics r=azriel91 a=vorner Hello As mentioned in #197, I've sketched some API how the batch dispatching could be improved so it's less awkward and doesn't require unsafe. This is very much a PoC/WiP, I don't want to merge it as it is. I know there are missing docs, copy-pasted comments that are out of context, extra includes that are no longer needed, some things are public when in fact shouldn't be and in general a lot of garbage. I plan to clean it up before asking for it to get merged. What I would like now is to have some feedback on the API. I have some specific questions, but any other suggestions are fine too: * Naming. In particular, the simpler case where it is decided up-front how many times the sub-dispatcher should run is currently called multi-batch. I think this is a bad name, because it suggests it's somehow „more“ than the usual but more complex case. * The multi-batch is a separate method of the builder. Alternatively, it could be exposed as the wrapper type and one could create it directly. I'm not sure on what's better. In general, however, I feel like this makes the API more approachable (obviously, after it gets some docs and examples). @azriel91 Do you think I should continue in this? (and, btw, there's a tiny doc update PR from me sitting there for some time as well). Co-authored-by: Michal 'vorner' Vaner <[email protected]>
push time in 5 days
push eventamethyst/shred
commit sha d23c39275d6383add640cf2d11cfebf7f59920bf
Batch dispatching ergonomics * The dispatcher is now passed in as a value, so it can contain data. * No need to touch unsafe by the user. * Helper for the usual case where the number of times the batch is run is decided ahead of the time. Closes #197
commit sha 97220c294b3d6b21bbf880fd03fb4e7b578bc474
[ci skip][skip ci][skip netlify] -bors-staging-tmp-198
push time in 5 days
pull request commentamethyst/shred
Is it timing in the tests (in some way I might be responsible for), or is it timing in submitting the tests to CI? I don't seem to be able to get to any kind of logs :-(.
comment created time in 6 days
push eventamethyst/shred
commit sha cd4b7c37be0728920b3292d7db8bc1ea572c6869
Merge #198 198: WIP/PoC: Batch api ergonomics r=azriel91 a=vorner Hello As mentioned in #197, I've sketched some API how the batch dispatching could be improved so it's less awkward and doesn't require unsafe. This is very much a PoC/WiP, I don't want to merge it as it is. I know there are missing docs, copy-pasted comments that are out of context, extra includes that are no longer needed, some things are public when in fact shouldn't be and in general a lot of garbage. I plan to clean it up before asking for it to get merged. What I would like now is to have some feedback on the API. I have some specific questions, but any other suggestions are fine too: * Naming. In particular, the simpler case where it is decided up-front how many times the sub-dispatcher should run is currently called multi-batch. I think this is a bad name, because it suggests it's somehow „more“ than the usual but more complex case. * The multi-batch is a separate method of the builder. Alternatively, it could be exposed as the wrapper type and one could create it directly. I'm not sure on what's better. In general, however, I feel like this makes the API more approachable (obviously, after it gets some docs and examples). @azriel91 Do you think I should continue in this? (and, btw, there's a tiny doc update PR from me sitting there for some time as well). Co-authored-by: Michal 'vorner' Vaner <[email protected]>
push time in 6 days
push eventamethyst/shred
commit sha d23c39275d6383add640cf2d11cfebf7f59920bf
Batch dispatching ergonomics * The dispatcher is now passed in as a value, so it can contain data. * No need to touch unsafe by the user. * Helper for the usual case where the number of times the batch is run is decided ahead of the time. Closes #197
commit sha 2e832440caa6dc7002ffbb2104b385df780b929e
[ci skip][skip ci][skip netlify] -bors-staging-tmp-198
push time in 6 days
push eventamethyst/shred
commit sha 481b358999450ef7db0a199f19888cb74d753f6a
Merge #198 198: WIP/PoC: Batch api ergonomics r=azriel91 a=vorner Hello As mentioned in #197, I've sketched some API how the batch dispatching could be improved so it's less awkward and doesn't require unsafe. This is very much a PoC/WiP, I don't want to merge it as it is. I know there are missing docs, copy-pasted comments that are out of context, extra includes that are no longer needed, some things are public when in fact shouldn't be and in general a lot of garbage. I plan to clean it up before asking for it to get merged. What I would like now is to have some feedback on the API. I have some specific questions, but any other suggestions are fine too: * Naming. In particular, the simpler case where it is decided up-front how many times the sub-dispatcher should run is currently called multi-batch. I think this is a bad name, because it suggests it's somehow „more“ than the usual but more complex case. * The multi-batch is a separate method of the builder. Alternatively, it could be exposed as the wrapper type and one could create it directly. I'm not sure on what's better. In general, however, I feel like this makes the API more approachable (obviously, after it gets some docs and examples). @azriel91 Do you think I should continue in this? (and, btw, there's a tiny doc update PR from me sitting there for some time as well). Co-authored-by: Michal 'vorner' Vaner <[email protected]>
push time in 6 days
push eventamethyst/shred
commit sha d23c39275d6383add640cf2d11cfebf7f59920bf
Batch dispatching ergonomics * The dispatcher is now passed in as a value, so it can contain data. * No need to touch unsafe by the user. * Helper for the usual case where the number of times the batch is run is decided ahead of the time. Closes #197
commit sha 695f00dd75451e93d830ca48d71f4940cf3e0474
[ci skip][skip ci][skip netlify] -bors-staging-tmp-198
push time in 6 days