FTE auto-detects the available elements in the gfx.wad file, and decides which hud to use based upon that. thus -hipnotic and -rogue arguments don't affect the hud by themselves. 

Spike man, it would be AWESOME if you nominated a version of FTE for a stable release, documented all of its current magical powers, and put it up on a webpage for the world to see. 

Just tried to load a quoth map, and there it did not work. fteqw.exe is what I used, latest SVN trunk. Didn't load the proper HUD with the Plasma. 

Is there a way to get around display glitches like these?
Yes, i've seen these glows before.
How prevalent are they. Are there any other zfix associated anoms ? 

I think that is it. It's either get weird z-fighting when you get levels which have overlapping faces or get those little glitter pixels instead. Though it really should not be hard to make levels in such a way that there will not be z-fighting and I think most modern maps avoid this so gl_zfix can be 0. 

@ptoing
should be fixed in revision 4744

@Johnny Law
you want it on a web page? Oh the horror! http://triptohell.info/moodles/web/ftewebgl.html#wee.fmf


regarding anti-z-fighting hacks, I can't help but think maybe we should have some special flag in the map/worldspawn to disable it.
alternatively maybe just enable it for id maps where its a problem and expect everyone else to fix it properly.
MH was against it too, and it can't easily be done in gles either. Mappers depending upon it without realising it is a bad thing. 

Z-fighting "fixes" aren't consistent. On one video card everything will look great.

On another video, the same fix will show every secret door or make the problem worse.

The cure is worse than the disease.

External .ent files to touch up the id1 maps would be the right thing to do. All you have to do is move a few entities 2 pixels down or 2 pixels to the left and problem solved. 

Anyone know where to find the relevant .ent files for id1 ? Rogue and Hipnotic affected ?? 

Not that I know of and I would imagine no such thing exists at the moment.

However, if you load up Mark V, go to the terrible z-fighting area on E1M1 with the Quad.

You will notice there is NONE! Yet Mark V isn't using any anti-zfighting in the rendering.

Because Mark V moves that brush down 2 pixels as an internal hack. You cannot visually tell anything changed (and I'm one to notice anything like that because I want it to look precisely right).

If you want to see something funny, start a maxplayers = 2 game on Mark V and connect with Quakespasm, making sure Quakespasm Z-fighting fixes off. Then go to E1M1 Quad. No z-fighting!

(Because what I did was the equivalent of using an .ent file, which takes effect server-side. I did the same for E1M2 exit doors.) 

I've got two questions regarding this:
1. Why two pixels? One seems sufficient in my test setup, but maybe that's hardware dependent?
2. How did you find out what entities to change? Which tools did you use? 

3. What is the "lip" line for in Mark V? Adding an "origin" alone seems to be enough in my tests so far. 

Mark V's tool_inspector, just type that in the console. Switch between weapon 1 thru 8 to see different entity information. One of them shows the server edict #, then "type edict 79" or edict 151 or whatever the edict # is, into the console

In Mark V, to export the world entities from map load, type "copy ents" in the console and the whole entities from the map are on the clipboard.

re: the 2 pixels

I can't recall exactly, but I did testing on a few different graphics cards. Changing the origin won't work, the lift will be too high or too low in the raised position.

re: "lip"

That in related to mapping and entity properties for func_plat/func_door:

func_door (almost the same as func_plat) http://www.quakewiki.net/archives/worldcraft/entity/standard/std2.shtm#5

http://www.quakewiki.net/archives/worldcraft/entity/standard/standard.shtm 

Try this .ent file in Quakespasm

http://quake-1.com/docs/utils/e1m1_z_fighting_fix_goes_in_quake_id1_maps_folder.zip

You see the E1M1 z-fighting go away without any rendering attempt to make it happen.

Unfortunately, E1M2 has 1 or 2 instances (exit door). E1M3 has at least one (box of rockets in "sewers". Probably several other instances.

And that's just id1 

Thanks for those links. With this info (and some testing) it turns out that the e1m1 case can be fixed by just adding a "lip" line (since the "door" starts in the open position).

Lip 8 is the default and hence shows z-fighting, lip 9 has the door start slightly above the ground, lip 7 has it start far enough underground to stop z-fighting (for me). Changing lip has no effect on the closed (raised) position of the door. (This can be verified by adding for instance a lip -1000 line, the door will then start so far underground that it will take several seconds to rise through the floor; it will still raise precisely to its normal position though.)

Which makes me wonder why you are including an origin change as well? It doesn't seem needed, and will in fact change (although just slightly) the level to which the door raises. 

Things like that shouldn't be fixed with internal hacks, in my view.

As for .ent fixes, here's a tip: in cases where a regular door would cause z-fighting in its open position, you can change the angle ever so slightly so that it moves diagonally 1-2 units behind the wall rather than on the same plane. That's a much better (albeit more complicated) solution than changing the door's origin. For a lift, lip should do, yes. 

Why is changing the angle better than changing the origin? Because that leaves the door in exactly the same position when closed? Or is there another reason? 

Yes, that's the reason. Imagine a secret door that's part of a wall - if it was indented from the get go, you would be able to spot it right away. Or maybe at times it's desirable to have a door align neatly to adjacent walls to avoid clipping. Slightly changing the way the door moves has the least impact on the original design. 

...doesn't use "lip", apparently. Does anyone know a nicer way to make them disappear far enough into the wall to avoid z-fighting than by setting "t_length" manually? 

Make them shrink along the axis of movement by a tiny tiny degree? 

Misc/homedir_0.patch is broken in current SVN.

patching file Quake/sys_sdl_unix.c
Hunk #2 succeeded at 31 with fuzz 1.
Hunk #3 succeeded at 152 (offset 4 lines).
patching file Quake/common.c
Hunk #2 FAILED at 1928.
Hunk #3 succeeded at 1937 (offset -7 lines).
Hunk #4 FAILED at 1965.
2 out of 4 hunks FAILED -- saving rejects to file Quake/common.c.rej 

I am on 2560x resolution with the negative accel issue, so it's not resolution dependent for me. 

Omi, any improvement if you try this build that uses SDL2?:
http://quakespasm.ericwa.com/job/quakespasm-osx-sdl2/lastSuccessfulBuild/artifact/quakespasm-r992-osx.zip

I play QS mostly on a mac with retina display too, and don't notice any negative acceleration; e.g. I have no trouble rocketjumping, quick mouse movements feel fine, but I'm not a great player so I could be missing it, or else it's not happening on my setup but is on yours for some reason.

Also - do you get the problem in both windowed and fullscreen? 

svdijk has been working on this... it looks like we're going to disable the z-fighting hack (gl_zfix cvar) that was applied by default to all brush models in previous QS versions, and which caused visual glitches like the one ptoing posted earlier, and instead ship replacement .ent files with quakespasm (maybe packaged in quakespasm.pak) for some of the id1 maps with the most egregious z-fighting, like e1m1. 

Misc/homedir_0.patch is broken in current SVN.

It applies ok (with fuzz) for me (rev 993).
Check your common.c with "svn diff common.c" ???

Thanks for inlining your SDL2 stuff eric. :) 

Hm, PEBKAC, works fine today.

Great idea with the .ent files, I think that is the best solution.