greebo

I can make renderer work a priority after the next release. Initially I wanted to work on that back in April (already sketched out a few issues for myself), but then got completely side-tracked by the VCS, Merging and Texture Tool projects. Overall the DR renderer is not a priority for both DR developers and mappers, with authors usually relying on the engine drawing things correctly. That's why we could get away with that DR renderer we have for such a long time in the first place. But on the other hand I still think that it'd be worthwile for DR to come up with a better renderer, even something that supports shadow calculations.

It's using the same frustum, if I'm not mistaken. In radiantcore/entity/light/Renderables.cpp => RenderLightProjection::render() you can see it referencing the same Frustum object to calculate the points from the frustum planes.

I'd lean towards the view that the TDM code is the leading one, DR has to follow where it can. It has been years since I've touched the light projection code, but it's all in radiantcore/entity/light/Light.cpp, look at Light::updateProjection(). Not sure if this is related to the phenomenon at hand.

It's all in the .darkradiant file, it contains layers, groups, selection sets, map timing, etc.

Oh man, I so saw this coming. The inexplicable texture offset can be explained by the rotation being pivoted in the center of the face. Look at the texture tool what it is doing. It rotates around the same spot now, in previous releases it was jumping all over the place, making alignment of rotated faces really tedious. You have to add an offset to the texture matrix to keep the texture at the spot while rotating and scaling. Thing is, the shift values in the surface inspector are faked all over. Don't pay attention to the shift values in the inspector, they are not telling you anything. You can use the buttons to shift the texture around by some pixels, that's working, but ignore the actual numbers.

It came along with all the changes I did in the textool branch (initially introduced Sept 16th), which were merged a few days ago, that's why nobody noticed up till now. It's fixed in source now.

I can confirm this behaviour. Please push this to the tracker, I'll look into it.

Reproduction steps? I can duplicate and rotate brushes fine on my end. Have you tried a clean checkout and recompile?

Simply put, yes. The "master" branch is moving forward as development progresses. You could checkout a specific revision from Git history and compile that, but I don't see much benefit in doing so for regular users. Apart from building directly from source, you can also use the .deb packages uploaded to @OrbWeaver's private repository, assuming that it is still hosting a recent package.

It's all about overall compilation duration for me. And yes, it is indeed a bit self-centered, since I want to use my time effectively when working on DR. I don't want to cut down my own free time just because low-end machines might get into trouble when building from source. Or do you? On a more general note, I don't explicitly force the Visual C++ compiler to do all builds in parallel, I just enable it by setting it the flags and defining the dependencies. I shift the responsibility to not overload the machine to VC++, which I think is respecting the amount of cores and memory, or is it not?

The compilation guide refers to the master branch, since the command git clone git://github.com/codereader/DarkRadiant.git will check out master. I wasn't aware that you're on Linux, because the snapshot builds above won't apply to you, it's for Windows x64 only. You'll have to build from source to test anything in between releases.

It's more like an all-or-nothing thing, you can't really cherry-pick a fix to a specific issue*. By checking out the source code that includes the fix to #5711, you'll also get all the fixes and changes that have been made in between the release 2.13.0 and the fix to #5711. I'd recommend taking a snapshot build that has been compiled from the recent "master", this should be good enough for your testing purposes. While there are no guarantees made, the code in the master branch is usually production-ready and can be used for actual mapping work. If I'm working on something that completely breaks features, I'll do that in a feature/dev branch, like the "textool" branch. *) Coders will correctly point out that this is an incorrect statement, one can probably pick and stitch together certain code changes to get something like "2.13.0 + this fix", but this is more work than it's worth. Just use the latest master.

Yes. One has to be logged into Github to see the download links, but there's a portable package for each pushed set of changes. E.g. https://github.com/codereader/DarkRadiant/actions/runs/1218642341

It's not the wrong area, this forum is fine for this, I'd say. In source means in the DR source code, it's been committed to Git. The next release will have the fix included, and if this is too long too wait, there are snapshot builds available on Github too.

Seems you are talking about this one: https://bugs.thedarkmod.com/view.php?id=5702 It's already fixed in source.

Yes, tracking all the things you work on into online forms is a tedious task that nobody likes, if not outright hates, myself included. Feels like needless bureaucracy invented by control freaks, and as such it feels like my natural enemy... but the only thing more tedious is to skim through dozens or hundreds of git commit messages to gather everything that's been changed in between releases, that's why I do it. And it's admittedly a nice feeling when you get to scratch something off a list when you're done.

2.13 was released in August, so I think yes.

Seeing that nobody actually changed their status in the past 48 hours, it might as well be broken - I haven't tested it myself to be honest

This just seemed to be deactivated. Not sure if it's a good feature, but there you go ==>

I've confirmed two of them right away, feel free to have a go at them! Not so sure about the Ctrl+S one - I can confirm that this is not intended behaviour, but I'm not sure if there's an easy non-hacky fix for that.

I've disabled the ranks feature for the moment being. If more people disapprove I'll consider re-enabling it again, I don't have a strong opinion on that one.

That's already fixed, at least I'd like to believe that: https://bugs.thedarkmod.com/view.php?id=5706 But I appreciate your readiness to look into it, helping hands are always welcome.

That's what effectively the solution and its configuration represents. It defines what projects should be built, like shown in the screenie above. DR doesn't do this, but one can define more configurations than just "Debug" and "Release", and specify which projects should be built and which should be skipped. IIRC, the TDM solution is using Configurations, to skip the compilation of the MayaImport DLL by default (which needs the SDK installed to compile and link successfully). It's a bit like specifying all these ./configure switches --enable-darkmod-plugins, just not as freely combinable.

Yeah, I've seen a few of those mega-solutions, they are rarely nice to handle. They also tend to cause problems with plugins like ReSharper, which severly slow down your VS installation. I can set the DarkRadiant (UI) project to rely on the DarkRadiantCore project, but I deliberately chose not to do that since I want the builds to work in parallel - and technically it wouldn't be true, the UI project really doesn't need the core project to compile and link. Setting the dependency would make the solution wait for the largest core project to have finished before it starts building the second-largest project - waste of time. I always hit Ctrl-Shift-B to build the solution, and I figured everybody would do the same - but I might be wrong on that assumption!