duzenko

In case image_blockChecksum was toggled after images were loaded. Then they would still have block checksums on them. There is always hope!!!

AFAIK only the diagnostic tool uses it. It will not find any duplicates. I think most of them were wrong because it did not check if R_LoadImageProgram returned valid data. I still have some duplicates with Illusionist Tower and they do look the same.

Thanks

Here's the full diff patch with the new cvar and the fix from the previous post. Using the map Illusionist tower I get 7.2 vs 6.2 sec in the console output for "all images loaded". BTW how do you get a text copy of the console?

I think there is a bug with the check procedure. Here's my patch that kinda works

It does not list "assets/briefing/nextpage" or "assets/briefing/prevpage" Is it mission specific? What mission is installed for you?

Just start TDM and run reportImageDuplication in console. It will list all loaded images with same content. It's fonts mainly.

This is another suggestion on improving load times. When loading a map, TDM calculates an md4 checksum on each texture image. The checksum is only used by a diagnostic tool (namely reportImageDuplication). Not sure how many map designers have used it because e.g. NHAT has 64 duplicates, 17 of them being the TDM GUI. Anyway I think it makes sense to add a config param to skip md4 calculation by default. Then if any map designer wants to test image duplication they can toggle the param. My test with NHAT: md4 checksum on: 21.2 sec md4 checksum off: 19.2 secYour tests will show less difference because I already don't use pk4's. I can prepare a diff patch if this idea is accepted.

Thanks. I apologize for any misunderstanding.

Umm... Sorry, are you saying that since nobody complained then it's ok or what??? I thought that everybody wants loading times as short as possible, not padded with artificial delays - but you sound like I want too much here??? Maybe I should create a poll or something to see if anyone else wants faster map loading and how much delay would be "unnoticeable" for average player. Heck, maybe increase delay to 10 seconds and see if anybody notices.

I think on a 64x64 frame multisampling does not significantly affect performance. With all the CPU calculations and cpu <-> gpu transfers how much do you hope to gain?

I assume you have noticed the diff patch and don't need me to answer that.

I noticed that when the map loading GUI is shown nothing is being actually loaded for a second or so. It affects quick loads too. Can we please get rid of the loop since it's useless in TDM. It's really annoying to wait each run when testing code changes.I think everyone will appreciate one less second of loading.Here's the patch

I think r_multiSamples only takes effect on vid_restart, so it is no use here.

Hm, tdm_ai_opt_interleavethinkframes did not do anyting really for me too. I think there are a number of situation where interleavethink option is overridden and AI thinks each game tick, such as when its movement is blocked. It's all in idAI::SetNextThinkFrame. On the other hand, _opt_nothink, again, doubles the fps. I have been looking at where cpu is spending most of its clocks and I think while some of it is AI but a lot of it is idAFEntity_Base. I have an idea which objects it could be. Here's a low-quality video with a jittering model stuck between spider and bed: https://www.youtube.com/watch?v=ekZkOBnE2u4. While TDM physics code may or may not be doing a great job handling narrow places like this I still think it would be easier to fix it on the map design level. If we relieve the white spiders from getting stuck around the bed it should help a ton in terms of fps.

How do I set the interleaved thinking frames higher on the Spiders?

Mine was downloaded in game last week end. Here are the screenshots My hardware is i5 5200U/hd 5500, and yours?

Excluding the skeletons from physics would be an ultimate solution. Another possibility would be to reduce poly count for their physical model?

I wonder what makes the cavern spiders so slow. Is it the corpses? The stalagmites? Does the spring water add any complexity into the calculation? Maybe we could alter the map and see how fps responds to each of the factors.

It looks like they were talking particularly about renderer there.

Try r_brightness 1in a game console

A harder question. How thread safe is the collision manager? Putting physics in a separate thread looks so beautiful and exciting in theory but my uneducated attempts to QueueUserWorkItem anything related to collision manager from the gametick code crashed and burned with null ptr AV. Ideally, SMP might easily double fps in the cavern, unless throttling kicks in. It's funny, really, how killmonsters doubles the fps here. We should absolutely put it in the Performance Tweaks wiki [trollface.png].

So we have been using the NHAT cavern for general benchmarking. Performance issues are obvious - I get 20 fps or less looking at the three spiders (notarget on). And I have a problem with it - the problem is that the bottleneck here is not the graphics rendering. I think I narrowed it down to physics simulation. The map author appears to have assigned the smaller white spiders to be "chewing" on the corpses. When you kill/gas the spiders or simply notarget off so that they move towards you then fps skyrockets. My research shows that CPU is sweating in the debris of Collision Model Manager. Quick questions: 1. How 'normal' is this? Do we need to do something about this issue? If it's exploitation of game mechanics to shock player with cannibal spiders then we probably should not use this scene for benchmarking. 2. Do we first kill spiders and benchmark then? I would not guess this unless I knew the spiders are the problem. 3. Do we need to blend animation frames each game tick for physics simulation? In my case, I have 20 graphics frames per second and 60 game ticks. If animation is 24 fps (judging by md5anim files) then would it not be enough to simply use the current frame? I understand that we want as much precision as possible for physics simulation but not at the expense of visual slideshow? Maybe introduce a new option - high precision vs low precision sims or something like that. Maybe automatically switch based on current fps. Again, these scene is CPU limited and I have a 2.7 GHz Core i5. We should aim to achieve at least 30 fps on modern midrange CPUs, shouldn't we?

1. I used to use Fraps but it might not work for you 2. (Wild guess) It might hook some OpenGL functions like glReadPixels that DM uses for lightgem and draw over it. Can you try my custom build from here and see if it helps.

It's around 10fps for me - glad I did that mission back when I had a real video card, not this energy efficient joke On the other hand, it gives some stimuli for optimization