Go to video options and switch hardware gamma off? 

I'm currently using Mark V 1.20 (not sure if that's the latest version), there's only 4 options under Video Options - Resolution selection, Fullscreen on/off, and apply and test buttons. The only thing I've seen relating to gamma is the slider, but that doesn't sound like what you mean. 

That menu item was added in the current version, 1.36. You'll probably prefer the DX9 build over the traditional Open GL version since it is much faster (nearly 3x faster in many situations), but both are available. 

Woah, what happened to my framerate? I tried the dx9 build and it was fine, but the GL build tanked. I was getting a perfect 72 on my map before, but now I get something in the range of 22-23 fps with the standard mark_v.exe.

At least dx9 works. 

Also, r_waterripple is really cool, it's a shame about the seams though. 

Is another topic that pops up occasionally. I'd like to see support for it. May be tough due to the way water morphs and deforms though 

As far as I know light maps are blended after textures are drawn, so depending on where the textures are warped it wouldn't be too much of an issue? I'm not sure how the water warping is done though. 

lightmaps and textures use different UVs so in theory the lightmaps don't have to warp. 

Pritchard, gl_subdivide_size 32 should get rid of the ugly seams, if you're talking about what I think you are, related to r_waterripple.

Something to try which might improve frame rate (GL or otherwise):

r_mirroralpha 1

Using non-hardware gamma will also decrease FPS, unless the gamma and contrast sliders are all the way down (basically disabled).

r_shadows decreases my FPS, so if you happen to be using that setting, try disabling it. 

I was thinking....

So, Mark V keeps a (somewhat hidden?) backup config.cfg file to prevent bad things, such as other Quake engines blanking out a lot of settings and such.

This is both good and not so good....

The good part is obvious.

But it can be not so good for some situations, like if I WANT to blank out my settings in my FvF folder... (they just get re-loaded from somewhere), and like above where I noted that when you play a new mod for the first time, things like "disable demo playing" should certainly revert to its default value (play the demos).

So part of this behavior is taking away user control, and part of it is altering a default behavior that can sometimes be better to not alter.


Anyway, here's my suggestion:

Instead of using a hidden config.cfg file, just have Mark V create its OWN config file in the current game directory, perhaps named something like Mark_V_config.cfg

And Mark V will automatically load the standard config.cfg file, then after that load it's own Mark_V_Config.cfg file.

This is an improvement in my view, because:

- The Mark_V_config.cfg file is easily editable/deletable by the user.

- Mark_V_config.cfg settings will not be altered by another engine which messed with the config.cfg

- Loading that file after the config.cfg will mean Mark V's settings will override settings that other engines have made (or erased) in config.cfg


Mark V would still alter the standard config.cfg file (as is standard Quake behavior) so that any applicable changed settings will apply to other engines. Probably the special Mark_V_config.cfg file would be nothing but a duplicate of the standard config.cfg file... (which is probably functionally equivalent to your special backup config.cfg file, but it's stored in the same game directory now).

And if a new mod is ran which does not contain a config.cfg or Mark_V_config.cfg, then the default settings should be applied (such as playing demos).

If you wanna get fancy, then save all BASIC keybindings and aliases somewhere and let them carry over even if no config exists for a new mod.

Extra fancy would be some menu option for this -- "Save basic config settings," "load basic config settings," "always retain basic config settings," or something like that within the Customize Controls menu (though I know how much you hate extra menus).


Or perhaps some of this this might mean making another config file, much like R00k was suggesting in #1224 (which sounds like a great way to do it all around -- saving aliases and such automatically, and automatically switching to new configs when changing mod directories).

So Mark V could write it's Mark_V_config.cfg which is basically a backup of the config.cfg, and also a Mark_V_user.cfg which will always be written to id1 and read no matter what mod is ran, which will just contain basic key bindings and aliases which would be unlikely to change from mod to mod. Though the Mark_V_user.cfg from id1 should load first in case the user has set up special key bindings for a mod -- such settings would then be read from the gamedir config files and override the basic user controls.

Hm, then, of course, any key bindings made while playing a mod wouldn't carry back to the basic user settings stored in the Mark_V_user.cfg in id1, but that's actually correct behavior, in my view -- UNLESS the user uses that hypothetical menu option "Save basic config settings". Of course, if the user was just running id1, those settings would be saved automatically.


So... in summary, and in order of loading:

Mark_V_user.cfg (always in id1, contains key bindings and aliases, loaded every time even when running other gamedirs. Saved automatically if running id1, or by user selecting a "save config" option when he's running a mod)

config.cfg (standard function, for cross-engine compatibility when possible)

Mark_V_config.cfg (saved alongside the config.cfg in current game directory, backing up all Mark V settings and overriding settings that other engines made to config.cfg).


All files are easily user-accessible.

And like R00k suggested, configs should be automatically saved/loaded upon switching gamedirs. 

It would be better to discuss lit water after a couple of single player releases have the feature.

Would be proof that mappers will use the feature, that the compile tools work reliably, that another engine has achieved a stable implementation.

When these maps exist in the wild and after the rank-file can play these maps and potentially report/discuss issues in engines that current support them, it isn't out of the "idea stage".

Where are these maps?

Until they exist, from my perspective they exist this is the same as talking about leprechauns or the Loch Ness Monster. 

Methinks the reason for the absence of such maps is exactly the fact that there's no proper engine support.

Right now - what, Darkplaces has it? FTE, maybe? I'm not even sure. People don't work with advanced engines here. And it's not exactly the kind of feature that you could squeeze in as an optional bonus for special engines. It affects the way the level looks a bit too much. 

I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler. But it is a chicken-egg situation; I don't have any way to know how my map actually looks with such an effect, since I know of absolutely 0 engines which support it.

I'm sure you can imagine that authors may have reservations about releasing a project with something that is "maybe it works and looks good here, but I have no idea since I'm practically blind".

It's totally fair to not want to be the first/only engine with support for something, even if that is a little disappointing. I'm just concerned that someone will have to take the plunge with support, and given features like mirrors, I had hoped that Mark V might finally do it. 

the latest version of gl mark v runs really slow on ad_magna, while it ran fine on previous version that i had (mid december). dx9 version of the latest build runs it fine. what fps killing features did i miss previous month? 

Just checked, the DP dev build render lit water:
https://icculus.org/twilight/darkplaces/download.html

Add "-splitturb" to the tyrutils-ericw qbsp command line to get it. 

@pulsar - I guess I'll be double-checking the Open GL build come spring time to see if I did something that inadvertently caused a performance drop in Open GL. 

Lit water is one of those things that seems like a great idea until you go poking at all the edge cases.

Yes, I implemented it, saw what it looked like, and got rid of it.

I'm willing to add it to my DirectFitz thingy but please be aware of the following.

An engine can 100% reliably detect if a map has lit water.

An engine cannot 100% reliably detect if a map has not.

That's because a surface not having a lightmap doesn't mean that the surface isn't lit in Quake. It means that it's in total darkness. This is the kind of "let's save maybe 200 bytes per map" thing that matters when you're trying to run on an 8mb MS DOS machine but that causes untold pain and suffering later.

So a map with no lightmaps on water can mean one of two things: either the map doesn't have lit water (draw it fullbright) or the map does have lit water but the water is in total darkness (draw it with black lightmaps).

Do you light lava? Slime?

Do you add a warp effect to lightmaps? The lightmaps are a combination of (1) still, and (2) darkening the original texture, so the warp effect on the original texture is lessened.

What about translucent water? Darkening the water will make it appear more translucent. Maybe we should decide that because light goes through translucent water it doesn't get lit.

Should a map with unlit water still have dynamic lights added to it's water surfaces? And if so, is it OK that this would make the light seem brighter than on surrounding solid surfaces?

--------------

These are probably questions that people can't answer until they see it and start exploring around it. Like I said, I'm willing to add it to my D3D9 FitzQuake port if anyone wants it that badly, but don't expect it to be a 100% robust implementation at present. 

I'm not a mapper and am crap at and with tools, so I quickly added lit water to something else I'm working on, just so you can see what it actually looks like.

http://www.quaketastic.com/files/screen_shots/LITWater/e1m2_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e1m5_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e1m6_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e2m5_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e4m6_litwater.jpg 

Mankrip said maps like e1m4 don't compile with lit water. This was months ago, maybe that changed.

Until someone steps forward proving any of this stuff works and is polished ... I'm not sold.

I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler.

Man up?

Maybe find the courage to actually use the compiler option?

Maybe find the courage to load the map in DarkPlaces or existing engine that supports it? 

http://www.quaketastic.com/files/screen_shots/LITWater/e1m4_litwater.jpg

This, of course, is not compiled by any light tool. 

Do you light lava? Slime?

Should be up to the mapper.

Do you add a warp effect to lightmaps?

I wouldn't, but it depends on how you perceive the warping. Does it only represent horizontal movement of the substance, or does it also imitate vertical waves to a certain degree? Distorting the lightmap can help with the latter, I suppose.

Maybe we should decide that because light goes through translucent water it doesn't get lit.

Then it will glow on its own. 

So some of the HD backs from here: http://quakeone.com/forums/quake-mod-releases/works-progress/11588-hd-textures-sp-maps.html

fail with Only type 2 and 10 targas are supported message. I get thrown back to windows until I find the files and delete/rename.

Of course I had to extract them from the pk3s but even re-extracting doesn't help. Example is +1wall58.tga from arcanum HD textures. 

I'll look at having tga files that aren't type 2 or type 10 just do console prints instead of errors in the future (next updates likely in the spring).

Erroring out to windows seems like overkill.

Thanks for point this out. 

I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water. And yes, the turbs were split.

Man Up?
It wasn't/isn't an issue of "manning up", at least not from my perspective. I'm fine with turning on a compiler flag. I just like to be able to see the results.
Imagine compiling lighting for a map in general and never ever looking at it. Doesn't that seem like a daft idea? Perhaps you got the values all wrong, everything is too dark or too bright. But because you never look and see what the results are, you'll never know and your map will suck.

untold pain and suffering
Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case?

The other way to handle that that I can think of right now would be to change the result based on whether there is ANY water with light data or not. If there is some, you could pretty safely assume that all water is supposed to be "lit", and so water surfaces without light data could be rendered black. If there is no light data for any water surface, then you could assume that it is not supposed to be lit. There may be a few edge cases there, but that would, I imagine, cover support for correct water rendering in 99% of maps, as well as allow for it in the rare pre-existing "lit water" map and all future ones.

Also, I'd be interested in finding out why some maps refuse to compile with lit water? I've never had any kind of lighting setup outright refuse to compile on me. 

@Pritchard try this map in DP: https://www.dropbox.com/s/p0ixun0h0ajr4zy/lightstest1.zip?dl=1

Here is what it looks like for me:
http://i.imgur.com/9rWWeR6.jpg