Jump to content

wju

Members
  • Posts

    140
  • Joined

  • Last visited

Everything posted by wju

  1. well, my espruino based "very ugly proof of concept" version is working! (left finger only so far, second espruino is on its way) the only issue was caused by my own stupidity; I have forgotten to plug bluetooth antena to motherboard and therefore spent two hours by thinking experimenting why espruino cannot be connected... As you can see, I have decided to build "ring" version with lipo battery (230mAh), as I hate gloves, battery can be smaller in the future, but this one was on my shelf the latching button swtitches on/off, where off can also be a charging mode; charging pins are not soldered yet. the only weird thing is when mouse becomes "white dot"; then it behaves oddly, i.e. moves with headset in oposit direction, (I understand why), but one can get use to it... anyway, guys @frenzon, @Sielu thanks for sharing!
  2. meaning the "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Holographic" trick or something else? wired mouse version based on Arduino works fine, but the wire is annoying, maybe I am "the most ugly solution award" winner anyway, espruinos ordered.
  3. well, I have found the root of my problem - the second monitor. When switched off, then FingersApp works as expected. When is Fingers running, it even does not mind when I switch second monitor back on. Mouse cursor behaves as expected. Now its the time to build a mouse (wired version at first ) based on an Arduino.
  4. Hi, @frenzonnice work with Fingers App! Thanks for Your effort! I took my Leap out of the shelf, where it had been rotting for years, printed the mount for my Reverb G2, installed latest Gemini, installed your Fingers 0.9.3, enabled BlueTooth (I do not use it, it was also rotting since ordovik on my PC) and viola! It works! Unfortunately with ugly offset to right, i.e. mouse pointer is shifted 1/4 screen size to right and therefore it is very difficult to use mouse pointer in DCS as it is very close to right hand edge of visible area, see the screenshot, Mouse pointer is cca at red point, as PrintScreen does not include it. This right offset is present for both hands. Is there any setting or calibration of Fingers app? I have found user.config in \\AppData\Local\FingersApp\FingersApp.exe_Url_oiz1xmo2tljpyqkdzivdgwc423rzymoi\1.0.0.0\ but there is nothing to meaningfully setup.
  5. agreed, reliable ms/fps measurement is not the simple the best would be ingame implemented standard benchmark... well, OXR is the right way to go on, no doubt. I have played with it yesterday for the very first time. for me personally, caveats are the lack of kind of NeckSafer and not so polished MR on the other hand, I was always struggling on complex multiplayer servers, with may units etc. I have tried server with many units yesterday with OXR, where I was always limited by poor CPU frametimes (above 18ms). Now, with OXR and MR locked it to 30fps it is very playable. Nice experience.
  6. nice, thanks in what mission/map/module did you take the measurement?
  7. culpa mea, sorry guys, I have switched CPU/GPU figures for steamVR, the correct result are as follows: frametimes measured: openXR MR off: CPU 14,8ms GPU 10.8ms openXR MR on: CPU 15,0ms GPU 13.6ms steamVR MR off: CPU 13.9ms GPU 9.6ms steamVR MR on: CPU 14.4ms GPU 9.7ms steamVR measured by fpsVR, openXR values read via frame tining overlay
  8. may I kindly ask You to perform your own measurement? or did you any already? the best both MR on/off
  9. the 3ms GPU gain is present only in case MR off, which is not relevant for me. When is MR on, GPU gain is still there, but far less, see figures. well, it is all about my system (poor CPU maybe?), my settings, my preferences. Others can have it vastly different.
  10. !!! edit: steamVR figures have switched CPU/GPU values, the coorect ones, see few posts below!!! I can confirm CPU significant frametime impact in OpenXR, unfortunatelly negative I did a short test, for both openXR and steamVR, motion reprojection OFF and forced ON. Instant action, Cau/FA18/Ready on the ramp, looking strait ahead - it is my usual simple test, frametimes measured: openXR MR off: CPU 14,8ms GPU 10.8ms openXR MR on: CPU 15,0ms GPU 13.6ms steamVR MR off: CPU 9.6ms GPU 13.9ms steamVR MR on: CPU 9.7ms GPU 14.4ms measurements are repeatable with deviation +/- 0.3ms, SS in both steamVR and OpenXR set to 60% (my usual steamVR value) well, from my point of view, the real benefit of all that openXR fidling is the ability to run VR reprojection locked on 30Hz (I have Reverb G2 and fly MR on only) but openXR is so CPU hungry and lack of VRNeckSafer... the choice is, as always, based on personal preferences..
  11. thanks for sharing - I am maybe a bit late to reply, but I had found my own solution before You have posted your scene. Yours is more simple, than mine, as I use empty dds file. So, in accord of Occam's razor, yours is better.
  12. as said many times elsewhere - more options
  13. Hi all, I am proud owner of MCGU since last week. I cannot setup trimmers for axes. I have watched official video 3x times, followed instructions step by step, but still cannot make trimmers working on my MCGU. Latest firmware, all defaults, just axes recalibrated. Starting with simple try to set up trimmer for roll axis (Axis1 in default), see the screenshot below. Set to device, but without any effect. Any hints? Do I miss something not mentioned in the official VKB video? Or is it working only with Gladiator( hope not)? Thanks in advance.
  14. eh thanks! I am not blid but stupid and inattentive as I am pretty sure I have tried this LCtrl+R combo..
  15. nomen omen I cannot find the key for Rumpflast - Jettison Fuselage Stores, am I blind or it is not available? I have been flying Dora for years, using cockpit click so far. Never realized, that there is no button for Rumpflast.
  16. Yes, the trick with acc.xyz += atm.inscatter * acc.a does not solve the cannopy flickering. It does not mean, that the root of bug is not the same. Anyway, feel free to post the bug with track file attached.
  17. I can confirm, that efect exist, also confirm that commenting the line acc.xyz += atm.inscatter * acc.a; in the airscrew.fx file cures the issue. But the probability, that someone from ED will check our issue without track file attached is very, very low... So I did. Here:
×
×
  • Create New...