OrbWeaver

If there is to be a new option, I would suggest making it a toggle button in the Surface Inspector similar to the one I recently added for aspect ratio-preserving Fit Texture. There is plenty of room for another such button perhaps next to the existing Natural button.

Resizing should be parallelisable but note that there are speed/quality tradeoffs to be made by choosing an appropriate filtering algorithm. I suspect most GL drivers just do a simple box blur, which is OK but not necessarily the highest quality way of downscaling mipmaps. GIMP offers a whole load of filtering options: Lanczos, Mitchell, Bicubic etc.

If you add a menu option to disable/enable the frob highlight, someone else will ask why there isn't a menu option to control the colour. Then somebody else will demand a menu option to change the frob distance. Then another option to control the fade in/out time of the highlight. And on and on it goes... Dumping everything into the menu is a UI design cop-out. It's basically saying "We can't get this feature to work well, so we'll just get you to figure out how it should work". In my view there are already too many menu options. I have no idea why I would choose "16/32/64 bit colour" or what this means in terms of appearance, although I'm sure it's useful for somebody, somewhere. If the frob highlight is too bright, or appearing at too great a distance, these problems should be fixed. And if some people still hate it after that, they can turn it off using the cvar. It is factually false to claim that there is "no way to turn it off" when there is an easily-accessible command that allows you to do exactly that.

How many missions are actually using custom shader-based processing of core mod normal maps? Could those missions packages be updated in the same way as the core mod: generate output DDS files for all the included image programs, then include these in the mission pack?

I'm not fully up to speed on the precise division of responsibilities between CommandManager and EventManager, but as I understand it "Commands" are things which can be executed from the console (so you can actually type in "GameConnectionBackSyncCamera" and it will work), whereas "Events" are things which are hooked into the UI (but events are usually built on top of commands). If you removed the last three lines I think you would only have the command, which means you could back-sync the camera by typing in the console but the clickable button would not work. It's possible (but I haven't tested) that everything in this case could be done through the event manager without needing to create a command, since it's likely nobody would actually want to sync the camera by typing in the console.

As far as I know, random only applies to sound shaders which are triggered repeatedly. I've never heard of s_looping do anything other than loop a single sound forever; if it has gained the capability to also switch between random sounds, that is news to me.

Possibly related, I'm seeing this in the console on Linux: XMLRegistry: Failed to save path /darkradiant/user/ui/colourschemes More seriously, I'm getting a segfault on startup which so far only affects the package build, which makes it fun to debug. Unfortunately I only noticed this after uploading the build to Launchpad, which I then had to delete, leaving the 2.12 build missing as well (since it seems Launchpad only stores the latest release for each Ubuntu series). EDIT: The failure to save colourschemes message looks like a red herring. I can change the colour scheme and the result is saved to the next session. Setting the brush colour does save, but for some reason brushes appear black in the next session until you open the Colour Schemes dialog, at which point they suddenly change to the correct colour. EDIT2: Hopefully the segfault is fixed now. It seems that I did not have libgit2-dev installed, and for reason this caused the main application to crash rather than silently drop Git features. This still needs to be investigated since Git is optional, but at least I should be able to get a working package out.

Agreed. There is no need to have every possible rendering option exposed via the GUI, just as we don't expose things like image_useNormalCompression or r_skipBump via the GUI. If advanced users want to configure these options, they can do so via the console.

I believe if you use the latest dev build, the map compiler will actually emit a warning for leaked visportals and write a pointfile which you can then load in DR. I don't know how much this helps with the situation where you already know where the missing portals are, but you just want to find out why they are leaking.

Definitely not trivial to implement (or even define), because you're not actually rotating anything, you're shearing the brush and changing the face shape. A brush face can be any straight-sided convex polygon, so which edge would the texture need to follow? It may seem obvious from the picture but it's definitely not obvious to a computer. If you're trying to make an angled wooden beam, you might consider making the beam as an upright brush, converting it to func_static then rotating it like a model (and burying it in surrounding geometry). Being snapped to the grid would no longer be important in this case.

Yes, if a sound shader is looping then it will only ever loop on one sound file. Otherwise how would it know when to switch from one to another, and how would it do so without a jarring interruption of the sound? In theory it would be possible to implement fading between multiple sounds in a single looping shader, but it would require additional work on the engine and extra fields in the shader to control things like how many seconds it should play each file for, and how often it should switch to another one. But I'm not sure this would be a very important feature, because the expectation is that if you want a load of random things in a single looping ambient, you just bake them in to the looping sound file using your audio editor. I very much doubt you will get any performance benefit from combining multiple location speakers into a single ambient. Playing sounds isn't the performance-affecting element in a game engine.

I checked out your branch. Everything built fine on Linux, and the basic functionality is good — seamlessly launching the game and going straight into the correct map is very convenient. There's a sizing issue with the dialog: widgets are cut off and the bottom buttons are not visible at all. The SetSizerAndFit() method is convenient for setting a window sizer and automatically setting the minimum size, otherwise you might need to explicitly set the minimum size based on contents as the Light Inspector does: SetMinSize(contents->GetEffectiveMinSize()); Probably I should find a way to refactor this into the TransientWindow base class, since we have a lot of problems with dialogs being shrinkable to nothing regardless of contents. Note that your branch is based on master from about a month ago; I recommend rebasing on the latest master (either mine or Greebo's) to get the latest changes and minimise possible merge issues. I will be interested to see how the hot reload functionality interacts with the 2.13.0 light brightness slider (hopefully it does not collapse under a flurry of tiny updates). Overall this is a massive improvement from the menu-based version, especially the autolaunch and dmap. I can definitely see myself using this as the main mechanism for testing map changes, rather than manually running the game from a terminal. Good job.

Decompressing and recompressing would be undesirable, it's a needless quality loss which will be permanently embedded in the mod resources once it's done and the uncompressed originals are thrown away. I believe the proper way to do this would be to dump the compressed image after the engine has loaded the shader and done the necessary processing, i.e. using the equivalent of image_writePrecompressedTextures (which may or may not need updating to support RGTC normals). This way you're only getting the compression artifacts once, after the final image has been generated, rather than generational loss from two sequential compression steps. Of course this only helps with core resources — if mappers are making their own shader stages that perform customised image operations on mod-distributed normal maps, there is no way to handle that except either continue to provide uncompressed source images or rely on decompression/recompression.

My first task will be to make sure things are updated on the Linux side for the 2.13 release, but I can certainly have a look at your changes after that. If that's the only menu item (and there are no plans to add any more), perhaps it should be moved to the Map menu? You might want to look at the current directory of icons to see if there is anything suitable as a placeholder. Some variant of the "refresh" circular arrows might work, although it might also be confused with a simple connection refresh operation rather than respawning the whole game. There should definitely be explanatory tooltips in the GUI, since most people don't read manuals and it won't necessarily be obvious what a pure icon button does. I'll update the online manual itself once the functionality is finalised and any GUI tweaks are finished, so that screenshots can be taken.

Well I'm not completely averse to using display lists if they would help. In fact I think we might already be using them for static models, which would explain why I never see static model geometry rendering appear in profiles. The advantage of display lists is that they are very easy to use — just "wrap" your drawing commands in a begin/end list command, and the whole thing is stored for later use. We might not see a huge benefit from using one display list per brush winding though, because there would be lots of lists with only a handful of vertices. More useful would be wrapping the entire set of geometry for a single shader in a list, but that requires more complicated management. I didn't notice that it was multiple times per frame, not just once per frame. That would explain why calculating light AABBs takes up nearly 30% of my profile time. No problem in theory, that's a very simple change. But again, it's not appearing in the profile right now so I doubt it will make a noticeable difference. Perhaps once other things are optimised the structure traversal will start appearing as a larger performance cost.

I think I did experiment with display lists at one point. They can be fast, but these days they are considered part of "legacy" OpenGL and not really recommended, so I probably wouldn't choose to switch to them unless the performance advantage was spectacular. This is my latest profile from perf (I think it's missing most of the time spent in OpenGL drivers, hence only 56% time in total appears in the profile). What this seems to be saying is that repeatedly calculating light AABBs is a big waste of time, and we could probably achieve a noticeable speedup by caching them in the light object rather than recalculating them on every frame.

Right, that matches what I remember from my last adventure with perf. A couple of percent here or there by bit-twiddling with data structures or implementing custom vector allocators, vs 40% in the backend render or 36% traversing the scenegraph. The OpenGL time can't be reduced to 0 of course, but I find it hard to believe we would gain absolutely nothing from using VBOs to store brush faces and model geometry, and re-use these if possible rather than submitting everything completely from scratch on every frame using ancient and slow glBegin/glEnd calls.

I'm happy to do some tests on my Linux machine at some point. I'm not too fussed about compile times unless they are becoming excruciatingly slow, but if there's actually a measurable performance degradation that affects users that is of course more concerning.

Let's not turn this into a long-winded "one true way to use C++" discussion. There is no way in hell we're going to start reverting to C89 idioms like using goto everywhere just because some programmer somewhere said "Exceptions are always bad and you don't need them, OK?". DarkRadiant may be a game editor but it is not itself a game, and we lean towards high-level C++ techniques not gamedev microoptimisations. As Stgatilov observes, Carmack might be a graphics programming wizard but he is no way an expert on C++ techniques (or at least wasn't, when the D3 code was written), and I certainly wouldn't be relying on the idTech 4 coding style as a guide to building a C++ application. However in DR we should still only be using exceptions for signalling actual errors, so if there are cases where exceptions are being thrown repeatedly because of normal parsing issues then we should definitely fix that. This would also help with debugging on Linux because "break on exception" will actually catch real errors instead of hundreds of useless internal exceptions. Aside: I'm actually dabbling with Rust, which I find a very well-designed and pleasant modern language, and Rust has no exceptions at all by design. The approach they use is for functions to return a Result<Type, Err> object which contains both a return value an error flag to indicate success, and the language specifically requires you to handle the error condition otherwise it's a compilation error. Something similar could be achieved in C++ for parsing methods (without the compile-time enforcement of course) instead of using exceptions; personally I would prefer this to using "out parameters" which I find very cumbersome to use. I'd want to see hard profiling data before potentially complexifying the code with multiple data structures and sorting passes. When I've looked at rendering performance, I don't recall ever seeing a significant chunk of time taken up by basic data structure traversal. Most of the time is spent in math operations like applying and calculating texture matrices, and the hopelessly inefficient use of OpenGL (no VBOs for storing brush face vertices, for example).

Every time I see my annoying non-updating OpenGL previews (texture browser and media browser) I wonder if we should just bite the bullet and integrate our own version of wxWidgets, rather than relying on whatever ancient version the distros are shipping. It's not a small task I'm sure, and we would probably need a Git submodule (which we decided against using for Eigen), but if wxWidgets version problems are going to get in the way of future development, maybe it's a price worth paying.

I see Greebo has pulled my latest master branch, so yes I assume the release will include RGTC support.

No problem at all. You can just stick letters on them for now if you want, and I'll do an icon pass once the GUI is finalised. As a general rule, I tend to allow at least 2 GB per compile process (since my machine is particularly memory-sensitive, and actually completely hard-locks with not even mouse pointer movement if it runs out of RAM), so I wouldn't generally use more than 6 compile processes even though I theoretically have 12 logical cores available. If it's one or two things using particularly high amounts of RAM, it might be possible to refactor the code to avoid memory spikes. We've done this in the past at work by using the Pimpl idiom for a particularly memory-heavy class.

I haven't seen a single person mention "being consistent with other 3D software out there" so I'm not sure what that is referring to. Also, I'm not sure why you keep mentioning what other Radiant versions do, since DarkRadiant diverged from the GtkRadiant codebase over 15 years ago, and comparing DR behaviour with other Radiant-derived software has never been part of the development process. Most likely the current behaviour arises simply as a consequence of how the code is written, is not the result of any specific design decision, and has not been changed because nobody has raised it as an issue until now.

DarkRadiant now also supports BC5/RGTC normal maps in lighting preview mode, using the same approach as the game (always reconstruct the B channel in the shader). This in turn means that I can save a bit of GPU memory by uploading uncompressed normal maps in GL_RG8 format just as the game does.

I think UI elements should be considered if the alternative is to require an immediate reload on failure, which is a tedious and frustrating process. Minimaps, quest markers... these might make the game easier but there is nothing that requires a reload if you don't have them. If you get lost, you might have to spend some time wandering around or checking your main map, but you don't irreversibly lose any resources. Furthermore, these UI elements give the player information they shouldn't automatically have. If the task is to find a particular piece of loot, it makes the whole thing rather pointless if the exact location is marked on the map or with a hovering quest marker before you even enter the mansion. With thrown objects, it depends on precisely what you are throwing and why. If the only purpose is to bash a bottle against a wall to distract a guard, the aim doesn't matter very much. If, on the other hand, you have to throw a specific object into a particular location (and potentially lose the object if you miss), then having to repeatedly reload after every failure is annoying. In this case, some kind of aiming hint might be advisable.