That Sound About Right
#9744 posted by ijed on 2010/04/23 02:59:53
With pie slice floor texture.
I think it can't work vertically though, only horizontally.
Iris Example
#9745 posted by madfox on 2010/04/23 05:52:44
And For Not QOOLE Users
#9746 posted by madfox on 2010/04/23 07:31:14
Re 9743
#9747 posted by necros on 2010/04/23 07:32:36
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
#9748 posted by Tronyn on 2010/04/23 09:21:39
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?
#9749 posted by necros on 2010/04/23 10:03:00
just run them through irfanview to shrink them, it's free :)
Search/replace
#9750 posted by negke on 2010/04/23 21:40:11
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++
#9751 posted by ijed on 2010/04/24 14:02:08
Alright
#9752 posted by Tronyn on 2010/04/25 05:26:48
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
#9753 posted by Tronyn on 2010/04/25 08:55:58
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
#9754 posted by negke on 2010/04/25 09:37:00
TY
#9755 posted by Tronyn on 2010/04/25 16:08:38
now go invent some other weird creepy sneaky Q1SP stuff :)
Weird Question
#9756 posted by necros on 2010/04/25 20:13:27
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
#9757 posted by ijed on 2010/04/26 00:52:11
On a higher level than me. But from that question my advice would be change engine.
#9758 posted by gb on 2010/04/27 14:41:07
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.
#9759 posted by gb on 2010/04/27 14:41:55
whoah, we made a good show here.
#9760 posted by metlslime on 2010/04/27 19:40:32
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.
#9761 posted by necros on 2010/04/27 19:51:30
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
#9762 posted by Preach on 2010/04/27 22:01:53
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
#9763 posted by necros on 2010/04/27 22:09:55
#9764 posted by Trinca on 2010/04/27 22:38:52
Quake God as Sub-Nigurath
Sounds Like
#9765 posted by Preach on 2010/04/27 23:27:22
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
#9766 posted by necros on 2010/04/27 23:48:24
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...
#9767 posted by mh on 2010/04/28 01:19:28
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.
#9768 posted by necros on 2010/04/28 04:16:00
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. :)
|