OrbWeaver

I don't think you can have a single sound shader which loops through more than one audio file continuously. You can either have a single audio file which loops (e.g. most ambients), or multiple one-shot audio files which get chosen at random when the shader is triggered (e.g. footsteps).

Great demonstration. I never realised the r_showTris output actually took into account per-light rendering, although it makes sense to do so. So the million-triangle scene might actually be 100k triangles falling within the radius of 10 lights.

High light counts are one possibility. I'd also look at your models carefully to check their polycounts (you can see this info in DR in the Model Selector). I wonder if some of those chain models have high polycounts due to the many small links.

It's been a while since I checked polygon counts in actual missions, but to me the second one looks fine but the first one is huge. That's almost a million triangles in one scene. You'd need r_showTris=2 (or 3) to see exactly where the triangles are coming from though. With a number that high, I wonder if you have a reflective surface (e.g. water) which requires the whole scene to be rendered again just to produce the mirror effect.

What Peter said. Some of those portals are clearly useful because they are turning red (so occluding some geometry), and maybe some of the tall thin ones around the edge are useful to turn the open space into a sort of square donut shape where opposite corners don't necessarily need to be rendered. But you still have a huge number of portals which appear to do little or nothing. For example the large horizontal portals hovering in mostly empty space don't seem to add much value, since they will probably never close and don't contain anything to hide even if they did close.

The question is: do you see an actual performance difference in terms of FPS with/without those portals?

It would be great to have TDM in some Linux repositories (DarkRadiant is already in Debian/Ubuntu), but this would require some changes to how the game handles its data files. Linux distributions would expect a binary /usr/bin/darkmod, data files in /usr/share/darkmod/*, and writable files like save games and config settings in a user's home directory under ~/.config/darkmod or ~/.local/share/darkmod. This is a significant change from the current behaviour of writing all data files into a single game directory (which would break completely if the game is installed to a read-only system-wide location).

I haven't been keeping up with the normal map compression changes, but I am confused about the current correct way to produce a DDS normal map. Exporting from GIMP, both DXT1 and DXT5 work fine, but have the blocky artifacts I associate with DXT-compressed normal maps. "RXGB" produces a normal map which is clearly missing one dimension, so I guess the DXT5 swizzling has been disabled. From the link @nbohr1more posted it seems like "BC5 / ATI2 (3dc)" (which exists in the GIMP plugin) ought to be equivalent to RGTC, but this only gave me garbage results. I don't know if this is the wrong format to choose or if it is a limitation of the GIMP plugin itself.

I've hopefully fixed #5641 (Non power of 2 textures show up black) and added it to the Roadmap for 2.13.0.

What is your source for this claim? I have never heard of any polygon limit in this engine (other than the soft limitations provided by the performance of any given GPU), and 1600 polygons is a tiny number compared to the hundreds of thousands of polygons which are on screen in a typical TDM scene. Are you perhaps confusing some suggested guideline (e.g. "Typical NPC models should have an average of X polygons") with an actual engine limit (which does not exist AFAIK)? By way of comparison, as I recall the original Thief 1 had an on-screen polygon limit of 1000 before rendering artifacts would appear. If some source is claiming that modern TDM can only manage 60% more polygons than a 1998 game which used a software renderer, that source is woefully inaccurate and should be ignored.

I'd be astonished if Microsoft Store and Epic Games don't have similar requirements to Steam with regard to licensing and a legal IP owner.

That's only a problem if you have some deep-seated hatred of Microsoft. It has nothing to do with software licensing, which remains open-source regardless of which hosting site you use. Steam is a completely different ball game. They won't even allow you on Steam unless you change your licensing model in accordance with their wishes, and create a legal entity to own and manage the game's IP.

Mappers do have a choice, but that choice is made via the forceHighQuality keyword. The engine has never used the image format on disk to make per-image compression decisions. The original engine expects all textures to exist on disk in TGA format, which it then decides to compress or not compress according to the image_useCompression option. If compression is enabled, it can optionally look for a precompressed DDS file on disk, but this is just a performance optimisation — if the precompressed image isn't there, or the image_usePrecompressedTextures option is disabled, the engine will compress the TGA image at runtime. This is why there are separate dds and textures trees with a parallel layout. The dds tree is just a cache of the textures tree, storing precompressed images which the engine can load faster than compressing at runtime. The way we are using the engine — supplying only DDS files for many textures — was not intended or anticipated by the original developers, but it does happen to work even in the closed-sourcd Doom 3. Now that we have the source code we could improve this behaviour to make it clearer and more flexible. For example, we could ditch the separate dds and textures trees, and have both DDS and TGA files in a single tree, with the engine loading whichever format happens to be used for each image. It could then be smarter about enabling compression based on the source format, rather than assuming both compressed and uncompressed versions are available and choosing between them based on game options.

I don't think there's any bug here. DXT is a cheap and cheerful texture compression algorithm that works OK for most images if you don't look too closely, but it doesn't handle smooth gradients very well. If you want a large and smooth background image filling the whole screen, you need to disable DXT compression. Setting image_useCompression to 0 will work for you (although it will disable compression for all images, so might increase GPU memory usage), but it won't help other users if you are using this image as part of a released mission. If you are planning to release this image and you want it to look good for everybody, you probably need the forceHighQuality material keyword.

This actually came up in a earlier discussion about Greebo's new favourites browser. Since the favourites browser can contain things other than textures (although I don't know if this is active in the released builds) there is an open question about how things like models could actually be inserted from the favourites list rather than the right-click menu. I actually like the idea of drag-and-drop asset insertion, although it would probably require some fiddly coding under the hood since DR's selection system is somewhat complicated. Even better would be if models could be shown on a 2D grid with preview thumbnails, rather than a tree with only a single preview at a time, but I have no idea if wxWidgets even offers support for a widget like this (or if it would have to be implemented from scratch as an OpenGL scene). That ought to be possible, certainly. Provided the wxWidgets style options that Greebo mentioned work correctly, there is no reason why this couldn't be initialised from the config file rather than hard-coded or default values.

I definitely wouldn't vote for a custom implementation of the notebook control, but there are a couple of other options: Only use icons for the tabs, at all times. This would require very clear and obvious icons (which work in both light and dark themes), and still might be less useable for new users who don't know what each icon means. A hack whereby we dynamically set the style to show or hide text, based on the current overall size of the dialog. This wouldn't be ideal because we'd have to basically guess the size threshold for hiding the text, and this might not be the same on all platforms with various different fonts.

Tears of St Lucia — no helmeted or lamp-carrying guards as far as I recall, easy to blackjack most of them. Working out how to safely get into the church can be something of a puzzle though, which you may or may not enjoy. In the North (William Steele 1) — well-designed mansion interior, I don't remember any helmets or lamps, although there are quite a lot of guards in total.

This sounds like something a Python script ought to be able to do. Either it could create a series of individual patches with matching texture coordinates, or it could displace a single large patch in a stair-stepped shape.

I suppose you can say they are in the same world, but not necessarily the same series — in the same way that Fantastic Beasts is part of the Harry Potter universe but not part of the main Harry Potter storyline.

I guess you're misreading the Wiki description for Braeden Church, which says: This means "Braeden Church is not part of any series". It is not referring to In The North, which certainly is part of the William Steele series and is listed in the downloader along with all of the other WS missions.

Aren't all the William Steele missions prefixed with "WS1:", "WS2:" etc? Try scrolling down to the missions which start with W.

If a model is out of view it will be culled anyway. There's no benefit in trying to use portals to do "manual view-frustum culling" when the engine already has automatic view-frustum culling to do the same job. If the idea with that screenshot is to make a huge horizontal portal flush with the top of the selected box, I struggle to see any viewpoint from which such a portal would provide any culling whatsoever. But perhaps testing with r_showPortals and r_showTris would prove me wrong.

You need to consider the sightlines and work out exactly what is going to be culled by each portal you propose to add. Will there be any vantage points from which your proposed portals will actually close, or at least substantially reduce what is seen through them? If not, then your portals are worthless. Portals are not go-faster stripes. You can't just dump them haphazardly into your map and expect to see performance improvements just because "I have lots of portals now". They need to serve a specific, technical purpose in restricting visible geometry.

I haven't seen any suggestions that NPCs specifically will have their own colour. It wouldn't serve any purpose — everyone can tell the difference between an NPC and a junk object. The only suggestions for colour coding have been loot vs other objects, and so far this has been nothing more than discussion, with no actual implementation as far as I know. Of course all the colours will be customisable, but it might take the form of cvars rather than explicit menu items.

Interesting to learn that TAA applies a jitter. Reading about TAA and its focus on motion I could never understand why TAA looks so good in Elder Scrolls Online even when I wasn't moving, but I guessed it must be doing some kind of "simulated motion" when the player is standing still. At work I implemented a basic jitter-based antialiasing for our spline rendering years ago (four samples for every frame in a fixed pattern), but never really thought of it as "TAA" — perhaps we should advertise it as such. Personally I wouldn't choose to use FXAA but I have no objection to it being available for people with lower-end video cards, if someone wants to implement it.