Jump to content
The Dark Mod Forums

I'm working on a VR version - early alpha


cabalistic

Recommended Posts

@nbohr1more: Interesting, I might try experimenting with the threading options. Just for the record, did you disable full screen?

I am aware of Carmack's comments to their problems with multithreaded rendering, but I did a fair bit of research. My approach with using two individual render contexts for the two threads with shared lists is generally considered a sane approach and should not cause any issues. If you were using an AMD card, I might be concerned about it, but you have the same brand as I (NVIDIA), and I don't think it would miraculously work on one NVIDIA card and not the other.

(Just to be clear: If you use the standard 2.05 executable on the exact same installation, you have no issues, right?)

 

@BuckleBean: Thanks for testing! I wasn't even aware of the options to disable player bob. I'll add that to the documentation at the very least. I don't have a Rift, unfortunately, but I also would have expected it to work with OpenVR. But since you have both, how does SteamVR actually select which headset to render to? Perhaps it's getting confused there...

Yeah, performance is still not good enough in some places, and that's not an easy fix. The display refresh should be irrelevant, as SteamVR handles vsync automatically. In fact, you should disable vsync in the game entirely, it might cause issues. The fixedTic option is obsolete in my build, it doesn't do anything.

 

@stgatilov: I agree, but as mentioned, that would require substantial modifications to the VertexCache and anything interacting with it, so it would be a major effort. Worth it for sure, but I had to go with the easier option for now due to time constraints...

 

The crash on mission reload is probably not related to that specific bug. From my investigations, it has to do with the VR resources (specifically framebuffers and render textures) which probably aren't properly recreated during the reload. That's not surprising as I haven't actually implemented that behaviour :)

Edited by cabalistic
  • Like 2
Link to comment
Share on other sites

@BuckleBean: Thanks for testing! I wasn't even aware of the options to disable player bob. I'll add that to the documentation at the very least. I don't have a Rift, unfortunately, but I also would have expected it to work with OpenVR. But since you have both, how does SteamVR actually select which headset to render to? Perhaps it's getting confused there...

Yeah, performance is still not good enough in some places, and that's not an easy fix. The display refresh should be irrelevant, as SteamVR handles vsync automatically. In fact, you should disable vsync in the game entirely, it might cause issues. The fixedTic option is obsolete in my build, it doesn't do anything.

 

Thank you, kindly. Yes, I expect performance to always be an issue simply because some missions are more taxing than others. It's something we may be forced to live with to one degree or another. Though, if SteamVR's re-projection or the Rift's ATW/ASW could kick in & lock things to 45fps dynamically, that could be helpful. That's why I'm scratching my head at the notion that I'm getting 200+ framerates. Maybe it's doubling for some reason...?

 

In terms of Rift vs Vive, I don't have both headsets plugged in at the same time. I ran into too many issues early on with applications getting confused. So I manually unplug/plug-in whenever I want to switch headsets. It's not as annoying as it seems as I tend to stick with one or the other for days/weeks. And I'm using the Vive link box for both. So the systems should not get confused because there's only ever one headset plugged in. I'll keep trying to get the rift up & running.

 

EDIT: Good news, it's working with the Rift. Perhaps I never re-tested after getting things up & running on the Vive last night, but it's working as expected. I don't believe there's anything special that needs to be done here, thankfully. Whatever work you're doing with OpenVR should translate to the Rift as expected. Sorry for the false alarm.

 

A couple other things I forgot to mention:

 

1. I'm hoping there's away to disable any effects related to how the player is knocked back when struck by a guard with a sword or rocks, etc...

2. You mention on the roadmap on the github page coupling head tracking with game logic & I definitely agree here. It's easy for the world to be accidentally titled/slanted. I think we need to find a way to lock the horizon without limiting your ability to move your arms up & down. It's hard to explain, but i think you get what I'm saying.

Edited by BuckleBean
  • Like 1
Link to comment
Share on other sites

@cabalistic

 

What was the base code version? I am trying to do a cumulative of your commits but comparing your initial commit to our 2.o5 source package I can see that yours is quite older.

 

Here's the smallest .diff I could make: 140KB. Beat me if you can.

https://drive.google.com/open?id=0B9OoHSmkeSeNaEh6blJYZjhiZkE

  • Like 1
Link to comment
Share on other sites

I sent a PM to get you SVN access to development assets. We had a thread about granting you access but it seems to have fizzled somehow.

I guess we need a few more team members with the privilege to grant internal access and (ideally) a way to offer read-only SVN assets to developers.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Since nobody can be bothered to grant Cabalistic svn access I decided to spend a day and apply the above patch to trunk svn. (SMP only)

A quick test shows about 21->27 fps raise in a particularly cpu-limited scene (the caduceus mission, wall corner looking at the tree and tower windows).

Solid work, Cabalistic!

Some thoughts:

- no need to change tic rate from 60 to 90 since we now have the unlocked tic rate controlled by the com_fixedTic cvar

- can't see why use glew - it compiles and runs just fine without it

 

P.S. Since the threaded renderer requires changes in the internal draw structs I think we better just switch to it and don't try to make it an option. Otherwise we'd have to if-else every line that deals with them.

  • Like 2
Link to comment
Share on other sites

P.S. Since the threaded renderer requires changes in the internal draw structs I think we better just switch to it and don't try to make it an option. Otherwise we'd have to if-else every line that deals with them.

Nobody talks about putting every line from the diff into "if".

Most likely, there is only one place really which makes everything work in parallel.

The idea is to commit common changes (like structs changes) as is, but provide a switch that makes everything run sequentally if requested.

  • Like 1
Link to comment
Share on other sites

Nobody talks about putting every line from the diff into "if".

Most likely, there is only one place really which makes everything work in parallel.

The idea is to commit common changes (like structs changes) as is, but provide a switch that makes everything run sequentally if requested.

There's backendGeo and frontendGeo now where just "geo" used to be in the surface struct.

Now half the code is using the b.e.g. and the other one f.e.g.

If we wanted to make it an option then we would have to do something like

if (smp)

write to backendGeo;

else

write to frontendGeo;

every time.

  • Like 1
Link to comment
Share on other sites

 

Since nobody can be bothered to grant Cabalistic svn access I decided to spend a day and apply the above patch to trunk svn. (SMP only)

So... have you ever though about truly opening development (including assets) and put everything on e.g. Github? I know that surrendering control is scary, but even if I had svn access, I'd still be in a dilemma. I can't really develop my VR version against svn if nobody besides the dev team can test that version. But developing against 2.05 is not ideal either, because it means essentially doing some of the work twice.

 

 

- no need to change tic rate from 60 to 90 since we now have the unlocked tic rate controlled by the com_fixedTic cvar

When I tested the fixed tic rate, the results were not so great (on 2.05). Generally, since the tic rate cannot truly run parallel to the frontend, it still matters what tic rate you choose vs the targeted refresh rate. A tic rate of 60 means that for the VR version at 90 Hz, every third frame will not calculate a tic, but the other two will. Maybe it's not that noticable, but it might make physics calculations seem strange. So, for VR, a tic rate of 90 is better. Alternatively, you could lower it to 45 or 30. 30 is the only one that fits both 60 Hz and 90 Hz refresh rates, but I don't know if that might be too low?

In any case, you certainly don't have to adopt the 90 Hz game tic, it's specific to VR :)

 

 

- can't see why use glew - it compiles and runs just fine without it

I originally introduced it to gain access to FBO functions in GL, which are not covered by qgl (at 2.05). Then, when I created the second context, I used the MX version because technically the GL functions are specific to the context, so you'd have to fetch them for both contexts separately. In practice, however, modern graphics drivers apparently always return the same function pointers, so this isn't really an issue. But since I had some problems initially, I wanted to rule out that source of error. In any case, you don't have to use glew on the svn version, it was just easier for me to use at the beginning of my developments :)

 

 

There's backendGeo and frontendGeo now where just "geo" used to be in the surface struct.

Now half the code is using the b.e.g. and the other one f.e.g.

If we wanted to make it an option then we would have to do something like

I think what he meant was always use the separation (i.e. frontend always uses f.e.geo, backend always uses b.e.geo), but make an option that runs the backend after the frontend, anyway.

  • Like 2
Link to comment
Share on other sites

I'm still torn on GLEW.

 

On one hand, it allows you to easily adopt new GL extensions.

 

On the other hand, you have the "static verses dynamic linked" war where every other bumpkin Linux distro

user goes "can you do a static version X because my distro has x restrictions" vs "can you update your

framework, etc so we can do dynamic linking to GLEW again."

 

With the latter reeking of the mess we had with Boost. (finally gone in 2.06!)

 

I guess Treb figured it out, there haven't been any GLEW bug reports recently in RBDoom-3-BFG

(but shortly after he merged GLEW... boy did he get pounded with complaints\bugs from the Distrowatch crowd...).

 

We had GLEW integrated when Revelator worked on the project but it was backed-out of along with other changes that were not ready for prime-time.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I think what he meant was always use the separation (i.e. frontend always uses f.e.geo, backend always uses b.e.geo), but make an option that runs the backend after the frontend, anyway.

Yes, exactly.

The separation into f.e.geo and b.e.geo may be not necessary for non-threaded version, but it should not make any harm.

I think we must have is a simple switch which quickly reverts the game to sequental version. This is very important in case someone meets some race conditions / driver incompatibilities / whatever.

 

I'm still torn on GLEW.

On one hand, it allows you to easily adopt new GL extensions.

Glew is great for small and fast projects, because you don't need to waste time on adding stuff manually.

But Doom 3 engine already has some paradigm of supporting GL extensions, what's the problem with it?

  • Like 1
Link to comment
Share on other sites

Yes, exactly.

The separation into f.e.geo and b.e.geo may be not necessary for non-threaded version, but it should not make any harm.

I think we must have is a simple switch which quickly reverts the game to sequental version. This is very important in case someone meets some race conditions / driver incompatibilities / whatever.

Well, I don't know how to, so that ball is in your court.

 

So... have you ever though about truly opening development (including assets) and put everything on e.g. Github? I know that surrendering control is scary, but even if I had svn access, I'd still be in a dilemma. I can't really develop my VR version against svn if nobody besides the dev team can test that version. But developing against 2.05 is not ideal either, because it means essentially doing some of the work twice.

 

When I tested the fixed tic rate, the results were not so great (on 2.05). Generally, since the tic rate cannot truly run parallel to the frontend, it still matters what tic rate you choose vs the targeted refresh rate. A tic rate of 60 means that for the VR version at 90 Hz, every third frame will not calculate a tic, but the other two will. Maybe it's not that noticable, but it might make physics calculations seem strange. So, for VR, a tic rate of 90 is better. Alternatively, you could lower it to 45 or 30. 30 is the only one that fits both 60 Hz and 90 Hz refresh rates, but I don't know if that might be too low?

In any case, you certainly don't have to adopt the 90 Hz game tic, it's specific to VR :)

I would like that too but it might be the size issue? I'm new to the project myself.

About the tic rate - when it is unlocked, it runs on the same rate as the renderer. I.e. if your system can squeeze out 90 fps then it's going to be 90 game tics as well. 120 -> 120, etc.

If you want to limit it on top, use VSync.

Yeah, it has been buggy, but since 2.05 most of those have been fixed.

 

Right now I don't see the need to run game tics in parallel to frontend because my tests show the bottleneck to be either GPU or the video driver.

The notable exception is spiders on complex terrain, but that's really rare. I can remember only two occasions on all missions I played.

  • Like 1
Link to comment
Share on other sites

So... have you ever though about truly opening development (including assets) and put everything on e.g. Github? I know that surrendering control is scary, but even if I had svn access, I'd still be in a dilemma. I can't really develop my VR version against svn if nobody besides the dev team can test that version. But developing against 2.05 is not ideal either, because it means essentially doing some of the work twice.

 

On this note, I'd love to continue to help test on both the Vive & the Rift, but it's looking like that may be tricky if I'm reading things right. I've had a chance to play around with the initial alpha release some more. It's really quite playable so long as you're familiar with the controls and don't mind peeking at the screen mirror for readables. I've also been playing the recently released Alien Isolation VR mod and there are a lot of similarities.

  • Like 1
Link to comment
Share on other sites

For me it crashes most of the time when ROQ starts playing on mission start.

Sometimes it also hangs. Sometimes it works as expected (rarely).

If I revert duzenko's commit, the issue disappears.

 

I have logging enabled for ffmpeg cinematics (set r_cinematic_log 1).

 

Here are three possible call stacks:

TheDarkMod.exe!AssertFailed(const char * file, int line, const char * expression) Line 580 C++
> TheDarkMod.exe!idBTree<idDynamicBlock<char>,int,4>::SplitNode(idBTreeNode<idDynamicBlock<char>,int> * node) Line 415 C++
TheDarkMod.exe!idBTree<idDynamicBlock<char>,int,4>::Add(idDynamicBlock<char> * object, int key) Line 175 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::LinkFreeInternal(idDynamicBlock<char> * block) Line 746 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::FreeInternal(idDynamicBlock<char> * block) Line 742 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::Free(char * ptr) Line 539 C++
TheDarkMod.exe!idStr::FreeData() Line 120 C++
TheDarkMod.exe!idStr::~idStr() Line 454 C++
TheDarkMod.exe!idFile::Printf(const char * fmt, ...) Line 271 C++
TheDarkMod.exe!idSessionLocal::FrontendThreadFunction() Line 3060 C++

> TheDarkMod.exe!idBTree<idDynamicBlock<char>,int,4>::SplitNode(idBTreeNode<idDynamicBlock<char>,int> * node) Line 411 C++
TheDarkMod.exe!idBTree<idDynamicBlock<char>,int,4>::Add(idDynamicBlock<char> * object, int key) Line 175 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::LinkFreeInternal(idDynamicBlock<char> * block) Line 746 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::FreeInternal(idDynamicBlock<char> * block) Line 742 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::Free(char * ptr) Line 539 C++
TheDarkMod.exe!idStr::FreeData() Line 120 C++
TheDarkMod.exe!idStr::~idStr() Line 454 C++
TheDarkMod.exe!idFile::Printf(const char * fmt, ...) Line 271 C++
TheDarkMod.exe!LogPostMessage(const char * message) Line 70 C++
TheDarkMod.exe!LogVPrintf(const char * format, char * args) Line 102 C++
TheDarkMod.exe!LogPrintf(const char * format, ...) Line 108 C++
TheDarkMod.exe!idCinematicFFMpeg::ImageForTime(int milliseconds) Line 915 C++

> TheDarkMod.exe!idBTree<idDynamicBlock<char>,int,4>::Remove(idBTreeNode<idDynamicBlock<char>,int> * node) Line 199 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::UnlinkFreeInternal(idDynamicBlock<char> * block) Line 754 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::AllocInternal(const int num) Line 610 C++
TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::Alloc(const int num) Line 468 C++
TheDarkMod.exe!idStr::ReAllocate(int amount, bool keepold) Line 88 C++
TheDarkMod.exe!idStr::EnsureAlloced(int amount, bool keepold) Line 305 C++
TheDarkMod.exe!idStr::idStr(const char * text) Line 367 C++
TheDarkMod.exe!idStr::Replace(const char * old, const char * nw) Line 673 C++
TheDarkMod.exe!idFile::Printf(const char * fmt, ...) Line 271 C++
TheDarkMod.exe!LogPostMessage(const char * message) Line 70 C++
TheDarkMod.exe!LogVPrintf(const char * format, char * args) Line 102 C++
TheDarkMod.exe!LogPrintf(const char * format, ...) Line 108 C++
TheDarkMod.exe!idCinematicFFMpeg::ImageForTime(int milliseconds) Line 915 C++

 

As far as I understand, logging starts to use idStr-s concurrently, and they are allocated via string pool (stringDataAllocator).

This string pool is based on idDynamicBlockAlloc, which is not threadsafe, hence weird crashes in random places.

I'm pretty sure that other logging functions can be affected, even trivial common->Printf can crash in the same way.

Also, I'm interested if there are other places where idDynamicBlockAlloc is used concurrently (there are a lot of them over the code).

Finally, I'm not sure that idHeap is threadsafe, and it is used by lots of code for memory allocations (not to mention that all new/delete calls can be redirected to it with ID_REDIRECT_NEW_DELETE).

  • Like 1
Link to comment
Share on other sites

Among other problems:

  1. Apparently, com_fixedTic has no effect now: the framerate is always unlocked. My GPU whines about it =)
  2. Debug rendering flickers. Check g_showCollisionAlongView or any other stuff which draws debug lines over the world.
  3. I see visual glitch with some weird text when I start new game: at the moment when "click attach to start mission" window appears.

Also, I have seen crash inside GLimp_SwapBuffers, but I believe it was caused by Fraps.

 

As for FPS in release build, it increased from 60-70 to about 120 (well, it constrantly changes) in Inn Business for me.

  • Like 1
Link to comment
Share on other sites

Yep, idStr must not use idBlockAlloc, or this whole thing does not work. There's a define to disable it which is set in my VR version. I did not observe any other allocation problems so far. Debug renderings could be tricky, because some of them seem to not be designed for the split between frontend and backend.

  • Like 1
Link to comment
Share on other sites

Just a quick note:

 

- The game crashes after enabling HRTF, as outlined here: http://forums.thedarkmod.com/topic/17689-improve-your-tdm-experience-by-playing-with-openal-soft-hrtf-better-3d-audio/. I doubt most people have this enabled, but figured it'd be worth noting for troubleshooting purposes. I don't know if the HMD's spacial audio is being utilized, but HRTF was pretty cool when used with vorpx.

  • Like 1
Link to comment
Share on other sites

Just a quick note:

 

- The game crashes after enabling HRTF, as outlined here: http://forums.thedarkmod.com/topic/17689-improve-your-tdm-experience-by-playing-with-openal-soft-hrtf-better-3d-audio/. I doubt most people have this enabled, but figured it'd be worth noting for troubleshooting purposes. I don't know if the HMD's spacial audio is being utilized, but HRTF was pretty cool when used with vorpx.

 

Make sure you have OpenAL installed on your computer.

If the game is still crashing, open up darkmod.ini and turn on the logging.

When it crashes, post the darkmod.log file contents here please.

  • Like 1

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

 

Make sure you have OpenAL installed on your computer.

If the game is still crashing, open up darkmod.ini and turn on the logging.

When it crashes, post the darkmod.log file contents here please.

 

Thank you. I'm not sure if logging is on. Perhaps you can tell by the contents of my log file, which are as follows:

 

[game\DarkModGlobals.cpp ( 362):INI (INIT) FR: 0] LogFile created at 2017.08.08 21:03:23
[game\DarkModGlobals.cpp ( 365):INI (INIT) FR: 0] DLL last cleaned and rebuilt on Jul 23 2017 11:13:21
[game\DarkModGlobals.cpp ( 367):INI (INIT) FR: 0] The Dark Mod 2.05, code revision 6757
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogBegin: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogEnd: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogInfo: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogDebug: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogWarning: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogError: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FRAME: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_SYSTEM: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MISC: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FROBBING: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_AI: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_SOUND: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FUNCTION: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_ENTITY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_INVENTORY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_LIGHT: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_WEAPON: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MATH: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MOVEMENT: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_STIM_RESPONSE: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_OBJECTIVES: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_DIFFICULTY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_CONVERSATION: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MAINMENU: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_LOCKPICK: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_AAS: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_STATE: 0
  • Like 1
Link to comment
Share on other sites

Not good. I patallelized some aspects of the frontend which scored high in the profiler, but in situations where it matters the backend takes just as much CPU time. So it doesnt help at all. The bottleneck in the backend seems to be animated models and the constant update of their vertex buffers. To get past that, I believe we would have to port the vertex cache optimizations and hardware skinning from Bfg, but that is a major undertaking...

  • Like 2
Link to comment
Share on other sites

Yes, but the structure has implications for both. For example, the backend spends a noticable amount of time binding vertex buffers, which the BFG edition doesn't have to, afaict. As such, I believe that the BFG version lowers costs for both frontend and backend, which is exactly what we'd need at this point.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 0 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...