> 1024 also OK, as long as it’s a fixed boundary :)
06.03.2026 01:59
👍 0
🔁 0
💬 0
📌 0
> 1024 also OK, as long as it’s a fixed boundary :)
Lots of in depth advice about how to make sure you can scale, but here’s an easy one for day one: your primary key starts at 1024, not zero, not one. The only thing that knows this is your “new <T>” flow
Though overall I feel there's no good solutions here. Unless UWP fits your need or you're making a game (so you just need an accelerated surface to draw on + input, no window management), MS haven't provided a good development experience for Windows apps since ~ XP.
BUT DARK MODE! (half /s)
You can get a bunch more of the Win32 stuff working in dark mode if you tell the framework your app is explorer.exe... *shudder*
While there's workarounds to invalidate the cache, it's then hard to make resizing work *well* while you're dragging the frame, even if it's a standard win32 frame
There's also a lot of resize issues caused by mobile-first frameworks being used on desktop; e.g. Yoga (the layout engine underpinning React Native) doesn't adequately invalidate caches when resizing the top-level container. Almost never happens on phone, common on desktop
That’s primarily about the title bar, but meeting the title bar (and general texture/corners guidelines) needs a non standard frame
I agree it’s often not worth it, but the default win32 title bar does not meet Microsoft’s own style guidelines: learn.microsoft.com/en-us/window... - and they don’t use it in their own toolkits.
If you follow the platform style guidelines, you must replace it. if you don’t, your app looks dated.
For part-time vim fanatics on windows: github.com/fredemmott/c...
By default, remaps capslock to escape - unless a game is running.
OpenXR Best Practices Validation Layer
We are pleased to announce the release of the Best Practices Validation Layer. It addresses a critical need in XR development: catching suboptimal API usage patterns that can lead to inconsistent behavior across different OpenXR runtimes.
Learn more: www.khronos.org/blog/new-ope...
#OpenXR #XR
Funding: if your mid/large business uses Dear ImGui - and maybe you are approaching end of year budget/planning etc. - please consider reaching out (PM/email) so I can help you help Dear ImGui !
hexdump and xxd side-by-side, showing byte swapping in 16-bit groupings
TIL either hexdump or xxd is endian-sensitive
3/3. Meta could bring hand tracking support to > 50% of PCVR headsets overnight by removing an arbitrary restriction - this would substantially change the cost/benefit of hand tracking for game developers.
2/3. More than half of the headsets on the Steam Hardware Survey are Quest-series headsets that have support for hand tracking, but it requires developer mode or third-party software.
1/3. Lukewarm take: the lack of PCVR game support for hand tracking is Meta’s fault.
WIP: Reimplementing the look-and-feel of WinUI3 in standard C++23, without a dependency on WinRT, XAML, or msbuild
Slightly snowed under with the spatial entities announcement, OpenXR 1.1.49 also includes the new render models extension which provides access to 3D models of the controllers currently held by the user.
With Meta's upcoming v74 SDK release, the built-in OpenXR path for Unity, UnrealEngine, and Godot will be the recommended path for development. #OpenXR enables you to build cross-platform and use Meta platform plugins to add unique HorizonOS features […]
*passing the CTS* on every release would be hugely valuable to everyone though , including runtime devs.
I need to write up my thoughts on this, but while the CTS is hugely valuable, I don’t see official conformance as useful to devs or users. IMO the primary benefit is the IP framework for official adopters
The CTS is free; official conformance requires adopter status and a passing submission (though there is a waive process). It does not require resubmitting or re-testing on new releases or new headsets
It's frustrating as a developer when I investigate crashes and see they're caused by a runtime bug that could easily have been detected before release.
It's frustrating for users when I have to tell them to hope for a fix from their manufacturer.
[5/5] This is clearly bad for developers and users - and it hurts the ecosystem as a whole; your readers/viewers deserve to know what they’re buying; don’t mislead them by saying headsets support OpenXR when they don’t.
[4/5]
- some vendors seem to stick with an old version of the test suite
- some vendors only seem to test their initial release, or only major milestone releases
- some seem unlikely to have passed any version, and only been spot-tested on a few games
[3/5] Some manufacturers routinely test their releases, and they should be celebrated for this: conformant runtimes make the whole ecosystem stronger and reduce locking.
I’ve unfortunately also seen a mix of:
[2/5] You can ask manufacturers what version of the CTS you should use - this should either be the latest version, or any other version published by Khronos that’s at most 180 days old.
[1/5] PCVR journalists: when covering a headset software/firmware update, run the OpenXR Conformance Test Suite. If it fails, the headset/software/firmware *DOES NOT* support OpenXR and users should expect problems. The CTS is freely available on GitHub.
Or the opposite, “We reward teams with fewer severe incidents” -> “hmm is this really worth opening an incident over?” “Is this really a *severe* incident?”, reducing communication and increasing time to fix and severity of incidents , even if there’s fewer labeled as “incidents”
Metrics often stop being useful once they become goals; rewarding productivity measured by number of commits can encourage spamming ridiculously small commits - eg one per file when one per concept might make more sense
