| slug | velaptor-release-v1.0.0-preview.45 | ||
|---|---|---|---|
| title | Velaptor Release v1.0.0-preview.45 | ||
| authors | kinson | ||
| tags |
|
import URL from "@site/src/components/Url"; import ReleaseNotes from '@site/src/components/ReleaseNotes'; import GHUrl from '@site/src/components/GHUrl'; import IssueOrPr from '@site/src/components/IssueOrPr'; import JoinComm from '@site/src/components/JoinComm';
Welcome to another exciting update for Velaptor! 馃帀
I'm thrilled to roll out this next preview release. We've been working hard on some internal plumbing that will tremendously help us understand how Velaptor is being used out in the wild, while also squashing some elusive bugs, beefing up thread safety on our OpenGL resources, and making file paths much friendlier across different platforms. This release is all about returning better insights to help us build a better framework鈥攁nd making it more robust along the way.
:::info Release Notes Check out the :::
A big thanks to the following contributors for their work on this release! 馃帀
{/truncate/}
In this release, we're introducing a brand new, non-blocking telemetry feature to Velaptor. This system tracks framework usage and hardware information (specifically CPU and GPU data) so we can prioritize bug fixes and framework optimizations moving forward. But that's not all! We also tackled an aggravating keyboard input bug caused by fancy media knobs, brought cross-platform sanity to file paths with built-in path normalization, and hardened our disposal logic to prevent race conditions during framework teardown.
We know the word "telemetry" can sometimes raise eyebrows, so I want to be completely transparent: this data contains zero PII, does absolutely no source code scanning, and uses no hardware fingerprinting. Moreover, it's disabled in your shipped release builds. In fact, it will never be enabled in any release builds of a game built with Velaptor. It's strictly for our internal use to understand the usage and hardware landscape during development.
Building a cross-platform game framework is tough when you're flying blind. We need to know what kind of hardware developers are actually using. Are most users on older discrete graphics cards, or running newer integrated GPUs? Does macOS need more specific attention on ARM chips?
Answering these questions ensures we aren't wasting time writing optimizations for hardware nobody plays on鈥攁nd guarantees we're fixing bugs that actually affect you and your players.
When we set out to build this, our absolute top priority was to ensure it wouldn't step on your frame rates.
The TelemetryService we built uses a strict "fire and forget", non-blocking asynchronous HTTPS call pointing to an endpoint.
This means that as soon as the telemetry ping fires, Velaptor moves on. It doesn't wait for a response, and your game loop
code won't feel a thing. Under the hood, this was made possible by leaning on dependency injection, injecting everything
cleanly into our window factory and OpenGL components.
To further improve performance, the very first time telemetry is collected, the data being sent out is cached locally to a JSON file. This means that subsequent telemetry pings will be lightning fast, as they will simply read from the local cache instead of re-collecting hardware info every time.
We also brought in a new hardware.info NuGet package and specifically set up custom interop for macOS to get reliable CPU
and GPU reporting across all our supported platforms!
Giving you control over this matters to me. So, here are the rules we enforce inside the framework to protect your privacy and reduce noise:
- Easy Opt-Out: Telemetry is opted out as default. This means you have to explicitly opt-in for us to collect data if you want to participate. Check out the page for more information on how to opt-in.
- Only Debug Builds: Telemetry is completely disabled in release builds (handled via preprocessor directives). You don't have to worry about your end players accidentally pinging our servers.
- Development Environment Only: Telemetry is only collected when you're developing your game in an IDE. If you run your game outside of an IDE, telemetry won't run.
This follows the principle that the
useris the game developer, not the game player.
We've updated the docs to make all of this transparent. You can now visit the new page, which elaborates on exactly what we monitor and walks you through the opt-in/opt-out processes via various IDE user configurations.
If you've ever adjusted your volume using a fancy keyboard knob right in the middle of a gaming session and watched your Velaptor game completely crash鈥擨 feel your pain.
So what happened here? It turned out our input library under the hood (Silk.NET) would emit an "unknown" key enum value when interacting with these non-standard peripheral media keys. Since we weren't expecting a mapping for those, it tripped a NotImplementedException, bringing the whole application down. Definitely not ideal! We've patched this up so that any Silk.NET.Input.Key.Unknown bindings are simply and gracefully ignored. Play on!
We've all been there: you write a path with backslashes on Windows \, push your code, and suddenly your POSIX environments crash because they expect forward slashes /. It's a tale as old as time.
To save everyone from OS-related path crashes, we've baked path normalization directly into the entire content system. Velaptor will now dynamically transition paths to match the runtime environment, meaning you can comfortably use either Windows-style or POSIX-style paths and the framework handles the rest. Better yet, we implemented this leaning heavily on Span<T>, keeping those allocations super low so we're not constantly triggering garbage collection just to fix slashes.
A few areas of the framework got some overdue hardening, specifically around how we clean up resources. There was a subtle race condition lurking where OpenGL resources (like textures or shaders) were being disposed. Because finalizers run on a completely different thread than explicit Unload() or Dispose() calls, two different threads could attempt to clean up the exact same native resource at the identical moment.
We locked this down by upgrading the isDisposed flag in classes like AtlasLoader, Texture, and ShaderProgram from a simple bool to an int. Now, we use Interlocked.Exchange() to perform a perfectly atomic check-and-set during teardown. Now, the first thread to start the teardown reliably takes ownership, keeping your cleanup logic safe and crash-free.
Lastly, we ran into an annoying testing issue tied to our OpenGLService. We were putting IGLInvoker debug method calls inside DEBUG and DEBUG_CONSOLE preprocessor directives for performance reasons. Makes sense, right? But this meant that if you ran unit tests on a release build configuration, those methods straight up didn't exist, and the tests would fail.
We fixed this tech-debt by yanking those preprocessor directives out of OpenGLService entirely and moving them right down into the GLInvoker implementation itself. We also spun up some helper methods so our tests can accurately reflect the active build configuration without randomly falling over in production pipelines. It's a small internal win, but it makes CI/CD that much happier.
That's all for this one! Until the next release! 馃殌