Curtis Olson wrote:
Hi James,
At the end of the day, the correct approach really depends on what you
are trying accomplish (what values and in what format are you trying to
compute?)
Also, there is a difference between the value in the property tree
(which is just a nifty way to look at
Vivian Meazza wrote:
Torsten Dreyer wrote:
So - I am just about to commit what I have done so far.
And now i did.
If anything is broken or does not work as expected, please shout.
So much seems broken right now, might be hard to spot :-)
It's not so much that things have broken, but the
This was posted in the forums by one of the people involved in the
project. It's really nice to see FlightGear used in projects like these.
http://alfonsodg.wordpress.com/2009/05/24/mi-17-helicopter-simulator-flightgear-core-floss-inside/
Erik
?? wrote:
Hi,
I know OSG can load many types of model, but in FlightGear, why do we
use AC3D model type. We know that OpenFlight format model can define
DOF, it should be easy to use than AC3D. And there have many other model
types, why do we just use AC3D model type?
Historically
Now you're way ahead of me, I'm still at the stage where I want to see
if it really helps as much as I hoped it would.
Erik
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production
Lee Qid wrote:
Hi there,
and excuse me for butting in on this one, but the post just rung my alarm
bell.
Am I interpreting your post correctly? You want to implement your own
XML parser.
No, I have already.
Wouldn't that be like reinventing the wheel? There are tons of them
out
Hi Gene,
Good to see you back again, how's the F-15 project going?
Gene Buckle wrote:
Were you born a complete jerk or is this something you learned in school?
Thanks for standing up for me, but I'm used to direct and to-the-point
comments (I'm Dutch you know). I can see why people might find
Let's clear things up a bit (I hope):
1. I'm not planning rushing the code into CVS since I know the XML
reader code is one of the most important areas of FlightGear. Get it
wrong there and all sorts of pesky problems can arise.
2. The Expat code (along with EasyXML code) will remain
Hi,
As some of you may know I have been working hard the last few weeks to
improve a seamingly not very important utility called xmlgrep in the
FlightGear utilities directory.
The reason for this was that the way this code works differs from the
expat xml reader that FlightGear has been
Melchior FRANZ wrote:
* Erik Hofman -- Saturday 09 May 2009:
The downside of this code is that it is not 100% validating (so
it might accept xml syntax errors where expat didn't) and it
doesn't support DTD's.
Hmm ... so it's sloppier *and* slower, but *maybe* increases
runtime
Hi Detlef,
Could you also add this to the wiki?
Erik
Detlef Faber wrote:
Description from the logo.xml file:
This is a generic square shaped Logo which can be referenced by any
Aircraft Model as a submodel.
--
gerard robin wrote:
Yes it is difficult to trap these nan which are coming ( + or -
randomly ? ? ? , though, getting trouble with carrier) ), and when we get it
the system is closed to be frozen , with black screen, and command line
overflowed with messages.
And when i tried with GDB
Torsten Dreyer wrote:
-// Written by David Culp, started Feb 2004.
+// Original by Written by David Culp
//
-// Copyright (C) 2004 David P. Culp - davidcu...@comcast.net
+// An attempt to refine the thermal shape and behaviour by WooT 2009
+//
+// Copyright (C) 2009 Patrice Poly ( WooT )
Torsten Dreyer wrote:
Erik
You are right - sorry. It is corrected. I am sure there was no evil mind
behind that.
Probably not but I felt it was important to point out.
Anyway, thanks for fixing it.
Erik
--
Stay on
Hi Patrice,
Patrice Poly wrote:
I am declaring :
_earth_radius_node = fgGetNode(/position/sea-level-radius-ft, true);
props-tie(debug/earth-radius-ft,
SGRawValuePointerdouble(earth_rad_ft));
with earth_rad_ft = _earth_radius_node-getDoubleValue();
Vivian Meazza wrote:
Erik
After a request in the forum for a nice pink sunset I decided to update
the sky coloring a bit.
The fog color now transitions into the sky dome which gives a way better
result (imho).
(changes are both in SimGear and FlightGear).
Let me know what you all
Mathias Fröhlich wrote:
Good morning,
On Sunday 12 April 2009 10:24:09 Erik Hofman wrote:
oops, that's a left over debugging printf in simgear/scene/sky/dome.cxx
I'll commit a fix soon.
Oops, concurrent debugging.
I am looking into the remaining problem with the groundcache changes and I
Jon Stockill wrote:
Sunsets look very nice, but this looks a bit odd, I've not noticed it
before, so I'm not sure if it was introduced with this change, or an
earlier one, the top of the skydome seems to have some rather odd shading:
http://courgette.jml.net/~jon/fgfs-sky-001.jpg
Jon Stockill wrote:
Sunsets look very nice, but this looks a bit odd, I've not noticed it
before, so I'm not sure if it was introduced with this change, or an
earlier one, the top of the skydome seems to have some rather odd shading:
Hmm, I've updated CVS to fix the problem by removing
Hi,
After a request in the forum for a nice pink sunset I decided to update
the sky coloring a bit.
The fog color now transitions into the sky dome which gives a way better
result (imho).
(changes are both in SimGear and FlightGear).
Let me know what you all think.
Erik
Stuart Buchanan wrote:
Tim Moore wrote:
I'm trying to give your generic approach a chance.
I may be mis-interpreting your words, but if this means you're actively
investigating coding your new changes without vectors, then you deserve
many heartfelt thanks for putting extra effort to
Mathias Fröhlich wrote:
Catching up with an already heated up discussion.
IMO:
Tim should go on and include arrays into the property system.
I even believe that aggregates and more sophisticated types will be something
good to have.
There is still something that isn't addressed with his
Melchior FRANZ wrote:
My announcement to leave was in response to Curt's green light
and vote, to his opinion that the arguments against the change
weren't strong enough. Had I assumed that this isn't decided yet,
then I would neither have made the announcement, nor given up. But
actually,
Tim Moore wrote:
Erik Hofman wrote:
There is still something that isn't addressed with his proposal.
At this time all types can be converted to all other types. It would be
easy to convert any float/doubles or integers to a one element array,
but how would a multi-element array
Vivian Meazza wrote:
S Andreason wrote
Erik Hofman wrote:
Why wait for a NASA Shuttle? There already exist several models to see
the /interesting/ effects at altitude, some which have changed with the
new ambient values.
For good or for bad?
(and if for bad what exactly, or as precise
This should now be fixed in simgear/scene/sky/oursun.cxx
Erik
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
Curtis Olson wrote:
I don't have time to follow along with IRC so I can only see what is
posted to the mailing list, so I very well could be missing key parts of
this discussion. But honestly, I am really having trouble understanding
the objection here.
The biggest problem that I would
Melchior FRANZ wrote:
* Vivian Meazza -- Saturday 04 April 2009:
This is how I think it should look,
Does indeed look much better here (on my *still* quite bad monitor ;-).
Alright I've updated the ambient table (multiplied all values by 2.5)
Let me know what you all think with the CVS
Vivian Meazza wrote:
I've now amended the table to reflect the static offset, and I'm happy with
the result.
Even at midnight?
I was worried the ambient might be too light with a static offset.
Do you want proceed with this, or just drop it?
Lets get it right this time.
Erik
Timothy Moore wrote:
Erik Hofman wrote:
1. Will ambient/r, ambient/g and ambient/b still be supported in other
locations besides xml embedded effects en techniques?
That's my plan.
Ok, that's good to hear.
I think this will eliminate many of the objections.
Except for a few
S Andreason wrote:
Hi Vivian,
Why wait for a NASA Shuttle? There already exist several models to see
the /interesting/ effects at altitude, some which have changed with the
new ambient values.
For good or for bad?
(and if for bad what exactly, or as precise as possible).
One problem
Curtis Olson wrote:
This isn't an argument for or against Tim's proposal in and of itself,
but it's at least interesting to observe other real world cases that
are at least partially similar. Has JSBSim run into any problems with
it's journey down this path?
This has been one reason why I
Tim Moore wrote:
If people really don't like the effects syntax, I might be willing to hold my
nose
and use the existing property implementation. I'm also not committed to
having the
effects properties be of class SGPropertyNode; they might be a subtype.
I have two questions after reading
Heiko Schulz wrote:
Hi,
Well, for someone who don't have any ideas or knowledge about shaders, it
looks really complicated at the first sight. On the other site, it looks a
bit like the .osg-files, and with a bit diggin in, it would be understandable
for me at least.
I guess it is a
There seemed to be a problem with my mail since I noticed in the
archives there were some replies to my previous post about this item.
I've tweaked the values some more and think I've got it just about right
(or good enough) this time.
Erik
Melchior FRANZ wrote:
* Vivian Meazza -- Saturday 04 April 2009:
I can fix it here, to my entire satisfaction, so if everyone else is
happy, don't worry.
I can't really say much about this, as I'm using a rather old and not
so great monitor that I don't seem to be able to calibrate
Vivian Meazza wrote:
I'm doing a small adjustment in light.cxx - seems to work:
float ambient = _ambient_tbl-interpolate( deg ) + (0.25 + 0.75 *
visibility_inv/10);
Not sure that I fancy tinkering around in Data/Lighting/ambient - someone
has obviously taken a lot of care to craft
Erik Hofman wrote:
After reading the comments I agree with it.
I'll take some time to adjust the ambient accordingly.
This has been committed to CVS now.
Let me know what you think.
(keep in mind that the darkest ambient color is defined in
data/Lighting/ambient which has not been touched
Vivian Meazza wrote:
I'm not clear about how much ambient light there should be in any situation,
but, to me right now there isn't enough with the default model. The effect
of visibility on the diffuse and specular setting looks OK in very low
visibility, but at high visibility it looks very
Frederic Bouvier wrote:
Maybe I missed something but the visibility is not related to the distance
between the viewer and the object. As far as I understand Erik's intention,
there should be no glossiness in fog or inside a cloud, so setting glossiness
to 0 when visibility is 0 makes
Heiko Schulz wrote:
I'm against this code- I can't really understand what's the intention of this
code is- destroying glossiness?
Only when it's foggy. On bright clear days it will shine like before.
The real intent is to make it a bit more realistic.
I would like to see a change of the
Vivian Meazza wrote:
This is a tough one - I expect you can ask 4 developers and get 5 opinions.
Here - ambient is much too dark, while specular is about right. But the
visibility also seems to have far too much influence.
Indeed tough, especially since we still do have models with a wide
Hmm, sitting in the sun today during lunch made me realize that what I'm
really after is probably the effect of looking towards the sun in
comparison to looking in any other direction. The Bright light of the
sun seems to make the ambient light much darker (higher contrast).
Anyhow, Melchior
Hi,
I have changed the specular and ambient behavior of FlightGear a bit by
reducing specular highlight at decreased visibility and by increasing
ambient colors at decreased visibility.
This means that, form now on, when testing the color components of an
aircraft it is best to switch to
syd adams wrote:
You mean I have to start over fixing my models ? I've only made it to
C ! ;)
Nope, not as far as I know (and i was hoping to prevent that).
If you think it´s incorrect now let me know and I´ ll try to fix it in
the code.
Erik
Specter wrote:
I write patch for changes of JSB turbine starter spin time.
Dave just recently committed this patch to JSBSim and I am preparing a
new sync between them soon so it'll end op in FlightGear that way.
Erik
Csaba Halász wrote:
On Tue, Mar 24, 2009 at 12:47 PM, Erik Hofman e...@ehofman.com wrote:
Specter wrote:
I write patch for changes of JSB turbine starter spin time.
Dave just recently committed this patch to JSBSim and I am preparing a
new sync between them soon so it'll end op
Ron Jensen wrote:
On Tue, 2009-03-24 at 14:06 +0100, gerard robin wrote:
Does that will modify the original Jon's recommendation to start an engine ?
Get the external Air compressor resources
The engine will spin up to a maximum of about %25 N2 (%5.2 N1)
This
Tim Moore wrote:
Perhaps. I'm not proposing to change the syntax you like. I just want to
evolve the very useful property system to support the syntax I like.
So far nobody seems to like the idea of abandoning r/rg/gb/b
for a list of numbers. I think you can safely forget about that.
To be
Frederic Bouvier wrote:
Tim, perhaps if you could show us a real effect file, with the syntax
you propose, we ( at least I ) could see what we are talking about, and
the pros and cons of the new syntax.
That was in the original proposal (RFC):
Proposal: Allow vector types as properties in
Frederic Bouvier wrote:
Is it the whole file ? Are we talking about ten lines or tons of them ?
This was just one example.
Erik
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web
Tim Moore wrote:
Erik Hofman wrote:
Allright but how would you acces /model/skin/color/red in the new case then?
What do you mean by access? In C++ or Nasal within fg, or in the XML parse
within
another app? Why would you want red without green and blue and maybe
alpha?
In the color
Tim Moore wrote:
property node aggregates and aggregate C++ types is not a real problem
coding-wise. I just don't like the current XML syntax.
If this is you main motivation I'm just plain against this.
But I have the feeling that you're gonna regret this comment.
Erik
Melchior FRANZ wrote:
How will a VEC3 property be written in an XML file? As
foo type=vec3123;341;123/foo? Will then every application
which reads such a file have to have its own (sub)parser for
certain fields, in addition to using an XML parser?
This is my strongest point to be against it.
Mathias Fröhlich wrote:
But from my point of view the property tree is also used as a reflection
framework to reflect objects state into the models/scripting/whatever. From
my
point of view, the serialization of the objects into xml is just a special
case of that reflection stuff. Given
Maik Justus wrote:
Hi,
Or we do it vice versa. We store the vec3 directly in the property tree,
e.g.. surface/color, but you can access any components over the property
tree in the approved way. (surface/color/red, curface/color/blue, ...).
From telnet, MP, property-browser, etc.
Mathias Froehlich wrote:
Update of /var/cvs/FlightGear-0.9/data/AI/Aircraft/Fokker-50/Models
In directory baron.flightgear.org:/tmp/cvs-serv2499/Aircraft/Fokker-50/Models
Modified Files:
fokker50.ac
Log Message:
Set the ambient color equal to the rgb color.
This is what currently
Mathias Fröhlich wrote:
Erik,
On Thursday 19 March 2009 09:08:29 Erik Hofman wrote:
To be honnest I don't like this action. I've always made sure all color
settings were right in the modeller and did'nt adjust them to look nice
in FlightGear in any way. Same goes for the F-16, T-37, T-38
I've been silent in this thread mostly because I'm not very active as a
developer these days, but it got me wondering why one would use lua
instead of nasal.
Searching for 'lua nasal' in google the first hit describes it all to my
opinion:
The main reason for implementing the property system is that it can
represent the contents of any XML file in memory quite easily.
Erik
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
alex wrote:
Does OpenAL support any other sound file configuration other than .wav?
I have problems with OpenAL unable to buffer some ..wav files but runs
fine with other .wav files. Does anyone know of a particular reason for
this.
Your thoughts would be appreciated
Like gerard already
Anders Gidenstam wrote:
On Fri, February 6, 2009 5:39 am, syd adams wrote:
Hello ,
Ok, I have everything in the data folder converted to /level-lbs.
(The Concorde was a bit of a nightmare) ... :)
If someone could commit the patch , I'm ready to commit the data ...
I can update
Stefan Seifert wrote:
On Wednesday, 28. January 2009, Jon S. Berndt wrote:
Is there sometimes confusion as to how or where to apply changes to JSBSim
code or aircraft models? Do we need to work on easing the process of
integration into FlightGear? More frequent synchs? (we'd need
John Denker wrote:
This morning I did a git-pull and make.
I observe that the new version executes in 855 megabytes under
conditions where the previous version from a week or two ago
executed in only 450 megabytes.
That seems kinda extravagant.
Is everybody else seeing the same
Martin Spott wrote:
Overall, I think some day the crowd should start making up their mind
about wether relying on an externally maintained FDM is still the way
to go. Developing a copy of the FDM _in_ FlightGear might return a much
higher benefit at reduced effort.
I more concerned about
Jon S. Berndt wrote:
Is there sometimes confusion as to how or where to apply changes to JSBSim
code or aircraft models? Do we need to work on easing the process of
integration into FlightGear? More frequent synchs? (we'd need additional
volunteers, and/or I'd have to step in - I don't want
Hi James,
It has been a while since I've looked at this so I have to dig a bit
here. I don't think much has changed in the mean time though, except for
adding positioning and directional parameters.
James Sleeman wrote:
Erik I think you wrote the xmlsound.README file. Do you know if there
John Denker wrote:
One guy says not to report bugs in the old FGPiston,
because it has been fixed upstream.
Another guy say snot to report bugs in the new FGPiston,
because it is not committed code.
I guess that's one way to make sure there are no reported
bugs.
Fair enough, but make
John Denker wrote:
Here's what the docs (docs-mini/README.xmlsound) say, they don't quite
seem to match that. Or has all this just wooshed over my head and I
have to read your message again more carefully?
I stand by what I wrote.
Don't believe everything you read in the docs.
James Sleeman wrote:
You are of course, right. The more I think about it, the more I see how
really arbitrary and subjective it just has to be because of all the
variables that we can't possibly accommodate, and it comes down to
fiddling with essentially arbitrary numbers until it sounds
John Denker wrote:
On 01/23/2009 01:40 AM, Erik Hofman wrote:
Don't believe everything you read in the docs.
You'd better do, this is the specification of OpenAL.
I was talking about what happens in the Real World.
The specification of OpenAL does not supersede the laws
of physics
John Denker wrote:
I quote from
http://www.av8n.com/fly/fgfs/htm/bug-list.htm
80::As of mid-January 2008, there is a “new” version of
FGPiston.cpp floating around. It has not yet been committed to
FlightGear CVS. It gets rid of the specific problems mentioned in bug
79,
Arnt Karlsen wrote:
..no F-g way, they add a restriction beyond the GPL,
toss out all Boeing models and replace them all with
similar Airbus, Tupolev, Antonov, Shin-Meiwa, Harbin,
Dornier, Short etc models. And do it LOUDLY. ;o)
Not true in my opinion, the GPL can't explicitly allow
Jon S. Berndt wrote:
Arnt, they are completely within their rights to add that
stipulation. You
can bet all of the other manufacturers will have the same stipulations.
That said, the note/ section is just a reminder to anyone who wants to
make a profit by selling a 'Boeing 747' simulator
Hi Jon,
Jon S. Berndt wrote:
The C310 is one of the aircraft that - in the JSBSim cvs repository - is
used for extensive testing of JSBSim operation. There is a need for an
autopilot for the aircraft to be able to fly out the tests. The autopilot
file is expected to be found in the same
Melchior FRANZ wrote:
* Erik Hofman -- Wednesday 21 January 2009:
[...]
Modified Files:
Boeing314A.xml
Log Message:
Add the license statement
+ license
+ licenseNameGPL (General Public License)/licenseName
+ licenseURLhttp://www.gnu.org/licenses
I came up with the following for the F-16 file:
note
This model was created using data that is, or has been, publically
available by means of technical reports, textbooks, image graphs or
published code. This aircraft description file is in no way related
to the manufacturer of the real
Melchior FRANZ wrote:
* Erik Hofman -- Wednesday 21 January 2009:
Neither the name of (any of) the authors nor the names of (any of) the
manufacturers may be used to endorse or promote products derived from
this file.
Maybe it should be made clear that this part is not an addition
gerard robin wrote:
These addons won't be a restriction only an information.
True.
Erik
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
John Denker wrote:
Around here it has received around-the-clock news coverage.
The commentators are amazed at how lucky the passengers
were. They all use the same word: It's a miracle.
I disagree. Any time your airliner loses both engines is
*not* your lucky day. And while a successful
Hi Tom,
This sounds exciting, thanks for the explanation (I even think I know a
few names behind the job descriptions). It's good to see developers to
step up to the daunting task of getting every little last bit right for
certification.
BTW. I agree on the competitiveness part.
Erik
gerard robin wrote:
Hello Erik,
I have just updated within FG CVS the engines regarding the model that i am
working on.
These engines are now running with the the last update from Ron which is in
the JSBSim CVS repo.
I guess that you were talking about it.
I can notice that is not a bug
gerard robin wrote:
I could be wrong but Ron gave, with the FGPiston update, a c172 Engine update
(eng_io320.xml) .
According to the result it is very accurate.
True, but this requires a base package update to work correctly. Which
is better to delay a few days so the binary only bugfix
I was wondering if this would be a good time to update JSBSim again or
would it be better to hold off a bit?
Ron Jensen did update the engine model quite a bit which is good for
accuracy but it might introduce a few problems here and there.
Erik
gerard robin wrote:
Hello Erik,
I vote yes , you could update, since these Engine update are very accurate,
and necessary.
I have some Piston Engine Propellers aircraft which could get profit of it.
I did discover this requires updates to the engine configuration files
and since there
gerard robin wrote:
On dimanche 11 janvier 2009, Melchior FRANZ wrote:
* Erik Hofman -- Sunday 11 January 2009:
I was wondering if this would be a good time to update JSBSim
again or would it be better to hold off a bit?
If an update means having to update all JSBSim aircraft (configs
Brian Schack wrote:
I've noticed that with AI traffic turned on, there is a constant
setting and resetting of the time accessed by
globals-get_time_params()
This sounds like a misplaced leading slash in a property for AI models
to me.
Erik
John Denker wrote:
Hi Folks
FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that
Syd wrote:
John Denker wrote:
46:: Capitalization: Example: As of rc2, on the command line, when
specifying --aircraft=dhc2W, the dhc must not be capitalized, while
the W must be capitalized. This does not seem user-friendly. From
the user's point of view, this does not make any sense.
Heiko Schulz wrote:
Yep, the grey ones are nimbus- ns and stratus, maybe ac too has to be
disabled if we want to make a good impression with the release!
I did some work on the stratus texture:
http://home.telfort.nl/sp004798/emh/cl_stratus.png
Does that solve anything?
Erik
John Denker wrote:
Here's a bug report. I have two machines that exhibit the same
behavior, namely invisible aircraft. No error messages, no warnings,
just no aircraft.
..
Both are using OSG 2.6.1 and the rc2 package.
One odd observation: Not only is the aircraft invisible, but some
BARANGER Emmanuel wrote:
James Sleeman wrote :
In short, there are plenty of aircraft out there I believe that ARE easy
to fly in real life, and just saying that the best models with higher
quality can never be easy to fly is a wholly incorrect statement.
Everything is explained here.
James Turner wrote:
On 1 Dec 2008, at 11:03, Alexis Bory - xiii wrote:
For the remaining .rgb files, yes it's also possible to switch them to
png though it's going to be a huge commiting work as the f-14 use
tenth of different textures. I'll try beginning with the biggest
textures.
An
Curtis Olson wrote:
I've done some work on the sound system in main.cxx and have attached a
patch for folks to review if they want to look at what I did.
I made a simplifying assumption that the listener is either stationary
(stationary enough) or it is tracking with the aircraft model
Pep Ribal wrote:
I think the best way to proceed, after reading your posts, is to focus
on this solution: a different (open) protocol for FlightGear inside
IVAO servers. So what I'd ask you is a set of reasons why we should go
for this solution and forget the INL: techical reasons
Martin Spott wrote:
Instead, some places in FlightGear itself (at least Nasal and JSBSim,
as far as I remember) are the factors that limit portability.
I'm pretty sure JSBSim works nicely on IRIX. I'll give it another try
soon to make sure.
Erik
Csaba Halász wrote:
On Thu, Oct 30, 2008 at 12:36 PM, James Turner [EMAIL PROTECTED] wrote:
Trying to test this patch, getting a different hang (sort of) now,
where the program is halting on a 'throw' inside OSG - in the Qt image
loader, trying to load the C172's clock.rgb. I'm using the OSG
Heiko Schulz wrote:
With Stuarts clouds we have the ability to have all cloud types we want to
have! Of course there are some bugs- it is a start, and a lot of things can
be added!
Look here:
http://www.flightgear.org/forums/download/file.php?id=263
Maik Justus wrote:
no. The Doppler problems are due to OpenAL bugs and limitations. On most
systems (at least at all which are using Open AL software Doppler
calculation) I got strange effects. On Linux systems a workaround was to
use only the relative velocity of listener and sound,
Melchior FRANZ wrote:
I guess we have to define what actual means here. As far as I
know by now, there are three variants:
(a) original OpenAL by Loki (as Erik pointed out recently)
(b) official OpenAL by Creative (continued from (a)). Development
I have tot state that the Creative
701 - 800 of 1053 matches
Mail list logo
