Jump to content

YorkyPudsy

Members
  • Content Count

    67
  • Joined

  • Last visited

Community Reputation

42 Unleaded

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Good suggestion, if anyone is still listening to feedback at this stage...? I imagine most of us would rather see the end of Racenet, but failing that, saving progress locally until a connection can be re-established would still allow leaderboards/progression to be protected from abuse (if that is indeed the main reason CM titles now insist on a connection), but without the negative experiences when there are brief interruptions. Or if it's still a concern, perhaps limit the number of events or similar that can be completed before requiring a connection, and/or perhaps put any rewards on hold, to be unlocked once a connection can be established to log & "confirm" your progress. This has been a problem with various CM titles for some time now, not just DR2.0... often cropping up after new game releases, updates or big sales events (anything with an influx of new players / traffic). But even outside of those kinds of events where Racenet issues have become predictable (where increased capacity should have been planned for those short periods), there can still be outages that players/CM have no control over, regardless of your equipment or stability of your connection, etc. This kind of "local progress until next connect" would help alleviate a lot of the friction players experience.
  2. Good to know, thanks! By "desktop mirror" I was referring to the game's own window which mirrors what you see through the headset. Besides a few low-quality/early VR titles, most other VR games (Steam & Oculus store) have always output just the one "eye" on their desktop windows for me, which is why it's puzzling that DR2.0 shows stereoscopic, especially because it only does it in the "Oculus VR" version on Steam. I assume you're referring to using "Oculus Mirror" by launching the "OculusMirror.exe" myself, and having that output into it's own window, in addition to the game's own desktop window. I've not had to use that for anything else before though. Will have to look into it more next time I try, although it is weird the game's own window is stereoscopic for me & some others... it doesn't seem the sort of thing the devs would do on purpose. Or maybe I need to toggle some setting like you say, through OculusMirror, and perhaps that will "stick" for the game's own mirrored window.
  3. Thanks for the suggestions... Last time I tried though, I did have the desktop mirror set to a small window (I've also seen the problem you mention about squished UI in fullscreen), but regardless of that it was still showing the stereoscopic output (two images, one for each of left + right eye, side-by-side), as per the screenshots in the op's post in this thread. IIRC people reporting the problem are using the native Oculus version of the game that was eventually added to Steam, rather than the native Oculus version from the Oculus store? Note that the SteamVR version on Steam does not have this issue (although it did exhibit worse performance for some people, hence the calls for CM to add a native Oculus version for Steam owners). @Ialyrn are you running the game from the Oculus store, or from Steam? And if on Steam, are you using the SteamVR version or native Oculus version?
  4. Yeah, it's such a shame the Oculus version on Steam still shows the output from both eyes, when this thread reporting the issue has been here for 6 months. I was hopeful a fix could have been slipped in at some point in all that time. It looks a bit amateurish really, reminiscent of the early VR titles. Unfortunately I suspect time is running out on the chances of us ever seeing this fixed in DR2.0, with the final Colin McRae pack DLC imminent. No doubt it'll already be on a to-do list for the next game! Sorry for the moan. It's just depressing when there's always such pressure from the top to move focus onto the next title, rather than make the current one the best it can be & support it for longer, so we end up with niggles that spoil what are otherwise awesome experiences.
  5. YorkyPudsy

    VR FAQ & Performance

    Oh, didn't know that. At least it's consistent I suppose! Yeah, hopefully they can sort it in future for both Oculus Store + Oculus-native on Steam then.
  6. YorkyPudsy

    VR FAQ & Performance

    It's great that we now have a native Oculus version of DR2.0 on Steam, but why is the desktop window stereoscopic / showing both-eyes? Obviously it doesn't affect whoever is wearing the headset, but it's not ideal for hotseat, recording/streaming, or observers in general. Most VR games (including the SteamVR version of DR2.0?) just show a single eye/view in the desktop mirror window. @PJTierney Any news on an official fix? Or perhaps someone knows a workaround in the meantime? Thanks!
  7. @PJTierney Please can you confirm if this "stereoscopic monitor view on native Oculus build" issue reported in this thread has been logged / is being investigated? (I'm on Steam, but OP @raymyburgh is on Oculus Store, so presumably affects both). Also as @cestomano asks above, why does the audio on the Oculus build only output to the default Windows audio device (desktop speakers) rather than to Oculus itself with optional mirroring to default device, as per every other native Oculus app? More details below... I've been away from DR2.0 for a while as I was frustratingly spending all my time with it troubleshooting & reporting issues. I decided to have another quick try yesterday now that we have native Oculus support on Steam, and after I read that the USB-device-related periodic stuttering was finally fixed (which I'm happy to report is indeed the case, for me at least!) But now I find that the native Oculus build on Steam is showing the output from both left & right eyes, side-by-side. As mentioned by others above, this isn't great for hot-seating / local observers / recording / streaming. It's hard to believe it was intentionally set up that way...? Why not just show the output from one eye in the mirrored desktop window, like the SteamVR version does? Also, the Oculus version of the game on Steam doesn't output audio to the Oculus device itself... instead sound is directed to the default audio device (desktop speakers). This leaves us having to switch devices manually, just for this game, because every other native Oculus game directs audio to the Oculus device & then is automatically mirrored to the default device if the user has that setting enabled in the Oculus software. Please can someone look into sorting out these couple of issues with the native Oculus build on Steam? Thanks!
  8. YorkyPudsy

    FPS & Stuttering (PC, non-VR)

    Yeah, thanks again @obo . I'm sure I'm not the only one who appreciates the work you put in (besides DirtFix itself) to investigate the cause & proper way to handle device polling, and then document it all along with suggestions. @PJTierney of course it is unusual for a large dev these days to revisit older titles outside of urgent/critical fixes. But as @Ialyrn suggests, now that the hard work has been done & the solution is a known entity, if someone could at least pass on the request & look into the feasibility of updating DR & D4, that would be greatly appreciated. Presumably future games might benefit from this same knowledge, maybe even GRID (don't have it yet, so dunno if it also has the issue.)
  9. YorkyPudsy

    FPS & Stuttering (PC, non-VR)

    @PJTierney is the quoted part below (from the upcoming v1.10.1 DR2.0 patch notes) referring to these "every-2-second" stutters which some of us are experiencing (unless we unplug/disable certain USB devices or use @obo's DirtFix)? If so, thanks very much! If possible, please can this same fix be retro-fitted into other affected CM titles? Fixing at least DR & D4 would be appreciated, since DirtFix also targets those games. And presumably the issue isn't present in the recent GRID release or has been fixed there too already? Thanks!
  10. Yes, please! If there's already an internal facility for detecting issues, then please adapt it into a public-facing "Service Status" page (assuming there isn't such a thing already?) Also would make sense to include notices of any planned downtime on there, along with any ETA on fixes etc. as more info becomes available. That way everything is in one place, in a consistent location that anyone can check as a first port of call when troubleshooting. It might cut down on the cumulative hours players spend investigating, reporting or trying to resolve connectivity issues that are outside of our control or already known about & being worked on by CM.
  11. Yeah, new CM game releases & discounts on older titles seem to be one common cause of Racenet failing due to increased traffic. And it appears to fail across multiple CM games when it does so. CM, please... invest in extra Racenet capacity increase capacity in advance of planned events which are likely to lead to increased traffic & failure of Racenet (new game releases, discounts, timed events) implement 24/7 monitoring & support for Racenet (players/community suffer needlessly each time it fails over a weekend & doesn't get fixed until UK office hours the following Monday) investigate possibility of Racenet services auto-recovering/restarting when these issues occur (as an alternative/interim arrangement to the above 24/7 support) reduce reliance on Racenet in your current/future games (in particular, allow single-player/career modes to function in their entirety without it) Thanks!
  12. YorkyPudsy

    FPS & Stuttering (PC, non-VR)

    @obo Thanks for doing a detailed analysis of the every-2-seconds stutter caused by input device polling, and you're an absolute star for providing others with a solution. I usually prefer to avoid using anything that modifies or hooks into games, for fear of triggering some form of anti-cheat or similar, and to avoid the risk of malware... that's just me being as cautious as I would be with any other code, so please don't be offended! In any case, I'm sure we'd all rather this was fixed properly... @PJTierney Is there any news regarding CM integrating this input-device-polling fix natively (into at least DR2.0 & D4 hopefully?), so we don't have to rely on 3rd party hacks/workarounds or unplugging/disabling random USB devices? It looks like @obo has narrowed down the cause quite specifically for the devs, along with suggesting a better method of registering to receive a callback when input devices change, rather than continuously polling all devices every 2 seconds. Or perhaps a quicker/interim solution might be to disable the polling during any on-road action, but leave it active in the menus? Thanks! https://github.com/simonowen/dirtfix/#cause
  13. YorkyPudsy

    FPS & Stuttering (PC, non-VR)

    ( EDIT: I just wanted to make clear, I had no noticeable stuttering when playing on a monitor before the VR update. My comments below are specific to me using the SteamVR version of the game after the VR update. I notice the "non-VR" in the topic title, so please feel free to move my post to the VR bug thread if it's more appropriate. However, a number of people have suggested that USB devices/polling could be the cause of the periodic stutters certain players are getting every 2 seconds, some on much more powerful hardware than me, so my comments seemed appropriate in light of these additional USB-related suggestions on this thread, especially since they didn't work in my case... ) Thanks for adding those, but unfortunately neither help solve the periodic CPU spikes & judder for me. I even tried unplugging everything including keyboard, just leaving mouse to launch the game. I was hoping this might work around the problem for now, as several people mentioned a possible cause being USB devices being regularly polled or similar by the game. The CPU spikes consistently happen every 2 seconds (pretty much exactly every 2 secs), as reported on the other VR bug thread, matching charts someone else posted of the same CPU spikes. I can see the CPU usage spikes/pulses on SteamVR's "advanced frame timing" graph, each pulse lasting for a fraction of a second (perhaps less than 0.2s, I didn't take too much notice of the duration, but the frequency is almost exactly 0.5Hz, so there's clearly something happening repeatedly at that frequency causing brief but heavy CPU usage.) The CPU spikes happen even with all the game's settings on the absolute lowest... and on those settings I'm clearly getting very fluid motion, and the hardware is easily capable of rendering at higher settings... except every 2 seconds my view "shudders" slightly for a few frames during the CPU spikes. I've tried various tweaks suggested by the community & guides here but haven't found anything which works yet. I've tried all these plus some others I probably forgot...! close all unnecessary programs temporarily switched to SteamVR Beta v1.7.4 force the game to use windowed mode for the VR mirror display instead of fullscreen by editing the hardware config xml disabled (lowered to zero) in-game "head shaking", just in case it was a bug with that disabled Steam overlay lowered the game's settings to minimum, including AA (worth mentioning since it's in a separate section of the game's options) unplugged all USB devices including my wheel (except for just mouse or keyboard to launch/navigate the game! I tried once with each left plugged in!) disabled USB HID devices in device manager updated to latest Nvidia driver & also tried latest hotfix driver Nvidia max render-ahead frames for VR = 1 all different options for Oculus ASW (CTRL+1/2/3/4)... interestingly disabling it (CTRL+1) seemed to make the game exhibit a constant jitter/delay with the game's tracking of the HMD, even when the framerate was very good, which doesn't seem normal at all... perhaps that's hinting at some kind of "fighting"/conflict between SteamVR & the game, in determining the position of the head/view? Or some kind of out-of-sync / delay on the game determining the head position? I mention that because I've noticed the floating HUD elements seem to track with that same kind of delayed response (regardless of ASW setting), like they're slightly behind the HMD movement (maybe just a couple of frames, only just perceptible), so they move slightly independently of eg. the windscreen etc. as you look around, and then they catch up when you stop moving your head. I just wondered if it could be related? reduced 'Application Resolution' in SteamVR, but it didn't seem to make a visible difference even at the lowest 20% (which I would have expected to be extremely blocky/blurry, but the resolution in the HMD looked the same, so either this setting doesn't work with Rifts, or the game is overriding something?) I run a number of other VR games on the same hardware, all the usual suspects of driving games which I won't bother to name, including the original DR... all without any problems. I usually settle for 45fps with ASW enabled, because my hardware isn't up to consistent 90fps, but that is perfectly acceptable to me, so I'm not expecting wonders here. DR2.0 does also seem like it would be plenty smooth enough, if it weren't for these regular brief judders every 2 seconds. Reading around the various forums (Reddit, Steam, here) I've seen a number of people having the same issue, not just with Oculus hardware but also with Valve Index & with WMR headsets. It would be interesting to find out if this issue is specific to the SteamVR build, but until/unless the native Oculus SDK build is made available as an option on Steam, we can only rely on feedback from people who have purchased on both stores (whether they own Oculus headsets, or use Revive with different headsets). ... ONE QUESTION: Have CM managed to observe or reproduce this regular/periodic (every 2 seconds) judder / CPU spikes ? Or at least taken note of the reports that it exists so they can investigate ? Thanks! ... Steam / DR2.0 Deluxe / Oculus Rift CV1 + 2 sensors / i5-4460 + GTX970 + 16GB RAM / Logitech G29 + Shifter + Pedals
  14. YorkyPudsy

    DiRT Rally 2.0 - Input on Inputs!

    Is there any news/progress on analog handbrakes? Whether it's being considered or prioritised...? Besides the requests in this thread, there seem to be plenty of other threads, but I've seen no official statement anywhere yet. Or at the very least, for those of us with an analog axis mapped to this binary input, please can we have some way of configuring a basic deadzone? Otherwise the in-game handbrake keeps engaging for fractions of a second due to vibrations or movement of the wheel/cockpit/whatever the input device might be attached to, which will obviously affect the control & pace of the car. DR2.0's input-mapping & multi-device handling are so much improved over the original DR & other CM games, but the handbrake seems to be the one thing that I think I'll still need to use a 3rd-party tool for.
  15. YorkyPudsy

    DiRT Rally 2.0 - Input on Inputs!

    Great news! Big thanks to the team for that.
×