FTE QW engine.

[vibok]

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?

[Spike]

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

[vibok]

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.

[Spike]

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.

http://triptohell.info/moodles/win32/fted3dqw.exe is a build that contains the d3d renderers (without gl). alternatively http://triptohell.info/moodles/win32/fteqw.exe has every renderer built in and allows you to just switch between them all via the menus. yay extra bloat.

[vibok]

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?

[Spike]

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.

[vibok]

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

[vibok]

Were you able to reproduce it? I kinda dropped this on you without even trying to invistigate.

[vibok]

Next time at least say that you wouldn't do it. I wasted quite some time just refreshing this thread. Not too much though.

[ChristianIce]

I remember I found somewhere a picture of FTEQW featuring players with visible weapon, but I can't find it anymore.
I would like to use FTEQW as a base for a MOD, a standard Quakeworld with visible weapons would be perfect.
Any help?

[Seven]

Hello ChristianIce,

Some engines have this feature already integrated. You only need the additional models and enable the cvars.
Look for Trickles vweps for example.
No idea if FTE also has this feature.

You can of course add them via qc mod as well. That works for single player and as long as everyone uses the same mod should work in multiplayer as well.
There are different ways to do it:
- Only change the weapon model and keep the player model (without weapons) when switching weapons.
- Combine the player and weapon model and change them for every weapon switch (that is how I did it).

Best wishes for your project,
Seven

[ChristianIce]

That works very well with md3 models and tags, with the "Setattachement" thing, but I guess if you do it with mdls it would result a bit laggy, like the flag in ctf, because that extra model doesn't have the client-prediction movement from the server.

[ChristianIce]

- Dynamic Lights in FTE on a Q3A map


- About FTE features (a request, in case the option is not yet available)
I am working on a map, and for my project I decided to use the Q3A map support.
The only missing thing is the control on dynamic lights... BUT...
Can the engine allow me to use the ingame dynamic lights (rockets, powerups) via qc?
Like mirroring the "EF_BRIGHTLIGHT" code in the server in something I can code with?
I mean, I could create an entity and tell the engine that it's a rocket, but that would be a silly hack, while having a separated entity would allow me to edit the intensity, color, make it flickering, turning on and off and so on...
I think it would be very useful for modders and it would fill the gap of "lacking atmosphere" when you use the Q3A map format.