Nothing different from everyone up here to say, except maybe that I found some badly aligned textures here and there...

Got to the green fog place, made me wanna puke. Had to quit.
You sure this is a good idea?

Sleepwalkr: I'll try out the port over the weekend. I'll keep you posted. 

It might be to do with mostly playing in quite a bright room, but I've occasionally just given up and played with r_fullbright 1 and generally had a better time doing so. I'm sure this makes me a terrible human being, but maybe a few fewer shadows would help? 

First of all - thanks for playing my map! :)

And the list of things you mention is a good list, I will be looking at some of the things you mentioned - some of the textures have been improved already (by Inkub0), and there are some other issues you mentioned which I plan to rectify (like the scale for example - I also think I could improve this). Unifying the crates a little more isn't a bad idea ither.

So overall, thanks for your feedsback!

@Spirit

Thanks also for your feedback, MOAR BASS!!!! 

mwh - which levels?

poison fog - there seems to be a split on this, some like it, some don't.

Blaster - will revise it. Q2 didn't have this though, it just had a warm up for the HB and a warm down for the CG. The idea here is that the weapon overheats, firing more powerfully, but needs to cool down afterwards as well. So not spamming with it is less effective, but spamming too much can leave you without ammo and/or unable to fire. 

I didn't realize the lasergun was heating up and inceasing damage (+cooldown time), either. It could be made clearer by two or three skin changes (glowing exhaust slots: not, orange, red), and a distinct wshhhh steam sound.

But like I said earlier, I think the weapon is kind of unnecessary and only makes the game even harder to balance. If you need to bump the monsters' health to make the weapons work, you're doing something wrong (wasn't it the same with the SSG before?).
In my view, it would be better if you allowed all standard weapons, and additionally, since the player is supposed to be an Enforcer, gave him a sort of laser DBS, or laser Riot Controller. Something that works similar to the standard enforcer attack; two rays + wait time. They would have to be more powerful (and costly) than regular laser shots of course, DBS/RC style. This way it could serve as a special weapon for certain situations, like the Cauterizer, and bound to this episode, but would not imbalance the regular gameplay and not require too much additional doctoring around.

As for setting a bigger heapsize - it was my understanding that the memory heap is only important for loading stuff, the map, precaches etc, but has no impact on the actual game performance. The bigger a bsp size gets, the bigger the heap requirements are (map data, visdata, lightmaps, textures etc). A heapsize of 64000 is usually enough even for the largest maps (within the 'old new' limits). Only now that maps can grow to 22MB more startup memory is required.

sock: HF in E3M1RQ (performance-wise). ;) 

+1 for a proper DBS animation. Ideally Something akin to Doom2, or at least some visible cocking. Or maybe an animation where the gun is lowered and a sound is played that suggests two new shells are being put in the barrels which is not visible to the player.

The animation of the new shotgun looks a bit odd to me, because the cocking is so fast. It seems the model was adjusted to the sound and not the other way around. It should be a tad slower (surely the firing delay allows for that?). And the hand could use some tan.

I don't want to make it more complicated for you, but I think the DBS too nerfed now. At least I didn't use it as often as I would have in this demo (when I had the choice between regular SG and DBS), though maybe it's only because the E3 maps focus so much on the laser rifle... 

...it's dark as fuck.

Have to play with all lights turned off, secondary monitor off and brightness settings tops.

Atmospheric? 

Poison Fog made me feel a bit sick too. I realise this was the intention, but I'm not sure why you'd want your playerbase to experience actual nausea. Anyway, I think you could fix it thus:

Reduce the swaying very slightly. Most of all though, change the way the section has to be played. Give the player an enviro suit at the top of the elevator which will run out when he's in the poison area, then have one or two more suits dotted around down there that the player needs to find if he wants to see & shoot correctly. 

So if I understand it correctly, if I keep firing the blaster, it gets more powerful, but eventually stops working? Because that never happened to me or I haven't noticed it. If the blaster has some kind of operating temperature, e.g. 0 to 120� C, it would only need to cool down if it went past 120� C during usage, and logically, it should have stopped working when it reached that peak. So in cases where I only use short bursts, it always works without any delay and needs less time to heat up again?

The Q2 HP didn't have that behavior, no.

The balance is very problematic because if you increase monster health, you'll have to change all the other weapons too. Otherwise, maps without the blaster will be much harder to play. 

That was problematic for me, too. I had to crank up the monitor brightness and in game brightness to be able to see something, but that made the entities washed out. Maybe it's related to the gamma curve, which is different on Mac systems. What do Windows users say? 

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.