Yeah, I think I never noticed any of those flickers in the original id maps. But I distinctly remember finding some secrets in custom maps when it was set to 1. 

Try going to the quad secret elevator in e1m1 with gl_zfix turned off for a nice example of z-fighting (look at the elevator while it's still "in the floor" and look around a little). 

Oh yeah, I noticed that in Fitzquake. I guess that does not have the zfix thing? or maybe it is not on by default. 

Guys,

I have further issues with the QuakeSpasm OSX client and just cannot use it for multiplayer. I am now using GLProquake OSX which has sound issues but I'd rather have problems with sound than the sum of the issues I've outlined below with the QuakeSpasm client. For informational purposes, I'm on the latest Retina MacBook Pro and also Thunderbolt Display.

1) There is a great deal of negative acceleration at the bottom and top of the screen. This makes RJing impossible. If you bring your crosshair all the way down to your feet to make a rocket jump, your crosshair will spazz out and throw your aim all over the place. Without RJing, multiplayer is severely limited.

2) The timer is inaccurate. The timer doesn't start at 0:00 if someone starts a CRMOD match. It ticks up from wherever the map started. So essentially it's like not having a timer. If someone pauses the match, the timer also keeps ticking. The timer needs to be fixed for clan ring / match play.

3) The teamscores in the HUD are not added up. Therefore, there's no way of knowing how far up your team is in the game without manually stopping the game to do math. This is important because in a DM game, sometimes with 2 minutes barely up you want to hide. Generally speaking,all clients have had these teamscores added for a while, they should be there?

4) LOC support missing.


I really think if all of this were addressed that this would be the best OSX client but even the negative acceleration is too big of a problem to ignore. 

Thanks for the issue reports.

Does negative acceleration happen with ioquake3? Specifically their prebuilt binaries from http://ioquake3.org/get-it/ (over 5 years old fwiw) use SDL1.2 like QS and the mouse handling code at first glance is basically identical to Quakespasm's.

Searching for "negative acceleration" a bit, the typical cause seems to be systems where the mouse cursor is centered in the window at the start of each frame, but if it moves fast enough to hit the edge of the window it just stops. If that's the cause of ours, there may be nothing we can do but see if they fixed it in SDL2 and bug the sdl devs about it.

Also if you could post a demo of what the spazz out when rocketjumping looks like, that would be sweet! 

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.