You can do vid_hardwaregamma 0 in Mark V and only get contrast correction (no gamma). Only other option. 

Next version: Marcher is fully coopable; engine overrides bad keys behaviors in coop. 

I might add a texture gamma option into the (it won't be very flexible though) next one. I want to see what texture gamma would look like (it might look nice, it might look "wrong" -- only one way to find out).

Mark V already can apply gamma/contrast, it does it to screenshots when hardware gamma is used so the screenshots look like what you see on the screen -- I just don't have it setup to do that when loading textures. 

Ah. Well, as I reported a while back, the Contrast adjustment makes everything look really good, except fullbright textures, which it makes look pretty bad (really washed out, losing a lot of the variations in color). So I ended up turning contrast all the way down.

If there was a way to have contrast not affect fullbright things (like wall torches), that would be great.

Interestingly, when the Menu is up and the rest of the screen is kind of "darkened" then the fullbright textures look good again, and you can see the fine variations in color in them.


Also, I think I saw this in FTE, but it's really nice how, when you have selected gamma or contrast in the menu, that "darkened" effect goes away, so that you are actually seeing what the game is going to look like while you are adjusting the colors.

Here, visual aid:

http://imgur.com/a/OPTqa

I really like the way contrast makes everything else look (colors are vibrant, especially the screen text, which becomes much easier to read); it just crunches the heck out of fullbrights. 

Could something be done about the visual glitch commonly known as "z-fighting?"

It's what you see when two surfaces are at exactly the same location, and the engine seems to draw them both, producing really ugly, flickery/flashy results...

One of the best (worst?) examples of this is the large platform in the water on e2m2, which must be raised to get to the exit area. When it's lowered, it's at exactly the same level as the water surface, and it looks reaaaaly bad (this issue only occurs in 3D engines -- not software renderers such as Mark V Winquake).

And it's not always a z-axis issue -- the same thing can be seen on e4m5 where the secret door opens at the start.

I suppose the engine should favor drawing any map brushes over door entities to address this.

I use an ugly hack in FvF and move every door and wall entity on every map by a tiny amount (less than one unit) just so they never appear at exactly the same position as a brush! It eliminates the z-fighting (or x or y-fighting), but it causes tiny cracks to appear near many doors, if you look really closely, heh. But that's a much less ugly thing than the z-fighting. 

gl_zfix 1. It is off by default.

Z fix fighting fixes in engines are evil.

On some graphics cards due to different calculations, they will reveal secret doors.

On other graphics cards the z fighting calculation may not fix z fighting the same.

There is no such thing as a z fighting fix, just a way to try to cover up problems where the solution may yield different problems (hidden doors being exposed). 

The way I always understood it, z fighting was a mapping error. As in, don't let two valid surfaces occupy the same place, doors exactly the same thickness as the wall they slide into and that sort of thing. 

Ah, thanks. gl_zfix 1 is a definite improvement, but not perfect for me (as you said).

It works better the closer I am to a surface. If I'm right up on something, it looks fine, but the farther away I move, the more it z-fights. 

In a perfect world, an OpenGL engine could use what WinQuake uses which as I understand it, clips away at doors and platforms where they occupy the same space as the world. Would be complicated and probably CPU expensive.

A different alternative would be someone making external .ent files to correct maps by nudging the entities on a case-by-case basis. But this isn't always possible. Mark V does this for a couple of maps internally (E1M1, E1M2, ..). quakespasm.pak has a few .ent files using this process. Plenty of instances where that cannot fix the issue, though. 

@gunter ... yeah z-fighting fixes suffer from the "fine tuning" problem ...

"Hey, this looks right on this map, where I am currently standing, with my specific video card, at this angle, if I don't go around and look at any more entities in the current map, ..." 

(pesky stuff) in next one:
1) Zoom: One-size fits all solution that handles specific sensitivity, fov, r_viewmodel_fov values according. dwere brought this up.

2) scr_showspeed - On-screen speed indicator, so someone wanting to speedrun a map or see how fast they can strafe jump doesn't miss JoeQuake.

2) renamed warppos to setpos for consistency with Quakespasm

3) scr_showpos -- for consistency with Quakepsasm r_pos will suggest this command. This is an on-screen indicator, not a console print one.

4) skyfog, wateralpha, slimealpha (etc) worldspawn keys ericw proposed as a standard

5) Curb stomps a couple of things in default.cfg overriding certain horrible Quake default keys, using a WASD setup for the keyboard. Only does this for default.cfg in id1/pak0.pak, does not interfere with mods that override that. 

I wonder if anyone has made a list of all instances of z-fighting in standard Quake?

There aren't all that many "major" places where it happens. It's actually pretty easy fix in QuakeC, heh, just by giving the appropriate entity a different value for either start position or end position when the map is first loaded. It's certainly easier to do it that way than to edit all the maps (one modified progs.dat as opposed to a bunch of modified maps).... 

All of this happened years ago, none of this is anything new.

http://quakeone.com/forums/quake-help/quake-clients/8030-ways-eliminate-z-fighting.html

http://quakeone.com/forums/quake-help/servers-coding/8033-breaking-up-z-fight.html

http://quakeone.com/forums/quake-mod-releases/works-progress/8064-z-fixed-quake-beta.html 

It's certainly easier to do it that way than to edit all the maps (one modified progs.dat as opposed to a bunch of modified maps)....

Depends on your tools. External .ent files doesn't need QuakeC, it's like doing -onlyents map recompile.

In Mark V do this:
1) "copy ents" ... copies the entire map entity string to the clipboard.
2) Save that as c:/quake/id1/maps/e3m3.ent
3) With the map in Mark V, type tool_inspector 1
4) Press 3 for the graphical display to show the edict #.
5) In the console type "edict 55" if the edict # is 55.

You can just find the map entity in the .ent and change numbers.

I'm only pointing out what you can do with tool_inspector in Mark V. 

Ah, that is pretty cool. Yeah, tool_inspector is a great feature -- I've found that very useful.

I didn't know about "copy ents," or really ent files in general. That seems like it would be a nice solution for engines that support it... but in practice it doesn't seem to work.

Looks like the ent information doesn't really contain ALL the information for the ent, and I can't seem to change an origin of a door using the ent file, even if I add a line for it. I know setting an origin can be tricky....


Hm, it looks like "copy ent" loads the information directly from the bsp (ignoring any changes I've made from the progs), and the ent file stuff is only applied if there's a difference between it and what's in the original bsp. And that happens after any progs changes have been applied (overriding any changes I make with QuakeC).

Also, having a blank ent file (as I first crated when testing) will prevent you from loading a level, heh, because "Host_Error: SV_ModelIndex: model progs/player.mdl not precached" 

An .ent file is just to replace the entity text in a .bsp (without recompiling the .bsp without doing -onlyents, which would replace that text).

Open a .bsp in a text editor, go to very near the bottom, that's the entity information.

It won't exactly match the output of the "edicts" or "edict x" command because some of the edict entity information is filled in at run-time.

An example is modelindex. The .bsp (the map) has no idea what that will be, because a map have idea what progs.dat will be running, etc., etc.

But some fields will be exactly the same much of the time, like "spawnflags". A monster's origin if stationary, door information, etc. 

Next will have:
1) Texture gamma option, change it on-the-fly. Uses no cpu/gpu. Should work on gunter's old video card. The no cpu usage/cpu usage thing was the appeal.

2) Gun positioning cvar r_viewmodel_scale. Similar to ezQuake/FuhQuake Can move the gun forward and more prominent.

3) Automatic 2D console/status bar scaling -- Small | Medium | Large or off and use the different FitzQuake cvars.

Change resolution and it will use the best non-jaggies combination of settings based on your preference. 

And "ProQuake" centerprint option --- which is just the same place that original Quake did centerprint. scr_winquake 1 to turn it on. Also sets the scoreboard at the top of the screen.

Mostly doing this because next update could be the last one for a very long time. 

Might add:

if (scr_center_lines <= 4)
..... y = vid.height * 0.35;
.. else
..... y = 48;

Is the original Quake code. And quite terrible, really.

So if less than 4 lines of text, sort of center it on the screen (sort of). If more than 4 lines, do it way up near the top.

So if the resolution gets really high, that discrepancy in positioning will get very large between the positioning of a 4-line centerprint vs. a 1-liner.

It is what it is.

I basically prefer the FitzQuake way provided the text is ensured to be above the crosshair.

/But then you have compatibility ... and I get that too. Hence, upcoming option I don't entirely like to begin with. 

What seems obvious is that the intention of that code is to fit a 320x200 display. Original releases of GLQuake scaled the menus, console, sbar, etc to 320x200 via glOrtho.

What seems deeply fucking odd is that the very same code survived through software Quake, GLQuake, QuakeWorld, Quake 2 and presumably Hexen 2 although I don't have a copy of it's source handy for cross-checking.

I stand by saying that the stated intention of centerprints is for important messages that the player needs to be pay attention to and that obstructing your view is the correct and desired behaviour.

Something like y = (vid.height * 0.35) - (scr_center_lines * 4) seems a better compromise to me. 

@mh - Mark V uses a formula not too different than that. 

It's really not as terrible as one might first think. It actually provides a great deal of control over the positioning of the centerprint (as I previously mentioned).

Also, it does seem worse when you use standard winquake or glquake (or proquake) in very large resolutions where the text gets teeny tiny, so the positioning is affected quite a bit, BUT this is not a problem with the centerprint positioning -- it's a problem with the text size, and Mark V lets us scale the text size up regardless of screen resolution, so the weirdness of positioning of teeny tiny text is really not an issue -- at least not for anyone who scales the text size up to something more reasonable/standard-looking.

Speaking of teeny-tiny text, I tried out the tool_texturepointer thing, and it does not scale the text up along with my other text, so it remains teeny tiny and hard to read in large resolutions.


Anyway, thanks so much for providing the option to use Quake's standard centerprint positioning. This ensures compatibility so that the text will appear as the modders intended (as they saw it in Quake), with pretty much every Quake mod (and standard Quake itself) -- assuming the user's text size is also scaled to a more "normal-looking" setting for Quake


Ya know, I don't think id designed Quake to only run in 320 x 200 -- that's just the minimum supported resolution. And text size is pretty unwieldy at that resolution (not to mention the console is too large); you can hardly tell the difference in the position of 4 or 5 line centerprints when in 320x200. I highly doubt they never tested it in the higher resolutions; they didn't just accidentally position the centerprints the way they did because they neglected to test in anything but 320x200.... 

I'm pretty certain that it wasn't exclusively designed around 320x200... Although conback.lmp is 320x200 so you sure can't make assumptions.....

Nonetheless, I'm also pretty sure that there are huge chunks of the engine that were designed around hardware constraints of the time. The whole zone/cache/hunk thing in the memory manager, for example, is so obviously designed around "must run in 8mb memory". 

Just found this on my hard drive. Dated 2 minutes ago. It is an interesting screen shot.

4-player split screen

.... 

Need tbh. Gonna play some DM with my buddies!

Will it have multi pad support somehow?