KindaABigDyl

Personally, Ardour > Bitwig. Couldn't ever figure out how to do anything in Bitwig. Very complicated an unintuitive.

Ardour is also unintuitive but 1) I did eventually figure it out and 2) it's at least free

Thankfully, we migrated to git entirely right before I joined the company

Neovim

So let's break the dang web

Return to the office. Forced to use Windows again

• Wayland has several new features like, say, removing screen tearing, but it's not necessarily "advantages" that are the reason to use Wayland. It's sort of a redo of how graphics should work in the Linux world, and it will be the standard going forward. X11 development has more or less ceased with those developers moving to Wayland (in fact, Wayland was created by X11 developers to address issues they had with the architecture of X11). It's not a matter of should you switch to Wayland; it's a matter of when should you switch to Wayland. The answer is, as soon as you can.
• Gaming varies drastically. Some games are fine. Some games make me launch Steam via Lutris to start (not sure why it works, but it does) but run fine after. Some games can't reach higher framerates. That said, no screen tearing is a plus. When it works, Wayland is very smooth, but it doesn't always work yet. An example off the top of my head, no matter what I do, Street Fighter 6 doesn't get above 45 fps on Wayland. It's a good idea to have an X11 option as a backup still imo
• The best way to migrate is just to install a Wayland compatible DE/WM. I've used both GNOME Wayland and Hyprland extensively and they both work great. If you're used to i3 (that's what I used to use and is still my X11 backup), Hyprland is great. KDE like you have on your Desktop already works good on Wayland from what I've heard.
• I have made the switch because most of my apps can run on Wayland, and it's the future. I still have a backup in case there's a game or something that doesn't quite work for me. For instance, I can't share screen on discord. It won't even recognize the pipewire route. Thus, I've gotta switch to X if I want to do that.

Systemd is a large piece of software. There are ways to make it smaller and disable various modules for it, but usually by default it's very heavy.

With a traditional init system, it's just an init system, and you'll use other other programs to do the other things. This basically means a chain of interconnected bash scripts. Perhaps you'll run into some integration issues. Probably not though. It'll be mostly the same.

There is no real advantage to this from a user perspective beyond a philosophical one. Systemd works quite well at doing the things it tries to do, but it's the Unix philosophy to "do one thing and do it well," and some people care very deeply that systemd does not follow their interpretation of that philosophy, and that's certainly a fair reason to not use it.

However, if you're not having problems with using systemd, I'd say don't bother switching.

Idk if I agree with that. The one that's in my laptop works pretty well. It's an RTX 3080 Mobile. It's fairly beefy, and I'm able to run AAA games at max graphics settings at 60+ fps. Sure there are crappy laptops with weak GPUs, but I mean gaming laptops exist and work great in my experience.

Any of them. I've gamed on Debian, Pop, Arch, Nix, Fedora, etc. Pick a DE you like, a package manager you like, a release cycle you like, an init system you like, etc and find the distro that matches. If you like Arch then use Arch. It's perfectly suitable for gaming.

wow

Is this what you’re doing here as well

Not at all. I don't have wall clipping support set up yet at all! It's a lot more simplistic. I've handled wall clipping in a similar camera system before using a SpringArm, but I don't think that will work here.

What I do here is I have one object that follows just the camera's y rotation, and I use that to get a forward vector using -object.basis.z.normalized() and I set a target position at player_pos + -forward * FOLLOW_DISTANCE + Vector3.UP * FOLLOW_HEIGHT and lerp to there. That handles moving with the player forward and backwards.

Then in the player code, I read the stick input into Vector3(x, 0, y) and then rotate it based on the camera's y rotation to put it into screen coordinates. Then I multiply by MOVE_SPD and set velocity.x & .z to the x and z of the product. This makes the player move forward and back with relation to the camera's forward and back.

However, you move left and right based on the tangent of a circle around the camera because back in the camera code, I have a look_at which causes the camera to turn as the player moves right/left relative to it, causing circular motion.

Beyond that, there are some simple tweaks like a timer that runs before setting a boolean to cause it to rotate back behind the player or only moving if the player is outside of the follow distance. Things like that.

It's pretty tightly coupled, which isn't great from a code perspective, but it's also unlikely to fundamentally change. If that were to happen, I'd probably want to totally rewrite the system anyway.

PS: I like that the test pattern texture of your level has so much detail. Not just the same plane checker square over and over again. :)

I just found it online somewhere years ago lol. Probably opengameart? I no longer have the original source, but it's pretty good for testing:

Yeah, I just did that bc there isn't a way to upload videos to lemmy. I appreciate the help to at least get it to show as a video lol