stgatilov

These are attempts to show direction to the source of sound. I would be glad if you propose a more understandable but still well implementable different way I set "noevents 1" in tdm_subtitles_common.gui.

You can go to idProgram::Restore, delete "saved_checksum != checksum" check, build the code and try again. But it is quite dangerous. The savefile does not store your scripts, it only stores their hash.

A hotfix release "release211a" is available in tdm_installer. Right now you need to select this version manually. As usual, the savegames are compatible both ways between 2.11 and 2.11a. In fact, the hotfix uses the same executable files, so there is almost no risk of breaking anything. We only fixed a bug with wrong map icons in one def file. Please update your 2.11 installation to this version. It is very unlikely you can meet any issues, but if you do, report them here

Revert scripts to their original state. Script mismatch immediately make savegames incompatible.

I think this can be implemented as postprocessing shader which takes a part of traditional render and bends it to get conformal projection. I.e. when conformat projection is enabled: Find minimum FOV so that camera view contains the whole thing visible in conformal projection Render everything with traditional camera and this larger FOV During tonemap, compute texcoords to sample input from using some nontrivial formula Of course, step 3 will stretch or bend the pixel-perfect render in pretty weird and non-uniform way, so perhaps it would look blurry by 1 pixel in the middle, perhaps it would have aliasing near boundaries. But it will achieve the desired effect with very little intervention into rendering.

"r_useNewBackend 0" will be removed in next release. It is already removed in the latest dev build. You would do us a favor by downloading dev build now and checking whether it works fine or not

That's because invisible full-screen overlay of subtitles block hover events... but not click events for some reason Fixed in svn rev 16790. Also, there is no color highlighting here implemented. Maybe just add hovercolor property?...

I'm pretty sure we will change the formatting/layout soon. Existing messages would fit the new limits (they would be a bit larger), hopefully without exceptions. But the particular look will change, that's for sure. Your question is exactly why we should choose the new format as good as possible and fix it in stone afterwards.

Changed the type of gameLocal.m_StartPosition from "const char*" to "idStr". Purely technical thing.

I'm against offering these setting in the menu, because it would result in subtitles look like trash for all players who have changed them from defaults. Something like cvars for experiments --- yeah, why not. I think it is OK, but this optional parameter must be preceded by keyword, like durationExtend. Otherwise you'll block possibility for adding other additional settings in the future.

dev16789-10349 is available.

I fixed it in svn rev 10348.

I have added support for aspect ratio correction in font: 6283 I'm not very keen to introduce aspect-dependent GUI layout without major need. Unless anyone is interested in 4:3 and 5:4 aspects, better hardcode 16:9 for now. Also I noticed a defect in fonts/stone font: some of its letters overflow their rectangle in font atlas, so neighboring letters render with a thin white line on the left. It is not nice but not critical either. It would be great if someone proposes several layouts & fonts for subtitles, so that people could choose which one to use. The requirements from me are: The amount of text must be a bit larger than what a subtitle currently can hold. Don't obstruct weapon/inventory icons and "you acquired compass" messages on default GUI size. Preferably readable font with 16:9 aspect correction, large enough to be readable when TDM takes half of monitor size. P.S. Did we agree on the syntax for extending duration of inline subtitles?...

Or with different font

Does this look more like a correct aspect ratio of font?

Previously there was single main menu UI, now it is recreated when you e.g. start game. So yes, gui vars can get lost if player starts game. This looks like what I would expect from looking at C++ code. And startpos2 should be the name of some entity. If it does not work, should I go through it in debugger?

You should attach files named like tdm_installer_1679746360.log. You can also try: choosing some specific mirror (Get custom version + choose mirror on next page) "No multipart byteranges" setting

The last time (5553) @Daft Mugi reported it "working well". I imagine it should work, no?

Regarding fonts stretching. Maybe I should try to implement width stretching in engine? Suppose that someone specifies "fonts/carleton$aspect=16:9". We break this into font + parameters, load the font, then do some postprocessing. If aspect=A:B, then we scale down by X in (A/B) / (4/3) times, e.g. scale down in 4/3 times in case of aspect=16/9.

I prefer to have one setting like "Motion Sickness" (some better name should be chosen), which simply disables both mantle roll and headbob (and does any future adjustments for the same reason). Most people play OK with default settings, changing these only matters for the minority which feels uneasy with them. At which point it is easier to just disable all the stuff: it does not have any gameplay significance anyway.

That's exactly how the latest dev build should work. With SRT, the sound is extended until the latest end time of all elements. Is it not working as expected?

Everything is rendered to 640x 480, then stretched to whatever screen you have. Giving some GUI element fixed real aspect ratio can only be achieved by computing inverse stretching at the moment when this element is rendered. I think we added "forcescreenaspect" window flag for X-ray overlay, which is usually combined with "hcenter" flag, and it is implemented exactly like this. Making font scale automatically is not a good idea, since it then you'll just get more variety with aspect ratios.

I think we should just add some free font which is scaled in such a way that it looks right after scaling back

I think part of the problem is that fonts are rendered into virtual 640:480 resolution, which is later resized to 16:9 or whatever aspect ratio you have.

Definitely won't do it. The first implementation did not have background, and it was hard to read subtitles on top of some bright parts in briefings. Background is here to ensure that text font is in contract with whatever the game displays below.