It would be nice if everything was pure rust.

[icefoxen]

Deploying DLL's on Windows is a pain in the butt. Pure Rust is much easier to work with. This would mean essentially ditching SDL and using a collection of crates that provide the same functionalities.

Ditching SDL will make life harder on iOS and Android. Hmmm.

The things that we would need to replace:

• Windowing, events and input (winapi/glutin, joystick and game controller input is a concern)
• Graphics (gfx?)
• Sound playing (ears, alto, ???) This is hard 'cause I believe the best crates depend on OpenAL anyway. Oh, cpal does not! Does it work well enough? rodio is built atop it, zang.
• Sound decoding (lewton, probably others). Need wav and ogg at the least, mp3 would be great. An opus decoder would be neat, as would midi and mod synthesizers
• Cross-platform file location handling (I know they're out there but don't remember what)

The main concerns with this is that a) we don't want to depend on something that subsequently never gets updated, and b) we don't want to take any steps backwards in functionality.

[icefoxen]

Roadmap, basically from easiest to hardest:

• File location w/ app_dirs crate, and maybe we can make it also detect when you're running from cargo (does it set an env var?) and look in the right location then as well (separate issue, see Make filesystem code more clever #39)
• Sound playing w/ rodio, maybe baal. Maybe add FLAC (Add a FLAC decoder RustAudio/rodio#37). Writing mp3 and opus decoders for it should be constrained to "for the lulz" rather than something we actually require. Positional audio playback might be nice, but seems to be essentially impossible without OpenAL because nobody's ever written anything better.
• Graphics w/ gfx and image loading with image. This is going to require writing a bit of an actual graphics engine, which I am honestly not super qualified to do. But, taking apart Love2D might teach me enough to do it.
• Finally, windowing with glutin. Getting controller input working on it would be nice. :/ We also need DPI numbers for resolution-independent font rendering.

[onelson]

maybe we can make it also detect when you're running from cargo

Sort of off topic, but I'd like to suggest adding some way to configure resource search dirs in the Config objects. Could ultimately be related to the work for this ticket.

[icefoxen]

That's a good idea!

[icefoxen]

File locations now come from the app_dir crate with commit d85d213 however there are still a couple of issues that need resolving upstream for full functionality (marked with BUGGO comments in the code):

• Can ZipFile implement Seek? zip-rs/zip-old#25 (necessary for reading sound files with rodio)
• Make AppInfo own its strings. andybarron/app-dirs-rs#19

[icefoxen]

For the record, baal is nice if you want a standalone thing but it goes through some grotty and unnecessary work to make and preserve global state. Which we don't need, because we do the Right Thing and bundle all our "global" state into the Context object. So adding stuff to it (which we would probably need to) would get sticky, and we might as well just not bother.

On the other hand, rodio does make life a little hard at times; it requires Sink's be thread-safe, which zip files are not. At the moment we can solve that by always slurping audio out of a zip file and into an in-memory buffer, but it would be nicer if we had a better solution. See zip-rs/zip-old#14

[icefoxen]

This is now pretty much complete to the level I want for 0.3: SDL is only used for windowing and input events. Need to look into making glutin handle controller and touch input at least as well as SDL does; until that point I suspect SDL is sticking around. But that's a project for another time.

[icefoxen]

Another concern: The emscripten API uses SDL for multimedia access. So if we stick with SDL and make gfx use WebGL (see gfx-rs/gfx#641) we might be able to just build things for web. Which would be amazing.

[DenialAdams]

Have you looked at the following for Controller support?

https://github.com/Arvamer/gilrs

I haven't used it (yet) so I can't comment, but it seems pretty neat.

[icefoxen]

Good to know, I'll check it out!

[icefoxen]

Another thing glutin apparently doesn't have yet: Proper cross-platform DPI figuring-out-ness. See rust-windowing/winit#105 , and the various implementations of hidpi_factor() for various platforms, most of which are... placeholder-y.

[NurbsOtter]

I saw someone did some preliminary glutin stuff but dropped controller support entirely, so I like hacked gilrs in on top. It works pretty good and doesn't require SDL2 to be installed anymore, It's at https://github.com/NurbsOtter/ggez/tree/glutin

[tomassedovic]

Instead of ditching SDL altogether, would it maybe be possible to add glutin as a Cargo feature? That way people who want/need pure Rust can opt in to it at the expense of some functionality.

(apologies if this has been discussed elsewhere -- I haven't seen it)

[icefoxen]

That's an interesting idea! However it would probably be significantly more work than just replacing SDL...

[icefoxen]

glutin has an emscripten backend now. 🎆 🎉

So we have basically no excuse not to use glutin instead.

[tomassedovic]

So as someone who's been wanting this forever and who's now considering switching from Glutin to SDL with their game, I'd recommend caution.

If you try to switch to fullscreen on Windows or OS X, it will panic.

Glutin uses Winit under the hood and there's a few important operations that are not implemented yet for anything other than Linux. And instead of not doing anything or printing a warning, they bring down your whole program:

https://github.com/tomaka/winit/blob/d92666c1880bad27d624dbbda2e14adc2b72e557/src/platform/windows/window.rs#L283-L300
https://github.com/tomaka/winit/blob/d92666c1880bad27d624dbbda2e14adc2b72e557/src/platform/macos/window.rs#L637-L654

Here's a winit's feature parity tracking: rust-windowing/winit#252

And a couple more issues related to the fullscreen situation:

rust-windowing/winit#72
rust-windowing/winit#37

I'm not advocating against the switch, but depending on the importance of these features on the various platforms for ggez, there may in fact be reasons not to use glutin instead yet.

I'd like to implement the missing bits myself, but I don't even know where to start /o.

[icefoxen]

Well then, we need to make winit suck less.

[tomassedovic]

Yeah! Like I said, I'd be happy to help with that but I'm not entirely sure how.

[francesca64]

In regard to winit, fullscreen toggling on Windows is now implemented thanks to rust-windowing/winit#457, and it looks like the same person plans on addressing macOS next.

At present, I'm more or less acting as winit's maintainer, and you can feel free to think of me as your liaison to the project. It would be fantastic to have ggez using winit, since more real applications using winit = winit having less bugs and a design that reflects real world needs. That said...

winit is not ready for production. By my most optimistic estimate, if development continues at the current rate (note that the current rate involves me spending all of my time on winit), it might be convenient to use in a year, and that's not even considering mobile platforms. My impression is that most people in the ecosystem assume glutin/winit is solid, since it's a de facto standard crate, and Rust's culture leads you to expect things to be clean and robust (that, and the tomaka seal of quality).

The biggest obstacle is that we're severely understaffed. I imagine that some people who would consider contributing could be turned off by incorrectly assuming that winit is run by tomaka's elite wizards, and that they don't have any hope of measuring up to our deep expertise in the arcane arts of using FFI to wrangle complex poorly-documented platform-specific APIs made in the 90s.

At least, that's how I felt when I submitted my first PR back in December. The reality is that nobody was around who could give my PR a thorough review, and a week later I became the person who reviews X11 PRs. I've recently started reviewing Windows PRs as well, but I still lack access to a Mac, so PRs that touch macOS code can be slow to merge. This also means it's difficult to roll out cross-platform API changes. There are other collaborators, and they've all done great work, but they tend to be busy. Even if they weren't busy, it still wouldn't be enough people; assuring the quality of something as central and complex as winit is simply too cognitively overwhelming to be handled by a very small number of people.

I do plan on making efforts to attract more contributors (posting this here being part of that), but I'm kept busy by reviewing PRs, responding to discussion, investigating bugs, and so on. @tomassedovic, if you want to help out on winit, I'd be willing to help you with anything and everything you need to know. This applies to anyone else reading this too; I'll even mentor people new to Rust if I have to, and I'm 100% serious about that. It's essential to the whole of Rust's graphical ecosystem that the situation with winit improves, and it pains me to say that using glutin/winit at present would be antithetical to ggez's goals.

[icefoxen]

Hi, @francesca64, nice to meet you and thank you for your input.

I've actually been seriously considering switching ggez to winit lately, and have been working on writing a blog post to that effect. Your honest opinion on this is invaluable and will be incorporated into this decision; I'm a firm believer in going as far up the dependency tree as necessary to make things work so I'm tempted to use winit anyway, but I like so many others only have so much time in my life. I've been spending this year trying to lay the groundwork for ggez to work on web platforms, and every time I use emscripten it bites me in the butt one way or another, so the best path so far seems to be to make it easy for winit to target wasm-on-web... but that's a bit of a a long road to begin with.

Might be in our best interests to call ggez as it stands (plus some bugfixes and maybe integrating gfx_glyph) 1.0, and then embarking on the more ambitious project?

[francesca64]

At this point, I'm less worried about winit itself. There've been a ton of improvements in the past month, and I've been able to give attention to the macOS backend as well. For games, winit should be more or less adequate; it's GUI/general purpose applications where winit still has glaring deficiencies, but I suspect the same is true of GLFW.

glutin is a different matter... I don't work on glutin (it's probably more fun than working on winit, but if I try to maintain all of tomaka's crates, then we'll be right back where we started). Nobody's working on glutin at all, though I doubt there are any show-stopping issues there. It's just that if there are, there's no one in place to fix them.

I'd say gilrs is the biggest obstacle. On Windows, it only supports XInput, and only on Windows 10. The Linux support (evdev) seems fine, but no other platforms are covered. It would probably only take me a week or so to fill in both DirectInput and macOS support, since working on winit so much has given me platform API superpowers. Android, Emscripten, WebAssembly, etc. would take more investigation, but I have to learn about those things for winit anyway. There's also surely a lot of API work that still needs to be done, since that's almost always true.

If people want me to Francescafy gilrs, I'll do it, since it means I'll get to hold a controller for the first time in over a month.

[Ratysz]

This is inspiring! Couldn't have been more timely, either: I finally (literally two hours ago) got around to messing with winit and glutin. Just learning for now, but fully planning on doing dev work (hopefully minor, if at all needed) - and, having more brains and eyes on inevitable ggez migration away from SDL2 is likely to be helpful, too.

I'll make sure to dust off my gamepads and experiment with gilrs as well. Said 'pads can switch between XInput and DirectInput, so at very least I'll be able to test support of that, if/when it happens.

[icefoxen]

@francesca64 I've been watching, and it's awesome! Thank you so much for championing winit a bit. I'm not super worried about glutin; I don't know much about its state but I'm fairly confident in my own abilities to bring it up to snuff if needed, and I'm sure the gfx-rs folks will chip in on it if necessary.

Personally, I consider gilrs a secondary goal; I'm a PC gamer, so while objectively gamepad support is a big deal, I always go for keyboard+mouse first and don't consider gamepads a blocker. 😛 I'll accept a gamepad support regression on some platforms if it makes things Start Working, and then improve it later. Emscripten and WebAssembly are also things I'm happy to tackle both for winit/glutin and for gilrs, and I know a lot more about the platforms for those than for actual operating systems. Weirdly. Alas, android+ios seem like they're going to continue languishing in the void until we find time to learn about them (hah).

So, work on what you want to, and I'll fill in whatever gaps need filling in. (Slowly.)

[icefoxen]

Devel branch now uses winit and it's rad af