1,085,079 events, 587,737 push events, 899,658 commit messages, 68,931,334 characters
Add an example to play notes using automation.
This is about as stupid as this gets, but it's C in which writing parsers sucks, and also in which bringing in a dep for a window is a pain. Since this is illustrative, just keep it boring for now.
We'll probably do something more involved in Rust.
Refs #73
Big cleanup commit.
Realization: working with vulkan by itself is soooooo old fashioned!
I've been strugging with life and whatever while trying to learn vulkan, and as cool as vulkan is, learning it has SUCKED!! I think I understand roughly how the various vulkan api components relate to each other and more or less their lifecycles, I just can't get over the tedium of working their management into a larger codebase. Ability to work move code complexity out of drivers and into usermode code is cool and all, but I think the vulkan api screams to be managed in more opinionated ways.
I've found myself trying to do just that (in easy_vk.rs), but after some research I realized that others seem to be significantly further down that path than I am. Here are some of the ones I've checked out and my thoughts on them:
-
amethyst Rust's cargo ecosystem seems to orient towards solving problems once. Accordingly there are a lot of very-specific crates presently available, including some that are pretty useful towards game development. Amethyst appears to be an attempt by developers to build a standard way to work with these crates to build graphics applications (but mostly games). They have a book, which I tried to read awhile back when I was working on a 3d X compositor and last encountered this how-do-I-draw-3d-objects-without-using-raw opengl-or-a-whole-fking-engine problem, but my ambitious attempts to follow the book turned into attempts to read through the book, which in turn became hopeful attempts to find compelling examples of the framework (some of the component crates have books by themselves!!), which ultimately resulted in me losing interest considering I mostly just want to pursue an idea that'll probably fail more than I want to invest in a rickety set of evolving tools.
-
vulkano This vulkan tutorial links to a vulkano-version of its c++ contents, which I attempted to follow alongside the tutorial. I went through a similar cycle of getting bored with learning as I did Amethyst, only instead of getting bored at the tooling I got bored at the tedium that goes into all of the babysitting that vulkan requires to manage its fairly well-thought-out interface.
-
rendy Rendy is a lower-level rendering engine built on a hardware abstraction layer similar to vulkan's API, so this was the first candidate I figured would be a good middleground between some engine and raw vulkan. The project's README is hard to read but seems to mostly address painpoints I've already experienced with vulkan as well as a bunch of other neat things like modular graphics pipelines, so I started trying to learn it...
...only to discover that there's not a lot. Rendy strangely hard to find when you look it up in search engines, and not too many people seem to be talking about it on forums. I did find an incomplete book book, whose author appears to be the second biggest contributor to rendy and who even wrote a cool physically-based renderer, but aside from that and rendy's examples and documentation, I didn't have much to go off of. There hasn't been much recent activity if my reading of the project's insight graphs is correct, and the README still lists many features as being incomplete. When, after encountering similar management struggles, I considered the age of the project with respect to its seeming negative growth, I decided to keep looking.
-
bevy Looks similar to Amethyst, only is more honest with itself that it wants to be a game engine. This would likely be a good fit for my project, but after learning how hard it was to adapt my project to Amethyst's way of thinking I fear I'll encounter similar problems with Bevy. Maybe it'll be good though if I ever do want to make a normal video game though. It has a book!
-
wgpu I decided to look at this because the rendy page listed an older version of wgpu as a user, which suggested that other people probably also thinking that rendy needed another layer on top of it. I quickly discovered that a bunch of other huge projects use wgpu (servo, even bevy!), which is immediately assuring. wgpu seems to be a graphics API abstraction that works with pretty much every possible platform in a vulkan-looking way without a vulkan-level quantity of babysitting. It's perfect, and reading through the book it looks like it'll be a good fit for the sort of problems I actually want to solve. I mean, just look at the big picture graphic, it's absolute quality Mozilla code!
So, I decided on wgpu. It feels like the right balance of lightweight and low-touch, and as learning any of these APIs feels like a gamble of my free time, I think it's the best horse in the race. I like the that it makes constructing graphics pipelines a relatively fluid experience, and the fact that Mozilla is dumping resources into it is always a good sign. Bevy seems to use it for its renderer too, which is both validating and also a sign that I should keep putting time into it so I can at least determine when it makes sense to use.
Learning all of this was cool, but as you can imagine by flow has more or less been on pause for the last few months now. I figure I just need to commit to something so I can get things back on track, so I think I'll stop my search at wgpu and keep bevy in mind for later. Instead of working through everything I've left pending, I'm instead saving it all now in a master commit so I don't lose it.
Screen/Linux: Support Wayland compositors without wl_shell, but xdg_shell.
libWaffle as of its latest release now also supports the basic stable xdg shell protocol for window creation and management:
In the past, only wl_shell was supported. Now it will try to use xdg_shell and fall back to wl_shell if xdg_shell is not supported. As most production compositors do support xdg_shell in at least a basic variant by now, this means most of the time xdg_shell will be used.
Adapt our window setup code to make use of this new Waffle feature. Also some cosmetic changes to status messages etc.
This now allows testing on wlroots-based compositors like Sway WM, which do not support old wl_shell, but only xdg_shell. Also a bit more robust on KDE's kwin wayland and GNOME's Mutter wayland.
Restrictions:
-
We do not use xdg_shell calls ourselves yet, but rely on Waffle, so we are restricted: Can't select which output to display a fullscreen window on. That's supported on wl_shell only so far.
-
Also no assignment of window titles in windowed mode.
-
Oh and we need a bug-fixed libWaffle, as upstream release has a bug in its fullscreen xdg support! I'll need to upstream my fix.
-
Sway does support the presentation timing feedback protocol, so now we have n=2 compositors with not totally broken timing, yay! However: Scheduling on Sway is as much of a s***-show as expected, as each Wayland compositor seems to reinvent the wheel in terms of composition scheduling. This will stay awful until a proper presentation timing extension is released and supported by most compositors. On Sway one needs these tweaks to get not totally awful timing and performance on a 144 Hz display:
In Octave: setenv('PSYCH_WAYLAND_SWAPDELAY', '-0.002') In Sway's config file (see man sway-output):
output DP-3 max_render_time 2
Why these magic numbers? I wouldn't know, but endless tinkering made it work best for these settings. Any other refresh rate would probably need different numbers.
-> So this is an improvement, but far from anything one would want to expose ones's users to. X-Server still rules...