Jump to content
The Dark Mod Forums

duzenko

Active Developer
 View Profile  See their activity

  • Posts

    4159

  • Joined

  • Last visited

  • Days Won

    50

 Content Type 

Posts posted by duzenko

  1. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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.

    If only someone could just switch our system to one big vertex buffer...

    • Like 1

  4. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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

  5. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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

  6. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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

  9. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    Are there any gl... calls in front end vertex buffer frame setup?
    About lightgem: it's quite possible that frontend for lightgem and frontend for player view might conflict with each other, but must be very system-specific because the lightgem stage is relatively short, probably shorter than game tic.
    Maybe combine lightgem and player view into a single draw command.

    But I would really like to see the work that's already done in trunk first.

  11. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    Then try 2.05 assets :)

    That worked.

     

    I haven't had time to build my own but I tried both v1 and v1.1 and they both produce some visual artifacts,

    random black tris around animating objects (etc). Still, better than the whole AI flickering when you get up close.

    Can't see any visual errors in Chalice of Kings. What map did you try?

  15. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    Cool stuff.

     

    Not that I'm a expert in this area but I've read that Mutex performance is pathological on Windows:

     

    https://www.arangodb.com/2015/02/comparing-atomic-mutex-rwlocks/

     

    http://demin.ws/blog/english/2012/05/05/atomic-spinlock-mutex/

     

    Did you try using Atomics instead?

    Probably won't be much difference here because it's only waiting once per frame per thread.

    I couldn't build the vr version quickly due to missing DXSDK that 2.05 required and 2.06 does not.

×
×
  • Create New...