[I made a fix for UI display for non-16:9 resolution.]

Thank you!
I have linked this to 5282.

Yes, I think doing this at the lower level of idDeviceContext (where virtual resolution scaling happens) is the better approach than trying to do it on the idWindow level.

It seems that you assume current UIs were made for 16:9. I'm afraid the sad truth is that they were partly made for 16:9 (new ones) and partly made for 4:3 (old ones). And the old ones look stretched. I'm not even sure which kind of intended aspect ratio is more popular now.
I guess I'll try to make the scaling configurable depending on settings in the root window (aka "Desktop") of the UI.

Moreover, we already have some overlay images prepared for several aspect ratios (ultrawide not included). Ideally, I'd like to drop all the duplicates and have only one image with proper scaling/padding. A long story obviously.

Yeah, the special handling of full-screen windows feels hacky. I guess I'll need to avoid it somehow.

[Subtitles - Possibilities Beyond 2.11]

@Geep Regarding 0.24 vs 0.25 font scale.

I think there was purpose, though I can't say now which exactly.
Maybe it was to ensure that all the text fits, maybe it was to make vertical padding symmetric.

Anyway, why do you think 0.24 and 0.25 differ?
I did not look in the code yet, but I think what engine does is 1) choose most suitable image, 2) render quad texture with it.

Indeed, we can avoid some blurring if the pixel size of the quad exactly matches the image size.
But I guess the engine counts font size in 640x480 virtual resolution. So even if the font size would be "12", it would later be stretched over whatever width you really have (if your aspect ratio is 16:9 then height would be stretched equally, but otherwise it would be stretched with different factor).

[Particle Collisions and Cutoff Feature]

On 1/13/2024 at 6:10 AM, Goldwell said:

3) Create the appropriate patch in game applying the above texture to it (with the texture fit to it and it facing down)

4) dmap missionname.map

5) runparticle missionname.map

Any warning during dmap?

Does your patch have [0..1] non-overlapping texcoords?

[Subtitles - Possibilities Beyond 2.11]

It looks like sooner or later we'll have to add settings menu for subtitles.

Verbosity can be moved to it.
Then there can be this big switch between background and outlined text.
And a bunch of color settings for various elements.

The only thing I wish to not see there is any settings which can affect text layout

[[2.12] Increased Mantle Speed]

I also hope the big pile of movement changes is finally over
All these changes seem minor but cause heavy reaction. First we got overly lengthy arguments about it internally, now the same continues publicly.

I'm not sure why everyone thinks parkour was the main motivation.
In fact, I watched parkour videos to understand how the hell it should be possible to do the wall climb up as fast as @Daft Mugi wants it.
Now I play Prey and its climb up is insanely fast, totally unrealistic... I guess in the end most people are annoyed by having to wait for the same boring mantling animation and prefer to regain control faster.

By the way, I believe 50% of reception to such changes boils down to plain habit.
When I took the first build of faster mantle it seemed crazily fast. But after we tweaked it (I don't think we made it much slower in the end) the reception gradually changed and I did not feel it that absurdly fast anymore.
That's why I even suggested accelerating mantle gradually (e.g. 100 ms per release) to avoid much negative feedback

[I made a fix for UI display for non-16:9 resolution.]

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.

[I made a fix for UI display for non-16:9 resolution.]

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.

[So, what are you working on right now?]

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.
 

[Subtitles - Possibilities Beyond 2.11]

10 minutes ago, snatcher said:

@stgatilov, would you mind sharing your latest version of tdm_subtitles_message.gui?

Added near screenshot.

[Beta testing 2.12]

beta212-03 is available.

[Subtitles - Possibilities Beyond 2.11]

20 hours ago, Geep said:

Your latest design is OK, but doesn't touch on several aspects that I addressed in my design:

1. ring lower edge no longer crushing the top of 1st line text
2. excess backing field below text 2nd line trimmed, to allow space for (1)
3. backing field behind ring, as I believe requested by snatcher & datiswous

• 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

[Subtitles - Possibilities Beyond 2.11]

17 hours ago, snatcher said:

Here you are, plus the Gimp template.

Replaced in svn rev 16896.

15 hours ago, Geep said:

Regarding the padding issue, to restate: TDM 2.11 and on through the 2.12 released beta version use a subtitle right text padding of 20 px. While some padding is necessary, this does a poor job of centering the text visually in the backing field. This is obvious with a short bark. My redo of this, with padding of 7.5px on both sides, fixes it, while I believe not causing any problems for word wrap of subtitles with the given compressed font & scale.

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):

 

Quote

I have been quite careful to ensure that making the subtitles narrower for barks (but not story verbosity) is not potentially breaking. Examples of this treatment have been included in all my more recent testSubtitles... releases. Yes, this is "crucial" for me.

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

[Subtitles - Possibilities Beyond 2.11]

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.

[Subtitles - Possibilities Beyond 2.11]

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.

[Particle Collisions and Cutoff Feature]

16 minutes ago, Frost_Salamander said:

Actually this doesn't seem to be the case.  The rain seems to stay outside the visleaf if the door is open. In the example screenshot from inside the Inn in In Plain Sight, the rain patch actually extends over the roof of this building.  With the door open, the rain 'stays outside'.

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.

[Particle Collisions and Cutoff Feature]

19 minutes ago, Amadeus said:

One thing I don't get is why TDM doesn't have core materials that support particle collision right out of the box. There is a small handful of rain materials that support this, but most of the core weather textures, and particularly snow textures, all use "deform particle2" even though that is not supported by particle collision; "deform particle" is the correct keyword for this

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 and Cutoff Feature]

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.

Quote

Why does it need a separate command (runParticle)? Can this just not be bundled in with dmap?

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?

Quote

What are the limitations of this (i.e. when should it be used and when shouldn't it be used)?

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.

Quote

Why isn't it the default behaviour?

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?

Quote

  Why all this work to get it into the map?

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?

Quote

Texture layout vs. Linear layout: what's the difference in the end, pros/cons, why would I use one over the other...

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.

[Beta testing 2.12]

1 hour ago, nbohr1more said:

I did a little testing of SVN 10610 and 10611 and haven't seen any light \ shadow problems thus far. I mostly play in shadow-map mode but I think the problems mostly impact stencil? ( haven't seen any issues in stencil mode either ).

Stencil shadows are more susceptible because only backfaces cast shadows.

Quote

I think the reverted Doom 3 style frustum may have cured the light leaks above some shielded electric street lamps too. It also may have improved the appearance to lighting in the mission "Behind Closed Doors" ( noticed more shading variation on the walls of the large stairway at the start of the mission ). Could be placebo, gotta compare screenshots.

I'll bet on placebo

[Beta testing 2.12]

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

[Subtitles - Possibilities Beyond 2.11]

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).

[Subtitles - Possibilities Beyond 2.11]

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).

[Beta testing 2.12]

On 12/31/2023 at 12:02 PM, waxhead said:

Trying to play "The adventures of Thomas: Lucy's quest"

This consistently crash when witnessing the "entertainment".

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

[Beta testing 2.12]

4 hours ago, taffernicus said:

Does this 2.12 bring much more graphic overhead for low-end GPU ?

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...

[High FPS (160+) Slows Creep Footstep Timing]

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).

[High FPS (160+) Slows Creep Footstep Timing]

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.