Jump to content

Yann

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by Yann

  1. Hello everyone, Correct me if I am wrong but, from what I understand the OculusAPI is not in charge of the actual rendering of the scene, this is done by a call to the rendering api (dx11, vulkan...) OculusAPI calls are "only" "preparing" the texture object and distort it to cope with oculus lens shape (and surely a lot of other things, like deal with sensors, ASW, etc...) Thus, with low-level api, like vulkan, it is up to the game developer (or game-engine developer) to implement features like mGPU rendering, leveraging the full access to hardware provided by this kind of rendering api. I doubt oculus will ever implement such things at their API level. I hope ED will dig into this when implementing Vulkan, because I believe, mGPU rendering to VR is key to provide the necessary rendering power for higher resolution.
  2. You are right. There is a buffer of 8kb (default size on Windows os). So, it all comes down whether the amount of data received between two frames fits into this buffer or not. Anyway thank you for taking this issue into consideration. And I hope you will continue to make this kind of great contribution to DCS. (I believe SRS is so awesome it should be integrated in DCS like IVC is in FalconBMS) Regards.
  3. What I understand from the luasocket documentation and others udp socket programming documentations is that : - settimeout() or settimeout(negative_value) sets the socket to blocking mode - settimeout (0) sets the socket to non-blocking mode - settimeout(strictly_positive_value) sets the socket to timeout mode. But my experience shows that depending on the internal clock resolution of the operating system, the timeout value you want may or may not be achieved. Thus, if your intention was to make the socket non-blocking (and I believe that's what you wanted to do by specifying a timeout of 0.0001s), you may want to consider using settimeout(0).
  4. @Coug4r : Ok thanks for the feed back, if you have time to make further testing, just let me know.
  5. @ Coug4r Just made some test with the F15. FPS issue still here. What fps are you getting with Vsync off. Because il you run below 64 fps you will not notice this fps limitation. Try to reduce graphics settings so as to obtain more that 65fps with vsync off. @Ciribob I think I have a beginning of explanation. The Windows internal clock default resolution is 15.6ms which translates in... 64fps. Thus, my guess is that, if no data is received, the UDP timeout call the OS sleep function, which is not woken up before 15.6ms. No matter the 0.1ms argument. This limit the fps to 64fps. If you can confirm that letting SR.UDPLosReceiveSocket:settimeout(0) has no side effects, I think I'll stick with that. Regards
  6. Thank you for these first feedback I'll try with the F15 in SP, when i get back home. Also I forgot to mention that i use the last available release fo SRS with the new audio library. More feedbacks are welcome :)
  7. Hello Ciribob, All First of all, thank you for this awesome piece of code! I installed it yesterday, and it works well, but i am experiencing FPS issues since the installation. I have quite decent computer, and running at moderate graphics settings : The M2000 free flight mission, gave me before installation of SRS : Vsync OFF : 140 fps / Vsync ON : Rock steady 60 fps After the installation : Vsync OFF : alternating between 64 - 65 fps / Vsync ON : 60 fps with frequent drops to 55fps. This occurs even is the SRS client and/or server is not running. Turning down the graphics settings does not change this limitation to 64-65 fps. I found that if I rename the folder %USERPROFILE%/Saved Game/Scripts, the problem go away. Since I am not using any other scripts than SRS, I believe that SRS is the source of the problem. I found that replacing in the DCS-SimpleRadioStandalon.lua line 64 : SR.UDPLosReceiveSocket:settimeout(.0001) by SR.UDPLosReceiveSocket:settimeout(0) the problem go away, and SRS seems to remain functional (had a quick test in multiplayer on the M2000, but need more testing though) Do you think this change can have any undesirable side-effects (I am not familiar with UDP programming)? Am I the only one with this issue? Sorry for the long post and thank you in advance!
×
×
  • Create New...