No announcement yet.

FTE QW engine.

  • Filter
  • Time
  • Show
Clear All
new posts

  • 2d elements are glitching for me. For example, when menu is open, the halftransparent area becomes fully transparent at the bottom. Like it doesn't get enough time to get drawn. Gui also flickers sometimes, also near the bottom.

    This only appears on faithful preset. On dynamic it's ok, but fps is too low.

    Any idea what this can be?


    • There is no 'half transparent' area...

      if you're using cl_sbar 1 and have replacement artwork that is for some reason not fully opaque then yes, parts of the screen won't be redrawn. Either delete that artwork or just set cl_sbar 0 (which it should be the default for the 'faithful' preset anyway - its only the vanilla/softwarey preset that uses cl_sbar 1, and frankly if you're trying to use that preset in combination with replacement artwork/textures then you're kinda doing it wrong).

      So yeah, I'm sorry but I don't know what you mean (unless you mean the vanilla preset rather than the faithful one, in which case see above).

      you said you were trying to run it on a 'potato' in the other thread. in which case, you should probably just go with the 'fast' preset instead. you should also consider trying the d3d9 renderer instead, iiuc intel have noticably better d3d drivers than opengl and you should get better performance out of it that way.
      if you're on win7 with a shitty/virtual gpu, you can try:
      setrenderer "d3d11 warp"
      this will then attempt to use microsoft's pure-software renderer, which was basically intended for things like RDP etc where an actual gpu might not even be installed, but it can also be useful with dodgy drivers/hardware too...
      Some Game Thing


      • Knew I couldn't describe it with words. Here's my photoshop.

        That glitch still appears on fast preset.

        How can I switch to d3d9 renderer?

        setrenderer says valid parameters are gl, none and headless.


        • okay, I've never seen THAT bug before. I see what you mean by not getting enough time to draw...
          afaik FTE doesn't use any APIs that are allowed to have race conditions like that, so I'm just going to blame the drivers for that one... if this were the vulkan renderer then it would be a different matter, but hey.
          you can try gl_menutint_shader 0; obviously your background won't be sepia any more (rather merely tinted), but at least it won't be annoying.

 is a build that contains the d3d renderers (without gl). alternatively has every renderer built in and allows you to just switch between them all via the menus. yay extra bloat.
          Some Game Thing


          • with d3d the bug is no longer there, and fps is good. Yeah, probably just a buggy driver.

            may I ask, where in the gl renderer source code the drawing of 2d things happen?
            Last edited by vibok; 07-02-2017, 02:38 AM.


            • good question...
              FTE basically just uses trisoup for everything, so...
              r_2d.c has a R2D_ScalePic function which basically just calls R2D_Image to accumulate some extra texture coord args.
              r_2d.c's R2D_Image function then checks if the current batch is okay, if not then it flushes it, otherwise it appends more geometry onto the end of the batch.
              Once something else gets drawn (or fbos switch or whatever), the function-pointer R2D_Flush will be called, which means R2D_ImageFlush will get called.
              R2D_ImageFlush basically just calls BE_DrawMesh_Single (which is some renderer-specific function) that does the actual trisoup drawing (at this point there could be multiple meshes/quads in the batch).
              [note that vanilla skipped the whole batching stuff, R_DrawPic would just directly throw stuff at the screen, which makes vanilla much easier to follow if you just want to draw a quad]
              inside gl_backend.c, [GL]BE_DrawMesh_Single basically just calls GLBE_DrawMesh_List with some extra args (*sigh*)
              At this point all sorts of crazy things happen. Depending on the gl driver, the batch might get thrown into vbos, vaos get in the way, there's a whole load of complications caused by backend modes, shaders, shader passes, backend overrides, and glsl, but for each shader pass that's actually drawn, BE_ApplyAttributes will get called along with some various opengl state changes (only if they're actually needed), and then a glDrawElements, leaving the gl state dirty in the hope that the next pass/mesh is mostly the same (if FORCESTATE was defined then dirty checks are basically disabled and every single bit of state is re-set...).

              Really though, if you're writing your own engine, you should be using VBOs for everything. However, to do this you should also ensure that your VBOs don't get changed at all between calls. This generally means that you need to write out your complete VBO before making ANY gl state changes. This is of course awkward and feels stupid which is why I never did it in FTE. The catch is that VBOs are not always supported (<gl2, or gles1|2)... The other catch is that NOT using VBOs is not always supported either! (core contexts).
              If you want proper advice on modern OpenGL, you should try researching AZDO - my azdo/toy engine attempt basically draws the entire world entity in a single opengl draw call, or up to 512 mdl entities in a single call (thanks to glMultiDrawElementsIndirect in combination with SSBOs and texture arrays).
              Its great for performance, but it also basically limits it to gl4+ drivers and no special effects. Its fine if every surface is basically the same, but things get much more awkward when your engine can have different effects happening on every single world surface, which is why it never managed to migrate over to FTE. Compat...

              If you want to see the exact opengl calls that FTE is making without bothering to read the source, you can install renderdoc and get it to invoke FTE with +set vid_gl_context_version 3.2 +set vid_gl_context_compatibility 0 -window
              (should also work with the vulkan and d3d11 renderers, but not the d3d9 renderer, nor with compatibility gl contexts hence the need for extra args)

              so yeah, its compliicated.
              Some Game Thing


              • Sorry, how can I compile d3d 32bit version of FTE?

                I'm trying
                make d3dcl-dbg FTE_TARGET=win32
                but it complains about "unknown type name" pubsubserver_t in engine/common/sys_win_threads.c. It's actually defined in engine/server/server.h, strange that it's not seen from there.

                gl version compiles fine