Jump to content
The Dark Mod Forums

cabalistic

Development Role
  • Content Count

    585
  • Joined

  • Last visited

  • Days Won

    16

cabalistic last won the day on September 1 2018

cabalistic had the most liked content!

Community Reputation

376 Legendary

1 Follower

About cabalistic

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

177 profile views
  1. Perhaps it's not texture-related, but rather the vertex/index buffers. That might suggest memory corruption or possibly missing/incorrect GPU fences.
  2. You people keep missing each other's points, I think. Context matters Alberto, while I agree with your practices in principle, even "universal" concepts don't apply universally to every problem. I would recommend trying to find a recording of John Romero talking about id Software's history and how they approached game design. He specifically mentions why missing assets are not treated as hard errors, and - surprise - it was specifically to enable fast iteration and getting products shipped Like I said, context matters. Missions and assets are not quite the same thing as writing code.
  3. This would basically require to develop a "new" renderer in WebGL, and possibly some other significant platform porting. I'm not stopping anyone from doing it, but this is going to be a significant amount of work. If I'm writing a new renderer, I'd rather learn Vulkan in the process than another variant of GL
  4. Well, I did get VR rendering working in my PoC, but it turned out that performance is too bad in many maps. That's why I abandoned the effort until perhaps one day enough performance bottlenecks are solved to make it more feasible. A basic stereoscopic rendering would not be as performance critical and is not terribly difficult, but there are some gotchas. In particular, some optimizations in the engine do not play nicely with stereoscopic rendering, so it's still some effort to put in. GIven that the renderer is undergoing some major changes at the moment, I don't think the time is right to add this, as TDM has enough to do for 2.08. Also, as long as that work is ongoing, the renderer is fairly unstable codewise, so that makes adding (and maintaining) stereo support more work.
  5. Stereoscopic support was only added with Doom3 BFG, but TDM is based on the older Doom3 engine. Therefore, there is no stereoscopic support whatsoever.
  6. Capture frame should just work. If it's not, I'm afraid I don't know how to help you with that. You could try the standalone version of nSight, it worked better for me than the Visual Studio integrated one.
  7. It's not about batching - it's about avoiding driver call overhead. Just to be clear, what it achieves is save CPU time in the backend, which in turn will get data to render to the GPU faster and avoid that the GPU needlessly idles. In order to profit from this, the GPU needs to be starving in the first place. If you have a poor GPU and run it at demanding settings, then yeah, it's possible you won't see much of an effect, because it wasn't the bottleneck. (It's also possible you're doing something wrong - you'd have to measure carefully with nSight to try and catch what's going on.) But in my experiments, where I replaced depth and stencil shadow draws with multi draws, the effects were pretty clear. They cut down CPU time for those areas significantly and as a result allowed the GPU to render more quickly. Of course, stencil (and particularly depth) are often not the most significant parts of the scene, so the overall effect on FPS is not gigantic (but it was still measurable).
  8. Anything that applied an offset, I rendered separately (classically). Eventually, I think we need to migrate away from using the GL functions and doing our own offsetting in vertex shaders based on parameters. For one, it enables to use them in multi draws, and for another, they would actually be predictable. The GL polygon offsets are not - their effects can vary among GPUs and drivers.
  9. Yes, you need a new set of shaders, no way around that. I'm not sure if you can make non-multipass use that same set on a GL3 feature base. Anyway, I used a single depth multi-draw command for all non-transparent objects, and then rendered the transparent ones classically on top. Since they use actual textures for drawing, it's not as easy to get them into a multi-draw call. But even if you do, since their fragment shader is much more costly, it still makes sense to have them separated from the solid ones and use a specialized fragment shader.
  10. There is no overhead - you have to transfer the model matrices, anyway. Whether by glUniform or buffer. In fact, buffer upload is most likely faster, because you only have a single upload for the batch instead of repeatedly setting the glUniform. It takes a little more GPU memory, but it's not dramatic. Note that UBOs have an array size limit of I think around 500 or so. For larger collections, you want to use SSBOs, which is what I did in my experiments.
  11. I got no clue. As far as I know, SCons does not directly support it, so you'd have to hack it in, somehow. I had to do the same in CMake (their native support for precompiled headers will only be available in an upcoming version), but I'm not knowledgable enough about SCons to repeat the feat. Nor would I want to - I'd rather replace SCons with CMake entirely.
  12. Imho, your code should not rely on the precompiled header to function correctly, it's just a compile speed improvement. In fact, not every file currently even includes the precompiled header - on MSVC it is auto-included in every file, but with SCons precompiled headers are not used and not auto-included, and that's one of the reasons why these kinds of missing headers regularly crop up in the Linux build (My CMake build does use precompiled headers even with GCC, which significantly speeds up compile times and is more on par with the MSVC build.)
  13. Include needs to go right in the file where it's needed.
  14. Sorry, yes, I'm working on a CMake build system. It was just the first result from AppVeyor I found, wasn't intentional. Are you saying idlib/Thread.cpp should not be compiled on Linux? If so, it's my mistake. Otherwise it has nothing to do with CMake...
  15. According to AppVeyor: c:\projects\thedarkmod\typeinfo\main.cpp(203): error C2143: syntax error: missing ';' before '*' [C:\projects\thedarkmod\typeinfo.vcxproj] c:\projects\thedarkmod\typeinfo\main.cpp(203): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int [C:\projects\thedarkmod\typeinfo.vcxproj] c:\projects\thedarkmod\typeinfo\main.cpp(203): error C2065: 'MAX_THREADS': undeclared identifier [C:\projects\thedarkmod\typeinfo.vcxproj] c:\projects\thedarkmod\typeinfo\main.cpp(206): error C2061: syntax error: identifier 'xthreadInfo' [C:\projects\thedarkmod\typeinfo.vcxproj] c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2065: 'info': undeclared identifier [C:\projects\thedarkmod\typeinfo.vcxproj] c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2182: 'Sys_DestroyThread': illegal use of type 'void' [C:\projects\thedarkmod\typeinfo.vcxproj] c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2365: 'Sys_DestroyThread': redefinition; previous definition was 'function' [C:\projects\thedarkmod\typeinfo.vcxproj] c:\projects\thedarkmod\idlib\sys\sys_threading.h(208): note: see declaration of 'Sys_DestroyThread' c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2448: 'Sys_DestroyThread': function-style initializer appears to be a function definition [C:\projects\thedarkmod\typeinfo.vcxproj] I think there were additional errors, but this is the first one AppVeyor stumbles over. Also, on Linux: [ 27%] Building CXX object CMakeFiles/TheDarkMod.dir/idlib/Thread.cpp.o /home/appveyor/projects/thedarkmod/idlib/Thread.cpp: In static member function ‘static int idSysThread::ThreadProc(idSysThread*)’: /home/appveyor/projects/thedarkmod/idlib/Thread.cpp:218:3: error: ‘_exit’ was not declared in this scope _exit( 0 ); ^~~~~ /home/appveyor/projects/thedarkmod/idlib/Thread.cpp:218:3: note: suggested alternative: ‘_Exit’ _exit( 0 ); ^~~~~ _Exit
×
×
  • Create New...