Jump to content
The Dark Mod Forums

duzenko

Active Developer
  • Posts

    4159
  • Joined

  • Last visited

  • Days Won

    50

Everything posted by duzenko

  1. I think the DR change would be as trivial as copy-pasting the BFG projection function from TDM
  2. The black mirror happens to me as well in svn. Will look into it.
  3. In this case, isn't it the primary issue that the mirror itself is black?
  4. @bwyan Where is the mirror you think is screwing things? I can only see the silverware in the 0.9 pk4
  5. I think the BFG code was disabled by default for a while after having been added Can't remember when the cvar controlling that was toggled
  6. Thank you very much, evidently your math expertise is a rare fortune for TDM The frustumTri's do appear flipped sometimes. I think I can reuse the indices from my previous attempt here (since your vertex order is the same as in BFG frustum corners) Here's a trivial normal test for latest svn While cubeIndices results in Committed to svn. You might want to refactor code just before my change as the indices get overwritten. I did not touch it as it's getting late here, bedtime for me I'm not completely sure about the vertex orientation too. Volumetric seems to work for me now, but it's not a 100% proof. Oh, and we still need to do something with DR
  7. I have a ts2 GPU and it's been running just fine (except for the already-fixed client arrays in core profiles)
  8. Hmm, I think I can see the problem I fixed the wireframe and now looking at the filled triangles ... At revision: 9654
  9. It seems as if the problem is with VBO but I can't see it For now I added a fallback code for compatibility profiles Completed: At revision: 9653
  10. Can you double check spotlight_normal2? It seems to have invalid start/end resulting in NaN in its matrices and debug asserts failing { "classname" "light" "name" "spotlight_normal2" "_color" "1 1 1" "light_end" "200 0 -20" "light_right" "50 0 0" "light_start" "0 0 -20" "light_target" "0 0 -100" "light_up" "0 30 0" "nodiffuse" "0" "noshadows" "1" "nospecular" "0" "origin" "-4 -300 40" "parallel" "0" "texture" "lights/ambient_roundedsquare" }
  11. r_showLights was based on fixed-function GL and needs some love to make work on core profiles It seems that volumetric is the easiest option right now
  12. You could use the debug code in the volumetric render function that compares corner vertices. That and maybe compare with dr corners. Maybe also use volumetric light to visualize the frustum and put 8 candles on frustum corners in dr
  13. Are we ready for bug reports in materials? E.g. a door in Cole Hurst 1 has depth fighting at 6250 555 -20
  14. Let's do something with it already
  15. The d3 frustum is not air tight Bfg code has some nice optimizations It will be a pity to see it go and endless source of suggestions to redo it
  16. I think it's too late to fix it then If even gl 3.1 was too much stress for that pc
  17. Don't you get a click to start gui before you get to 3d world?
  18. I'm rather clueless on how to accomplish that due to my inadequate skills in linear algebra Can you do that while keeping the idRenderMatrix stuff in working condition? Will it be 100% what D3 projection was, or something in-between that and BFG? At any rate any decision is better than no decision as the beta season starts soon
  19. 1. Update graphics driver 2. Upgrade the hardware 3. Downgrade TDM
  20. Select a dev build in the installer
  21. Then what are we left with? It would be great to keep the render matrix stuff but you say it requires the BFG-constructed projection matrix? I suppose we should then change DR to use that method as well? Probably the only change should be the end pos being relative to origin rather than start to improve compatibility with the existing maps? Sorry, what do you mean by that? Being a frustum means that near/far planes are parallel to XY or ???
  22. I was thinking the frustum is generated from the matrix. The both style matrices define the same frustum since one is computed from the other. Currently the D3-style matrix is computed from the BFG one. I was suggesting to reverse this so that the BFG matrix is computed from the D3 one. This way, we will end up with the D3 frustum, and both matrices would be compatible with it
×
×
  • Create New...