Maps require a small amount of -heapsize to run but a large amount to load, yes.

But if it loads OK then -heapsize shouldn't affect runtime performance (e3m1rq only needs 16mb of heap to actually run, for example).

Things that can affect runtime performance are many and varied. You own PC's performance, size of the BSP and how much impact all the BSP tracing done by the engine has, sounds, QC, drawing stuff, etc.

The one thing that can make performance suck badly and you do have immediate control over is textures.

If you're using large replacement textures on hardware with only 256 or even 512 mb of video RAM these can kill your performance as the total amount of textures may not fit into video RAM and your driver will be continually having to swap them in and out.

We set the hardware requirements as "in or around similar to Doom 3" so far as the rendering tech is concerned, but that doesn't tell the whole story.

Doom 3 used 256x256 textures (which were compressed on lower spec machines). The Quake community likes to use 512x512 or even 1024x1024 textures.

A full mipmap chain for a single 1024x1024 texture needs just over 5mb of video RAM. Use 40 of those and that's over 200mb. Gone.

If you run at something like 1280x1024 resolution you're using 15mb for your front buffer, your back buffer and your depth buffer.

A 1024x1024 skybox needs 25mb.

You're looking at about 40mb for lightmaps.

There are additional textures created for post-processing effects (like the underwater warp) - these will take about 16mb at that resolution.

All MDLs and brush surfaces go into vertex buffers which take more (the alternative - streaming them from system memory on demand - is worse for this kind of content).

You see where this is going?

So first thing to do is drop back to native textures and if that resolves any performance issues then you've located the cause of your problem.

Second thing to do is ramp back the video mode a little. Drop a notch in resolution. That might help a little. Also drop back AA and AF in your video card's control panel. You may be used to running regular Quake content maxed out, but this is not regular Quake content. This is extremely heavy content. You may be used to running modern games maxed out, but Quake formats (in particular Q1 BSP) are SHIT for hardware accelerated rendering. That's a tradeoff you need to understand and accept that you're working under when you use Quake formats. 

Why would you set the Hardware requirements to "in or around similar to Doom 3" when you're not aiming to make a game that looks as "good" as Doom 3? And if you do want to look like Doom3, why not just use DarkPlaces?

Honestly, looking at RMQ I see very little reason it shouldn't require similar specs to something like FitzQuake. Maybe there's something technical that I just can't comprehend going on, but if it isn't obvious in the visuals then perhaps it's unnecessary or should be scaled down by the development team rather than the players? 

The problem is that the BSP format is not suited for hardware acceleration, and this problem gets overproportionally worse as the maps get larger. 

Yeah, this was previously discussed in the thread, it's missing heat up vfx and similar.

The DBS has had some internal discussion as well.

Removing the blaster and adding a laser DBS sounds kind of 'would sir like an apple, or a pear?'. What's broken there is that the cooldown isn't enough to force you try to fighting like an Enforcer.

So if you play cautiously you'll fire, say, a couple of shots at a time and never waste ammo - but if you go berserk and fire off a lot of shots then you'll do more damage but also become more vulnerable + waste ammo.

The pro player will try and keep it somewhere between the two - doing slightly extra damage and wasting almost no ammo.

A case of getting the balance right. 

Is this only in my maps or in Ricky's as well? 

...with obvious variation in places.

The Gunsmith secret area pops to mind... You can barely see the path to get to the goodies. 

being darker, or at least having more pitch black corners. I'll replay and check. 

The hardware requirements are similar in terms of the GL extensions I use.

The formats and underlying technology are completely different. Doom 3 stresses your hardware in much different ways than this stuff does, and depending on how your hardware responds to this stress you may have a very different experience on both.

DarkPlaces is not an option because a custom BSP format was needed during the course of last year. Q1 BSP imposes various 64k limits which were overflown - vertexes were an early one, which got worked around, clipnodes became a serious problem, and leafs is a fairly recent one.

Using a different BSP format was not an option for various reasons. Formats considered either did absolutely nothing to resolve the problem (Q2, HL), were missing important features (Q3A), were encumbered by licensing restrictions (HL) or required too much upsetting of codebases and changing of the toolchain (all of them). The eventual choice to extend Q1 BSP by using ints instead of shorts in key strategic places meant that mappers could continue using their preferred editors and that minimal changes were needed to both tools and engine code (and - importantly - the very same backend code could be used in the engine for both the new format and the original - there were some small changes in the loader but that was all).

If DarkPlaces implements support for this format then DarkPlaces will become a serious contender.

None of that makes Q1 BSP suitable for hardware rendering. It was designed around the requirements of a software renderer running on a p60 with 8mb of RAM, so it chops surfaces up far too much (and far too small) leading to poor batching and lots of tiny submissions of geometry to the GPU - all things which make hardware rendering suffer. This wasn't resolved in any ID engine until Q3A, which would be easily capable of running this content with much higher performance. 

I'd expect my maps to be darker since I work in bright places..

I think in future I'll light for minimum brightness settings on my machines, it's the only way to make it work properly for everyone.

Point of fact I played the brilliant Moonlight Assault the other day and couldn't believe how bright it was - thats not the level thats broken, but my set up.

BTW Text_fish, yes, what you're describing there is an idea for a trigger_status which would cause status changing effects and have methods for not affecting the player, like being in an envirosuit, partially or fully submerged (fire) and so on. In theory it could instead become an extension of the trigger_hurt's functionality, which would be neater.

What you see in e3m3rq is basically a maphack. 

So then the logical step must be to reduce the map's complexity, use fewer textures, or optimize it in other ways to make it playable on a smooth framerate. As painful as it may be. 

Just checked the texture folder. E2M1RQ has 183 files with a total of 100MB. E3M1RQ has 100 (!) files totalling to 220MB, lots of them being 3MB. Obviously, some optimization in this area is required. 

Sounds like a lot of 1024x1024 RGB textures.

Even pulling them down to 512x512 would help a lot to relieve the hurt. We probably need to talk more about this internally as there are tradeoffs to be made here (one of the options we've been looking at recently is using DXT compression, which would reduce that 220mb to 27.5 mb and also enable much faster texture sampling in the fragment shaders - there are patent issues surrounding that however, which would affect the ability to provide a reasonable fallback for those using free Linux drivers that can't support the required extension).

Lighting

I don't think that there's a perfect solution that will run well for everyone. Everybody's hardware is different, different monitors will have different gamma curves, etc.

The next release of the engine is going to have an r_lightscale cvar that you can use to bring up lighting levels (but without any clamping or washout) which may be all that is needed. 

Sure, but right now I'm lighting from a middle position, if instead I go from one extreme (full black / full bright) and work towards the opposite then it should result in a more balanced range overall.

Starting from black will leave the levels with max brightness being almost whiteout - at least that's the plan.

Maybe not explaining that very well: right now the brightness range is to small between black and white.

Textures; yeah, 1024 isn't actually visible on most monitors just down to pixel real-estate. Granted it might look good if you headbutt a wall - but thats not something you're going to be doing much, compared to say, fighting.

Map size is something we probably won't be decreasing, there's levels in the works that are a little bit bigger than those in this release. I suspect on textures alone we can save a massive amount of overhead. 

We're saying 'Make gigantic maps!' or 'make maps with a huge amount of detail'. The toolkit that we use is really amazing. Just the engine and tools alone open huge possibilities. 

 

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.