Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16449
  • Joined

  • Days Won

    23

greebo last won the day on September 13

greebo had the most liked content!

Reputation

206 Excellent

About greebo

  • Birthday 11/26/1979

Contact Methods

  • Website URL
    https://www.thedarkmod.com
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    conduction band
  • Interests
    Physics, Sports, Guitar, Coding

Recent Profile Visitors

16407 profile views
  1. You can also select the light and switch to Vertex Manipulation mode (hotkey V) to drag the vertices around.
  2. 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.
  3. 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.
  4. 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.
  5. It's all in the .darkradiant file, it contains layers, groups, selection sets, map timing, etc.
  6. 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.
  7. 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.
  8. I can confirm this behaviour. Please push this to the tracker, I'll look into it.
  9. Reproduction steps? I can duplicate and rotate brushes fine on my end. Have you tried a clean checkout and recompile?
  10. 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.
  11. 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?
  12. 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.
  13. 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.
  14. 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
  15. 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.
×
×
  • Create New...