you can find the legacy executables in the included backup folder if you have the GOG version of TG, anyone who would want to use them for whatever crazy reason is free to restore them by copying the files into the game's root folder. also, TFix can install legacy executables which accomplish the same thing, but without having to copy files around manually (and leaves the NewDark part of the install unmodified, so one can run both versions from just one install of the game).
Last edited by voodoo47; 7th Aug 2018 at 13:12.
As opposed to an analog download?
Looking Glass couldn't even be bothered to update the software renderer after the first Thief. You seriously think some fan coder is going to waste time on it?
Anyway, NewDark already has some config options to turn off texture filtering. That's as close to software mode as you're going to get.
Digital copies are sometimes differentiated using those words, yes. Lets not argue about it.
If someone is going to the trouble to update newdark, its a reasonable request for a request thread, so I am request8ng it
I did not know that - thank you, I will give it a look.
In any case, its probably not a huge leap to be requesting such a thing.
Even if it is.... I can ask and hope
I'm sure I am not the only interested party.
I think I would most like to have a few more solid modeling primitives. The most common solid primitives provided by solid modeling programs are (a) box, (b) sphere, (c) cylinder, (d) cone, (e) torus, (f) wedge, and (g) pyramid. We have the box, cylinder, wedge, and cone/pyramid, but no sphere and no torus. Adding those would greatly enhance our ability to model.
No texture filtering with 16-bit lighting looks pretty close to software already. The only major difference is the water which uses a different texture in software.
I know this is wishful thinking and I imagine it can't be raised any further at this point but another increase in cells would be very appreciated. I've become pretty good at minimizing their impact through various methods but 32760 is still quickly reached.
I think that has already been mentioned somewhere with someone (LarryG?) pointing out that the current value is very close to 32768 (don't remember precisely, but a 16bit limit of some sort, I believe), meaning it probably cannot be increased any further without significant effort.
I've hosted your requests in the french forum.
I'd love to see torus shaped brushes as well, but PinkDot explained that brushes need to be convex which is not possible for such a shape. Spheres would presumably be fine. You can actually approximate a sphere quite well using the intersection of three cylinders, but it's a bit of a nuisance at present since it requires a lot of adding and removing of water at intermediate stages.
Torus could be built with a number of convex sections. So, the primitive that we would need would be a 'torus section', representing let's say 22.5 degrees of the arc. Still it would be tricky to get it snapped, so the vertices are aligned. I mean Dromed would have to go out of its ways, to store a pivot of the brush outside of the brush etc...
Also Dromed is very limited in terms of parameters that it takes for the primitives, apart from the bounding box size. Cylinders and cones take number of sides. Torus would need more, I guess.
But a primitive that a lot of people would appreciate, I believe, would be a gothic arch (taking cylinder sides parameter into account). I know "it's possible" to build it with wedges, but it's a nightmare to deal with in even a semi-complex scenarios.
Also - chamfered box. Again - this would require an extra parameter to specify size of the chamfer.
Spheres would be nice, but a hemispheres would be a useful option too. For the domes in buildings, it would be less intrusive - not damaging your interior brushes.
Spheres would require some clever UV mapping algorithm though - probably a couple of options. Remember Dark Engine cannot stretch polygons, so you'd get a lot of seams between the trapezoidal polygons.
Gothic arches are easy enough to make with wedges. In any case, you want your arches to be made out of solid wedges anyway (except for non-90° architecture), that saves a whole lot of cells versus air cylinders.
A vaulted arch is just two arcs. Think of a normal circular arch with the middle chopped out and the left over sides brought together. One of the sketches on this page demonstrates this.
Posting this for reference (cylinders instead of wedges, some advantages and some disadvantages):
https://dromed.whoopdedo.org/dromed/vaulted_arch
I don't know how it affects the cell count compared to wedges, but I've never cared out it.
Yes, I know those techniques for building any arches you want. But while it gives you a sense of being creative and inventive it's just a convoluted way of building things. In general I hate the techniques that involve overlapping brushes or using water brushes as a mid stage to get what you want. Portalizing would be faster too, since fewer overlaps means fewer CSG operations.
I've been building cathedrals with a lot of vaulted ceilings etc.. and got to a point, where moving a brush in time (order) through a list of 2000 brushes was just wasting of my life. So was an attempt to resize built architecture.
Why not just have one brush, that creates a gothic arc and voila - no mess! You save time (your life) you save grey hair on your head, you save brushes for more detailed architecture somewhere else. And if you fancy the techniques of overlapping brushes to get an unusual shape, you can push it even further, having a more sophisticated shape as your base. Everybody wins.
This issues with non-primitives like a Gothic arch are many, but first and foremost is that the directed distance calculations can be quite complex. Does object A hit said Gothic arch or no? The reason those 5 or 6 primitives are the standard set is simply because the math calculations are simple, known, and fast. Better would be for a working set of macros for parametric building of common architectural structures using these standard primitives. Say, a working stairs tool, or a working Gothic arch tool, or one for vaults, or ... . But you get the idea. And those tools could be made outside of the existing engine, with a sequence of command line functions, couldn't they? Or perhaps in Squirrel? Can Squirrel scripts get executed from within DromEd to create geometry? I don't know, but someone must.
I don't think this is an issue. I think during the calculations everything is stored as convex volumes built out of planes and intersections are calculated on a plane to plane basis. Dodecahedrons are pretty irregular shapes anyway yet they're in the original pack.This issues with non-primitives like a Gothic arch are many, but first and foremost is that the directed distance calculations can be quite complex. Does object A hit said Gothic arch or no? The reason those 5 or 6 primitives are the standard set is simply because the math calculations are simple, known, and fast.
Yeah, that would be great - I had a look at this once, but didn't get far. Dromed wasn't really designed for scripted creation. But it would be useful to have a proper API, where you can query the scene and create objects using certain industry standards.Better would be for a working set of macros for parametric building of common architectural structures using these standard primitives. Say, a working stairs tool, or a working Gothic arch tool, or one for vaults, or ... . But you get the idea. And those tools could be made outside of the existing engine, with a sequence of command line functions, couldn't they? Or perhaps in Squirrel? Can Squirrel scripts get executed from within DromEd to create geometry? I don't know, but someone must.
I'd prefer support for Python inside Dromed though, as it's more popular language, relatively easy to learn and has a vast library of modules to use.
In the unreal 99 engine one can save any custom brushes they cut so that you can say, save a window and use it 100 times instead of using the 3 shapes 100 times.
Thats probably beyond dromed though![]()
If you're talking about in-game, then no, there are no BSP primitives in-game. Portalizing converts all brushes into the worldrep, which is raw polygon geometry. A stripped MIS file contains only this geometry, discarding the terrain brushes.
NewDark actually does enhance multibrushes quite a bit. The extended UV mapping mode allows multibrushes to retain texture orientation no matter how/where they're placed, and they can now retain the correct textures when loaded into a different mission.
Just a bit of useless Sly/DromEd trivia...I have never used a multi-brush.
remove poly_edge error
I'd love to have a way to detect the faulty brush or area in the monolog window, through coordinates or maybe a highlight feature. I've had this weird error for a while and it seems it was a rather simple brush which was its source, but I'm not even sure I fixed it for now.
There are two enhancements to the texturing workflow that would help me a lot. First the problem:
Normally in the 3d view, left-clicking selects a brush and a particular face of it. I use this a lot in order to edit texture alignment, and often to set textures by number. I also use this to select a brush without especially caring which particular face is selected. My problem is, when the texture palette is open, left-clicking no longer selects a brush or a face—instead it applies a texture to the face that is clicked. This means I cannot easily select faces to edit their alignment while the texture palette is open. So I end up opening the palette, picking a texture, applying it, closing the palette, select face and align, open the palette again for the next face… I would like to be able to continue to select brushes and faces in the 3d view while the texture palette is open, without completely removing the ability to assign textures easily in the 3d view.
I would very much like the following options, or something to similar effect:
1. An option to change the texture palette's "apply texture" action from a bare left-click to alt+left-click, so that a bare left click continues to simply select brush faces even when the texture palette is open.*
2. A new shortcut, ctrl+left-click, when the texture palette is open, to apply the selected texture to the clicked brush's default texture instead of the clicked face.
(*Digging through gedit.c, I just discovered I can set "txtrpal_select 1" in dromed.cfg so that left-click applies the texture _and_ selects the face. For me this is better than the default, but still makes "picking" the texture off another face impossible while the texture palette is open.)