Re: [Flightgear-devel] no doppler sound with actual build
Maik Justus wrote: That would be the best. But how to know, that 1.2 would work? It looks If version 1.2 still contains this bug it will be noticed rather quickly and changing the test would be easy. like, if the OpenAL Doppler effect bugs are a never ending story. And they do not work correctly at Linux (at least not on every build). For a short while I thought it would be the best, to use always the own calculation. But then I learned, that some (all?) Linux versions of OpenAL report them self as version 1.1 (in the header file), but do limit the allowed pitch range of a sound, which is in contrary to the As I understand it implementations are free to limit the pitch range and I know almost for sure that Creative implementations don't allow pitch settings above 2.0 due to hardware limits. Erik - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] bug: no runway lights, no taxiway lights (point sprites)
When flying at night in the default configuration, I observe no airport lights. That means no runway lights, no taxiway lights, no approach lights, no VASI lights, et cetera. If I go to the rendering options menu and turn off the point sprites option, the lights come on. As a workaround, I've taken to setting --prop:/sim/rendering/point-sprites=0 in my .fgfsrc file. This is observed with the current CVS version with OSG2 and the following graphics system: OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI MOBILITY RADEON 9600/9700 Series OpenGL version string: 2.0.6473 (8.37.6) direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: ATI client glx version string: 1.3 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_ARB_get_proc_address, GLX_SGI_video_sync, GLX_ARB_multisample, GLX_ATI_pixel_format_float, GLX_ATI_render_texture GLX version: 1.2 GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_ARB_multisample - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control locking byautopilot
On Wednesday 27 June 2007 23:05, woodyst wrote: My yoke is CH Products Yoke. I think (as I see in the code) than FlightGear tests yoke position every input.cxx pass. If it finds that yoke position is different of the virtual yoke it applies real yoke position. And when the autopilot is changing virtual yoke it is different. Not quite. It tests if the current joystick position is more than a tolerance value from its previous position. If it is then the joystick position is applied to the virtual yoke. No, it is not noisy. I have tested it with utils and found that my yoke is very quiet. I think my previous afirmation may be correct. Very quiet might not be quiet enough. If the noise is more than the tolerance value hardcoded into input.cxx (0.002) then you will see what you are seeing. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control locking byautopilot
On Wednesday 27 June 2007 23:05, woodyst wrote: The diffs are at http://www.eurogaran.com/fgfs/fgfs_ap_joy_locking.diff and http://www.eurogaran.com/fgfs/kap140_locking_controls_capable.diff AFAIK real life autopilots can be overpowered by the pilot. Wheter this is done by brute force or if the servos can sense that they are being overpowered and then let go, I don't know. Since we don't have any force feedback support in Flightgear, we'll have to make the autopilot sense that it is being overpowered. The hard part will be how to decide that the pilot is trying to overpower the autopilot. One possibility is to press a button to tell that you are overpowering. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control locking byautopilot
FWIW I observe the same thing with my CH yoke, and even more so with my Saitek joystick. On 6/28/07, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: On Wednesday 27 June 2007 23:05, woodyst wrote: My yoke is CH Products Yoke. I think (as I see in the code) than FlightGear tests yoke position every input.cxx pass. If it finds that yoke position is different of the virtual yoke it applies real yoke position. And when the autopilot is changing virtual yoke it is different. Not quite. It tests if the current joystick position is more than a tolerance value from its previous position. If it is then the joystick position is applied to the virtual yoke. No, it is not noisy. I have tested it with utils and found that my yoke is very quiet. I think my previous afirmation may be correct. Very quiet might not be quiet enough. If the noise is more than the tolerance value hardcoded into input.cxx (0.002) then you will see what you are seeing. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Hans Fugal Fugal Computing - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control locking byautopilot
2007/6/28, Roy Vegard Ovesen [EMAIL PROTECTED]: On Wednesday 27 June 2007 23:05, woodyst wrote: The diffs are at http://www.eurogaran.com/fgfs/fgfs_ap_joy_locking.diff and http://www.eurogaran.com/fgfs/kap140_locking_controls_capable.diff AFAIK real life autopilots can be overpowered by the pilot. Wheter this is done by brute force or if the servos can sense that they are being overpowered and then let go, I don't know. Since we don't have any force feedback support in Flightgear, we'll have to make the autopilot sense that it is being overpowered. I agree. But for a realistic simulation I have to be able to keep my yoke untouched with autopilot enabled and then virtual yoke has to be fully controlled by autopilot. I thank that a good solution would be making a new intermediate property, a virtual axis that would be the result of ap_selection + yoke_axis_position but the changes in the code are more complex. And for emulating force I thank that it would be interesting that the factor of the yoke had to be decremented when autopilot is enabled so you have to make more force for moving it. But it would break force feedback devices and wouldn't be realistic at all, because you would have to move yoke more distance for a less movement of the virtual yoke. The key binding for disabling or enabling yoke is another solution, but I prefer the auto-deactivation because, as we discussed earlier, in real life it is not a common situation that a pilot overpowers an autopilot (IMHO). If you think there is a better solution I will agree. But IMHO I think the worst mode is the actual, with an autopilot that makes virtual yoke move very quickly and it is this way if you keep joystick stoped too. The hard part will be how to decide that the pilot is trying to overpower the autopilot. One possibility is to press a button to tell that you are overpowering. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Woodyst. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] no doppler sound with actual build
Hi Erik, Erik Hofman schrieb am 28.06.2007 08:50: Maik Justus wrote: That would be the best. But how to know, that 1.2 would work? It looks If version 1.2 still contains this bug it will be noticed rather quickly and changing the test would be easy. ok, I will test for the 1.2 and use the OpenAL Doppler calculation if successful. like, if the OpenAL Doppler effect bugs are a never ending story. And they do not work correctly at Linux (at least not on every build). For a short while I thought it would be the best, to use always the own calculation. But then I learned, that some (all?) Linux versions of OpenAL report them self as version 1.1 (in the header file), but do limit the allowed pitch range of a sound, which is in contrary to the As I understand it implementations are free to limit the pitch range and I know almost for sure that Creative implementations don't allow pitch settings above 2.0 due to hardware limits. Yes, the driver is allowed to clamp the pitch, but the allowed range to pass to OpenAL is (0.0f,any], therefore I wouldn't expect an error reported by alGetError(). But no problem, I just will ignore if alGetError() returns an error after setting the pitch value. I will try to make a patch for all reported bugs (up to know). Erik Maik - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Some AI related notes
Today I finally got around to commit a series of patches / changes to the AI system. Thomas Foerster contributed some new code that will allow us to specify aircraft performance data, which will allow runway length calculations on a per aircraft base. He also contributed an implimentation of the Dijkstra route finding algorithm, which outperforms my own make shift algorithm by magnitudes. In the mean time, I have been working on detecting and resolving higher order interaction problems, in the network. A higher order interaction, labelled circular wait by me is a situation where aircraft a waits for b, b waits for c, and c waits for a. Eventually, a situation like this will block the entire traffic pattern at the airport. So detecting and resolving is crucial. The detection code works, fairly well, but the resolution is currently rather crude: remove one of the offending aircraft from the scene. Finding a better solution is necessary, but that will take time. Today, I got my head around implementing different runway assignments based on traffic type. There was already rudimentary support for this, but everything was defaulted to one type of traffic at the front end. Finally, Innis Cunningham sent me a nice traffic demo for the San Francisco area, which I have just committed. There's an interesting variety of aircraft, right now. Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] a4 files
Hi, I just noticed that I had two modified files belonging to the A4 in my data directory, which should not have been committed (a4f-set.xml and Models/fuel-aar.nas). As far as I can tell, their all back into their original shape, but somebody might want to double check. Sorry for the mess... Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fun with nasal ai
Here's a small Nasal file to play with (attached). If you put
it into $FG_ROOT/Nasal, start fgfs with the ufo and press the
g-key, then you get a file-select dialog where you can select
a parking.xml file. When you click the Load button, then an
object is placed at every TaxiNode of the chosen airport.
And what is it good for? For *nothing*. Well, for showing off
some recent Nasal additions: the file selector, the put_model
function, and the xml parser. If the coordinates weren't in a
funny format, then it could have been done in very few lines.
m.
# opens file selector on g-key press, loads the selected parking.xml file,
# and puts a radar object on every TaxiNode.
var uncheesify = func(c) {
var i = 0;
for (; i size(c); i += 1)
if (!string.isspace(c[i]))
break;
i size(c) or die(empty coordinate);## added i
if (c[0] == `N` or c[0] == `E`)
var sign = 1;
elsif (c[0] == `S` or c[0] == `W`)
var sign = -1
else
die(first character not one of N,S,E,W);
var s = ;
for (i += 1; i size(c); i += 1) {
if (string.isdigit(c[i]))
s ~= chr(c[i]);
else
break;
}
var deg = num(s);
deg != nil or die(invalid degree);
for (; i size(c); i += 1)
if (!string.isspace(c[i]))
break;
var s = ;
for (; i size(c); i += 1) {
if (string.isdigit(c[i]) or c[i] == `.`)
s ~= chr(c[i]);
else
break;
}
var min = num(s);
min != nil or die(invalid minutes);
return sign * (deg + min / 60);
}
var load_file = func {
if ((var tree = xml.process_file(cmdarg().getValue(), xml.tree, )) ==
nil)
die(error loading ~ file);
foreach (var taxi; tree.getNode(groundnet/TaxiNodes,
1).getChildren(node)) {
var lat = uncheesify(taxi.getNode(lat, 1).getValue());
var lon = uncheesify(taxi.getNode(lon, 1).getValue());
var n = geo.put_model(Models/Airport/radar.ac, lat, lon);
}
}
var gearDown = func(v) {
file_selector.open();
old_gearDown(v);
}
var old_gearDown = nil;
var file_selector = nil;
setlistener(/sim/signals/nasal-dir-initialized, func {
if (getprop(/sim/aircraft) != ufo)
return;
file_selector = gui.FileSelector.new(load_file,
Select parking.xml file, Load Models,
[parking.xml],
getprop(/sim/fg-root) ~ /AI/Airports,
parking.xml);
old_gearDown = controls.gearDown;
controls.gearDown = gearDown;
});
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fun with nasal ai
Am Donnerstag 28 Juni 2007 22:02 schrieb Melchior FRANZ: Here's a small Nasal file to play with (attached). If you put it into $FG_ROOT/Nasal, start fgfs with the ufo and press the g-key, then you get a file-select dialog where you can select a parking.xml file. When you click the Load button, then an object is placed at every TaxiNode of the chosen airport. And what is it good for? For *nothing*. GREAT addition for debugging the ground network following code. THX. :-) (Haven't tried it yet but sounds promising.) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] no doppler sound with actual build
Hi all,
here is a new patch for the Doppler effect, which should work on every OS.
Please report, if you get any error messages or hear any unexpected sound.
(Due to some debug-error-messages not intended to go into cvs)
Maik
Maik Justus schrieb am 28.06.2007 20:22:
Hi Erik,
Erik Hofman schrieb am 28.06.2007 08:50:
Maik Justus wrote:
That would be the best. But how to know, that 1.2 would work? It looks
If version 1.2 still contains this bug it will be noticed rather quickly
and changing the test would be easy.
ok, I will test for the 1.2 and use the OpenAL Doppler calculation if
successful.
like, if the OpenAL Doppler effect bugs are a never ending story. And
they do not work correctly at Linux (at least not on every build). For a
short while I thought it would be the best, to use always the own
calculation. But then I learned, that some (all?) Linux versions of
OpenAL report them self as version 1.1 (in the header file), but do
limit the allowed pitch range of a sound, which is in contrary to the
As I understand it implementations are free to limit the pitch range and
I know almost for sure that Creative implementations don't allow pitch
settings above 2.0 due to hardware limits.
Yes, the driver is allowed to clamp the pitch, but the allowed range to
pass to OpenAL is (0.0f,any], therefore I wouldn't expect an error
reported by alGetError(). But no problem, I just will ignore if
alGetError() returns an error after setting the pitch value.
I will try to make a patch for all reported bugs (up to know).
Erik
Maik
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Index: sound/sample_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.cxx,v
retrieving revision 1.27
diff -u -p -r1.27 sample_openal.cxx
--- sound/sample_openal.cxx 21 Jun 2007 21:46:21 - 1.27
+++ sound/sample_openal.cxx 28 Jun 2007 19:22:14 -
@@ -75,12 +75,17 @@ SGSoundSample::SGSoundSample() :
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(true)
{
}
// constructor
-SGSoundSample::SGSoundSample( const char *path, const char *file) :
+SGSoundSample::SGSoundSample( const char *path, const char *file , bool
_no_Doppler_effect ) :
buffer(0),
source(0),
pitch(1.0),
@@ -88,8 +93,13 @@ SGSoundSample::SGSoundSample( const char
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
-{
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(_no_Doppler_effect)
+{
SGPath samplepath( path );
if ( strlen(file) ) {
samplepath.append( file );
@@ -145,7 +155,7 @@ SGSoundSample::SGSoundSample( const char
}
// constructor
-SGSoundSample::SGSoundSample( unsigned char *_data, int len, int _freq ) :
+SGSoundSample::SGSoundSample( unsigned char *_data, int len, int _freq , bool
_no_Doppler_effect ) :
buffer(0),
source(0),
pitch(1.0),
@@ -153,7 +163,12 @@ SGSoundSample::SGSoundSample( unsigned c
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(_no_Doppler_effect)
{
SG_LOG( SG_GENERAL, SG_DEBUG, In memory sounds sample );
@@ -247,14 +262,23 @@ SGSoundSample::bind_source() {
}
alSourcei( source, AL_BUFFER, buffer );
+#ifndef USE_SOFTWARE_DOPPLER
alSourcef( source, AL_PITCH, pitch );
alSourcef( source, AL_GAIN, volume );
+#else
+print_openal_error(bind_sources return);
+alSourcef( source, AL_PITCH, pitch *doppler_pitch_factor );
+alGetError(); //ignore if the pitch is clamped by the driver
+alSourcef( source, AL_GAIN, volume *doppler_volume_factor );
+#endif
alSourcefv( source, AL_POSITION, source_pos );
alSourcefv( source, AL_DIRECTION, direction );
alSourcef( source, AL_CONE_INNER_ANGLE, inner );
alSourcef( source, AL_CONE_OUTER_ANGLE, outer );
alSourcef( source, AL_CONE_OUTER_GAIN, outergain);
+#ifdef USE_OPEN_AL_DOPPLER
alSourcefv( source, AL_VELOCITY, source_vel );
+#endif
alSourcei( source, AL_LOOPING, loop );
alSourcei( source,
Re: [Flightgear-devel] no doppler sound with actual build
Hi,
I forgot: only for osg/head.
Maik
Maik Justus schrieb am 28.06.2007 22:55:
Hi all,
here is a new patch for the Doppler effect, which should work on every
OS.
Please report, if you get any error messages or hear any unexpected
sound.
(Due to some debug-error-messages not intended to go into cvs)
Maik
Maik Justus schrieb am 28.06.2007 20:22:
Hi Erik,
Erik Hofman schrieb am 28.06.2007 08:50:
Maik Justus wrote:
That would be the best. But how to know, that 1.2 would work? It
looks
If version 1.2 still contains this bug it will be noticed rather
quickly and changing the test would be easy.
ok, I will test for the 1.2 and use the OpenAL Doppler calculation if
successful.
like, if the OpenAL Doppler effect bugs are a never ending story.
And they do not work correctly at Linux (at least not on every
build). For a short while I thought it would be the best, to use
always the own calculation. But then I learned, that some (all?)
Linux versions of OpenAL report them self as version 1.1 (in the
header file), but do limit the allowed pitch range of a sound,
which is in contrary to the
As I understand it implementations are free to limit the pitch range
and I know almost for sure that Creative implementations don't allow
pitch settings above 2.0 due to hardware limits.
Yes, the driver is allowed to clamp the pitch, but the allowed range
to pass to OpenAL is (0.0f,any], therefore I wouldn't expect an
error reported by alGetError(). But no problem, I just will ignore if
alGetError() returns an error after setting the pitch value.
I will try to make a patch for all reported bugs (up to know).
Erik
Maik
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Index: sound/sample_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.cxx,v
retrieving revision 1.27
diff -u -p -r1.27 sample_openal.cxx
--- sound/sample_openal.cxx 21 Jun 2007 21:46:21 - 1.27
+++ sound/sample_openal.cxx 28 Jun 2007 19:22:14 -
@@ -75,12 +75,17 @@ SGSoundSample::SGSoundSample() :
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(true)
{
}
// constructor
-SGSoundSample::SGSoundSample( const char *path, const char *file) :
+SGSoundSample::SGSoundSample( const char *path, const char *file , bool
_no_Doppler_effect ) :
buffer(0),
source(0),
pitch(1.0),
@@ -88,8 +93,13 @@ SGSoundSample::SGSoundSample( const char
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
-{
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(_no_Doppler_effect)
+{
SGPath samplepath( path );
if ( strlen(file) ) {
samplepath.append( file );
@@ -145,7 +155,7 @@ SGSoundSample::SGSoundSample( const char
}
// constructor
-SGSoundSample::SGSoundSample( unsigned char *_data, int len, int _freq ) :
+SGSoundSample::SGSoundSample( unsigned char *_data, int len, int _freq ,
bool _no_Doppler_effect ) :
buffer(0),
source(0),
pitch(1.0),
@@ -153,7 +163,12 @@ SGSoundSample::SGSoundSample( unsigned c
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(_no_Doppler_effect)
{
SG_LOG( SG_GENERAL, SG_DEBUG, In memory sounds sample );
@@ -247,14 +262,23 @@ SGSoundSample::bind_source() {
}
alSourcei( source, AL_BUFFER, buffer );
+#ifndef USE_SOFTWARE_DOPPLER
alSourcef( source, AL_PITCH, pitch );
alSourcef( source, AL_GAIN, volume );
+#else
+print_openal_error(bind_sources return);
+alSourcef( source, AL_PITCH, pitch *doppler_pitch_factor );
+alGetError(); //ignore if the pitch is clamped by the driver
+alSourcef( source, AL_GAIN, volume *doppler_volume_factor );
+#endif
alSourcefv( source, AL_POSITION, source_pos );
alSourcefv( source, AL_DIRECTION, direction );
alSourcef( source, AL_CONE_INNER_ANGLE,
Re: [Flightgear-devel] fun with nasal ai
* Melchior FRANZ -- Thursday 28 June 2007: Here's a small Nasal file to play with (attached). Whoops ... please change the setlistener call to a _setlistener call (with leading underscore). Otherwise it may not run on some systems. m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS on OS X
Here's what I had to do to compile CVS on OS X Tiger. Install dependencies. I got plib from macports, simgear from CVS, and OSG 2.0 binaries from the OSG website. Tiger includes OpenAL 1.1, but not ALUT, so there is no alut.h on the system. According to Apple[1] you should install freealut to get alut.h, but Apple in their infinite wisdom decided to include the ALUT symbols in their OpenAL framework, so if you try to install freealut you get symbol conflicts. See [2] for the gory details. The simplest solution seems to be to grab alut.h from the OpenAL 1.0 distribution and put it in /System/Library/Frameworks/OpenAL.framework/Headers As mentioned in a previous email, there is a compilation problem due to glut.h undefining APIENTRY. I hope that we can find a workaround for that in FlightGear source, but in the meantime the easiest fix is to hack your plib/pu.h to define APIENTRY after including glut.h (or hack glut.h to not undefine it). The following patch is required: --- a/src/Instrumentation/render_area_2d.cxx +++ b/src/Instrumentation/render_area_2d.cxx @@ -30,7 +30,8 @@ # include windows.h #endif -#include GL/gl.h +#include simgear/compiler.h +#include SG_GL_H #include render_area_2d.hxx Since OSG binaries are frameworks, the linkage needs to be changed to use -framework instead of -l. If you build OSG by hand, -l is correct, however you have to set OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.0.0 because the make install target and the source code aren't on the same page as to where plugins should be installed. I have reported that to the OSG list and hopefully in future releases it will be fixed. In any case, users will rather use the binaries (frameworks) and developers can build frameworks from SVN, so -framework seems to me to be the most correct. Whether using -l or -framework for osg libraries, I had to link in osgGA and osgText explicitly or it would not link. Are we working towards total independence from plib? If so the APIENTRY problem will disappear on its own. The -framework issue I am happy to provide a patch for, as soon as I can figure out the right way to hack the autoconf/automake stuff to do so. Currently src/Main/Makefile.am includes the -l phrases explicitly, that will probably need to be changed to something more generic, probably in configure.ac. Does anyone know the right place for this? I'm inclined to take the OpenAL test in configure.ac as a basis. Thanks References 1. http://developer.apple.com/qa/qa2006/qa1504.html 2. http://opensource.creative.com/pipermail/openal/2006-August/009761.html -- Hans Fugal Fugal Computing - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS on OS X
Hi Hans,
Thanks for your contribution!
There are some workarounds that I made for Macs (Xcode project) on
these issues.
You can check out the patches from the svn repository available from
FlightGear Mac OS X website so take a look at that.
Since I need to make universal binary packages for Mac OS X, I
haven't integrated the
Mac portions into configure/automake in the original source tree, but
it's very
welcome to have configure/automake things for Macs.
Plus, I really hope that such patches will be applied into the
repository soon.
# Or I should have a cvs account to do it myself.
anyway, about ALUT thing, I simply added the alut.h since I don't
want to change
Apple's framework.
To avoild errors regarding to APIENTRY, I made a patch:
--- org/plib-1.8.4/src/pui/puGLUT.h 2004-02-16 05:49:03.0
-0800
+++ PLIB/plib/src/pui/puGLUT.h 2006-11-16 07:37:01.0 -0800
@@ -32,6 +32,10 @@
#ifdef UL_MAC_OSX
# include GLUT/glut.h
+# ifndef APIENTRY
+// This is a workaround to avoid getting errors in osg/BufferObject
+# define APIENTRY
+# endif
--- org/SimGear/simgear/compiler.h 2006-11-03 01:57:02.0
-0800
+++ SimGear/SimGear/simgear/compiler.h 2006-11-16 01:23:06.0
-0800
@@ -376,7 +376,9 @@
# define SG_GLU_H OpenGL/glu.h
# define SG_GLEXT_H OpenGL/glext.h
# define SG_GLUT_H GLUT/glut.h
-
+# ifndef APIENTRY
+#define APIENTRY
+# endif
inline int (isnan)(double r) { return !(r = 0 || r = 0); }
#else
# define SG_GL_H GL/gl.h
Hope it helps.
Now I'm working on building both 0.9.11-pre1 and cvs head.
I had some errors in linking osgViewer (when building fgfs cvs-head/
OSG-svn head)
OSG-2.0 seems OK so I'll go with it for cvs-head for a while.
By the way, do you know which revision/tag is suitable for building
0.9.11-pre1?
Tat
On Jun 29, 2007, at 6:51 AM, Hans Fugal wrote:
Here's what I had to do to compile CVS on OS X Tiger.
Install dependencies. I got plib from macports, simgear from CVS, and
OSG 2.0 binaries from the OSG website.
Tiger includes OpenAL 1.1, but not ALUT, so there is no alut.h on the
system. According to Apple[1] you should install freealut to get
alut.h,
but Apple in their infinite wisdom decided to include the ALUT symbols
in their OpenAL framework, so if you try to install freealut you get
symbol conflicts. See [2] for the gory details. The simplest solution
seems to be to grab alut.h from the OpenAL 1.0 distribution and put it
in /System/Library/Frameworks/OpenAL.framework/Headers
As mentioned in a previous email, there is a compilation problem
due to
glut.h undefining APIENTRY. I hope that we can find a workaround for
that in FlightGear source, but in the meantime the easiest fix is to
hack your plib/pu.h to define APIENTRY after including glut.h (or hack
glut.h to not undefine it).
The following patch is required:
--- a/src/Instrumentation/render_area_2d.cxx
+++ b/src/Instrumentation/render_area_2d.cxx
@@ -30,7 +30,8 @@
# include windows.h
#endif
-#include GL/gl.h
+#include simgear/compiler.h
+#include SG_GL_H
#include render_area_2d.hxx
Since OSG binaries are frameworks, the linkage needs to be changed to
use -framework instead of -l. If you build OSG by hand, -l is correct,
however you have to set OSG_LIBRARY_PATH=/usr/local/lib/
osgPlugins-2.0.0
because the make install target and the source code aren't on the same
page as to where plugins should be installed. I have reported that to
the OSG list and hopefully in future releases it will be fixed. In any
case, users will rather use the binaries (frameworks) and
developers can
build frameworks from SVN, so -framework seems to me to be the most
correct.
Whether using -l or -framework for osg libraries, I had to link in
osgGA
and osgText explicitly or it would not link.
Are we working towards total independence from plib? If so the
APIENTRY
problem will disappear on its own.
The -framework issue I am happy to provide a patch for, as soon as
I can
figure out the right way to hack the autoconf/automake stuff to do so.
Currently src/Main/Makefile.am includes the -l phrases explicitly,
that
will probably need to be changed to something more generic,
probably in
configure.ac. Does anyone know the right place for this? I'm
inclined to
take the OpenAL test in configure.ac as a basis.
Thanks
References
1. http://developer.apple.com/qa/qa2006/qa1504.html
2. http://opensource.creative.com/pipermail/openal/2006-August/
009761.html
--
Hans Fugal
Fugal Computing
--
---
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] CVS on OS X
On 6/28/07, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Now I'm working on building both 0.9.11-pre1 and cvs head. I had some errors in linking osgViewer (when building fgfs cvs-head/ OSG-svn head) OSG-2.0 seems OK so I'll go with it for cvs-head for a while. By the way, do you know which revision/tag is suitable for building 0.9.11-pre1? I was able to build and run the 0.9.11-pre1 tarball without any changes at all (using the 0.9.11-pre1 SimGear and macports plib). I don't recall for sure, but I probably already had the alut.h fix in place. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
