stgatilov

Yep, the situation about scissors test is: shadow volumes without them would be awfully inefficient. The question remains whether any scissors usage causes this issue, or we can change something a bit so that the problem disappears. The warning about PBO is interesting, and the second warning is probably related. But it should be considered by looking into mesa source code (it is easily googlable by error messages). Probably Duzenko could do it if he wants. Anyway, this info is a bit too hardcore for generic discussion about "TDM 2.06 issues" Probably we should restrain ourself from talking about it here and move the question to e.g. PM.

Nope. I have just downloaded 2.06 sources archive from website. Here is what I have in C:\TheDarkMod\darkmod_206_src\unpacked\tdm_update: It is easier to maintain three build configs than to maintain two completely separate scripts. Anyway, there is no intent of changing the way tdm_update works. P.S. It seems that such pranks were popular on our childhood

Ok, I can reproduce it on my machine on 2.06 x64 build. I simply set "Fullscreen" to "No", then "Screen Size" to something like "1280x720" and click "Restart Game". It restarts and shows a properly sized window initially (for half a second), but then it quickly switches back to fullscreen with original resolution. If I stop the game and then start it freshly, it also does the same: switches to fullscreen. Indeed, the game is alt-tabbable. But it covers full screen and it is not possible to see it alongside other stuff, e.g. DR. This happens for me only when r_useFBO and antialiasing are both enabled. When I disable either of them and restart engine, it runs in windowed mode. The situation is further complicated by the fact that disabling r_useFBO is not easy for NVIDIA user , because he also has to disable soft shadows beforehand (and the only way to guess it is to read the 2.06 release notes ) Given the mess with configurations which we have in 2.06, I think this is not an urgent issue. I'm glad that everything works properly and nothing crashes I suppose that instead of fixing this with introducing yet another hack, we should move steadily to FBO-only renderer with proper multisampling support. On the other hand, this issue is probably worth tracking anyway.

The updater is not a script because it exists on both Windows and Linux with most of the code reused. Can't imagine how we would ask every Windows user to run a python script (or shell script) and be happy Not to mention that some of the stuff there is not quite simple... Of course, lack of Linux 64-bit binary updater is a problem which should be fixed.

COMPILE.txt does not explain how to build tdm_update, it only explains how to build the game itself. I think you are running scons from wrong directory. Go to darkmod_src/tdm_update and run there scons build="release" -j4. This should build the 32-bit executable for you. Now download the attached two files and replace the original versions with them (indeed, remove the .txt extension). After that run scons command again. Hopefully, you will get a 64-bit executable. P.S. This is hacky and unofficial, you know... SConstruct.txt SConscript.tdm_update.txt

Thank you for report! Yes, it seems that we simply forgot to provide 64-bit build of tdm_update, as silly as it sounds. I have created issue 4807 for this, so this will be fixed by 2.07. Not sure about 2.06 hotfix though. A possible workaround is to install the standard libraries for running 32-bit stuff. We have an Ubuntu-oriented instructions of how to compile 32-bit TDM on 64-bit Linux (the page). While most of those libraries are not necessary for just playing, I guess simply installing all the stuff is an easy enough fix for now.

I think console dump and fms\missions.tdminfo would be helpful.

Note that you must enter the name exactly as it is printed in game console. I think the effect would be same as if you disable the other two devices in Windows, but worth a try anyway. We have a clear problem with OpenAL: for some reason it does not work on Anderson's machine. This is strange, given that we use openal-soft, which should not depend on hardware. There is a chance that tweaking openal-soft config can help (maybe switch to another backend), but it is very complicated. Perhaps the best thing which can provide more info is to get internal logs of OpenAL. Set environment variables: And run TDM. Then try to start a mission. Find the openal_log.txt file (it should be created if you properly configured env.vars) after you exit TDM and post it here.

You can try to change sound device. 1. Set s_nosound back to zero. 2. Disable some sound devices in Windows. Probably it is the best idea to disable everything except one set of speakers. 3. After that launch game and check these lines in console: If I am right, you won't see disabled devices here anymore. 4. Try to run mission again. I think "Realtek High Definition Audio" is the device that should be used. The other devices look as either virtual or recording...

Toggling this cvar in-game does not change anything. I believe it only matters during game startup: if this cvar is disabled, then the whole sound system is not initialized, and there is no way to get any sound afterwards. Toggling volume should work well as a workaround: toggle s_volume_dB -1000

Nbohr1more, could you please elaborate which this is necessary? or at least why it helps? I have TDM running in windowed mode almost always, with FBO, nvidia, soft shadows. Never had any problems. It is bad that it does not work for someone, especially since we plan to switch to FBO-enabled only in 2.07. I think this is caused by migration to OpenAL. If you find the new behavior annoying, the best thing would be to post a feature request in bugtracker --- then it can happen by 2.07

Anderson, I see that you gave up this effort. But I would be especially happy if you try this cvar. It disables the sound system completely: if the game runs after this, we will be sure that sound system is the culprit. Note that you have to set this cvar manually in Darkmod.cfg: setting it in console won't work. Alternatively, it is possible to disable all sound playback devides in Windows, but this is prone to errors.

It does not depend on EFX. All sounds are played with this OpenAL code now. Let's consider the simple cases first. Could you please open tdm_sound_sfx02.pk4 file, find the wav file TDM complains about (sound/sfx/movement/footsteps/player/grass_walk_r02.wav). Just look it at, write its size to us. Try to play it directly with any player and confirm that sound is OK. Also, you can try to rerun tdm_update --- if the file is wrong, it should redownload something.

I doubt this is a shader compilation problem, because GLSL errors usually only cause shaders to not work, they don't drop the whole game. Could you please also post console dump after trying to start mission? There is high chance that the game prints some useful info to console when the problem happens. Are you sure there is nothing of interest in console after a mission drops? I compared condumps, and the different lines are: Couldn't find proc address for: wglBindTexImageARB Couldn't find proc address for: wglReleaseTexImageARB Couldn't find proc address for: wglSetPbufferAttribARB ...PIXELFORMAT 4 selected Max active textures: 16 X - EXT_depth_bounds_test not found Couldn't find proc address for: glCopyImageSubData The missing gl functions may be a problem...

Do you mean objective performance (FPS) or subjective performance (laggier response to controls)? Speaking about new stuff, you can try to disable soft shadows and antialiasing to check if performance returns back to old level.

Probably Theoretically, a video is still just a material which can be put on objects. The concept did not change in this sense. So you can probably do with new videos whatever you could do with ROQ, even texture 3d objects with them. If you use embedded sound, then it gets a bit more complicated and fragile. But I did not test anything except replacing the single-mission briefing cutscenes. If you test some non-standard scenario, please write here about it. I would like to hear both positive and negative outcomes. In the positive case, I'll know what is possible, and in the negative case, there is a chance to fix it in future. The video cutscene inside mission does not sound any different from normal briefing cutscene. But since there is no stock GUI code for in-mission cutscenes, you will have to set up GUI yourself. Applying videos to GUI elements is exactly how things work internally. You can specify a material to any GUI element, and you can use e.g. a looping video for a button. But I think having too much videos is not a good idea. BTW, there is a FM "Score to Settle", where two looping ROQ videos are being played on same screen with GUI text around. And it plays well with FFmpeg playback. Note that in 2.06 all videos (including ROQ) are played with the same FFmpeg code. The old ROQ-playing code is no longer used (but can be enabled by cvar).

I am hesitant to rename a wiki page, because it will change its url. This is the original title.

The sound system in TDM version 2.06 has been switched to OpenAL on all platforms. It means that the environmental effects (formerly known as EAX) can now be used by everyone with no requirements on sound hardware. This wiki page explains generic pipeline about setting EFX in your map. Also see this Judith's post for some ready-to-use presets. For now the best approach perhaps is to copy/paste these presets into EFX file. If you have any problems or questions regarding EFX, the most suitable people to ask are: me and Judith. The Judith's topic is the recommended place for discussing EFX presets and properties. P.S. Do not forget to enable OpenAL EFX in the main menu

In 2.06 you can use standard video formats for cutscenes: no need to mess with long-forgotten ROQ any more. This wiki page explains how to set it up, including the question how to play audio embedded in the video file. Note that video files must have extension .mp4 or .m4v or .avi, other extensions won't work properly. P.S. And in case of any trouble with this feature, I am the most suitable person to ask.

I have tried to update the wiki page and realized that the whole system is quite messy. This awful system of translating one values to other values, with total confusion of EAX / EFX values... And no presets, that's why Judith had to translate them by hand (sorry for that). I simply don't know how to update the section on properties now. I think for 2.07 it would make sense to do the following: Implement a new set of properties, which will have exactly the same names as the EFX constants (without the leading "AL_EAXREVERB_"). These properties would be passed to EFX as is, no need to convert bells to dolls. Implement a "preset" property, similar to what "environment" property meant before EFX update killed it. Enumerate all presets listed in efx-presets.h and make them all available by number. All of these changes will be available when "Version 2" is specified in the first line of the file. The "Version 1" definitions continue to work as they do now (forever).If we do this, then we can simply reference the OpenAL EFX manual in wiki, which already has detailed explanation of all properties. Also, we can list preset names with their numbers in the wiki --- mappers will most likely simply use this number. The number of available presets will increase of course. The possible downside is breaking compatibility with Doom 3 and EAX (although kcat recently noted that at least one property is converted incorrectly from EAX to EFX, so EAX compatibility is not perfect now). But I have a feeling that both are rather dead now, so maintaining this compatiblity does not provide us with any additional knowledge of EFX. P.S. If we recall another TODO for 2.07, then it is a global revision of all stock sound shaders and putting no_efx in some.

Is there a way to run some console command repeatedly? For instance, I want to reload sounds every second, so I write into console something like: repeat 1000 reloadSoundsContext: I'm revising the wiki page about EFX.

When I try to open it for the second time, the window loses focus, and I start seeing my mouse cursor (which no longer affects player orientation). If I then press tilde again, TDM gets focus back. For the whole time, TDM renders without any problems just as nothing happened. Maybe that's not a TDM problem at all, maybe I just messed somehow with generic Windows interface

I have problems with opening console in-game in windowed mode on the current trunk. Probably due to these changes?... The console opens by tilde the first time, but it does not open after that (and it I spawn main menu, it opens there). I hope I'm not alone who has the problem?

I'll probably say that making beginner's mapping resources even more accessible is not good The reason is: playing is easy, mapping is hard. It is much more important that the forum is easy to explore for newbie players than for newbie mappers. First of all, I suppose that few people come to forums with mapping already in their mind. Most are only playing the game at this moment, and come to mapping later (if ever). Second, I have heard that a lot of newbie maps never get released due to various reasons like: starting overly ambitious map / heavily underestimated the amount of effort needed. So it is probably not a good idea to push mapping over beginners: it's better if they gain some courage and patience before starting mapping (enough at least for overviewing wiki, forums, videos).

Calling me? I think we discussed enabling FBO automatically when soft shadows are enabled, but did not do it for some reason. Perhaps because it becomes cvar mess this way (no one knows how to disable r_useFBO back when r_softShadows is disabled --- player definitely won't know about it). And we did not enable FBO by default because it lacks builtin antialiasing. I usually enable FBO and play with it, and I don't remember any issues caused by it lately. In fact, the case when FBO is disabled feels more fragile now. P.S. Half a year ago I thought that 2.06 release was coming soon, but it has not been released even by now. I won't say anything like "it seems too late" anymore, because I was wrong with it so many times