stgatilov

I think I see both issues in the code. Created 6610, will fix shortly after 2.13 release.

Actually, it is even more interesting. It is not just a force field. It is looks like a sliding door which pushes the player: "classname" "atdm:mover_door_sliding" "name" "launcher" "accel_time" ".1" "decel_time" ".1" "translate" "-40.185 0 335" "translate_speed" "15000" I must admit I don't know how to compute the velocity, and why it depends on frame rate. Perhaps better somehow record the initial velocity, while using capped FPS mode? Or just use binary search to find experimentally which velocity is good.

It won't help reliably, because the amount of impulse can vary greatly. The correct fix would be to set predefined velocity or impulse using script. The way it works now is it applies some predefined force, which is supposed to act exactly 16 ms, generating exactly the impulse mapper wanted. But now the duration of one game tic can be anything, so we should just look at the hardcoded force, compute impulse on the piece of paper, and make sure player gets exactly this impulse somehow.

Isn't it broken since the inception of Uncapped FPS? We have big issues with "force" entities in general. I tried to untangle the mess once, but without success.

You probably run some old executable?

beta213-05 is here. @snatcher, could you please try it and see if random texture show up or not? I could not reproduce the issue myself.

Better postpone this until after 2.13.

Maybe simply nobody noticed? Because if it is caused by this new feature, it just means the feature needs to be disabled until it behaves properly. The "Uncapped FPS" is just an unfortunate name for a completely different approach for timing and modelling the game. In reality it should be named something like "variable game step". On the other hand, it is questionable why we still have Max FPS as a setting. I think today we can set cvar e.g. to 350 and delete the option from the menu.

The defaults in the latest beta are the best: Vsync on, FPS cap off. Whenever the game produces a frame to monitor Vsync is on, the OS blocks the game until monitor refresh happens. So as long as the game can do its part faster than refresh rate, it will reliably deliver one frame per refresh. If you also set FPS cap close to 60, then the game will measure the time passed since previous frame processing started, and will not start processing a new frame until 1/60 sec passes. Of course, the time measurements don't match ideally, and frames take different time to process. It can happen that the game will wait 1/60 sec, then start rendering a new frame and miss refresh moment, so when the frame is done it will wait about 1/60 more. This results in a frame drop.

But it means that all people with higher-than-60 Hz monitors will play on 60 FPS. I doubt they will find the monitor refresh rate cvar. I would say the downsides of such change far outweigh the benefits. Max FPS should be significantly higher than refresh rate, so that the game can produce frames exactly by Vsync signals. If max FPS is equal to refresh rate, then the frames will be missed occasionally. Basically, you ruin the butter-smooth experience with this. UPDATE: Just remember the old "fixed FPS" mode. It also tried to limit FPS to exactly 60. Did it work well with Vsync on?

beta213-04 is reelased. There are some feelings that beta phase is coming to and end, and this is considered a release candidate. Which means that further changes won't get into 2.13 without serious need.

There has been many times people reported problems with the installer, and every time I checked the install myself, it worked fine. Finally this is a reminder to me that it is still worth checking.

Perhaps some kind of antivirus blocks the file?

Because non-archived cvar. Moreover, I think you also need to write "set" instead of "seta".

I fixed this double button. As for the button labels, I don't know what to say. Ideally the C++ code should be expanded to model each forward/backward transition and detect where it goes, then assign the labels. And the GUI script should call this new "label initialization function".

beta213-03 is released.

I think only strings inside .script files are counted towards this memory limit, because they are stored in script program. Entity spawnargs are stored outside scripting system, then don't count towards the limit. In particular, "editor spawnargs" take a lot of memory, and nothing fails because of it. Actually, one of the greatest improvements in savefile size was to not save editor spawnargs in iot.

Automatic BC4 compression can be enabled for the new parallax maps. This is most likely true. As far as I understand, most of the specular maps should be grayscale. It does not mean we can enable the compression for all maps. But the loading code already checks whether all channels are the same and switches to single-channel format automatically if it is true, so it is possible to use BC4 instead in this case. Also there are light falloff textures. But they are few, small, and they'd better be uncompressed. Also there are light projection textures. Sometimes they are single-channel, in which case it makes sense to compress them it mapper wants to do it explicitly. Luckily, no. It is possible to set texture swizzle on the texture during creation, then it will automatically broadcast red channel to RGB on all fetches. That's how grayscale images work right now.

Yes, it seems that BC4 is just half of BC5. It should not be too hard to implement it. Maybe even use it automatically... e.g. for heightmaps. Or for all single-channel and grayscale images.

I think only Shadows of Northdale 1 have this problem, it simply does not boot. The other changes should fix things in 2.13 but should not break them in 2.12. At least in theory... I'm not sure I checked it though.

beta213-02 is available.

Of course if you enable tonemap then you get gamma = 1.2 which increases contrast and sharpening filter which reduces antialiasing/blurry border of the fonts. But is crisper always better? Maybe we should make all fonts black-and-white without antialiasing and use nearest sampling? Because then we'll get the most crisp result. I don't see a major difference in the menu with/without tonemap. The fonts look crisp enough for me both ways. I wonder how many people are actually disappointed by the increased blurring. Removal of tonemapping in main menu has other side benefits, like no color banding in videos, and presenting custom images exactly as mappers intended them to be. Finally, I suppose sharpening filter might be dropped in the future. Modern graphical effects often rely on dithering and low-resolution rendering, simply because rendering that stuff in full resolution is too costly. Sharpening makes the artifacts much more noticeable, as it happened on volumetric lights. UPDATE: As for clipping, I can't reproduce any dependence on tonemap/sharpening. I also tested inside Linux VM. Subpixel clipping might depend on resolution, but thus far clipping is the same for me in all cases.

Try svn rev 10931?

Yeah, I thought it might happen So I guess the explanation is something like this. The main menu was previously rendered as overlay, on top of the previous contents. When the game starts, the previous contents is probably undefined. If tonemap is disabled, then rendering goes directly to OS window buffer, and it is probably cleared to black in all systems. But if tonemap is enabled, then rendering goes to framebuffer, and its initial contents is undefined. Perhaps it happens to be black usually, but e.g. mesa drivers don't clear it unlike other drivers. Now there is forced clear to black at the beginning of frame render while main menu is active, so the issue is fixed.

BTW, this is tracked here: 6594