|
From: James H. <ja...@al...> - 2022-08-22 17:04:02
|
On 22 August 2022 09:56:20 BST, James Turner <ja...@fl...> wrote: >> On 19 Aug 2022, at 23:45, James Hogan <ja...@al...> wrote: >> Okay thanks. A quick update: >> * I've fixed the windows+osgXR build breakage (apparent preprocessor pollution >> on Windows necessitates changing osgXR::Settings::OPAQUE -> >> osgXR::Settings::BLEND_MODE_OPAQUE, which is a source API change, and ancient >> OpenGL headers bit again). > >Windows loves to define random CONSTANT as some value : any chance setting LEAN_AND_MEAN helps you? WIN32_LEAN_AND_MEAN at top of cxx files didn't prevent it. I redefined UNIQUE to see where its coming from. Its from wingdi.h apparently. > >> * I've rearranged my windows-3rd-party patch a bit, to put it all in >> msvc140/3rdParty.x64/ so its picked up automatically by the flightgear build >> (needing tweaks to paths in the cmake files). Unfortunately it does seem to >> need the main openxr_loader.dll to run so I've included that (<2MB) and added >> it to the windows installer. Diff [--stat] below. > >That’s perfectly fine and exactly what I would recommend. > >> >> I'll push osgXR 0.5.0 when I'm happy with it, and update >> flightgear/3rdparty/osgXR to match, then if there are no objections I'll try >> pushing the openxr loader to windows-3rd-party and fgmeta. > >Yep, please do. Now pushed and todays windows build appears to be openxr enabled and from a quick test with dummy driver on steamvr seems to work. SV001R: feel free to try a nightly build and let me know if you hit any issues. Cheers James |