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

Might be solved with

cl_minpitch "-70"
cl_maxpitch "79.49"

The pitch bounds in original Quake are -70 to 80. Some servers reject pitch angles out of this range and bound them to the -70 to 80 range.

[FitzQuake 0.85 rounds angles to the next integer, even *after* the pitch bounds checking. Then the angles are converted to bytes (protocol 15) or a short (protocol 666), which may adjust the angle even further in the conversion process. So the 79.49 is to prevent it from being rounded up to 80, which can get converted to 80.0024 which result in some negative acceleration.] 

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.

Yes, thanks. This is what I have been thinking during that whole discussion. Sometimes you engine coders creep me out with your suggestions for fixes. A problem in the progs or a map does not ever belong in the engine. These are hacks!
If a problem lies in one of the ID maps, then it should be fixed in the .map, recompiled and an unofficial patch made. When people complain about bugs in stock maps, the patch can then be pointed to that will work on all engines. 

The z-fighting in the original levels in some places (E2M3 is one example) is too severe to ever be "fixed" without making material alterations to the map.

There are many platform entities that occupy the same location as the world model.

The only "true" solution would be an advanced rendering engine that clipped entities the way WinQuake does.

No amount of .ent files or even recompiling maps is going to stop that z-fighting.

Case in point, you have a platform that extends out which is situated exactly where a world brush is: you can't move the platform down; you can't move the world model brush.

If you do, it won't look the same.

WinQuake clips those. 

I feel like replacement content to fix bugs is an extra burden on the user. Maybe if there was a common, easily accessible pak file with everything fix in it (that everyone agrees on) for people to install, it might not be that bad. Otherwise, it's all theoretical. These bugs could have been fixed with a replacement pak file 15 years ago when glquake came out, does that pak file exist? And how many of you (non-newbie, power users) have it installed?

The reason I am okay with engine hacks to fix stuff like this is that the content wasn't broken when it was released (it worked fine in the engine that shipped with the levels) and it's only more recent engines that can't render it as intended. Also because i like things to be easy for the user and these hacks are completely transparent to them (or at least, they should be.) 

Technology available back in 1996 inside the original DOS Quake.exe --- can solve all z-fighting. 

metslime nailed it. 

I had actually forgotten dosquake didn't z fight... so the problem is that the renderer is different between software and opengl. Is it then not possible to just give precedence to bmodels? That would serve to emulate the original behaviour.
I just started to raise my eyebrows at the talk of detecting the map being played, the entity with the problem... it's just crazy.
I mean, you couldn't even say 'I will displace all entities up 0.5 units', because sometimes there's z-fighting on the walls or the ceiling. 

Is there a solution where you could draw the world, then change the depth test bias, and then draw the entities? I have NO idea how the engine works so apologies if that is super basic and already dismissed ... 

Patching content over fifteen years old. How far do you go? Fix the texture misalignments as well? That will mean new brushwork and expanding on the texture sets.

The best way would be to organise some sort of community project to rebuild all the maps, maybe adding some new content like enemies and so on.

Has anyone tried that before? 

 

the engine guys want fixes in the engine and the level guys want to rebuild the levels