You have it right, Pritchard. mh is confused.... Maybe he didn't fully digest the post I made where I showed that the positioning I want is actually the default positioning of original Quake.

See for yourself. Start a single-player game in original Quake, GL, or Proquake (which uses the same positioning). As you walk through a hall you will get the one-line message about "this hall selects whatever skill." Note the position above your crosshair. Now enter the first episode area, and you get the 4-line message about the dimension of the doomed. Note that it still starts at the same place, but is still fully above your crosshair position (assuming you aren't in a tiny resolution). All good. Now enter the second episode area where there is a FIVE-line message about the realm of black magic... but look where it is positioned! It's way up near the top (again, resolution dependent)! Why? Probably for the same reasons I talk about: so that it doesn't actually start to extend to the crosshair area and block that important area of your view, when instead you can move it upward because you have all that extra screen space where it could go instead.

This is NOT a case where I want to change the positioning JUST to suit my mod -- this positioning would be better for ANY mod that uses centerprints, and even for original Quake. So yeah, it IS more optimal for the general case.

id, in all their wisdom, chose this positioning for good reasons. I, in all my wisdom, wanted this positioning too, for good reasons, before I actually realized it was the original positioning, haha. I didn't know at first that this positioning was from original Quake (I've been away from Quake for a couple years :p ) -- I just knew that it had changed from what I was used to in ProQuake, and the change had made things less optimal, and it ended up obscuring my view in an unpleasant way.


So it turns out you actually agree with me, right mh? You think the default Quake behavior should be used, correct? Good, glad we have that settled.


Or are you focusing too much on the idea that I am wanting to change the PURPOSE of centerprint messages, from when I said, "But I think at this point they are no longer 'always important,' sooo.... they don't really need to be inconveniently in the middle of your view anymore :D"

Much like id's original statement, I was not being completely serious. id's original statement was a small joke (I thought it was funny anyway) -- it's simply not true that every centerprint in Quake is 'always important,' and they aren't even always inconveniently in the middle of your view, as I demonstrated above.


Sure, I did talk about even changing it a bit beyond the original positioning, but that's the kind of ideas that should get thrown around in threads lie this. After some testing, I have found that I actually have a great deal of control with id's original centerprint positioning.


If I want it to appear closer to the center of the view, I just make it 4 lines or fewer (that is the actual limit, now that I've checked for sure).

If I want it to appear near the top (it's "7 lines" from the top), I just make sure to pad it with extra lines ("one line\\n\\n\\n\\n" will appear at the top).

I can even move it below the crosshair area if I stuff in a bunch of extra lines above what I want to print....


I have lost this level of control in Mark V, so yeah, I would like it reverted to Quake's default behavior.

And apparently you agree with me, right mh? You seem to pretty strongly advocate for using "defaults..." So we are in total agreement here!



Now let me consider some of these other juicy changes Baker is adding in.... 

Yeah that's difficult since a lot of stuff is not well-documented, plus there's an avalanche of little things that someone may or may not care about.

One could try to do a chart comparing engine support for widescreen, rendering API, palettized rendering output, texture filtering, QW multiplayer, QW listen server, singleplayer, colored lighting, soundtrack music files (and in what formats), bsp2, map texture replacement, model texture replacement, alpha-masked textures, various fog behaviors, .ent files, .loc files, QC extensions, clientside QC, XInput controllers ... you could really keep going and going and even then never get to things like "centerprint behavior" :-) or corrected weapon-viewmodel-height or whether the demos play on startup. Which some folks really care about!

It might be a good thing to try to set up as a shared Google-docs spreadsheet that a few engine experts/aficionados would be interested in keeping up-to-date. I dunno. There's a chance it would just get dozens of feature-columns added for minor things which only apply to one specific Quake engine. 

was replying to Qmaster there 

"Coop players spawn partially transparent ... cannot be telefragged"

Brilliant! We do have that problem in FvF! Unfortunately, I don't think this is going to help me, heh. That would be a server thing, right? Polarite runs some linux proquake for the server.... Further, FvF doesn't actually run in coop mode -- it runs in a special deathmatch mode (coop 0, deathmatch 3), so all the doors are already open and we don't have to go around collecting keys and things most of the time. We just get to killing the monsters.

But this certainly give me the idea to try this change in the mod, instead of the standard 3-second spawn protection pent (which prevents telefragging, but causes people to sometimes be pushed into the floor). Hm, but what happens if the players are standing on top of each other when they became fully opaque?


I'm hopeful about the gl issue workarounds.... 

That is pretty weird behaviour in WINQUAKE.EXE: set the res to 1024x768, walk up to the episode 2 entrance in start.bsp, and the 5-line message is near the top of the screen. The episode 4 message (4 lines) is just above the crosshair.

This feels like something where the code is fudged in a way that looks good at 320x240. (another is the weird left-aligned deathmatch hud) 

The episode ending messages use WriteString, not centerprint and that is why they are at the upper portion of the screen.

@Johnny Law: Might do...sounds tedious but I do like that sort of thing. 

Last night I was using chase_active 1 too look at some splashing water effect I'm trying, and I thought it would be nice if the crosshair was still accurate even in chase cam.

I used the autocomplete and found the chase_active setting which I had forgotten about, and toggled it on, and found that my crosshair was accurate in chase mode! Ok, that's nice.

However, chase_mode does not act in an intuitive manner -- I reported this as a bug in the past because I did not know what was happening. It seems that chase_mode cycles through 8 different modes (and most all of them are going to be completely non-useful, I think) without letting you know it's doing that. I did find that I can do "chase_mode 1" to specify I want that first mode with the accurate crosshair.

Perhaps the cycling of chase_mode should be followed by a notification, like "chase_mode is 4" or whatever.

And I guess this would throw everything off with crosshair accuracy, but it would really be nice if I could re-position the chase cam so that it was like right above my shoulder, as in many 3rd person shooter games (chase_right just doesn't work in chase_mode 1, etc).

Maybe one of the default chase_modes could be a view like that....

I can't tell what the difference is between chase_mode 1 and chase_mode 2. Chase_mode 3 and higher are rather crazy.

Quake has had chase cam for a long time; it's just never been that useful. Having an accurate crosshair even in chase mode is a big improvement. I just need to be able to move the cam to the right a bit so my guy isn't blocking my aim.... 

Chase_mode is a "for fun" feature.

Gives different camera perspectives, possibly for making a "movie"/.avi/Youtube video.

Games with sophisticated camera control have massive C++ libraries created by paid game professionals, sometimes involving camera hint entities and such in the maps.

Like shadows, chase_active 1 is just a hack. I gave some extra flexibility for making a Quake vid and ...

... gave it an MH tune up where MH made the chase camera collide with the wall far more accurately. Used to be something mh and I talked about a ton, haha.

But once I saw the massive C++ camera code in commericial class engines, yeah ... sadly it's a lost cause.

Won't be altering chase_mode for the foreseable future. Have more important issues.

I'm just one person. 

I'll probably be making at least some light documentation since it looks like the engine will finally be out of beta testing stage -- a place its been living due a lack of time. 

I don't know how fixable this would be, but I'll mention it.

I have an altered gamma profile on my netbook, to brighten the screen a bit -- the default is too dark. It loads up automatically in windows once I set it in the graphics properties.

Mark V uses hardware gamma, as you have mentioned, and it looks good in the game.

If I run Mark V in a window, I can see that my other windows are even brighter than usual, but when I switch away from Mark V (or when I exit Mark V) it returns my netbook to the default setting instead of my altered gamma profile (switching back to Mark V changes it again to the gamma settings I made in Mark V -- of course, this all still applies when I run in fullscreen too; it's just easier to notice when I run in a window).


It's not a huge problem, since I have a taskbar icon I can use to set my gamma profile, but ideally it would return my gamma profile to what was selected before I started Mark V, rather than the default (which is "no adjustment"). 

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"