stgatilov

Did you really calculate this size according to instructions? It should be about 30 MB, I think.

Yes, you are absolutely right, it is an entirely different problem then. Maybe try different versions of shadows implementation (Maps/Stencil, Soft/Hard). Can it be a problem with model normals (although I cannot imagine how bad vertex normal could affect single quad) ?

Please report which exact version of TDM you used a) when dmapping your map, and b ) when running it. Report it both 1) for the state in the past where you got no problem, and 2) for the newer state where you get missing geometry. Please reopen 4877. Explain where to get the exact .map file with the problem (I guess it is beta-tested map), and report coordinates of the places where geometry is missing (the more = the better). The coordinates can be obtained by writing getviewpos command in game console.

The new version beta207-04 is up on the URL: http://tdmcdn.azureedge.net/beta207-04

New version (codenamed beta207-04) is ready for update. The changelog is here, as usual. Please pay attention to any AIs which you are already dead / knocked out by the time you discover them (there should not be any with the new version). Also check out how AIs sit/lie on various chairs and beds. Another domain which needs extensive testing now is mantling, which has been changed a lot. Check out mantling as is, and combined with crouching/jumping. Check it near ceilings and in places where there is not much space. Check it in water, on starts and ropes, etc.

That's exactly where I got the idea from. rsync needs special server, but there is zsync which downloads over HTTP. It looked too Linux-specific, so I rolled my own equivalent. Anyway, the current plan is to switch to a different synchronization algorithm which is tightly integrated with zip file format.

Savegames are usable. We can do a bit of time-travelling if it is absolutely necessary. Also, developer can take source code of that version directly. Just note which version you were using (either SVN revision from game console or codename). But the most convenient information on a stable map is: 1) Which mission it is, and 2) Your exact location (execute getviewpos in console to get it).

I think the current SIMD memory copy is weird. Using MMX for copying memory is stupid this day, and in 64-bit mode it is excluded anyway (no MMX). Someone should replace the MMX version with the SSE one. To be honest, I think custom memcpy should accept a flag which tells if the copy should be cached or not (or implement two versions). SSE has ordinary writes and "streaming" writes, and which is faster depends on circumstances (and the first one is faster in most cases).

As a matter of fact, now the updater works with the official TDM beta-testing location. See updated point (2a) of the original post. Note: remove the tdmupdate_tdmsync.exe that you have already downloaded and download the updated version. Otherwise, updates from TDM beta-testing location won't work.

Created 4940. Caught into this myself by noticing that most of women are off before I even find them in Crucible Omens. For instance, here is Lazarova, which was "drunk as dead" when I found her:

My personal "thank you" for this map! While it is not a "mission" at all, it is fun to play with! I did not even imagine we already have so many AIs Moreover, it will serve as a great test map for TDM team P.S. noticed a problem with bumpmap on the walls of the arena:

Lowering "Render Scale" slider in the upcoming TDM 2.07 is a good way to decrease GPU load. while sacrificing image quality. But if you are limited by CPU, then it won't help (just as downscaling images won't, I think).

I think there are tons of weird behavior with dead bodies and such. I often see knocked out women remaining on their feet in ragdoll state (while chest going horizontal). I noticed that if you take a rat corpse in the goal location of Rat's Triumphant and move it into wall/floor, than it starts crazingly fast rotations. Please post which mission it is and which exact location (getviewpos) it is. The behavior can depend a lot on coordinates. A config file may also be worthy.

Happy New Year! Interesting to see that I'm not the first one to meet New Year here (with my GMT+7)

GUI nicety is definitely missing. The prototype was created by applying minimal changes possible to make the update work. Of course, no GUI was added: only the existing one remained.

Yes, I saw this. Doesn't matter right now. FM files rarely change. I wonder what those 116 MB megabytes are. I'm afraid my mirror is working weird sometimes... Do not remove keep-mirrors! You did a very ordinary update to 2.06 release: all pk4 files which were different were downloaded from scratch. The codename of TDM 2.06 is release206, that should be put instead of e.g. beta207-01 in tdm_mirrors.txt. Check out the original post, codenames release206 and release205 are available in addition to beta packages. If you have not noticed that, 2.07 installation is about 340 MB larger than 2.06 release (starting from the very first beta). So this is quite expected download size. That's normal. You can probably try to set OpenAL settings in another place?... Or remove the need for alsoft.ini with integrating HRTF on/off switch into TDM That's expected. When a release package is created (whether it is beta or final release), a differential update from the previous release is created. When beta207-03 was generated, differential update from release206 to beta207-03 was created. You can use it only if you have exactly the "from" version, and it carries you exactly to the "to" version. When you updated from TDM 2.06, stock updater applied the differential package. When you updated from previous beta, it simply downloaded complete pk4 files which were changed.

I tried to run updater from TDM 2.06 on my beta installation (not exactly the same environment, should not differ). The self-update worked properly. I guess a log file is needed from our side (the one saved just before you click "Restart" for the first time).

The problem with testing package is resolved. Well, it turned out that there was no problem at all You can now freely use tdm_update to get new beta package. In fact, it is advised to run tdm_update now just to be safe. The new beta release beta207-03 is available. The summary of changes is available here. After update, please make sure that cvars are: r_useFBO 1 and r_fboSharedDepth 0 The problem with heatHaze materials and depth-reading material stages is resolved. Adding maskDepth keyword to such materials is no longer necessary (is it was in 2.05). The keyword has been removed from all corresponding stock shaders. Please test various heatHaze/translucent/postprocessing materials with the new beta, with antialiasing off (and also test a bit with AA on). Another thing which needs serious testing is the Linux build. Whoever runs native Linux build, please check how Alt+tabbing works in various modes (Windowed/Fullscreen). One known issue is that some Linuxes has "Alt" as a hotkey, which somewhat messes with Alt-tabbing. P.S. And if you are feeling lucky, you can try to get beta207-03 via tdmupdate_tdmsync prototype. It greatly reduces download size for beta207-02 to beta207-03 update. Just make sure to configure tdm_mirrors.txt properly and enable two checkboxes if you do so.

As a matter of fact, some sound samples were changed in the second beta (codename: beta207-02). As a result, many sound packages got modified. With stock updater, it is necessary to redownload all these pk4 files when updating from beta207-01, resulting in about 370 MB download. With this prototype, only about 80 MB of data is downloaded. ========================================================================= Differential update from beta207-02 to beta207-03 takes 40 MB of download on this experimental updater. Stock updater downloads 750 MB of data.

Please do not run tdm_update right now! If you have run tdm_update with beta-testing mirrors during the previous 12 hours, then wait for further instructions. The problem is resolved.

Make sure to look into the list at the end of this post. I update it to contain all feedback from this thread.

The need for it arises in different contexts: gamma correction, maybe SSAO, maybe FXAA. We can resist it now, but fullscreen pass will eventually appear anyway We have r_gamma/r_brightness as a general solution which does not decrease performance. It you want to avoid messing with desktop, then you have to do the correction yourself. Which means you have to spend resources on it. Obviously, GPU resources. Then you either add a separate pass for it (expensive), or concatenate it to existing pass (cheap). For a global correction, you can only concatenate correction to full-screen final pass. So either you have one, or your introduce one. "Just render on higher precision" is not so. Format GL_R11F_G11F_B10F won't increase precision on low colors, and anything else means increasing size of all FBOs, meaning more bandwidth and noticeable performance loss. One thing which is worth trying to a postprocessing shader which looks at neighboring pixels and tries to interpolate color after correction, so that those ugly isolines between flat zones got blurred. Of course, this thing means more performance loss compared to simple correction (something on par with FXAA).

It is impossible to NOT suffer from color banding using any global gamma correction. Because TDM has no real HDR yet: all intermediate colors are stored in 8-bit values. The main reason why Duzenko did the correction for ambient light only is that inside a single shader you can avoid color banding since intermediate values are 32-bit floats. Up to the latest moment I did not know that gamma/brightness correction can be done via postprocessing cvars. If it is global and can fully substitute r_gamma/r_brightness (without affecting desktop), it would be great to switch to them in future. Then r_gamma/r_brightness can be forever left at their default values or even removed.

Well, if this is repeatable you can try to record a crash dump. Then I could look at it and probably understand what's going on.

Lowenz wants to say that we can downgrade OpenGL version in NVIDIA control panel. I already ran TDM while tricking it to think it has only GL 2.0 with minimum extensions. But there is major difference between simulating something and running it for real. I think Duzenko wants to know the behavior on the real piece of hardware.