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. 

Sorry ... it probably was busted.
I'll try to do some doco and patch updates tomorrow.

Re .ent files - Yeah , thanks Sander for that.

I'd never had a problem with gl_zfix, but obviously some people do. 

I think .ent files shouldn't be done to 'fix' this. I can't see it working on demos for example. It's pure shooting-fish-in-a-barrel.

Instead, I think a new format (.off?) should be created just to add polygonal offset origins or angles to map entities and this would only apply visually in the renderer, rather than server. Probably could start off the same as ent files, just parsed separately, disregarding other entity keys the renderer shouldn't care about. 

Pure shooting-fish-in-a-barrel? I think you are misunderstanding that analogy, unless you mean that using .ent files to do this is super trivial. And if that is the case, why wouldn't you do it that way. :P

A special format for doing this might be warranted though, but I will leave the coder folk to that. 

If i were fixing it, i would do it as narrowly targeted as possible to the actual problem:

1. do it all in the engine
2. do it on the client (it is only a rendering problem)
3. detect the specifc combination of map (name + CRC), model, and origin that causes the problem. (i.e. this would only take effect when the model is in the open state, if that is when the problem occurs.)
4. apply a specific offset to correct the problem. (add '0 0 -0.5' to the position for example)

The engine would have a table of such fixes, one for each known map that has this problem.

Those fixes would work in demos, they would work as a client in a MP game, they would not affect gameplay at all, and they would never have false positives against other maps that have the same filename, and they wouldn't prevent players from using their own .ent files for other purposes (like replacing all the monsters.) 

and more targeted than the .ent files. maybe we could migrate to that at some point, using the data from the .ent files as a guide 

I think there may be cases where a secret door slides sideways first, and z-fights the entire time it's sliding. This is different from the e1m1 platform that only zfights in one position. So there may be cases where you need to apply the fix for all but the initial position of the entity. 

Yes, that applies to at least two of the most obvious examples, the exit doors in e1m2 and the bars before the exit doors in e2m7.

I agree with most of your points, especially since not all cases can be fixed with ent files, at least not without noticeable side effects. For instance in e1m3 one of the sliding plates in the floor in front of the wall that shoots the big spike causes z-fighting with the floor in the adjacent room when opened; since func_doors can't move down "a little" (their direction is either vertical or horizontal), I don't see how this could be fixed without changing eithers its origin (not wanted) or its class (also not wanted).

There's one point that you mentioned that I don't agree with though, the first one, to do it all in the engine. These are content errors, and fixes for them hence also belong content side, not engine side. Support for some kind of external "renderfix" files would be needed IMO.

Anyway, at least for the moment I think external ents suffice, since they improve two things compared to the last formal release: they avoid the glitches gl_zfix gave, and the move the fix to the content side. 

.tga screenshots are cruel and unusual punishment to an average user.

First, they can't share them on the internet easily.

Second, to even *view* their own screenshots on Windows they will need a special graphics because nothing that comes with Windows supports .tga.

The next Mark V uses only .png for screenshots.

I happen to be using http://lodev.org/lodepng/ since it doesn't require .dll/.so dependencies. 

You might also consider applying the current level of gamma to the screenshots so the screenshots actually look like what the user sees on the screen.

[If you aren't, I haven't checked in Quakespasm lately ...]