http://kneedeepinthedoomed.files.wordpress.com/2012/01/spdemo3_9.jpg 

200 mb of textures for a map roughly sounds like the q1 mega texture space requirements. I'd definitely like that. 

It's an interesting idea but not something I'd be keen to do in a production engine. Not with OpenGL anyway.

OpenGL is basically shit for updating dynamic resources. glTexSubImage is OK provided you invoke the correct eldritch incantations, but anything built on the GL_ARB_vertex_buffer_object and GL_ARB_pixel_buffer_object extensions is pure and total rubbish. Vague usage flags, mysterious crap happens behind the scenes, the driver does what it wants to anyway irrespective of what you do or don't specify, you get arbitrary fallbacks to software emulation and in the end it would have been faster if you'd just used system memory instead. (They're OK for purely static data though.)

Essential reading: http://www.stevestreeting.com/2007/03/16/glmapbuffer-how-i-mock-thee/ (one of the Unity people also has a "GL_ARB_vertedx_buffer_object is stupid" post but I can't access it from this PC at the moment - try Google). 

 

is to actually lit the places where it matters - ie where player will have to go or will have to look at, instead of relying on a dim ambient that only works with high gamma settings.
Doesn't help that some of your textures are very dark, like peaking at 40 and cutting off at 70 (out 0-255 obviously) and you can only go down from those values since no overbrights.

Btw my monitor gamma is brighter than SRGB (I can distinguish the lowest grades, even 1-2-3 depending on the view angle http://www.lagom.nl/lcd-test/black.php) and I found some places too dark as well. 

That this is just not gonna work. I run my own monitor fairly dark (and I smoke so it tends to pick up a lot of gunge over time) but I could still see everything OK.

Which means that one's own individual experience means absolute squat in terms of how the maps are lit.

And: "no overbrights"? I don't think so. In fact the engine enforces overbrighting always on. 

I blame TFT screens! 

I had Quake brightness slider half way up and it was WAAAYYY too bright on e2m1rq. Put it back to the default (lowest) setting and the map seemed OK to me.

The person who said the map was too dark:-

1 - what is your GPU? (U never know)

2 - what is the brightness/contrast setting on your monitor?

3 - what was your brightness setting in the engine? 

It was you! Sorry mate, I forgot who had made the post. 

here goes:

1 - AMD Radeon HD 6970M - 1024 MB.

2 - Optimal, I'd say, even though the iMac screen is a bit too reflective for my taste...so I tend to keep it a lil' bit higher than I'd do on a normal monitor...

3 -Top. 

Nice rig btw :)

Is it a Mac though? I mean OS, engine etc... 

You don't understand, you need to properly light the map with contrast lights so it looks fine regardless of the gamma in the areas that are important for the progress (not secrets obviously) and use functional lighting to lead the player. (Unless you want to pull Doom3\Amnesia)

There are no overbrights on external textures, they always look darker http://i.imgur.com/722XZ.jpg 

an interesting point. Er... MH? 

What engine is that? 

Mac Port of the engine. 

is by far not as dark as e3m1rq, although it's missing overbright lighting, too. 

Lighting in fitzquake should not care whether it's an external texture or not (and i assume RMQ hasn't changed this) -- do you have the "idgamma" patch installed? That would cause brightness on 8-bit textures to be different. 

don't forget that you can use gl_max_size and gl_picmip to reduce the texture sizes and memory needs...

(gl_max_size will reduce only the largest textures, gl_picmip will reduce all textures by the same amount.) 

 

Sleepwalkr: so you see the same issue as shown in the screenshot in post #279?

Sleepwalkr or Ghd Fladjern Tilbud: does the problem in the screenshot go away if you set gl_overbright to 0? If yes, then it sounds like you're right and the overbright doesn't work on external textures. (again, this assumes RMQ behavior for that cvar hasn't changed from fitzquake) 

Doesn't exist in RMQ. 

i've noticed there is a difference between external textures and internal bsp ones. i just assumed it was due to the palette subtly changing colours when i palettized the textures. 

@ijed, I went back to the original Q1 and the basic marines are a couple of shots with the single barrel rifle. In RMQ they are one shot, it feels too easy compared to the previous game. (I did nothing to change the skill level)

If you are changing health based on skill level then that is indeed a bad idea. Get the designer to swap AI units around based on skill not fix it with code. Let players understand the AI better by knowing what to expect (damage wise) to kill them. Tweaking numbers based on skill is a recipe for disaster.

@RickyT23, good luck with the textures. Ideally you should start with a proper unified set that is actually designed to work together. At least fix the texture density so they are all consistent. It is the first thing I notice and makes me stop and stare even more. 

okay, guess it's changed enough from fitzquake that i can't really help much :) 

There are overbrights on the external textures; there are overbrights on all textures and the fragment shader code is very explicitly texture * lightmap * 2.0; I wrote it and I know that that is what it does.

Saying "there are no overbrights" makes precisely zero sense because we are talking about an explicit mathematical operation here that does not distinguish in any way, shape or form between whether the texture is external or not.

Convince me that "TEX diffuse, fragment.texcoord[0], texture[0], 2D;" or "(l * 42.5f) / 255.0f" is capable of distinguishing whether a texture is external or not.......

None of this means that I'm saying that problems don't exist - what I'm saying is that if there is a problem - you're barking up the wrong tree. It's coming from somewhere else.