plasticman

[not fast enough] For the comparison shot above I copied all the pro vocals into one file. The peaks go to 0 dB, so overall the set is normalized. The problem comes with the camparatevely high dynamic range, i.e. some utterances are very silent, near the -20 dB mark. For a temporary fix, boosting in Audacity should do -- iirc you can do batch processing from the menu, what will save you a lot of mousework. [/not fast enough] In the meantime I found the culprit in my s_mindistance 0 issue: It's as easy as that, when doom sees the property is set to 0 in the map file it treats it as if it wasn't set at all. As a consequence it falls back to what the shader says. If the shader has no info as well it defaults to minDistance 1/maxDistance 10. (Yes, I tried what happens when you set maxdistance to 0.) What happened to me was the rock_door_loop shader in TDM. It defines minDistance 20. My mapper input s_mindistance 0 made it fall back to that ridiculous high value, that only makes sense as a typo in the shader... ...without it I wouldn't have noticed the issue. I'll see to make the info available in the wiki -- just registered.

I'm not a coder, but what I gather is: it's not broken in the SDK, but enforcing all s_minDistances to a fixed value is possible. While it is not a correct model for sfx, we still want to keep s_minDistance customizable (for ambient sounds). Esp. since it only occurs when explicitly set by the mapper.

Hello?! -- Beep, beep, beep.

I think the base color of the map should be less white, more yellowish. But it looks nice so far.

Thanks for the comfirmation. We can rule out for sure it happens only on my machine methinks. I did some reading on iddevnet and checked a few things in game. I think Orb is right: the volume gets capped on both channels so the sound virtually moves to the center. I consider this a bug in doom, though it only appears once the assets are produced "wrong". Still it should not break the left vs. right balance. The mechanism can be controlled globally via the s_clipVolumes cvar (works instantly without restarting anything) and locally (overriding the cvar) via the unclamped keyword in the soundshader (always wondered what this bes). Any sound that comes with this declaration will not be clipped in doom no matter what the cvar is -- this means it will be clipped by the hardware if it is too loud. So, the purpose of dooms clipping is to prevent overdriving your audio hardware, some sort of "fuse" that normally should not get triggered by the assets. Although volume refers to a decibel value (and thus defaults to 0) there seems to be a little headroom. There are roundabout 3400 shader declarations in vanilla doom that use the volume keyword. Positive values distribute like this: volume / number of shader declarations > 0 : 1441 > 5 : 430 > 10 : 83 > 15 : 54 > 20 : 8 The maximum is 30 (used 2 times). I guess the few with real high values are only rarely used in situations where it doesn't matter, like cutscenes etc.; some of the others are important for gameplay and this is what I think the headroom is meant for, so you can "lift" some of the more important sounds over the usual ambience buzz. How much space there is I don't know. But I assume it does not work like a limiter in an audio app -- they wouldn't waste any CPU resources for audio processing when those are needed for calculating shadow volumes. So it likely does not matter how much dB your sound really is, the audio data gets treated like 0 dB plus what the shader says. If I am right with that assumption the Pro needs some dynamic processing besides fixing in the shader. Here is a comparison shot: As you can see someone had a reason to give the Pro a raise... People just don't SEE those things... There is a cvar to make sounds visible: s_drawsounds. "0" disables it, "1" shows sounds that can be heard at the moment, "2" seems to draw all sounds. This will show a box where the speaker is and label it something like this: rock_door_loop (3/3 2/26) 9That translates to <shader> (a/b c/d) eWhere a is the calculated distance (through doors and portals), b is the real distance (line of sight), c is minDistance, d maxDistance and e seems to be the number of the speaker. This little tool showed me there are quite a few sounds in game that seem to work with a minDistance of 0. But when I set up a speaker in Radiant with s_minDistance 0 it shows up in game with minDistance 20, independent of the other factors (vol., maxdist.). My map file looks fine in a text editor, so it must be (again) doom's fault: minDistance 0 works, s_minDistance 0 gets "converted" to 20. Hope I don't sound like ranting, just wanted to write things down in case I get hit by a train tomorrow...

If you really want to track it down you could try to interpret the POST messages. Usually the manual of the mainboard lists their meaning. If you think the video card is to blame, simply remove it and boot without it. When the POST message signals you something like "found no ram" you know at least that inserting another card won't solve the problem completely...

@Orb: like that. That's not what we want, right? It is mono. I set up four speakers in the map pointing to the same soundshader. The only difference is s_volume. Yes, real sounds do not have a something like minDistance. But we do not locate sounds (like footsteps) only by their volume. You can also tell if a guard in a hallway for example walks from the left to the right. Not by raising it, more by raising and breaking it. When I use minDistance 0 in my map I do not get the desired falloff, more something that sounds like minDistance 10 / maxDistance 26. With minDistance set to 1 I can clearly hear the falloff as it should be (one is close enaugh to zero in that case). The slightly different issue I was trying to point out is: the falloff only works correct (between min. and maxdist.), when volume is <=0. A value like 20 will produce a falloff area that is much smaller like the space between minDistance and maxDistance. The louder the volume, the smaller the falloff area.a center area that is not bound to minDistance and at the same time breaks sound location in the stereo field. The sound becomes omnidirectional (like ambient music, only mono).If for example a guards footstep sound was broken like this and you listen from inside a room how a guard passes by in the hallway, you would get the following: The guard is coming from the left side, you first get hit by a small falloff area where you can determine the sounds origin (left) and that he is coming closer (volume works, every step gets louder). Next you are in the rather big center area. You can not determine where the sound comes from, it is coming from everywhere. You do not hear wether the guard is approaching or leaving (volume is capped). Finally comes the the other end of the falloff, where it works as intended.

Okay, I may have found something. When minDistance is set to 0 it sounds like it falls back to a value that is somewhat maxDistance - x. For a vast speaker setup this results in the unrealistic falloff behavior you described. Inside the boundaries of maxDistance I can locate sounds when volume (or s_volume in DR) is 0 or less than 0. Positive values gradually make location impossible. This starts at the origin, raising the value expands the affected area. It seems to override minDistance, the falloff area gets smaller at the same time and there is no gain in volume from a certain point on. I can reproduce this in Linux and Windows. The attached demo map illustrates the problem. If it's not only me, this means: Volume settings in sound shaders are critical. Unless your sound is omnidirectional avoid positive values for volume (I have a feeling 10 should be the maximum for really loud machinery, earthquakes, thunder, etc).Mappers should be aware of this, because they can override the shader's setting via the s_volume spawnarg.Some shaders need fixing: the "pro"-vocal set defaults to volume 20. It is almost impossible to say where the voice comes from. I did not check what all these s_@x$%! cvars do. If there is a thread/wiki-entry/whatever somewhere buried that can enlighten me about all of these things... sndt.map.txt

Basic pathfinding works out of the box, but it usually needs manual optimizing by the mapper (via monsterclip-brushes). See Wiki.

OK. I sent you a PM pointing to a .zip that contains all the sources and a description. Should be sufficient for anyone to take things up if needed. It definately gets louder with positive values. I tried to get some info on modwiki, but it only says volume sets the volume inside minDistance, not which values are valid. Maybe there is a problem with minDistance being set to 0. Will do a little testing when I have time. In general yes, why throw away the dynamic range? -- For what I am doing here it can be discussed. I tried to fake the object's resonance via an impulse response processor in the mastering section. Therefore I had to set the relative volumes before that section so the comparatively quiet move sounds do not trigger more resonance than you expect them to. That's why chest_wood_close define the peak, and chest_wood_move can barely be heard. Yes, that's overdoing things.

Not sure I get you right, but there are closing sounds. I didn't think of a looped move sound before, so I sure keep that mind. It won't be necessary for the wooden chest IMO. Any movement time > 1 s is way too long for that. But it is sure an option for the old chest, that, discovered in an underground, long deserted pirate cave, opened with an old rusty key that needs to be retrieved from a wrecked ship at the other side of the map, makes a very long squeeking opening sound... @Aprilsister: Thanks for putting it up here. (How come I didn't think of this in the first place?) True. Beside my little testing environment I modified some containers in Outpost to check my sounds in a "real" mission (not the best choice, it lacks ambient sounds and music iirc). If tweaking in that regard is desired I would prefer to do that inside my sound app and provide a "remix". I am using renoise btw., best "source" would be if I sent you the *.xrns (renoise format module), which holds all the source samples, efx-chains etc. -- but if this is not how the repository is organized I am happy to send the waves as well. The only problem is a broken router that my ISP hopefully replaces tomorrow... Thanks. Really don't know much about filehosters, ul.to was my second guess after the big one, which wanted me to register or limit the number of downloads... ...maybe I'll finally have a look at ubuntu one. Another question: I figured the volume setting in the shader has an effect on stereo perception. It seems not only to change the volume. When you crank it up on 50 it sounds omnidirectional whithin several meters. No idea wether this is intended behavior or a bug, nor if Doom or TDM is to blame. It shouldn't be like that, right?

Something. I just finished three sound shaders for the wooden chest. As usual, fan mission format. You can grab it here (uploaded.to, less than 400 kb). I consider this to be ready to get in the mod. Non the less, comments are welcome -- I think I can use the current setup as a base to work from and modify them for the remaining big containers (chest_old, chest_metal, footlocker). No promises on the time frame though -- recording needs time and even more time to bring it in game where you figure it just doesn't sound right... ...I didn't work on this for two months or so when none of my sounds felt right in game. Frustrating when you are not a foley artist, I just ran out of ideas how to make sounds. [whine] And then my headphones died! [/whine] Finally the solution was mixing different non fitting sounds together, including some heavy post production. --

I like how TMA's Children of Karras get philosophical in the very moment you shut down their furnace. ...an error... ...error... ....things to understand... ...creation...

...don't have much to prove my point, but I have a feeling that too many window-sized visportals near each other are prone to bugs. Could be a technical issue or just an effect of the raised chances to introduce vis-leaks.

Cool! Somehow I managed to overlook this more than once... It is not exactly full-screen in the embedded layout -- but it's a wise chioce to keep the inspector windows there. More than happy now.

...no, it's a 2008 japanese action comedy "Legend of the Mask".

Actually I was referring to that sexy "floor me" function in DromEd.

Just a response to the OP (didn't read the thread to prevent getting distracted...): I am using the embedded window layout. It would be nice to have a key that toggles render view to get maximised when needed. For me it could as well be bound together with the actual RMB in render view.Is there a "drop item to floor"-function? I think I have seen something like it in some pretty outdated game editor... Keep up the good work, thanks for rocking it!

The connector doesn't make the difference here. Analog signals may get a little squished when there's a bad connector or a bad cable involved. But from my experience it's useless to buy the even better cable with gold connectors etc. -- the signal quality on today's graphics cards just isn't the same. Only few people still use CRTs, so guess where the cheap parts go... It's not completely dead. Maybe the tech sees a comeback in the consumer segment once OLED fails. (dreaming...)

Rarely seen such a poor thing. I doubt anyone with only half a brain will ever buy anything from a site like this.

models/darkmod/dungeon/gallows01.lwo models/darkmod/dungeon/guillotine.lwo

Loved their regestration form that offered so many gender options. I think I decided to be "Jedi".

It really looks impressive. I think I just fell in love with the art style. Too bad there's so much scripted stuff and it's a shooter.

Alt+Tab moves you through all the windows on the actual desktop. Ctrl+Alt+Tab moves you through all the windows on all desktops. I don't know how things look in Mint, but iirc it's based on Ubuntu. So my guess is look for icon in the gnome panel, right upper corner. There should be "rhythmbox" next to the volume control, when it's running.

That's an interesting take on it, some sort of action photography approach -- just inverted: the camera moves, the scene not so much. Thanks for the idea. It's sure more on the sloppy side of things, but it's always good to explore new options. I will try this the next sunny day from my skateboard. Taking two pictures without a tripod needs a little practice. A usual tip is to stand upright, both feet on the ground, then put your weight on the left foot for the first shot and then shift it to the right foot for the second shot. Also, use the view finder. You can see what is at the top and bottom border and avoid z-movement that way. Sure. You could also get one of those good old ancient soviet made rangefinder stereo cameras (look for FED CTEPEO) and shoot slides... ...the downside is the lack of control over the stereo base, so for me they needed to get really cheap.