The big math libraries are cgmath and nalgebra. Both of them have deal-breaking flaws for many, namely (imo):

• cgmath has a weird, idiosyncratic design that simultaneously does too much and too little, and tries to shoehorn in genericism with complex traits that are difficult to internalize.
• nalgebra stretches the type system so far that the documentation is nigh impossible to understand without extreme patience and a deep understanding of generics.

As a result, several people have gone and made their own math libraries that try and solve those problems, which don't get adoption because the ecosystem hasn't grown up around them. I'd like this issue to house discussion on how exactly we can go about designing a library that addresses those issues, while developing enough consensus that we can potentially replace both of the current libraries.

Update: Most work is done! Unfortunately this didn't help the GL API as much as it helped the newstyle APIs like Vulkan/Metal/gfx-hal/wgpu, but it was a good improvement.

Windowing Side

• [x] winit: raw-window-handle is supported as of 0.20.0-alpha3
• [x] glutin: GL has problems in general with it, but glutin uses a new enough winit that it technically has the support.
• [x] beryllium: Available in 0.1 series and via feature in 0.2 series
• [ ] sdl2: Issue opened, https://github.com/Rust-SDL2/rust-sdl2/issues/910

Graphical Side

• [x] ash: Ash doesn't track the extensions enabled, so it can't actually use raw-window-handle to automatically do anything for you. You're just on your own, which is what you'd expect from a minimal bindings library.
• [x] gfx-hal added in https://github.com/gfx-rs/gfx/pull/3038
• [x] wgpu: Fixed in https://github.com/gfx-rs/wgpu-rs/pull/70
• [x] glow: Updated to a new enough glutin in https://github.com/grovesNL/glow/commit/7a73cf9a258ec326fd378cc4388ce1bb926a808e, though the GL limits still apply.

original issue post follows:

gfx-hal (technically the Instance type in gfx-backend-foo for one of gl, vulkan, dx12, etc) takes a &Window, but all types actually secretly have their version number as part of their type so it takes a &Window-v0.19.0. That's fine and all except there's a new 0.20.0-alpha2 out and people are supposed to be trying out that new alpha but they can't draw a picture because it's the wrong version so you get a type mismatch error. We can hardly alpha test the library if we can't even draw a picture. The backends have a plan for what to do: ignore their winit integration, possibly disable the winit feature entirely, and then use the create_surface_from_THING version for whatever raw window thing you have. This is annoying, but you can do it. The gfx-backend-vulkan crate has support for xlib, xcb, wayland, and even an existing vulkan surface. Honestly, all that create_surface does with the &Window is look inside the Window for the raw window data (using the right platform specific extension trait), and then call one of the other constructors anyway.

What we should do is cut out the whole middle step where gfx-hal has to know about the unstable winit crate, and we let it rely on a very stable interface that both winit and gfx-hal and other window libs and other graphical libs can all agree on.

We'll call the crate raw-window-handle (bikeshed here). The crate only needs a single trait and a support enum for the return value of the single method on that trait:

pub unsafe trait HasRawWindowHandle {
  fn raw_window_handle(&self) -> RawHandleData;
}

pub enum RawHandleData {
  Win32{ hwnd: *mut c_void},
  XLib{ display: *mut c_void, window: u64 },
  Cocoa{ .. } \
  // etc, one for each windowing system,
  // we prefer c_void and pointer casting instead of the "real" pointer
  // types when possible so that it builds easily on all platforms.
}

Then winit implements this for Window, and gfx-hal backends can write create_surface(win: &impl HasRawWindowHandle), and end users trying to get the two to talk to each other stop having to match their versions up quite so tightly. The raw-window-handle crate can just be one of those "0.1 crates that basically never updates because it does the job fine as is" like libc, perhaps to become 1.0 once we've really kicked the tires a bit., perhaps never to even bother with 1.0 at all.

And that's something we could get done in just 1 month.

This is the place to propose new agenda items and things to discuss in the next meetings.

Current agenda:

• Discuss status on issues.

Feel free to add subjects as a comment.

If you can't make it to the meeting don't worry as there are no decisions made in meetings. It's just a place to discuss ideas, check status of various ongoing things and the only actions taken as a result of a meeting would be: opening a issue or clarifying something on an issue

Action items:

• [x] Give feedback on @TimDiekmann's allocator repository. (~@kabergstrom will champion~ Done by @wodann)
• [x] Review and discuss state of input handling.
• [x] Investigate possibility for standardising more core concepts
  • [x] thread pools (@Lokathor)
• [x] Host AreWeGameYet and transfer domains (@ozkriff)
• [x] minimal frame allocator with bump allocation and a reset function.

Action Items From Last Meeting

• [ ] Discuss open wg PRs
• [ ] Investigate more about Placement New (pre-rfc? rfc? where is the ecosystem at).
• [ ] More chat about the state of rust audio libraries? Bindings to opens OpenAL, cpal latency issues (low-handing fruit?), the cpal/rodio workload split.
• [ ] Rust on Mobile (CI, cargo integration, etc)
• [ ] custom allocator followup (wg link)
• [ ] Any movement on the ecosystem guide (@Wodann)
• [ ] Improve issue tracker triage (smaller issues if possible, more labels about areas/skillsets, etc)
• [ ] Ecosystem survey (if it's been published).

From last meeting:

• [ ] Helping the alloc-wg move forward with getting their experiments in front of more people (@Lokathor)
• [ ] Discussing an update to the gamedev-wg charter so that it is more like the embedded-wg's charter (@Lokathor)

Ongoing subjects of note:

• [ ] gamedev survey?

Post more agenda items here if you have them!

Action Items From Last Week:

• [ ] @kabergstrom: help gather more info about allocator use cases
• [x] @kvark: ask granka about custom allocators progress (also generics?)
• [ ] Debug performance (mostly generics)
• [ ] AreWeGameYet status

Post more topics to discuss!

It's been 2 weeks time for another meeting.

Same time as usual, same place as usual.

I know it's late notice, but put agenda items here.

EDIT: Proposed Topics:

• @kvark: GL in raw-window-handle
• @msiglreith: Memory management, including "placement new"
• @msiglreith: Audio, (https://github.com/rust-gamedev/wg/issues/40)
• @Wodann: Adopting rust in industry
• @aclysma: How we should cope with the Known Issues List

(Regular reminder, meetings are public on Google Hangouts, info is in the repo's readme)

Action Items From Last Meeting

• [x] Did we put last meeting's action items in this meeting's agenda?
• [ ] Gather info/guidance around "placement new" language feature or possible workarounds.
• [ ] Try working with something like MyType::new_here(&mut MaybeUninit<MyType>).
• [ ] Investigate lower level sound API
• [ ] Contact Ready At Dawn for more info about their Rist usage, possible closer collaboration.
• [ ] Contact Embark Studios for more info about their Rist usage, possible closer collaboration.

Agenda This Week

• TBD, post here if you want something to get discussed.

In today's meeting, we discussed maintaining a list of issues we'd like to raise to the core language team as a markdown file. (#38)

I looked through the bugs in this repo and the embark repo and these are the ones that stood out to me.

Rendered

For discussion:

• Anything to add/remove?
• Is this the right level of detail for each issue?
• Obligatory bikeshedding of filename, location, prose... :)

I've created an issue on the arewegameyet repository to see if the owner would be interested in transferring ownership to this wg. The motivations for this are listed in that issue, and I'm posting this here as a tracker and to see if it's something the wg would be interested in.

As you may know, we have a Twitter account (that is mostly run by me) for making announcements and collecting all the cool rust gamedev stuff there into one feed - and I'd like to experiment with creating a similar "official" account on https://mastodon.gamedev.place Mastodon server. Seems like a bunch of rust gamedev folks&projects post to fediverse now so it should have enough content.

Any thoughts or objections?

Rusty Jam(Game jam with games written in rust) co-host here. We recently got approached by a crypto company wanting this:

We are currently looking for interesting partnerships with in order to bring more amazing builders into the blockchain space. Would you be interested to catch up on aa short call to see where we could collaborate? (and they did clarify that it's about Rusty Jam)

I don't exactly know what they want from us, but I think it would be great if they're going to be ready to sponsor Rusty Jam #3 prizes. I have zero experience with prizes, but I think the prize should be something small but will still make them feel good thing, like maybe 100$ dollars. Bigger prize is going to turn the whole thing from light-hearted competiotion to a battlefiled.

What do you think?

I've had a chat with @erlend-sh, and a few topics came out.

First: does anybody has any interest in maintaining the project? The task should be to review incoming PR.

Second: should game library maintainers be collaborators (read permissions) on the project? The idea is that, along a repository maintainer, a second pair of eyes should be a game library maintainer.

That'd be it. I can take care of the technical maintenance of the repo (README updates, CI, etc.), which I'll start shortly.

@64kramsystem is pretty far along with a project that I believe would make an excellent community-driven project for the GameDev WG.

This would be in a similar vein as https://github.com/rust-gamedev/wg/issues/89, which arguably went quite well even though it’s not that actively updated; I like to think we collectively realized that speed is only one aspect of an ECS, and a rather small one at that once a baseline of performance has been established.

rust-game-ports has a greater potential for ongoing development because ‘How do you made Game X in Engine Y’ is an ever-evolving question.

From the rgp readme:

The completed ports are:

| Source | Game | Engine | | ------------------------------------ | :-------------: | :--------: | | Code the Classics Vol. 1 | Boing | ggez | | Code the Classics Vol. 1 | Cavern | Macroquad | | Hands-on Rust: Effective Learning... | Rusty Roguelike | Bevy (ECS) | | Code the Classics Vol. 1 | Soccer | Fyrox |

I currently don't plan any further ports.

What I’m suggesting is inviting the Rust gamedev community to add new example games to this repo, so the matrix of different games continues to expand. What we want is games like pong, boing, space invaders etc. to be implemented side-by-side in several engines. Engine devs are incentivized to lend a hand with these examples to make them representative of best practice.

Hello guys & girls,

2 years ago I've started a rust game, which is a clone of the good old SuperMorph for SNES. My goal was a 2D Game for Windows and Android, but mainly trying to build a Multi-Platform OpenGL based game from scratch.

What makes this project interesting?

• It's based on it's own engine, nearly implemented from scratch.
• It seems it is one of the few solutions, working on android (by fixing winit & glutin bugs). Is this still a problem? I don't know.

Why is not finished?

• I'm no student anymore, real life caught up with me.
• Work, Family, other stuff and less time make it hard to continue
• Basic concepts are already implemented, main problem is level design.

Where can I find the project? https://github.com/Kaiser1989/morph

What should you/we do? I don't know. But I think it would be a shame if this project would die on my disk.

Best regards