Beta Testing 2.09

[Zerg Rush]

Yes, this is clear to me, the usual thing is to do it with the pick and a tension tool, as is done in other games as well. Not that it bothers me or disapproves of the way I do it in TDM, it was a mere observation.

[nbohr1more]

On 1/27/2021 at 2:34 AM, stgatilov said:

In the Mother Rose FM it is not a white flash, but instead something like a screen shake. Obviously, for a brief moment screen contents are replaced with some garbage, which can be different.

With bisecting, I tracked the problem down to revision 8981. Setting "r_tonemap 0" removes the issue. So it is some trash from FBOs.

Aside from that, there is a slight change in the sky while doing quicksave, but I guess it is some old issue. Maybe the same as the one about jittered screenshots with sky.

Hmm? No visportal or shake issues for me in Mother Rose. I completed with 100 percent loot and 0 stealth score.

[stgatilov]

2 hours ago, nbohr1more said:

Hmm? No visportal or shake issues for me in Mother Rose. I completed with 100 percent loot and 0 stealth score.

I was talking about the moment when you hit quicksave.

[nbohr1more]

I thought I might be crazy or mistaken about this but unfortunately not...

Somewhere between 16017-8976 and 16027-9022 all the torch particles have this strange triangular artifact:

16027-9022:

 

16017-8976:

 

[stgatilov]

11 hours ago, nbohr1more said:

Somewhere between 16017-8976 and 16027-9022 all the torch particles have this strange triangular artifact:

Yes, I confirm.
Looking at changelog, most likely I broke it in "Major refactoring of particle systems (5138)."

UPDATE: Broken in svn rev 9011.

[stgatilov]

Fixed the triangular particles bug in svn rev 9100.

[stgatilov]

beta209-05 is available.

Changelog is provided in its usual place.
Use tdm_installer to get the new version, and don't forget to check "Get custom version".

 

[Dragofer]

I've just done some measurements of the loading time of The Painter's Wife after having cleaned up its assets for v1.2 and noticed that 2.09 appears to load significantly slower than 2.08:

2.08: 5 minutes, 45 seconds

2.09b4/b5: 7 minutes, 25 seconds (same for v1.1, v1.2 and an intermediate version)

This is the v1.2 FM archive that I was loading on an Intel i5-9400F, Intel UHD 630, 8 GB RAM and an SSD: Google Drive

[wesp5]

2 hours ago, Dragofer said:

I've just done some measurements of the loading time of The Painter's Wife after having cleaned up its assets for v1.2 and noticed that 2.09 appears to load significantly slower than 2.08:

2.08: 5 minutes, 45 seconds

2.09b4/b5: 7 minutes, 25 seconds (same for v1.1, v1.2 and an intermediate version)

Wow, over 5 minutes to load a mission! That is really long. Can't we at least have the intro animations and such play at the same time? Or would this slow down everything even more?

[stgatilov]

3 hours ago, Dragofer said:

I've just done some measurements of the loading time of The Painter's Wife after having cleaned up its assets for v1.2 and noticed that 2.09 appears to load significantly slower than 2.08:

Most likely that's because of RGTC normal compression.

I'm afraid @duzenko removed the code which was used in 2.08 for DXT compression. But you can try "image_useNormalCompression 0" to see if the difference is big enough. Also note that AMD cards compress more slowly than NVIDIA ones.

The plan was to use on-the-fly RGTC compression by default in 2.09. And if there are no complaints about quality, then convert TGA files to DDS for the next release.

 

[Dragofer]

2 hours ago, stgatilov said:

Most likely that's because of RGTC normal compression.

I'm afraid @duzenko removed the code which was used in 2.08 for DXT compression. But you can try "image_useNormalCompression 0" to see if the difference is big enough. Also note that AMD cards compress more slowly than NVIDIA ones.

Applying "image_useNormalCompression 0" with the console has turbocharged loading, now it only took 2m40s to load the map. The performance seems virtually the same and visually I think its the same too. So that definitely made a huge difference.

Note that this is on a PC with an Intel integrated graphics. Ill probably use that setting in the future.

[nbohr1more]

I have never had good luck with uncompressed textures.

When I set image_useNormalMapCompression 0 then start Penny Dreadful 3 the load time doesn't dramatically improve

but FPS tanks down to 7FPS when starting the mission ( compared to 67FPS with compressed normal maps).

I guess I have some sort of memory bottleneck there.

 

I am guessing that image_downSize won't help with load times (when paired to uncompressed normals) since it also must generate new textures and mipmaps (the main source of long load times)?

[wesp5]

I took a quick look at my favorite sound issue in beta 5 and I think we are getting there ;). The double-fail sound when quitting in the middle of lockpicking is gone, but it is still overlapping the lockpicking-succeeded-now-use-the-other lockpick sound. So whatever you did, please do the same when switching between lockpicks because this is confusing!

Also while testing this I noticed something which I don't know is new to 2.09 or not: in the tutorial lockpicking section you can unlock the first chest twice, once on the lid and once on the bottom. Which brings back the idea that frobbing should only be possible on the bottom with the lock and once it succeeds, the bottom should become unfrobbable and the lid should become frobbable to open it. This would also fix the common issue that it's hard to frob items out of chests!

On another note, the white flash when quicksaving is gone :), but you can still get a quick glimpse of the starting point of the map before the location is set to the one from which you saved when loading a game.

Also there are still too many spaces in front of the "Ask this every time?" answer when quitting the game...

Edited February 2, 2021 by wesp5

[AluminumHaste]

8 minutes ago, wesp5 said:

Which brings back the idea that maybe lockpicking should only ever be possible on the bottom with the lock and once it succeeds, the bottom should become unfrobbable and only the lid can thus be opened. This would also fix the common issue that it's hard to frob items in chests if the bottom of the chest is frobbable too!

That's a good idea but custom chests in maps, especially older maps, wouldn't be affected.

[wesp5]

7 minutes ago, AluminumHaste said:

That's a good idea but custom chests in maps, especially older maps, wouldn't be affected.

If it would work for all default chests it should still be worth thinking about.

Also I fixed the quit-question distance. Please for the next 2.09 beta change

in:

mainmenu_quit.gui

this:

choiceDef QuitGameDialogAskEverytimeOption
        {
            rect        130,85,60,20

 

Edited February 2, 2021 by wesp5

[AluminumHaste]

But if we fix that, I won't be able to enjoy how annoyed you get

[nbohr1more]

I have no strong feelings about the "are you sure" gui. It has been the same since TDM 1.02 (at least) but I honestly never even wanted this "feature" to exist in the first place. What 0.0000000001% of TDM players want to be warned about accidentally exiting TDM? A more critical thing to work on is rearranging the mission install process  ( Obsttorte had an excellent prototype... ).

That said, if the fix looks good we can merge it. I just wish we would ditch this warning feature altogether.

[wesp5]

10 minutes ago, AluminumHaste said:

But if we fix that, I won't be able to enjoy how annoyed you get

If you mean the spaces, I can just as well update my patch with that fix and be happy ;)! And yes, I am a perfectionist :).

On another note, while checking if my fix works at lower resolutions, I noticed that I can't seem to switch away from my current HD one. Whatever I do, even if I edit the cfg manually, the game will go back to full 1920x1200! Is there another file that needs to be changed? P.S.: In windowed mode it works fine, in full screen it always goes to native resolution...

Edited February 2, 2021 by wesp5

[nbohr1more]

1 minute ago, wesp5 said:

If you mean the spaces, I can just as well update my patch with that fix and be happy ;)!

On another note, while checking if my fix works at lower resolutions, I noticed that I can't seem to switch away from my current HD one. Whatever I do, even if I edit the cfg manually, the game will go back to full 1920x1200! Is there another file that need to be changed?

Are you in Fullscreen, Windowed, or Fullscreen Windowed mode?

As I recall, there was a plan to ditch "real" resolution switching in favor of "resolution scaling".

Though... I thought that would also mean that if a user selected a lower resolution TDM would automatically change the internal FBO resolution factor which I don't believe has been implemented yet?

I do remember real resolution changes worked for me in earlier TDM 2.09 beta builds but I am a Linux user so screen management may differ for me.

[wesp5]

37 minutes ago, nbohr1more said:

Are you in Fullscreen, Windowed, or Fullscreen Windowed mode?

i am in fullscreen and borderless behaves the same, but in windowed mode I can change the real resolutions.

[nbohr1more]

Yes, there is a 2.10 tracker to get Linux to do what is done in Windows (always desktop resolution).

So changing the resolution in Windows should be similar to using the render scale slider ( r_fboResolution ).

If you choose a lower resolution in the GUI and disable Sharpening do the game graphics become blurrier (as with resolution scale)?

[stgatilov]

5 hours ago, nbohr1more said:

So changing the resolution in Windows should be similar to using the render scale slider ( r_fboResolution ).

I think changing resolution in fullscreen mode simply has no effect. It is reverted back on restart.

[grayman]

On 2/1/2021 at 11:09 PM, stgatilov said:

beta209-05 is available.

Changelog is provided in its usual place.
Use tdm_installer to get the new version, and don't forget to check "Get custom version".

 

When running the installer, I get this error:

 

[stgatilov]

1 hour ago, grayman said:

When running the installer, I get this error:

One day I'll rename this stupid model, I promise!

Just... not today

[stgatilov]

4 hours ago, stgatilov said:

One day I'll rename this stupid model, I promise!

On the second thought, it wouldn't help with this problem.

Users are free to have their files in installation directory, and the files can be named in any way they want. Installer should skip them properly.