stgatilov

Oh, I tried to apply forceaspectratio to Objectives, it seems to apply to single window only. To make this flag useful, it should apply recursively to all children. Also there are forceAspectWidth, forceAspectHeight, but they also seem to be non-recursive.

Some time ago we added "forcescreenaspect" flag to GUI windows for this: void idWindow::CalcClientRect(float xofs, float yofs) { drawRect = rect; if ( flags & WIN_INVERTRECT ) { drawRect.x = rect.x() - rect.w(); drawRect.y = rect.y() - rect.h(); } if (flags & WIN_SCREENASPECT) { float renderAspectRatio = float(renderSystem->GetScreenWidth()) / renderSystem->GetScreenHeight(); float widthMultiplier = renderAspectRatio / (640.0f / 480.0f); drawRect.w /= widthMultiplier; } Ideally, it should be combined with "hcenter" of course. The plan was to go and add these flags to where they fit, but I did not return to this.

I'm trying to support many mirrors/remotes/whatever potentially seeing each other. (This won't get into 2.12 of course) There are some issues, but in general it seems to work fine. Of course the performance on such scenes is abysmal. My understanding is that such things should be supported despite bad performance, simply because sometimes mappers get these situations unintentionally. For instance, you have two adjacent rooms with mirrors, and when player opens a door between them you might suddenly get two mirrors in the view. Right now renderer will break one of the mirrors. Processing both mirrors properly with lower FPS seems a better approach.

Added near screenshot.

beta212-03 is available.

reduced height of the box & text from 45 to 37, while moving everything up by 9 points location ring moved up by 2 points added background field to location ring distance between subtitles reduced from 55 to 52 (50 makes location ring merge with next subtitle box) tdm_subtitles_message.gui

Replaced in svn rev 16896. The 20 pixel padding was introduce conservatively before the font was changed. Merely applying the 16:9 vs 4:3 correction allows to reduce it to 15. But also the font is significantly smaller now. I tried to edit text in order to see maximum overflow. It seems that capital W is the widest letter in this font, and I can't get a significant overflow (see image below). So I have reduced padding from 20 to 10. Also I shifted everything to the right, so that now subtitle ring and text field are centered horizontally (instead of the background box being centered). This looks much better with frobhelper activated, because previously frobhelper and location ring center we not at the same X position. Finally, I have increased step between subtitles from 50 to 55 to avoid next subtitle box overlapping with previous subtitle location ring. These tweaks can still be changed, since they don't change anything regarding the text layout. Here is how it looks now (blue background shows the text box): My stance on this is still the same: if large empty boxes look ugly, then we can make several possible background boxes and make engine select the best one that text fits into. This way the decision of which box is OK can be made with the very same code that actually renders this text, instead of some external independent computation. There is no reason why smaller background box should be applied depending on verbosity, except that "it looks all non-story subtitles are small enough now". One exception is enough to break this idea. Alternatively, it is quite possible that we switch from background boxes to black outline around text. Both approaches works rather well, and without background we can forget about tweaking the background box. tdm_subtitles_message.gui

Oh, I realized that this location ring is not symmetric. The center white dot should be moved up, along with the sector. EDIT: Maybe sector can stay unchanged, but I believe the "center dot" should be at center.

I really like the location ring image by @snatcher , the white symmetric one with a sector. I'd like to replace the current image with it. @snatcher, could you please share it for download? Thus far I can only see enlarged jpeg version, but I think tga/png version is needed. Also, big thumbs up for outlined font version. This was my first idea when subtitles were initially implemented, but I did not manage to make this outlining. I added "dilate" image processing function and applied it to the font atlas. But then letter boxes in atlas must be enlarged, and the whole atlas needs to be repacked because otherwise there is not enough padding. Rendering the text with 4 shifts sounds stupid but solves the problem in much better way. As for layout and spacing of subtitles, I think it would be everlasting discussion. Everyone has his own taste regarding this. It might be OK to shift the subtitles up and down. But all the discussions about making them narrower/wider or removing padding (basically, everything which may affect text layout) is potentially breaking, so I'd prefer not to do such changes unless it is crucial.

I'm not sure you are right. It seems that it is limited by area scissor. Basically, take axis-aligned 2D bounding box of the door visportal: that would be the scissor of the outer area. The particles should be limited to this rectangle only. If you move around, this rectangle will change of course.

Because that we would have to copy/paste all rain materials to introduce "deform particle" version. Note that we cannot delete "deform particle2" versions because they are already used, and they cannot be replaced that easily. Then we would have to copy everything again in order to add versions with collisions. But I'm sure mappers might want to create rain patches of different size, so we'll probably have to have versions with layout texture 1024 1024, layout texture 512 512, layout texture 256 256, etc. And then different mappers might have different feelings about the balance between quality and waiting time in case of layout linear, so we'll have many versions of snow too. All of this causes combinatorial explosion, and we'll get at least ten times more materials and particle decls than we have now, causing a lot of confusion. Perhaps combinatorial explosion can be avoided if these settings are specified in another file. I guess at that moment I was not brave enough to introduce a new type of decl files.

Particle collisions cannot be computed in realtime, particles are purely graphical effect which cannot interact with collisions. So the collisions have to be precomputed beforehand, just like dmap precomputes triangulations of brushes. Most of the nuances grow from here. It was possible in theory to run it automatically during dmap (just like e.g. you never have to run aas tool directly, because dmap calls it automatically), but I'm afraid it would annoy everyone because it may take quite a lot of time depending on settings. Now that some people have some practice with this, should we change it? Most importantly, collisions are precomputed statically. If you move the emitter, the collision information becomes wrong. All objects which seem dynamic are automatically excluded from precomputation, so the particles will still go straight through all the guards and moveables. What do you mean by "default" behavior? Default behavior of what? particles? Like make all particle emitters stop on collisions automatically? What about cases when mapper wanted particles to pierce walls? What about moving particle emitters? The goal was to reduce amount of work actually. As soon as you are able to set one huge particle emitter over the whole map, I think you don't have to mess with it any more, just remember to execute runParticle occasionally when you want up-to-date collisions. Before that, mapper had to split the rain patch into many patches and manually tweak every patch so that it stops at proper height. As far as I understand, it was very time-consuming and painful. As for areaLock, it does not restrict particles to single area. It only disables the whole system if renderer proves player does not see the specified area. As long as the door is open, you should still see rain falling indoors, no? Yeah, this is a tough question. Texture layout: Only works properly if particle evolves exactly the same way if emitted from the same location. Interacts with texturing: requires you to set non-overlapping texcoords in 0..1 range on the emitting surface. The only option in TDM 2.08. Ok for straight-falling rain, but snow is out of question. Linear layout: Only works for a periodic system, i.e. the whole system exactly repeats itself after some time. Precomputation might take a lot of time, especially if you insist on a large period. [problem for maintainers like me] If particle code is changed in TDM engine, the collisions must be recomputed. Was added in TDM 2.09. Supports pretty much any kind of particles, although snow was the main goal.

Stencil shadows are more susceptible because only backfaces cast shadows. I'll bet on placebo

beta212-02 is available. There is yet another major change in the light portal flow implementation, and there can be more issues now. Or less --- never sure

Padding on the right is necessary because text rendering engine allows one-character overflow. And trying to fix it breaks many readables in many missions. So unless background is disabled, padding will stay. As for how large it is, I think it was minimum plausible at some moment. But then the font was changed and maybe it can be reduced now --- history digging is required here. I believe background will stay by default. There is no other simple way to make sure text is visible in all circumstances. As for size and spacing, I doubt you'll be able to reduce anything without making font even smaller and potentially less readable (especially in Windowed mode).

I guess added sector is enough to drop the idea of more thickness on lower half of the ellipse. It is possible to expose colors of background and text to cvars. If the location ring image is black-and-white with varying alpha, then I suppose it should be possible to expose its color too (by modulating configurable color).

Messages about pthreads is just some trash which is printed almost always. The issue is most likely not related to it. Please provide some more specific info. Location (getviewpos), maybe savefile. Probably instead config file too. https://wiki.thedarkmod.com/index.php?title=Reporting_Problem

With a year full of changes, I'm pretty sure I can find something that might increase GPU load in some cases. However, if it seems that 2.12 is slower to you. Please find some specific locations/cases, compare to 2.11, and report this. Be sure to include name of mission, viewpos, and you config file (see the wiki page linked in the first post of this thread). Occasionally unintended performance regressions happen. The worst thing is that they are rarely noticed until a few years later...

Maybe we should adjust menu setting to only include these "integer ms" values (while secretly settings com_maxfps between two consecutive ms values for reliability).

I believe the issue with footsteps not playing is fixed on 2.12 beta. As for how max FPS settings works, I noticed that it takes effect on integer number of milliseconds per frame. So if you set 180 Hz, you'll get 166 because it's 6 ms. And if you set 220, then you'll get 200, since it is 5 ms. The actual code which establishes FPS cap uses microsecond precision, it is not obvious why this millisecond effect happens.

There are many uses of this texture, and all of them use this compression algorithm. Perhaps replace it with full black texture would be better, since it already works that way. I wonder why this texture was even created with (1, 1, 1)... //matt black - there are already blacks but cannot get _black nor bc_black to reference as diffusemap // NB: this texture still has default specular reflections. For complete black, use black_pure below textures/darkmod/sfx/black_matt { qer_editorimage textures/darkmod/sfx/black_matt_ed diffusemap textures/darkmod/sfx/black_matt } The original code comes from 2008. And there is also 4151, where black_pure and white_pure materials were added. I hope someone familiar with assets will help decide

This is caused by DXT1 compression of textures/darkmod/sfx/black_matt.tga. This image has constant color (1, 1, 1) everywhere, i.e. almost black. Previously, the image was compressed by OpenGL driver, so you could get different results depending on vendor. I got (0, 0, 0) everywhere, you probably got the same. But someone else on another vendor could get something else. Now, compression is done by our code, same for everyone. It compresses the color to (0, 1, 0). Obviously, this is a bit closer to (1, 1, 1) than (0, 0, 0) Notice that DXT1 uses 5 bits for red and blue but 6 bits for green. So while it is possible to represent 1/255 value for green, it is not possible to do the same for red and blue. However, this 1 tick adds a bit of green to the overly black picture, and then you apply huge gamma correction (basically take sqrt of all color components) and this green becomes noticeable. Some ways to fix the issue: Use _black texture. It is (0, 0, 0), and I am rather sure it will be compressed to (0, 0, 0) by all implementations. Modify textures/darkmod/sfx/black_matt to be full black (0, 0, 0). Add forceHighQuality to the stage which blends textures/darkmod/sfx/black_matt. Add DDS version of textures/darkmod/sfx/black_matt to core assets. Note that points 1, 2, 4 produce equivalent output, i.e. force texture to (0, 0, 0) color. Point 3 leaves the texture as (1, 1, 1), but there is no way to do this for all materials: the keyword has to be added to each material. Points 1 and 3 look bad because they fix the problem now, but don't stop the problem from happening again in the future.

So, should I simply desaturate the current image, i.e. convert to grayscale?

See this wiki page: https://wiki.thedarkmod.com/index.php?title=New_light_leaks_in_2.12 I have bound changing both cvars + reloadModels to [ and ] respectively. I guess I'll toggle them a lot in the nearest future.

I think I have already discovered this page once. @taaaki, could you please remove it somehow, or put redirect onto the main downloads page? Otherwise we'll always forget to update it.