News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
That Sound About Right 
With pie slice floor texture.

I think it can't work vertically though, only horizontally. 
Iris Example 
And For Not QOOLE Users 
Re 9743 
that's not a real iris though. a true iris has pie shapes that rotate outwards.

http://www.youtube.com/watch?v=rskukxKo5UI

but yeah, what preach said works pretty good and looks really cool when opening and has the benefit of working as a vertical door. a lot of sci fi use doors like that. 
Sweet 
yeah you guys were right, it was just the spaces in the texture names. Awesome now I can finish these maps. Yay! Now here's the situation I'm in. I'm using the Nexiuz textures, the originals are 2x the size of the recent Q1 conversion ones, so I want to keep with the originals since otherwise my texturing will be messed up everywhere. I guess my question is, what would be the best way to replace the spaces in the names of the textures in the original wads with _'s, or, is there a Nexiuz texture wad available for Quake with all the textures in the original sizes? 
 
just run them through irfanview to shrink them, it's free :) 
Search/replace 
Wordpad. Or, if the map file is too large for it, a text editor like Notepad++ for example. 
All Your Bases Are Belong To Notepad++ 
 
Alright 
fixed the texture names, now I just need to convert (some of) the original nexiuz textures to the Q1 palette in their original sizes. What's the best program to do this? 
Or 
if anyone wants to do me the favour of converting these textures you'll be rewarded with a couple new Q1SPs, heh. 
Texture Conversion Tool 
TY 
now go invent some other weird creepy sneaky Q1SP stuff :) 
Weird Question 
what is the formula to calculate the maximum distance a sound can be heard?

i don't think volume plays any part in it, just attenuation.

i have some looping sounds that may start when the player is beyond hearing range. if this happens, the engine doesn't register the sound as playing so i need to continuously check if the player is entering hearing range, but the check is done on multiple types of entities with different attenuation values, so i can't just use a flat range. 
You're 
On a higher level than me. But from that question my advice would be change engine. 
 
ask LordHavoc, Spike, mh or metlslime?

The problem where Quake stops playing sounds when the player is out of range (and continues them weirdly when he returns), is, er, a problem. 
 
whoah, we made a good show here. 
 
what is the formula to calculate the maximum distance a sound can be heard?

I never figured this out, in the end i just experimented with different distances until i found one that seemed right. 
 
i asked on inside3d, so we'll see. :)

i just experimented with different distances

i would do that if it was only one sound, but i will have multiple sounds at multiple attenuations, and it would be unlikely that i could guesstimate all differences accurately. 
Sound Thinking 
We can pick atten to lie between 0 and 4. The engine now defines:

nom_atten = atten / 1000

dist = nom_atten * length(sound.origin - player.origin);

So the crucial thing here is to notice how the attenuation affects the distance.
Attenuation 2 samples are effectively twice as far away as attenuation 1 sounds.
Attenuation 0 sounds are always treated as distance 0 away.

The next thing you need to know is that the volume is multiplied by
( 1 - dist) * rscale in the right ear and (1 - dist) * lscale in the left ear.

rscale is equal to 1 + v_right*normalise(sound.origin - player.origin)
lscale is equal to 1 - v_right*normalise(sound.origin - player.origin)

Don't worry too much about what rscale and lscale mean, just be aware that they are never negative and sum to 2.

We need to compute when both the left and right ear go to zero volume, as in that case the sound is not played.
We know that lscale and rscale are never both equal to 0. So the only case we need to think about is

1 - dist <= 0

this implies that
dist >= 1
so
nom_atten * length(sound.origin - player.origin) >= 1

atten * length(sound.origin - player.origin) >= 1000

It is best to keep the inequality in this form, so that you don't have to worry about dividing by 0 if either the attenuation or the length go to zero.

In real terms, this means a sound with attenuation 1 is audible 1000 units away, attenuation 2 is 500 units away, etc. 
You Are A Quake Hero 
 
 
Quake God as Sub-Nigurath 
Sounds Like 
If you are going to run this function very frequently, then you might consider it a candidate for optimisation. As it happens, this inequality is ripe for one of my favourite optimisation tricks. It hinges on the idea that calculating the square root of a number is expensive compared to regular operations such as addition and multiplication.

The length of a 3d vector is calculated as

sqrt(x*x + y*y + z*z)

What we notice is that if a and b are > 0 then

a*a >= b*b is equivalent to a >= b

so we can rewrite our inequality from earlier as:

atten * atten * length * length >= 1000*1000

But we have multiplied length by itself, which reverses the sqrt involved in the calculation of length, and takes us back to the value before that step.

So we can replace that with

atten * atten * (x*x + y*y + z*z) >= 1000000

If we were writing this straight in C, there would be no doubt that this method is faster, it replaces one call to sqrt with a single multiplication. In QC, it's a bit harder to decide if it's beneficial, because vlen would have done the multiplication in the brackets for us, which is a little cheaper than doing it ourselves in QC.

In effect, we have replaced the function call to the builtin vlen with four multiplcations and two additions. It's worth noting that a function call has quite a bit of overhead too, so it's likely that we're a way ahead in doing this. If I'm really honest, this is more of an "inner loop in critical c++ rendering code" optimisation, but it's cute to look at. 
Thanks Again 
very simple when it's all laid out like that, and a nice trick for optimizing vlen calculations. ^_^

(as it turns out, i have other parts in my mod that require frequent vlen calls as well) 
Just Replied On I3D But Hey! Here Too... 
That value of 1000 *may* have been 1500 in an earlier version of Quake. This is based on a comment I saw in somebody's source maybe 6 years ago; can't remember where or who now.

I've no reason to either doubt or believe it, but I've switched to 1500 myself (in fact I've turned it into a cvar) as I like the extra ambience that it generates in a map. 
 
now that i know a little more about it, i found this line in snd_dma.c for fq085:
vec_t sound_nominal_clip_dist=1000.0;
so it looks like id brought it back down to 1000 unless metl did that, but there's no comment there about it. :) 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.