Josh

Mint is still the best, and it feels like they're the only one even trying to make a normal OS for computers. It seems like for everyone else, the actual desktop user is an annoying afterthought. Ubuntu is still chasing the Windows 8 dream of having a big touchscreen on your phone, TV, and computer. (Yes, I know Canonical no longer controls that, but that's even worse because they are allowing their name to be damaged.)

Okay, I quickly ran into some limitations when trying to do actual development on Bazzite. It looks like this OS is really just meant to act as a console OS, and doesn't allow you to install software in a normal way. There are pros and cons to that depending on intended usage. I tried "rebasing" to the developer version of Bazzite, which bricked the hard drive. My impression is that it's really just meant as an alternative OS for the Steam Deck and desktop usage is an afterthought. Linux Mint is probably my next stop, although I love the branding, name, and visuals of Bazzite, and that stuff matters to me.

Steam has worked like that for as along as I remember.

Writing this on Bazzite. I think it's pretty good.

Aren't these already the hotkeys for cut, copy, and paste, in the script editor?

5.0.2 beta If the world render call uses one single synced frame, then camera mouse looking will be updated in the main thread, which eliminates the latency of the rotation coming back from the rendering thread. This provides the absolute highest precision for tightly synced games. Added Window::GetMouseAxis back in. It will return the mouse position and print a warning the first time it is called, stating the command is deprecated. But old code will still compile without changes.

5.0.2 beta I came up with a way of handling the camera mouse look feature in a way that makes things easy on the developer. If the Windows GameInput service is not available, the mouse look will be performed in the main thread using low-resolution mouse input. If the GameInput service is available, the mouse look will be performed in the rendering thread using high-DPI mouse input, and the sensitivity will be adjusted to match the current Windows mouse speed setting. This will produce the same results on the same machine, with GameInput on or off. This way you don't have to check if the feature is supported, and you can just use it without worrying. The function definition Camera::SetMouseLook is slightly different now: void SetMouseLook(bool mode, float mouselookspeed = 0.1, const float smoothing = 1.0, bool invertmouse = false, Vec2 pitchlimits = Vec2(-90, 90) ) In this build, the NuGet package GameInput is required. To do this, select the Tools > NuGet Package Manager > Manage Nuget Packages for Solution... menu item, search for "GameInput" and apply it to the project.

Let's consider this command line: +map "Maps/level1.map" -fullscreen If you have a word that starts with +, it takes the next parameter as the value: +map "Maps/level1.map" Values can be strings, numbers, or booleans. If you have a word that starts with - it just sets the value to true: -fullscreen So in the returned table, the value "map" would be "Maps/level1.map" and the value "fullscreen" would be true.

Is it possible to upload this project for me to try?

5.0.2 beta Stack reserve size in new C++ projects is increased to four megabytes by default:

Another option is to increase the stack reserve size in the project settings: Properties->Configuration Properties->Linker->System->Stack Reserve Size The default value is one MB. Set this value to 4194304 to change it to four MB.

This has something to do with the Lua binding code being too big for the stack. When I declare this before the call to LoadScene, the program works correctly: GetLuaState(); Specifically, it's crashing in the Entity class binding code, which is probably the class with the most methods.

Did you get this sorted out?

5.0.2 beta I found a new library Microsoft has for low-latency thread-safe device input that doesn't clog the event queue with thousands of events. This is exactly what we need to support gaming mice with the lowest possible latency. However, there are two downsides to it: When this is implemented, C++ projects will require the GameInput nuget package be added to them. The feature is not guaranteed to be installed on all versions of Windows. There's a redistributable you can include in your installer, but we have seen from experience users will not install it, or the install will occasionally fail, or they will disable the feature, etc. Still, the Microsoft GameInput library is the ONLY way to do what we want. Therefore we will roll this out gradually. The new project template includes the GameInput nuget package by default, but existing projects do not yet require this to compile. Window::GetMouseAxis is removed from the API, to be replaced in the future with another command. The experimental Camera::SetMouseLook feature is removed, to be implemented in the future using GameInput. The only stock script that was using Window::GetMouseAxis was the CameraControls script. That code has been updated to do away with the calls to GetMouseAxis. The idea here is to make it so new C++ projects by default will be compatible with future GameInput support, but I don't think this feature justifies the introduction of incompatibility with existing C++ projects yet. If you want to add the package to your project, just select the Tools > NuGet Package Manager > Manage Nuget Packages for Solution... menu item, search for "GameInput" and apply to the project. YOU DO NOT NEED TO DO THIS. Even when this feature is completed, you will still need to check to see if the feature is installed on the user's computer, so if you want to support high-DPI gaming mice, you will still need a fallback mode in case the feature is not supported on the user's machine. For now I strongly recommend just relying on standard mouse input (Window::GetMousePosition).

The command is actually SetShadowCascadeDistance. I must fix the documentation.