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 

 

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

The funny thing is, IMO anyway, Fitzquake's rendering has been the benchmark for a lot longer than software quake. So even if we had a perfect OpenGL clone of whatever winquake does, I would argue there's not much point.

The gl_zfix hack that was enabled by default in QS was pretty decent, besides showing outlines of secret doors sometimes, and one of the results was Scampie put Z-fighting in one of his jam maps because he didn't see it when testing in QS :-/ 

I'd also be fine with not fixing these bugs at all. Either way the solution (or absence of a solution) should not break newer content that was authored correctly. 

Intel ATI Mobility:

Arwop: Roman1 --> +2 fps (18 -->20)
id1: start --> (-10 fps?) (172-->162) ??? 

Would you mind trying the roman1 demo again with "gl_fullbrights 0" and "r_drawentities 0"? That should cut off all drawing that's not using the vbo - I just use it on the lightmap + texture pass for world + brush models - and maybe show more clearly if there's any benefit to the vbo.

I'm not sure about why id1 start got slower. I am using unsigned int indices which is sometimes not recommended. 

I didn't do a timedemo, btw. On both maps, I just stood still at the start for about 20 seconds.

On roman1, doing gl_fullbrights 0 has no fps change (still 19-20 fps).

r_drawentities 0 it goes up to 53 fps. (Older Quakespasm, gets 46 fps with that ... so this is a +7 fps gain) 

Yo, I am just reposting this comment from my youtube here as I don't know the answer to his questions :

"quakespasm best quake engine that I know of overall, but it still has some glaring flaws in my opinion. The biggest issue for me is the way it handles- or rather doesn't handle- weapon models.

In quake, just like in doom, weapon models were placed in the center of the screen intentionally to be used as aiming sights. This mechanic, for me at least, is a crucial tenant of the classic doom and quake experience, and it goes completely out the window in quakespasm, as the engine doesn't compensate for the absence of a status bar and draws a microscopic weapon model at the bottom of the screen, about two miles from the center of the screen. The only way to compensate for this is to jack the field of view way up to say 130, which brings the weapon up to where it should be, but seems to stretch it vertically, and of course comes with all the issues that come with a grotesquely large field of view.

If anyone has an idea for fixing this within quakespasm, let me know." 

I posted a question about this general thing on I3D a while back; there's some discussion about the issue in the thread: http://forums.inside3d.com/viewtopic.php?f=3&t=5527

...but as far as solutions for a player to change things, I don't think so. 

They might like using Fitzquake Mark V with r_viewmodelhackpos = 1? 

You can use the "scr_ofsx" console command to move the weapon model further into view of the player. By default it is set to 0. A positive value draws the weapon in closer, and a negative value pushes it out further.

I personally use -4 as my value, but give different numbers a try and see which one suits you best. 

I will post this to them, thanks. 

sometimes I feel it's too low on the screen when playing with the statusbar partially transparent. It could be nice to have an option where the gun position doesn't move down when you make the statusbar transparent.

Thx for the link Johnny. 

it might look ugly though. the ssg is particular doesn't have much more to its model besides what's already on the screen. 

New prerelease builds uploaded at http://quakespasm.sf.net/devel/


win32:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r1032_windows.zip

win64:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r1032_win64.zip

macosx:
http://quakespasm.sf.net/devel/QuakeSpasm-0.85.10-macosx-r1032.zip

source:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r1032.tar.gz

Linux users can build from the source for themselves.


Changes since the previous r980 test builds from Aug. 29 include:

* SDL2 support. Disabled by default, 'make USE_SDL2=1' to enable it.

* Unix/Mac user directories support. Disabled by default,
'make DO_USERDIRS=1' to enable it.

* Revised/improved the 'game' command, i.e. on-the-fly mod changing.
It now accepts an optional second argument for mission packs or
quoth support i.e. -hipnotic, -rogue, or -quoth. For example, for
WarpSpasm: "game warp -quoth"

* Command line: "-game {quoth/hipnotic/rogue}" is now treated the
same as -quoth, -hipnotic, or -rogue.

* Console speed now resolution-independent.

* Disabled gl_zfix, which caused glitches and is undesirable for new
maps. Replacement .ent files to fix z-fighting for several id1 maps
added to quakespasm.pak.

* PF_VarString buffer bumped to 1024, avoids truncated centerprints
from the 'In The Shadows' mod.

* Support for OpenGL vertex buffer objects (VBO) for world and brush
models.

* Dropped support for GL_SGIS_multitexture

For more detailed list of changes see the README file, or browse the
svn history.