Jump to content
The Dark Mod Forums

cabalistic

Development Role
  • Content Count

    539
  • Joined

  • Last visited

  • Days Won

    16

cabalistic last won the day on September 1 2018

cabalistic had the most liked content!

Community Reputation

355 Legendary

1 Follower

About cabalistic

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  1. Feel free to experiment with it, but make sure to do very careful GPU profiling on the results, as the performance impacts of switching from glMapBufferRange to glBufferSubData in this context are completely unclear to me... Also note that the current implementation dynamically resizes the dynamic buffers if needed. If you do want to store static data in the same buffer, you'd need to reupload that in those cases and thus would need to keep that data around.
  2. Actually, I may have been mistaken. Reading this (https://www.khronos.org/opengl/wiki/Buffer_Object#Mapping) It may be impossible to use a single VBO for GL3, because if a buffer is mapped by glMapBufferRange, then simultaneously reading from it (i.e. rendering) is apparently not allowed, not even from the regions which are not mapped. This is solved with persistent mapping, but that's a GL4 feature and thus not something we can do in the core of the engine. Alternatively, you'd have to work with a system RAM shadow copy in the frontend and transfer via glBufferSubData after every frame, which would cost RAM, and the performance implications are unclear to me. So I still think solving this at the draw call level is the safer approach
  3. Keep in mind there are three dynamic vertex buffers (one for frontend updates, one for backend draw calls, one for GL driver sync), so you'd have to replicate the static data three times. I think it is theoretically possible to use a single large buffer instead of the three separate targets, but it does complicate certain things and is not a trivial change. What I think would be easier to do is to separate draw calls by static/dynamic nature and issue the static calls first (per pipeline stage), which would give you almost the same benefit. In fact, for some of the GL3/GL4 optimizations I did in experiments I already did that.
  4. Well, I would be strongly in favor of a move to Git. Yes, it is initially more complicated than svn and has a learning curve, but once you're past that you end up with workflows that are just superior (imho). Particularly in a distributed team context as we have here. Also, if we ever want to actively attract new developers to join or at least contribute to the project, I believe there is no alternative. The private SVN repository is a hassle and huge turn-off in that regard.
  5. My audio card is set to 16bit, 48kHz. I have not had any problems so far.
  6. I haven't removed the previous releases, they are still there: https://github.com/fholger/thedarkmodvr/releases No need to compile anything, the latest (0.1.3) is the latest working version.
  7. Actually, I at least do expect some performance gains, and I've already seen some during experiments I did for my VR mod. They won't be stellar, but the switch does allow some optimizations in regards to driver overhead. The current backend performs very poorly in that regard and regularly drains the GPU of work. That is going to get better with GL3 and there is also some potential for even further improvements with optional GL4 features. Like I said, it's not going to be a massive improvement, but it should definitely make an observable difference in scenes which particularly suffer from this.
  8. Sorry, I got stuck with some issues and decided to put the mod on hold for now. The renderer upgrade really must happen first in base TDM, otherwise it's just too much effort for me to maintain the VR port So probably no further update before 2.08.
  9. It was part of the original BFG vertex cache code that I copied. It is an SSE2 optimized copy, and at the time at least TDM did not have an SSE2 memcpy, so I left it in. Feel free to replace it if there is no performance loss. Like I said, the vertex cache only has two modes - static or dynamic. Static means it must be uploaded at level load and cannot be updated at all after. If the interactions you have in mind fall into that category, you can try to move them there. But if not, it's better not to bother. Implementing a semi-static system carries a massive cost of its own, and it is very likely you will end up with worse performance due to the overhead. At the very least you will make the code a lot more complicated, which is not a good thing for further parallelization.
  10. What exactly is your concern? I don't understand the question. If they are truly static (as in, static over the whole level load), you could move them to the static buffer. However, i tried that for static shadow caches, and it caused some issues and did absolutely nothing for the performance, so I dropped it. If they are only static for a certain time, then you can't reuse them. Keep in mind that the original code did that, and the new vertex cache is faster. If you truly want to save some transfers, the best improvement would be to implement GPU skinning, imho.
  11. What's the baseline fps you get without it on that map? The enhancement is only effective if frontend and backend take roughly the same amount of time. There are situations where this is not the case; in those instances the enhancement will not help.
  12. Generally, the vertex cache only has two modes: static or per-frame. So either something is in the static cache (thus valid for the entire duration of play until level load happens), or it's only valid for the next frame and needs to be reuploaded thereafter. Shadows, in general, are currently not in the static cache. I initially tried to imitate BFG and move certain shadows into the static cache, but it caused problems when loading save games that I couldn't figure out, and it didn't seem to make any difference whatsoever to the framerate.
  13. Stability (and speed) is very likely to improve with 2.07. Right now, most of the trouble people might experience is probably due to the two threads both calling to OpenGL. 2.07 introduces the vertex cache enhancements which removes the need of the frontend thread to access OpenGL. As mentioned, the multi-core enhancement is really just a dual-core enhancement at the moment, splitting the renderer into a "frontend" and "backend". Frontend is basically the CPU path collecting what and how to render, whereas the backend is the path actually issuing OpenGL render commands. I did experiment with splitting up the frontend further over multiple cores, and I do have some working code lying around that improves frontend speed. However, the gain is not as spectacular, and it currently does not help, because in those locations where it actually helps, the backend uses at least as much time, and so speeding up the frontend without also speeding up the backend does not result in any net FPS gain. When we get around to overhauling the GL backend, this might be worth reinvestigating
  14. Well, my near-term roadmap currently looks like this: fix one outstanding bug to get the preliminary port to 2.06/2.07 workingget UI elements including menu to render to a separate plane so that you can actually see and read them in VRdecouple vertical mouse movement from the head motion as it's incredibly confusingAfter that, I'll see if I can quickly add some sort of "pointer" like a 3D crosshair to give an indication of where the mouse is currently aiming at. This isn't just important for bow and arrow, but also basic things like looting and picking up stuff, because that's still bound to the mouse aim. As for roomscale: it's always been my distant goal to make this a full roomscale experience, but it is a very long road. And performance is still a huge concern. There is one major change and a few quick wins that are specific to VR that I'm going to try to implement that will probably help a little. But even then there are going to be maps which are not playable in VR, and probably few will be playable without reprojection. Some further performance optimisations will have to go through improvements in the base TDM project, so that will take a while, and it won't do miracles, either. I'll just have to see what's possible in what timespan. So for a first step, I'm just trying to make it a decent seated experience, because I figure that's better than nothing Whether roomscale will ever truly happen remains to be seen.
  15. Haven't looked at fhDoom's approach. But a class-based design is the goal, yes. It will especially come in handy to cleanly separate the optional GL4 improvements.
×
×
  • Create New...