stgatilov

This is reported as issue 4693. Initially FBO was required to make soft shadows work. Then Duzenko hacked them into the case when FBO is off. As you see, they are far from perfect (random flickering squares, often light leaking). I guess it's better to discuss in the soft shadows thread, not here. But yes, if computed blur radius is 3 pixels, having 96 samples spread over 30 pixels is overkill. High number of samples gives benefit only when effective blur radius is high (e.g. if you set "r_softShadowsRadius 10"). I have a feeling that main confusion here comes from the fact that we have too many options in GUI setting for soft shadows. Perhaps we should simply limit the choice to three cases: 0 (none), 12 (medium) and 24 (hard). This should be enough for normal gameplay and not tough for GPU. And if anyone wants more, he can set any number he wants by cvar (just like soft shadow radius).

Speaking of soft shadows, set Medium and be happy. If you see separate lines on the shadow boundary, try increasing to Hard. Anything above is excessive in my opinion. I guess this is caused by soft shadows also. There is an issue 4660 which describes a similar problem. If you see the problem in other places, please report them there. And if you manage to isolate the issue (create a small testmap with it), I will be happy Or at least give some idea in which cases it happens. Also note that: 1) the problem happens less often with "r_useFBO 1", 2) the abovementioned issue contains a workaround which helps in some cases.

I also have a feeling that excluding some clearly non-EFX sounds won't take much time. I mean, at least, all menu/UI sounds, all ambients.

Yes. Maybe. I think there is not too many sound shaders, putting no_efx flag to some of them won't take much time, but testing them can take days. Mappers would have two options: Leave all sounds with EFX, as if this discussion never happened. Completely override every sound shader that they don't like to be affected by EFX. I.e. put same-named shader file info their pk4, which I suppose would create FMs with unchangeable sound shaders.I have a feeling that second options is even worse that the first one in the long run. Anyway, I need to know: should the "no_efx" flag be added to 2.06 or leave it for 2.07?

How is dmap working in the beta? Have you met any maps on which dmap crashes? As of now, Bikerdude's WIP seems to be the only map with serious dmap issues (as noted in 4661).

Lifting a tiny bit does not help. I'm mainly concerned about the issue when r_useGLSL = 1. The case with ARB shaders is not so important, really.

The config file. Also, I have noticed some weirdness with lighting. This is with r_useGLSL = 0 (table is not lit): And this is with r_useGLSL = 1 and enhanced interaction: If I switch to "default interaction shader" in menu, than the whole table is lit properly. EDIT: I can reproduce these issues with the table on SVN version (but not the sky issue). It is Inn Business, second floor, third door from the main enterance.

Sky is broken on the latest beta, when "r_useFBO 1" is set: It seems that something it not properly cleared between frames. Moreover, having bloom enabled iteratively increases sky brightness until completely white color.

I agree with freyk. Removing features and proper architecture for the sake of some tiny optimizations (well, do they give +20% FPS?) is a simply the wrong way to go. If you do microoptimizations, please be sure that they don't break anything.

No, the issue 4661 is not worked on currently. I have just written my ideas about it in the issue. If you have any other maps with dmap issues, please let me know.

No, not yet. I think it would be as soon as there is some certainty that the way we try to solve the issue now really works.

No, I mean files with .vs and .fs extensions, not the ones with 'P' at the end. Sorry for the error: there is 'S' instead of 'P'. Yes. That is the purpose of all the repacking mess at least.

Let's try to set versions manually. Go to into tdm_base01.pk4 (it's just a zip archive), then go to glprogs/. Now you need to set "#version 130" at the beginning of each .vp or .fp file where it is not present. Where #version line is already set, change the number after it to 130. Absolutely no idea what this means. If graphics still does not work after setting all versions as described above, try to delete the shadowMap.gs file inside glprogs.

I don't agree with you. Testing on a single map is not a good solution. EFX is not like gamma correction. For gamma correction, you do it once either in your texture, or in your engine. In any case, you only have to ensure that it is done exactly once, but it does not matter where. EFX is like lighting. You can bake lighting effects into texture (e.g. lightmaps or ambient occlusion), but then you loose the ability to change light sources around it. As a result, a texture with baked lightmaps can only be used in a single place on a single map. If we bake reverb into a sound, it looses the ability to reflect the environment around it. It would sound well in one place, but weird on another place. The fact that a sound with baked reverb sounds well without EFX when you are in one particular area (with some EFX effect) does not mean that it would sound appropriate without EFX in all other areas (with different EFX effects). Of course, this also depends on how different are the EFX effects you can create. If all of them are mostly equivalent to "apply reverb of strength X", then maybe it does not really matter. So the only "correct" solution is to decide which sounds should logically be affected by surrounding environment, and which should not. If any sound already has reverb and must be affected (or has no reverb and must not be affected), the only "correct" solution is to fix the sound sample. The problem is that this "correct" solution may be too hard to achieve, so we need some ad hoc solution for 2.06.

Isn't SEED's main purpose to merge all individual entities into single mega-entity, in order to workaround the entity limit?

Added support for "no_efx" keyword in SVN rev 7337, binaries updated in SVN rev 15109. Everything is ready for the sound shaders review. Recall that you can type "reloadDecls" in TDM console to update sound shaders without reloading TDM. Theoretically, the engine allows overriding some sound properties on sound emitter by setting spawn args (e.g. s_volume or s_omni). I did not change anything there, so it is currently not possible to override no_efx setting. Even if I add support, it would be one-way: spawnarg can turn EFX-affected sounds into no_efx sounds, but not vice versa.

From theoretical perspective, each sound which is physically present in the game world and is emitted close to the player must be affected by EFX. The following things should not be affected: the internal "thoughts" of the player, in-head player sounds, generic ambients, menu + inventory + objective sounds, probably even distant sounds like storm. The following things should be affected: weapon unsheathing, probably rats sounds + every sound which may be heard by guards. As for body shouldering sound, we have to decide if it is in-head sound or not. If it is not heard by guards, then it would be more logical to consider it "in-head" or "helper" sound and exlude it from EFX. EDIT: listened to shouldering sound, it seems to be a technical thing (like inventory sounds), not a physically present sound. As for weapon switching, I'm not sure if this is a real sound in the world, or just a "helper" sound to tell player that the weapon is changed.

Unless there are any objections, I'll implement support for no_efx flag in sound shader (tomorrow). I'll commit it to SVN. After that someone has to review existing sound shaders and set the flag where appropriate.

There are several possibilities for EFX setting: 1. Mark sound shader which must not be affected with special "soundClass". soundClass is already parsed by TDM. Here is description about sound classes (only classes 0, 1, 2, and 3 are possible now): // sound classes are used to fade most sounds down inside cinematics, leaving dialog // flagged with a non-zero class full volume const int SOUND_MAX_CLASSES = 4; 2. Set a flag in sound shader of existing type. Here is the list of all flags currently parsed by sound shader: no_dupsno_flickerloopingno_occlusionprivateantiPrivateplayonceglobalunclampedomnidirectional 3. Add a new flag, which we would set in sound shader to disable EFX effects on sounds. Just invent a name for this flag (different from existing ones), and I'll add it --- that's simple.

The menu sounds are not affected because they live in separate idSoundWordLocal. So their sounds are completely independent. All the rest is affected by EFX. If does not matter whether sound is spatialized (i.e. has 3d location) or not (i.e. is just ambient thing without location): weapon sheathing is not spatialized, but it is still affected by EFX. It is not hard to selectively disable EFX for some sounds. At the moment where we need to decide whether to apply EFX effect or not (see the code snippet above), we have access to: idSoundChannelidSoundShader: all parameters (min/max distance, volume, shakes, soundShaderFlags, soundClass), shader filename, even description (e.g. "Made by comp-music"), idSoundSample (the one being played + all described in sound shader): filename, format, size, whatever.We can set any rules we want there --- there is no technical problem. As a proof, I have disabled EFX on all non-spatialized sounds in svn rev 7333. But I'm not sure that it is a good idea.

I'm afraid there is nothing like "EFX spawnargs". He is investigating the parameters in EFX file. EFX file can only specify location where each effect is applied, it does not allow to set any conditions like "affect only such sounds".

EFX code is not looking at anything, I'm afraid. There are many "effects", one effect per EFX file entry. There is a single "auxilliary effect slot" called "listenerSlot" (see snd_world.cpp). As far as I understand the OpenAL system, you attach an effect to a slot (using alAuxiliaryEffectSloti with AL_EFFECTSLOT_EFFECT), and then you send any sound sources into this slot to get them affected. Look where "listenerSlot" is used in snd_world.cpp. Excluding Init and Shutdown, there are only two other places: Here engine sets the effect for the slot: // only update if change in settings if (listenerEffect != effect || justReloaded) { common->Printf("Switching to EFX '%s' (#%u)\n", s.c_str(), effect); listenerEffect = effect; soundSystemLocal.alAuxiliaryEffectSloti(listenerSlot, AL_EFFECTSLOT_EFFECT, effect); } And here the sound sources are sent to the slot: if (idSoundSystemLocal::useEFXReverb) { if (enviroSuitActive) { alSourcei(chan->openalSource, AL_DIRECT_FILTER, listenerFilter); alSource3i(chan->openalSource, AL_AUXILIARY_SEND_FILTER, listenerSlot, 0, listenerFilter); } else { alSource3i(chan->openalSource, AL_AUXILIARY_SEND_FILTER, listenerSlot, 0, AL_FILTER_NULL); } } I see no checks around this piece of code, so it seems that every OpenAL source is sent into the slot and is affected by the EFX effect.

An urgent question. Could someone take the latest beta build on Linux x64 and check if saving and loading game works ? EDIT: it seems that savegame compression code still has 64-bit portability issues, which may results in crashes on save/load

I think it is only used by in-game GUI editor. You can type "editGUIs" in console to launch it. It does not seem to work though.

These are the parameters which express "gain". All of them are converted between TDM and OpenAL the same way. In OpenAL, you specify the gain factor F. It means something like "the loudness of this thing is F times greater than the generic loudness of the sound". So, it is just a plain ratio between two volumes, i.e. the sound pressure. In TDM, you specify things in millibels, which is 1/100 of decibel. Decibel is logarithmic value typical to measure difference in sounds volume. Here is the conversion: each 2000 additional millibels increases gain in 10 timeseach 200 additional millibels increases gain in pow(10, 1/10) = 1.258... timeseach 20 additional millibels increases gain in pow(10, 1/100) = 1.0232... timesFor example, -2000 millibels converts to 1/10 gain factor, -4000 millibels converts to 1/100 gain factor, and -6000 millibels converts to 1/1000 gain factor.