Try playing with higher display resolution. If this helps, we are at least finding the cause of the problem.

http://www.doomworld.com/vb/source-ports/50224-mouse-in-sdl-ports-choco-ee-odamex-prboom/
And you know what? It is limited to the resolution:
for 320x200 it is [-160;159], for 800x600 it is [-400;399]
and so forth... So, if the mouse responsiveness (dpi) is high,
like logitech g5/g9, the game becomes unplayable,
unless you set hi-res, like 1600x1200+...
Bug appears when mouse cursor coords try to go over "screen limit" -
movement is just trimmed. 

Being able to execute mods from within the engine is pretty cool. But I wondered if there is a way to also change the -hipnotic and -rogue switches from within the game, and perhaps also have another one to switch back to default id hud layout. 

Yeah, those could probably be cvars 

Mark V has a such a feature.

typing: "game warp -quoth" in console.
or "game metmon -quoth" etc. 

Add: a vanilla implementation is pretty easy to implement. In Mark V, I paired it up with the "game" command because the existence of "-hipnotic" or "-quoth" or "-roque" affects what pak files to load. 

Would be a great feature to have in QS as well :) 

The mark v implementation sounds like a good way to go 

When? 

I've wondered when next FitzQuake will come out too. 

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?