stgatilov

First of all, you should not use the whatever osx branch which you see in SVN: most likely, it is too old. Use either release2.06 version or trunk. Second, there were some instructions for compiling macosx version in the old compilation guide. Go to the compilation wiki page, and expand a section at the very end of it. Then find text about macosx there. Note that 2.06 changed a lot. For instance, there is no thing like game pak any more. Also, the guide mentions MACOSX_TARGET_ARCH, but I guess I removed it from scons, because 1) more generic TARGET_ARCH is now present, and 2) I hope no one needs ppc binaries any more.

Attention to everyone who has started creating new videos or intends to do so before 2.07. FFmpeg is a huge library with tons of codecs and formats, and the actual set of supported formats greatly depends on how it was configured. It is hard to keep this set constant over time, which can potentially result in breaking TDM cutscenes regularly in some distant future. To avoid breaking maps, there is a plan to restrict the set of supported formats/codecs to the bare minimum. This way the chance of breaking existing video files should become much lower. Unfortunately, the unrestricted FFmpeg is already released with TDM 2.06, so the restricted version will be used starting from 2.07. It means that if you now add FFmpeg cutscenes in wrong format to your missions, then they won't play in 2.07. This is why your attention is important here After some internal discussion, we decided to start with this set of codecs and containers: containers: avi m4v mp4 roq video codecs: h264 mpeg4 roq audio codecs: mp3 aacAs you see, it provides two options in each domain (in addition to legacy roq). One option is usually the most widespread currently (i.e. mp4+h264+aac), and the other option is something which was popular in the past (avi, mpeg4, mp3). BTW, all the above-mentioned codecs (except roq) are patent-encumbered. Our conclusion is that it is not a problem for TDM given that the game is free and will remain free for eternity. There exist completely free codecs and formats (ogg+theora+vorbis and webm+vp8+opus), but it seems that they are so unpopular that it is hard to find a converter which could create such videos. The plan is to come to final conclusion about the set of codecs/formats in the nearest future. After that I'll probably release a tool (e.g. ffplay.exe) which could be used to check that a video is going to be playable in uncoming TDM 2.07. If you already have done some work for compressing videos for TDM 2.06, please check which container, video codec and audio codec you used. Any comments on the situation are welcome

Fixed in svn rev 7478. Of course, you can simply comment the problematic static_assert-s as a workaround.

It is not asm, it is my code with SSE instrinsics. It seems that offsetof should solve the problem.

Any suggestion about how to get offset of a member in a struct in bytes, so that it is compile-time constant?

As you probably know, TDM 2.06 still works on Windows XP. We had an issue that the latest tdm_update did not boot on Windows XP. There is a fixed version. If you need it, please PM me. The current idea for the future 2.07 version is to allow running it on Windows XP too. However, this support cannot last forever. Windows XP support by Microsoft ended in 2014 (though hacks can probably extend it to 2019). A lot of libraries (including the ones we use) have already dropped support for Windows XP. For instance, FFmpeg has dropped support in version 4 released two months ago. There is no prebuilt version of boost for MSVC2017 with XP support. Microsoft Visual Studio 2017 can still build stuff compatible with Windows XP, but it is not clear when this will end. The idea is to drop Windows XP compatibility by TDM 2.08. This is not the next version yet unreleased, but the one after it. So I would like to ask everyone: who still runs TheDarkMod on Windows XP? If yes, then what do you think about dropping Windows XP support? Do you have a plan to migrate to newer version of Windows (or to Linux) ?

I assume you created a tracker issue for the reported problem, so it would be great to post the link here

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.