stgatilov

I'm sorry but I cannot find your previous report. I have just tried to reproduce it, and the stats look correct, except for Times Saved: 0 despite one quicksave. It is the only problem you have? I hope someone more competent in sound department will look into it.If you explain what exactly you mean, I could create an issue myself. But I don't know what are zoned/unzoned sound, and what do you mean by "filtered" here

Tracked as #4832. The tragedy of shadow volumes is not that they are slow per se, but that their implementation is covered with ifs/branches which are slow on current hardware

Post a screenshot and I'll look into it

I think this problem is solved simply by not using steamworks. People say it is not required to publish game on steam. It would mean no integration with steam, just a game page (like a website) and downloading functionality.

Yes, this is true. When both light source and shadow caster do not move, there is no need to recalculate shadow volumes and send them from CPU to GPU. Moreover, if light source is marked as non-moveable by cvar, then dmap probably precomputes shadow volumes for static models and brushes. On the other hand, I often see light sources which constantly move around slightly (e.g. fireplaces). They should be as costly as light sources attached to physical things like chains.

In terms of performance, it is unlikely that a light source hanging on a chain is more costly than a static shadow-casting light source. At least, I don't see how it could be more costly. Shadow volumes are not reused between frames: if your light is shadow casting, than its cost should not increase due to movement.

Ok, added feature request: 4815

Well... almost We forgot to create 64-bit tdm_update.linux, so Linux gamers still have to install 32-bit runtime to install/update TDM (issue 4807).

For cleaning up, the best idea would be to delete everything which was hacked on and start from scratch I mean: remove both TheDarkMod executables, both ExtLibs dlls, the file alsoft.ini. Then backup your darkmod.cfg and delete it too. Run tdm_update and then the game itself --- after that you'll have fresh 2.06 installation. Then open the backup-ed darkmod.cfg and copy whatever you want from, mainly key bindings (all the lines starting with "bind"). The less clean approach would be to review all the posts in this topic and check if the corresponding modification is still present. If yes, then restore it to original state. Most importantly, revert all changes to cvars starting with "r_". BTW, you need the modified shaders for shadows to render properly. The ready-to-use archive was provided in this post --- maybe you should start with this.

You can try to disable rendering during quickload. Run this command in console (given that F10 is not bound to something else): bind "F10" "r_skipRender 1;loadgame quick;r_skipRender 0"Now when you press F10, it will first disable rendering, then quickload, and finally enable rendering back. Maybe it would help you. The other option is to record a crash dump. Either do it from process explorer or download procdump and run procdump.exe -i before starting TDM.

Ok, I think s_force22kHz is enabled somewhere, but strangely not in darkmod.cfg. Check the autoexec.cfg file. In fact, having autoexec.cfg is not a good idea at all, especially for setting cvars: all of them can be set in darkmod.cfg. Anyway, find and remove seta s_force22kHz "1" line. UPDATE: created issue 4814 Thank you very much for your patience!

Great! Here are your calls: alBufferData: 261 2 7BAFC066 8820 22050 alBufferData: 262 1 27CBD3C2 10000 22050 alBufferData: 263 1 1B8C3CE4 13145 22050 Here are my calls: alBufferData: 261 2 C4C3EC82 17640 44100 alBufferData: 262 1 D7C91279 20000 44100 alBufferData: 263 1 4313D51E 26290 44100 The last argument is frequency, the prelast is size of buffer in bytes, which must be even. As you see, on my config all files have 44100 Hz frequency. But on your config all files have 22050 Hz frequency, and all their lengths are halved. As a result, the third wav file has 13145 bytes of data (which must be even) --- this is an error. Now this gets much more clear. Hardware and drivers are not culprit, this is a TDM bug I think. We need some configuration guru to tell us why the samples are at 22Khz on your machine If we force back 44100 Hz frequenceyof wav sounds, the problem should disappear. I'll go to sleep for now

Oh please, could I have a condump taken after mission load failed?

You can download a special build of TDM 2.06 here. I have made two changes: 1. Whenever TDM calls alBufferData in the place where the error happens, all the calls are logged to TDM console (along with all arguments). 2. alBufferData must now print a message into openal_log.txt which shows where exactly this error happens. So after you download, replace the original exe and dll with these two (either backup the original files, or run tdm_update after everything ends to restore originals). Remove the alsoft.ini --- it does not help us. Then run the game via .cmd file and start mission. After it drops you to main menu, make a condump and exit game. Finally, attach both openal_log.txt and condump file. If this won't shed light on the reason of your issue, I am lost Maybe we should summon kcat to help us then...

The file that you downloaded from forum does have an additional .txt extension. Recall that windows explorer does not show you the last extension of a file by default (unless you disabled this stupid "feature").

The config file did not take effect. Ensure that you placed file into proper place (and removed the .txt extension!) If it takes effect, you should see something like this in the openal_log.txt: AL lib: (II) ReadALConfig: Loading config D:\tdm_update_win\alsoft.ini... AL lib: (II) LoadConfigFromFile: found 'drivers' = 'winmm' AL lib: (II) LoadConfigFromFile: found 'decoder/hq-mode' = 'false' AL lib: (II) LoadConfigFromFile: found 'decoder/distance-comp' = 'true'

Nothing revealing, unfortunately The log shows that your device uses 192KHz frequency, which is quite high (44.1 KHz is sort of default). So I suggest tweaking openal-soft configuration. First, let's try to switch to another backend: mmdevapi is used by default, and we will try winmm now. Download attached file and save it as D:\tdm_update_win\alsoft.ini (I guess darkmod is located in this directory). After that start darkmod via .cmd-file and try to start mission. Finally, post the new openal_log.txt here. The config file has one line which specifies backend: # won't be considered for use (e.g. '-oss,' will try all available backends # except OSS). An empty list means to try all backends. drivers = 'winmm' So if winmm does not help for you (i.e. mission still not loads), you can also try other two backends: dsound and wasapi In order to try another backend, simply replace winmm inside quotes with corresponding name. alsoft.ini.txt

Nothing suspicuous, unfortunately. You can try to disable experimental settings (especially "multicore" and "uncap FPS") if you have them turned on. If you have NVIDIA's "threaded optimizations" enabled, better turn them off. You can also post darkmod.cfg.

Create a new file run_with_openal_log.cmd in the same directory where TheDarkModx64.exe is located, paste the following into it: set ALSOFT_LOGLEVEL=3 set ALSOFT_LOGFILE=openal_log.txt TheDarkModx64.exeThen execute this .cmd-file instead of running .exe directly. It depends on encoding. In your case the name is encoded in UTF-8, so you should open it in UTF-8. If your editor (e.g. notepad.exe) opens the console log in win1251, then you won't see anything good. I think the best idea would be to copy/paste the name of the device from console log into darkmod.cfg, then adapt it with this "seta s_device" and put quotes properly. The game does not know anything about the encoding, I guess it only looks if the bytes are the same. No. I also have russian Windows and the names of OpenAL devices are also partly in Russian. To be honest, I'm not sure exactly what nbohr1more tries to achieve. The game enumerates all the enabled devices (their names do not matter at all), then chooses one of them as it sees fit. Now if you want to specify the particular device using "s_device", then you have to specify its name (that's how the game will know which one you want). However, the last time when I checked, all devices which are disabled in Windows are invisible to OpenAL. So specifying one particular device with s_device should be equivalent to simply disabling all other devices in Windows (which is much easier). You can even check this by looking at the game console when you disable all the other devices: if it contains only one "OpenAL: found device" message, then you can be absolutely sure that the game chooses this device.

Issue tracked: 4812 Thank you for the fix! Someone will integrate it into SVN.

If I'm not mistaken, this timeout limit is set on single frame, i.e. if your GPU computes for 2 seconds (default) without response, then it is killed. It is unlikely that a normally playable game can suddenly start rendering so slowly that one frame takes 2 seconds. It sounds more like a bug of some sort which causes GPU to hang...

I think the most relevant page is this one. On the other hand, most of the information is probably short-lived, given that 64-bit executable is going to be provided in future. Not sure about wiki access though, perhaps it is not public. Yes, it will be enough to compile the game. The assets are downloaded by tdm_update (the pk4 files): they are completely separate from the executable. So you simply take the stuff downloaded by tdm_update, then overwrite the included binary with self-built one and it would work.

I like this idea too. Because when running TDM inside a virtual machine, mouse does not work properly Those "turn left/right" keys are what I use to navigate through levels. UPDATE: If there are no objections, I'll create a feature request?...

This file is more like debug info for developers, it does not contain anything interesting now. Better post console contents. Open darkmod.cfg and add a line at the end (don't forget to remove it when investigation is over): seta logFile "2"Now run the game. After it crashes, look at file fms/<name_of_mission>/qconsole.log. Attach it here as txt. P.S. There is also a way to record crashdump, but that's quite tedious (if the described approach even works on WinXP). So let's start with console log described above.

Yes, exactly. SVN trunk is also OK, but it would be safer to download release2.06 branch from SVN if you only want to build 2.06 yourself.