#1156 posted by Joel B on 2014/09/02 05:08:11
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.
Spike
#1157 posted by ptoing on 2014/09/02 09:28:59
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.
Ptoing
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 ?
#1159 posted by ptoing on 2014/09/03 15:36:52
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.
#1160 posted by Spike on 2014/09/04 08:22:49
@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.
#1161 posted by Baker on 2014/09/04 08:58:41
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.
Cheers Baker Man
Anyone know where to find the relevant .ent files for id1 ? Rogue and Hipnotic affected ??
Well, Here's To Evil
#1163 posted by Baker on 2014/09/04 12:09:15
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.)
Hi Baker
#1164 posted by svdijk on 2014/09/04 19:56:05
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?
One More
#1165 posted by svdijk on 2014/09/04 20:28:08
3. What is the "lip" line for in Mark V? Adding an "origin" alone seems to be enough in my tests so far.
@svdijk
#1166 posted by Baker on 2014/09/05 05:10:04
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
@sa
#1167 posted by Baker on 2014/09/05 05:24:08
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
@baker
#1168 posted by svdijk on 2014/09/05 09:25:39
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.
Hmm
#1169 posted by negke on 2014/09/05 10:38:20
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.
@negke
#1170 posted by svdijk on 2014/09/05 10:48:35
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?
#1171 posted by negke on 2014/09/05 11:04:31
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.
Func_door_secret...
#1172 posted by svdijk on 2014/09/05 20:33:21
...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?
#1173 posted by Lunaran on 2014/09/06 18:26:26
Make them shrink along the axis of movement by a tiny tiny degree?
#1174 posted by Spirit on 2014/09/07 15:10:23
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
Negative Accel
#1175 posted by Omi on 2014/09/08 09:27:38
I am on 2560x resolution with the negative accel issue, so it's not resolution dependent for me.
Hmm
#1176 posted by ericw on 2014/09/08 09:54:17
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?
Re: Z-fighting
#1177 posted by ericw on 2014/09/08 10:07:28
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.
Honedir, Sdl2
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. :)
#1179 posted by Spirit on 2014/09/08 12:20:04
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.
|