Jump to content


Photo

I'm working on a VR version - early alpha


  • Please log in to reply
231 replies to this topic

#51 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 80 posts

Posted 28 July 2017 - 02:31 AM

@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, 28 July 2017 - 02:33 AM.

  • nbohr1more and Anderson like this

#52 BuckleBean

BuckleBean

    Member

  • Member
  • PipPip
  • 49 posts

Posted 28 July 2017 - 01:04 PM

@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, 28 July 2017 - 01:28 PM.

  • Anderson likes this

#53 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 579 posts

Posted 30 July 2017 - 01:11 PM

@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...aEh6blJYZjhiZkE


  • Anderson likes this

#54 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 80 posts

Posted 30 July 2017 - 01:41 PM

Not sure what you are comparing it to, but I based it on the 2.05 source download from the website... http://www.thedarkmo...mod.2.05.src.7z


  • Anderson likes this

#55 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 7821 posts

Posted 30 July 2017 - 01:56 PM

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.


  • Anderson likes this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#56 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 579 posts

Posted 06 August 2017 - 07:49 AM

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.


  • nbohr1more and Anderson like this

#57 stgatilov

stgatilov

    Member

  • Development Role
  • PipPip
  • 378 posts

Posted 06 August 2017 - 12:41 PM

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.


  • Anderson likes this

#58 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 579 posts

Posted 06 August 2017 - 01:59 PM

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.


  • Anderson likes this

#59 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 80 posts

Posted 06 August 2017 - 04:10 PM

 

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.


  • stgatilov and Anderson like this

#60 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 7821 posts

Posted 06 August 2017 - 04:33 PM

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.


  • Anderson likes this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#61 stgatilov

stgatilov

    Member

  • Development Role
  • PipPip
  • 378 posts

Posted 06 August 2017 - 10:23 PM

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?


  • Anderson likes this

#62 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 579 posts

Posted 07 August 2017 - 03:29 AM

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.


  • Anderson likes this

#63 stgatilov

stgatilov

    Member

  • Development Role
  • PipPip
  • 378 posts

Posted 07 August 2017 - 12:34 PM

It seems that the code is already in SVN.

So who is going to implement the safe switch? I mean: the cvar which would make everything sequental?


  • Anderson likes this

#64 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 579 posts

Posted 07 August 2017 - 02:02 PM

Best be left to Cabalistic after he's granted svn access?


  • Anderson likes this

#65 BuckleBean

BuckleBean

    Member

  • Member
  • PipPip
  • 49 posts

Posted 07 August 2017 - 08:37 PM

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. 


  • Anderson likes this

#66 stgatilov

stgatilov

    Member

  • Development Role
  • PipPip
  • 378 posts

Posted 07 August 2017 - 10:07 PM

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:

Spoiler
 
Spoiler
 
Spoiler
> 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).


  • Anderson likes this

#67 stgatilov

stgatilov

    Member

  • Development Role
  • PipPip
  • 378 posts

Posted 07 August 2017 - 11:03 PM

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.


  • Anderson likes this

#68 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 80 posts

Posted 08 August 2017 - 12:03 AM

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.
  • Anderson likes this

#69 BuckleBean

BuckleBean

    Member

  • Member
  • PipPip
  • 49 posts

Posted 08 August 2017 - 08:29 AM

Just a quick note: 

 

- The game crashes after enabling HRTF, as outlined here: http://forums.thedar...etter-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. 


  • Anderson likes this

#70 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 5761 posts

Posted 08 August 2017 - 09:25 AM

Just a quick note: 

 

- The game crashes after enabling HRTF, as outlined here: http://forums.thedar...etter-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.


  • Anderson likes this

I always assumed I'd taste like boot leather.

 

#71 BuckleBean

BuckleBean

    Member

  • Member
  • PipPip
  • 49 posts

Posted 08 August 2017 - 08:06 PM

 

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

  • Anderson likes this

#72 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 7821 posts

Posted 08 August 2017 - 08:56 PM

Hmm...

 

https://github.com/f.../tree/threading

 

How's this one going?


  • Anderson likes this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#73 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 80 posts

Posted 09 August 2017 - 12:27 AM

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...
  • stgatilov and Anderson like this

#74 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 579 posts

Posted 09 August 2017 - 01:31 AM

The vertex cache is updated from frontend, not backend?


  • Anderson likes this

#75 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 80 posts

Posted 09 August 2017 - 11:38 AM

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.


  • Anderson likes this




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users