Re: [Warzone-dev] [OpenAL] distance attenuation
Per Inge Mathisen schreef: On 1/9/07, Giel van Schijndel [EMAIL PROTECTED] wrote: I am not sure what you are referring to. Can you give me a pointer? I see now that even the back-end is mixed C/C++ (as opposed to pure C++), anyway: http://www.openal.org/repos/openal/trunk/OpenAL-Windows/Router/ Looks pure C to me. Perhaps you are confused by the use of .cpp for C files? This is a common oddity from MSVC users. http://www.openal.org/repos/openal/trunk/OpenAL-Windows/OpenAL32/ The only file with actual C++ code I can find is this one http://www.openal.org/repos/openal/trunk/OpenAL-Windows/OpenAL32/alThunk.cpp Why it uses C++ and classes internally when it exports only C functions, is beyond me. Seems rather pointless. There is a MacOSX implementation using C++, too, but I am not sure what the status of it is. But I see no C++ in the sample implementation itself, which AFAICT is the one used on Linux. Yes that alThunk file is just about the only back-end file I've really opened. Anyway my point was: it is possible to link C with C++ code. I think I've proven that one. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
[EMAIL PROTECTED] schreef: On Tue, 09 Jan 2007 14:37:51 -0500 Giel van Schijndel [EMAIL PROTECTED] wrote: Yes that alThunk file is just about the only back-end file I've really opened. Anyway my point was: it is possible to link C with C++ code. I think I've proven that one. -- Giel Yes, of course that is possible. We just have to make sure it works on all the compilers people use. If it came down to a choice of having work done in C++ or not, then C++ wins. After all, you will be the one doing the work to get this to work. :) Quite true, especially since I've been working on some test cases (in C++ that is) for past few days. That'll slow down a bit for this and maybe the next week though. Just started a new internship and shifting my day/night rhythm (in the wrong way mind you! I.e. I need to get up early now) as a result of it. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
On Sunday, 7 January 2007 at 14:17, Per Inge Mathisen wrote: On 1/7/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Well the problem with a local tree would be that I would only be able to commit anything but incremental changes without breaking things (i.e. without breaking the trunk). Maybe I should not use the word 'tree'. What I mean is another local copy of the trunk. If it works in your local copy, it will not break the trunk. Whenever I want to develop something bigger, I make a separate local copy for that. So I have one copy for small commits, one for the memory patch, and so on. That way I can integrate other people's changes that are done while I am developing my stuff merely by doing svn up on each copy. This seems to me the easiest way to work (alone) on bigger changes. I am not telling you not to create a branch, I am just trying to see if you really think this is the best way to work on it. As I said, I doubt branches give you anything but more work unless you are multiple people working on the same changeset. I see several advantages to a public branch compared to working just on a local copy: - Other people have the chance to comment, test, report bugs, help with coding... (impossible if noone knows what you're doing). - Smaller changes. On a local branch you can only make one big patch that has to work (more or less) before being applied. A SVN branch records your steps while working, enabling people to follow your work, and understand the new code easier, as well as giving more fine-grained changes to look for eventual bugs. (Of course you can use a local revision control system to work with and record your patches, and when it all works, apply those subsequently to SVN. But that's more work, and you lose the time factor that let's people follow your progress.) I am not saying that this will happen with a public SVN branch, but with a local branch, it can't even happen. C++ provides easier ways of error handling (e.g. exceptions), plus it natively provides OOP. I am aware that some level of OOP abstracting is provided in the current warzone codebase since the used technique however is not native to the language it is harder to maintain. Especially RAII is rather difficult to implement using C (whereas C++ provides constructors/destructors and operaters new/delete for an easy implementation of RAII). And secondly the only thing becoming more difficult to maintain should be building (i.e. as far as I see). Which I think should be made more easy by the creation of a C interface and the fact that the this C++ implementation is kept local in a library. My experience from work, where I maintain a large codebase of mixed C and C++ code, is that such mixing is a maintenance nightmare. I do not want this unless there is a very good reason for it, and what you are providing are arguments to convert all of Warzone to C++, which, even if you buy those arguments, is a totally different discussion. Hm, and the current code isn't a maintenance nightmare? I think using some C++ to encaspulate stuff will make things better, not worse (if done right, of course, but you can write bad and good code in both C and C++). That might be possible with C as well, but to me it seems more natural in C++. What I don't agree with is making a C interface to a C++ interface to OpenAL - seems like duplicated work to me. I'd just use C++ in the code and compile the complete game with a C++ compiler. But that's just me, I guess there needs to be some decision about how to use C++, or we just follow the usual those who do decide approach. -- standards, n.: The principles we use to reject other people's code. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
Dennis Schridde schreef:
Am Montag, 8. Januar 2007 19:43 schrieb Christian Ohm:
I see several advantages to a public branch compared to working just on
a local copy:
- Other people have the chance to comment, test, report bugs, help with
coding... (impossible if noone knows what you're doing).
- Smaller changes. On a local branch you can only make one big patch
that has to work (more or less) before being applied. A SVN branch
records your steps while working, enabling people to follow your work,
and understand the new code easier, as well as giving more
fine-grained changes to look for eventual bugs.
(Of course you can use a local revision control system to work with
and record your patches, and when it all works, apply those
subsequently to SVN. But that's more work, and you lose the time
factor that let's people follow your progress.)
I am not saying that this will happen with a public SVN branch, but with
a local branch, it can't even happen.
My experience from work, where I maintain a large codebase of mixed C
and C++ code, is that such mixing is a maintenance nightmare. I do not
want this unless there is a very good reason for it, and what you are
providing are arguments to convert all of Warzone to C++, which, even
if you buy those arguments, is a totally different discussion.
Hm, and the current code isn't a maintenance nightmare? I think using
some C++ to encaspulate stuff will make things better, not worse (if
done right, of course, but you can write bad and good code in both C and
C++). That might be possible with C as well, but to me it seems more
natural in C++.
What I don't agree with is making a C interface to a C++ interface to
OpenAL - seems like duplicated work to me. I'd just use C++ in the code
and compile the complete game with a C++ compiler. But that's just me, I
guess there needs to be some decision about how to use C++, or we just
follow the usual those who do decide approach.
Basically I think that's the maintainance problem...
Actually I didn't even know that it is possible to link a C application
against a C++ lib, because I thought the C++ ABI is incompatible to the C
ABI...
In fact OpenAL itself is written largely in C++. They simply wrapped its
interface (or more accurately the include files with function
declarations) in an extern C {...} declaration to make sure the
compiler generates C-style symbols which can then be resolved by the
linker when linking with C-code.
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
Dennis Schridde schreef:
Am Montag, 8. Januar 2007 21:08 schrieb Giel van Schijndel:
Dennis Schridde schreef:
[...]
What I don't agree with is making a C interface to a C++ interface to
OpenAL - seems like duplicated work to me. I'd just use C++ in the code
and compile the complete game with a C++ compiler. But that's just me, I
guess there needs to be some decision about how to use C++, or we just
follow the usual those who do decide approach.
Basically I think that's the maintainance problem...
Actually I didn't even know that it is possible to link a C application
against a C++ lib, because I thought the C++ ABI is incompatible to the C
ABI...
In fact OpenAL itself is written largely in C++. They simply wrapped its
interface (or more accurately the include files with function
declarations) in an extern C {...} declaration to make sure the
compiler generates C-style symbols which can then be resolved by the
linker when linking with C-code.
Aha, didn't know that...
Can someone explain that in more detail or provide a link?
I'd like to know how that works, that a C app can link against a C++ lib
using
a wrapper interface...
In fact I can give you several:
http://web.mit.edu/answers/c/c_with_plus_plus.html
http://www.objectvalue.com/articles/LinkingCtoCplusplusV02.html
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
On 1/8/07, Giel van Schijndel [EMAIL PROTECTED] wrote:
In fact OpenAL itself is written largely in C++. They simply wrapped its
interface (or more accurately the include files with function
declarations) in an extern C {...} declaration to make sure the
compiler generates C-style symbols which can then be resolved by the
linker when linking with C-code.
What OpenAL implementation are you talking about? The sample
implementation looks pretty pure C to me.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
Per Inge Mathisen schreef:
On 1/8/07, Giel van Schijndel [EMAIL PROTECTED] wrote:
In fact OpenAL itself is written largely in C++. They simply wrapped its
interface (or more accurately the include files with function
declarations) in an extern C {...} declaration to make sure the
compiler generates C-style symbols which can then be resolved by the
linker when linking with C-code.
What OpenAL implementation are you talking about? The sample
implementation looks pretty pure C to me.
The backend.
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
Per Inge Mathisen schreef: On 1/8/07, Giel van Schijndel [EMAIL PROTECTED] wrote: What OpenAL implementation are you talking about? The sample implementation looks pretty pure C to me. The backend. I am not sure what you are referring to. Can you give me a pointer? I see now that even the back-end is mixed C/C++ (as opposed to pure C++), anyway: http://www.openal.org/repos/openal/trunk/OpenAL-Windows/Router/ http://www.openal.org/repos/openal/trunk/OpenAL-Windows/OpenAL32/ The two sibling dirs (Alc and Alu) are the respective interfaces as provided by the include files ALc.h and al.h. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
On 1/9/07, Giel van Schijndel [EMAIL PROTECTED] wrote: I am not sure what you are referring to. Can you give me a pointer? I see now that even the back-end is mixed C/C++ (as opposed to pure C++), anyway: http://www.openal.org/repos/openal/trunk/OpenAL-Windows/Router/ Looks pure C to me. Perhaps you are confused by the use of .cpp for C files? This is a common oddity from MSVC users. http://www.openal.org/repos/openal/trunk/OpenAL-Windows/OpenAL32/ The only file with actual C++ code I can find is this one http://www.openal.org/repos/openal/trunk/OpenAL-Windows/OpenAL32/alThunk.cpp Why it uses C++ and classes internally when it exports only C functions, is beyond me. Seems rather pointless. There is a MacOSX implementation using C++, too, but I am not sure what the status of it is. But I see no C++ in the sample implementation itself, which AFAICT is the one used on Linux. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
Hi, First of all, Happy New Year to you all ! Now I guess I have to answer this... When I ported that sound code to OpenAL, I first tried to use the parameters you mentionned (for position, attenuation model etc.). Problem was the attenuation didn't sound good (I tested with all models). It might be due to the OpenAL implementation model I was using at that time (was under Linux, I don't remember the OpenAL version, though), or maybe I did something wrong. This is why the current code has its own attenuation model. Reimplementing the sound lib (and using all OpenAL features) is probably a good idea (if I made a mistake in my first implementation, it is very unlikely someone else will repeat it). If this succeeds, You might want to try setting the velocity of sound sources (at least fastest ones, like projectiles and VTOLs) and add the Doppler effect. :) Best regards, Rod Selon Giel van Schijndel [EMAIL PROTECTED]: Just taking a look into the current sound libs. And of course we're using OpenAL there. So why should we actually when using OpenAL, erm actually erm, use it When looking at lib/sound/openal_track.c:sound_SetObjectPosition() I'm getting a headache. Rather than just simply setting the sound-generating object's location using an OpenAL API call, and let OpenAL handle all the gain and volume attenuation stuff, this code does the job which OpenAL should do (and is probably better at considering it uses hardware acceleration where possible). That function first calculates the distance between listener and sound source (Pythagoras like; using a quadratic formula then sqrt) . Then based upon that it calculates the sound's gain based upon the distance and tells OpenAL to use that gain. Then it makes a final call to the OpenAL API to set the position of that sound's source. Since one of the things sound_InitLibrary() does however that last call won't have any effect because it disables OpenAL's distance calculation by this call: alDistanceModel( AL_NONE ); What I tried to explain here, is that the current sound implementation only uses OpenAL as a sound mixer (which SDL happens to be capable of just the same) just for playing different sounds in parallel. The same distance computation is btw provided by OpenAL when the distance model is set to AL_LINEAR_DISTANCE and the sound source's AL_MAX_DISTANCE=1.0, AL_REFERENCE_DISTANCE=0.0 and AL_ROLLOFF_FACTOR=ATTENUATION_FACTOR (ATTENUATION_FACTOR is currently defined to 0.0003 which is _very_ low). Therefore I propose a major overhaul/reimplementation for the sound lib (probably best in a separate branch). So please give me your pros and cons to this proposal (or its grounds). -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
On 1/7/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Anyway if nobody objects (yes, read that in your opinion the sound code isn't crappy, no specifics however, so if you object please clarify), I'll create a (temporary(?)) branch somewhere tomorrow (i.e. after 1300 CET, cause I won't be available, read awake ;-) , very early before that time) for a reimplementation. Are you sure it is less effort (for you) to create and maintain a branch, than just work on it in a local tree? Syncing branches is a lot of work, and I do not recommend it unless you actually need it, say for coordinating several developers. Making a branch for just one person to work on, I would find pretty pointless and a waste of time. I'd prefer to do this using C++ (I'll obviously provide a C interface so that linking against the new lib will be possible for C), please also say so when you don't like that idea. I do not like that idea at all. Why start adding C++ to the codebase? I do not see a technical reason for this, and it makes things more complicated to maintain. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
[EMAIL PROTECTED] schreef: Hi, First of all, Happy New Year to you all ! Same to you and every one else ;-) Now I guess I have to answer this... When I ported that sound code to OpenAL, I first tried to use the parameters you mentionned (for position, attenuation model etc.). Problem was the attenuation didn't sound good (I tested with all models). It might be due to the OpenAL implementation model I was using at that time (was under Linux, I don't remember the OpenAL version, though), or maybe I did something wrong. This is why the current code has its own attenuation model. Well at the time of writing I've done some math to compare both formulas (i.e. the current one in the WZ code vs OpenAL's one). When the constants (or actually sound-source settings) are set as I've described them in my previous mail both are mathematically identical. Reimplementing the sound lib (and using all OpenAL features) is probably a good idea (if I made a mistake in my first implementation, it is very unlikely someone else will repeat it). If this succeeds, You might want to try setting the velocity of sound sources (at least fastest ones, like projectiles and VTOLs) and add the Doppler effect. :) Yes, I was already keeping the Doppler effect in the back of my mind ;-). Problem is currently that it will be very difficult to implement it using this OpenAL implementation. Best regards, Rod Selon Giel van Schijndel [EMAIL PROTECTED]: Just taking a look into the current sound libs. And of course we're using OpenAL there. So why should we actually when using OpenAL, erm actually erm, use it When looking at lib/sound/openal_track.c:sound_SetObjectPosition() I'm getting a headache. Rather than just simply setting the sound-generating object's location using an OpenAL API call, and let OpenAL handle all the gain and volume attenuation stuff, this code does the job which OpenAL should do (and is probably better at considering it uses hardware acceleration where possible). That function first calculates the distance between listener and sound source (Pythagoras like; using a quadratic formula then sqrt) . Then based upon that it calculates the sound's gain based upon the distance and tells OpenAL to use that gain. Then it makes a final call to the OpenAL API to set the position of that sound's source. Since one of the things sound_InitLibrary() does however that last call won't have any effect because it disables OpenAL's distance calculation by this call: alDistanceModel( AL_NONE ); What I tried to explain here, is that the current sound implementation only uses OpenAL as a sound mixer (which SDL happens to be capable of just the same) just for playing different sounds in parallel. The same distance computation is btw provided by OpenAL when the distance model is set to AL_LINEAR_DISTANCE and the sound source's AL_MAX_DISTANCE=1.0, AL_REFERENCE_DISTANCE=0.0 and AL_ROLLOFF_FACTOR=ATTENUATION_FACTOR (ATTENUATION_FACTOR is currently defined to 0.0003 which is _very_ low). Therefore I propose a major overhaul/reimplementation for the sound lib (probably best in a separate branch). So please give me your pros and cons to this proposal (or its grounds). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
Per Inge Mathisen schreef: On 1/7/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Anyway if nobody objects (yes, read that in your opinion the sound code isn't crappy, no specifics however, so if you object please clarify), I'll create a (temporary(?)) branch somewhere tomorrow (i.e. after 1300 CET, cause I won't be available, read awake ;-) , very early before that time) for a reimplementation. Are you sure it is less effort (for you) to create and maintain a branch, than just work on it in a local tree? Syncing branches is a lot of work, and I do not recommend it unless you actually need it, say for coordinating several developers. Making a branch for just one person to work on, I would find pretty pointless and a waste of time. Well the problem with a local tree would be that I would only be able to commit anything but incremental changes without breaking things (i.e. without breaking the trunk). And reimplementing something seems hardly an incremental change to me. I'd prefer to do this using C++ (I'll obviously provide a C interface so that linking against the new lib will be possible for C), please also say so when you don't like that idea. I do not like that idea at all. Why start adding C++ to the codebase? I do not see a technical reason for this, and it makes things more complicated to maintain. C++ provides easier ways of error handling (e.g. exceptions), plus it natively provides OOP. I am aware that some level of OOP abstracting is provided in the current warzone codebase since the used technique however is not native to the language it is harder to maintain. Especially RAII is rather difficult to implement using C (whereas C++ provides constructors/destructors and operaters new/delete for an easy implementation of RAII). And secondly the only thing becoming more difficult to maintain should be building (i.e. as far as I see). Which I think should be made more easy by the creation of a C interface and the fact that the this C++ implementation is kept local in a library. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
On 1/7/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Well the problem with a local tree would be that I would only be able to commit anything but incremental changes without breaking things (i.e. without breaking the trunk). Maybe I should not use the word 'tree'. What I mean is another local copy of the trunk. If it works in your local copy, it will not break the trunk. Whenever I want to develop something bigger, I make a separate local copy for that. So I have one copy for small commits, one for the memory patch, and so on. That way I can integrate other people's changes that are done while I am developing my stuff merely by doing svn up on each copy. This seems to me the easiest way to work (alone) on bigger changes. I am not telling you not to create a branch, I am just trying to see if you really think this is the best way to work on it. As I said, I doubt branches give you anything but more work unless you are multiple people working on the same changeset. C++ provides easier ways of error handling (e.g. exceptions), plus it natively provides OOP. I am aware that some level of OOP abstracting is provided in the current warzone codebase since the used technique however is not native to the language it is harder to maintain. Especially RAII is rather difficult to implement using C (whereas C++ provides constructors/destructors and operaters new/delete for an easy implementation of RAII). And secondly the only thing becoming more difficult to maintain should be building (i.e. as far as I see). Which I think should be made more easy by the creation of a C interface and the fact that the this C++ implementation is kept local in a library. My experience from work, where I maintain a large codebase of mixed C and C++ code, is that such mixing is a maintenance nightmare. I do not want this unless there is a very good reason for it, and what you are providing are arguments to convert all of Warzone to C++, which, even if you buy those arguments, is a totally different discussion. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
Am Samstag, 6. Januar 2007 07:00 schrieb [EMAIL PROTECTED]: I doubt anyone has even looked at that code much. If it looks like you can improve it, then why not. Sure, do it. I won't object. The sound code is currently crappy anyways as many people report that they have problems with distorted sound. --Dennis pgphTZlMSYPhL.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
[EMAIL PROTECTED] schreef: On Sat, 06 Jan 2007 06:53:04 -0500 Dennis Schridde [EMAIL PROTECTED] wrote: Am Samstag, 6. Januar 2007 07:00 schrieb [EMAIL PROTECTED]: I doubt anyone has even looked at that code much. If it looks like you can improve it, then why not. Sure, do it. I won't object. The sound code is currently crappy anyways as many people report that they have problems with distorted sound. --Dennis Distorted sound? This is driver related, not specific to how the sound code is now. Otherwise, we would all get distorted sound. The code isn't crappy IMO. He was just changing the API call for sound, and not precalculate it, and let openAL handle that stuff. Would have done that already if A) I have had the time for the past two days (i.e. this one included) and B) I wouldn't have thought about reimplementing the sound library. Anyway if nobody objects (yes, read that in your opinion the sound code isn't crappy, no specifics however, so if you object please clarify), I'll create a (temporary(?)) branch somewhere tomorrow (i.e. after 1300 CET, cause I won't be available, read awake ;-) , very early before that time) for a reimplementation. I'd prefer to do this using C++ (I'll obviously provide a C interface so that linking against the new lib will be possible for C), please also say so when you don't like that idea. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
On Sat, 06 Jan 2007 19:11:20 -0500 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: On Sat, 06 Jan 2007 06:53:04 -0500 Dennis Schridde [EMAIL PROTECTED] wrote: Am Samstag, 6. Januar 2007 07:00 schrieb [EMAIL PROTECTED]: I doubt anyone has even looked at that code much. If it looks like you can improve it, then why not. Sure, do it. I won't object. The sound code is currently crappy anyways as many people report that they have problems with distorted sound. --Dennis Distorted sound? This is driver related, not specific to how the sound code is now. Otherwise, we would all get distorted sound. The code isn't crappy IMO. He was just changing the API call for sound, and not precalculate it, and let openAL handle that stuff. Would have done that already if A) I have had the time for the past two days (i.e. this one included) and B) I wouldn't have thought about reimplementing the sound library. Anyway if nobody objects (yes, read that in your opinion the sound code isn't crappy, no specifics however, so if you object please clarify), Wait, reread that. Dev said the sound code was crappy since it had distortion for some people. I said, that is not the cause of distortion in sounds, so in this case, the sound code isn't crappy. The distortion is the result of crappy drivers AFAICT. Having the game itself calculate the position/etc versus taking that out and using API calls to do the dirty work for you is just a different way to do the same thing. I'll create a (temporary(?)) branch somewhere tomorrow (i.e. after 1300 CET, cause I won't be available, read awake ;-) , very early before that time) for a reimplementation. I'd prefer to do this using C++ (I'll obviously provide a C interface so that linking against the new lib will be possible for C), please also say so when you don't like that idea. -- Giel If you are going to do it in C++, then a new branch is best I think. Maybe a testing branch or something? This might be a good time to check how we can mix C++ C code on all the different compilers we are using since it should be fairly small patch. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [OpenAL] distance attenuation
I doubt anyone has even looked at that code much. If it looks like you can improve it, then why not. I don't see that on the tasks list. Then again, I don't see GUI overhaul on it neither. On Fri, 05 Jan 2007 18:10:25 -0500 Giel van Schijndel [EMAIL PROTECTED] wrote: Just taking a look into the current sound libs. And of course we're using OpenAL there. So why should we actually when using OpenAL, erm actually erm, use it When looking at lib/sound/openal_track.c:sound_SetObjectPosition() I'm getting a headache. Rather than just simply setting the sound-generating object's location using an OpenAL API call, and let OpenAL handle all the gain and volume attenuation stuff, this code does the job which OpenAL should do (and is probably better at considering it uses hardware acceleration where possible). That function first calculates the distance between listener and sound source (Pythagoras like; using a quadratic formula then sqrt) . Then based upon that it calculates the sound's gain based upon the distance and tells OpenAL to use that gain. Then it makes a final call to the OpenAL API to set the position of that sound's source. Since one of the things sound_InitLibrary() does however that last call won't have any effect because it disables OpenAL's distance calculation by this call: alDistanceModel( AL_NONE ); What I tried to explain here, is that the current sound implementation only uses OpenAL as a sound mixer (which SDL happens to be capable of just the same) just for playing different sounds in parallel. The same distance computation is btw provided by OpenAL when the distance model is set to AL_LINEAR_DISTANCE and the sound source's AL_MAX_DISTANCE=1.0, AL_REFERENCE_DISTANCE=0.0 and AL_ROLLOFF_FACTOR=ATTENUATION_FACTOR (ATTENUATION_FACTOR is currently defined to 0.0003 which is _very_ low). Therefore I propose a major overhaul/reimplementation for the sound lib (probably best in a separate branch). So please give me your pros and cons to this proposal (or its grounds). -- Giel Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
