Tetra 0.7

[17cupsofcoffee]

Some breaking changes are starting to pile up, so I think it's time to start thinking about Tetra 0.7!

I don't expect there to be any huge API changes - this is just an opportunity to clean a few things up.

Work so far: https://github.com/17cupsofcoffee/tetra/compare/0.7 Changelog: https://github.com/17cupsofcoffee/tetra/blob/0.7/CHANGELOG.md

Current roadmap (subject to change):

Note: I've crossed out a few items that I don't think I have the bandwidth to do at the moment.

• [x] Upgrade to Rust 2021.
• [x] Remove all deprecated items.
• [x] Add support for more texture formats.
  • This will supercede #274.
  • [x] To avoid data loss when using HDR formats, Color ops should be made non-saturating.
• [x] Update rodio and vek.
  • Long term, I would like to switch from rodio to oddio, but I don't have time to work on this at the moment.
  • It would be good to look at how we can make these kinds of updates not be a breaking change in the future.
• [ ] Make any dependencies that aren't 100% required into optional (but potentially on-by-default) features.
  • This would be nice both for compile times and for reducing the amount of licenses that need to be bundled with a game.
• [ ] Consider if the run API could be changed to future-proof for a web backend.
  • The current design of propagating errors back to main is nice, but completely incompatible with platforms where the game loop runs asynchronously. I don't know if I'll ever get around to writing a web backend, but it would definitely need a breaking change if I did.
• [ ] Future-proof DrawParams for if we want to add extra fields later on, either by making the fields private or by making the struct #[non_exhaustive] (which would prevent constructing through a struct literal, but would not prevent reading the fields).
• [ ] Allow setting non-uniform frame lengths for animations?
• [x] #276
• [x] #296
• [ ] #269
  • Still not quite sure how I want to resolve this, but I think it could end up being a breaking change.
• [ ] #262
  • I tried adding this to DrawParams but it didn't really feel like the right place for that to go, as it doesn't make sense for meshes.
• [x] #299

[tesselode]

My thoughts:

• Find a way to make graphics settings not rely on global state (blend mode, stencil state, etc.)
• Rename functions like get_window_size to just window_size (more idiomatic naming in the Rust community)
• Change API to use mint instead of vek

[17cupsofcoffee]

Find a way to make graphics settings not rely on global state (blend mode, stencil state, etc.)

Good call - I had a go at trying to implement something like Love2D's state stack before and trying to do it in a non-breaking way seemed like it'd be an absolute nightmare. Can't guarentee I'll find a nice solution for 0.7, but I'll give it some thought (if you have any ideas of what this API could look like, I'm all ears!)

Rename functions like get_window_size to just window_size (more idiomatic naming in the Rust community)

This is definitely idiomatic for field getter methods on a struct, but I'm less sure what the consensus is for free functions? I'll have a look at what other libraries do there.

Change API to use mint instead of vek

I'm open to this if it doesn't make the API more awkward to use - I've never really tried mint so I don't know how it works in practice!

[tesselode]

I've never really tried mint so I don't know how it works in practice!

In ggez, functions that take vectors or other math types are generic and they let you pass in anything that implements Into<mint::Vec2> (or the appropriate mint type). That way you can pass in types from any library that has mint support.

[17cupsofcoffee]

I think taking mint types as parameters would be okay, the bit I'm less keen on is the cases where we return stuff like Vec2 - could be a bit gross to have to convert the return value back to your own type every time. But might be worth it for the improvements elsewhere, I'll give it a go and see how I feel about it :)