miniquad VS ron

You also have Miniquad which is a very cool minimal graphics project. It has almost zero dependencies (only system ones), and compiles under 2 seconds to give you a window with OpenGL on all platforms including mobile very easily. It has a wrapper graphics API but it doesn't try to be modeled after OpenGL at all (after all it might support Metal in the future), so it's gonna be quite different doing your project in it, but it's still the same kind of low level graphics.

Theirs also https://github.com/asny/three-d or https://github.com/not-fl3/miniquad. Or lower level ones like WGPU or GLOW.

In that same rust game jam the second most used engine was macroquad, which was used by 3 games, two of which are playable in the browser. Macroquad is a cross-platform game library inspired by raylib. Macroquad is built on top of miniquad. I think macroquad is a bit more approachable than bevy since macroquad doesn't impose an ECS and tries to be minimal with its features so they are available in all of the platforms it targets.

(miniquad is a lower level lib https://github.com/not-fl3/miniquad - both miniquad and good-web-game is built on top of it)

Single command deploy for both WASM and Android build instructions

Hi, I am using macroquad. There is an issue with `window_reizable` property. In my archlinux, this property doesn't work when set to `false`. Then I saw here that it is used only for windows. If I am correct, could you let me know the reason for this? Thanks

If you want to write your own shaders: miniquad.

Sounds like you want miniquad: https://github.com/not-fl3/miniquad

Whenever this kind of arguments come up, I am sad that RON (https://github.com/ron-rs/ron) is not better known. To me it feels like a cleaner and better JSON.

In any case, my little experience with it had made me hate YAML. Generally speaking, I have come to dislike any language with significant whitespace other than Haskell.

Part of the reason why I migrated away from RON in system76-scheduler is because I needed to rely on the 253-untagged-enums branch from https://github.com/MomoLangenstein/ron. Which still isn't resolved today: https://github.com/ron-rs/ron/pull/451.

Sounds like RON - Rusty Object Notation

Serde is strongly, strictly typed: you have to specify what type you want to decode to. It’s nothing like Python’s Pickle protocol.

See, for example, https://github.com/ron-rs/ron/blob/484fcab0686dfd18c7e29b6c1..., where it (in a type-inferency way) says “parse as Config”.

Cool project! I ran into some limitations of serde a while ago while trying to add some new features to ron: https://github.com/ron-rs/ron/pull/328. Not sure if that's the kind of issue you are planning to address, but either way it's a concrete example of a use case where serde is currently not a perfect fit.

You might like RON[1]. It's far from perfect (and far from complete), but seems nice so far.

[1] https://github.com/ron-rs/ron

While there's JSON5[1] now, it just has not the same level of native (ecosystem) support as JSON has.

[0]: https://github.com/ron-rs/ron

[1]: https://json5.org/