Josh Babcock wrote:
How difficult would it be to make a nasal function call that would
return the lat/lon/alt of the point on the ground under the cursor?
You certainly can't do it in Nasal alone. Code would have to be
written to project a line between the eyepoint and the cursor location
and
Neville van Deventer wrote:
Error validating location: I/O exception occurred: Connection
refused: I HATE YOU
Heh, that's amusing. I googled this, and it turns out that I HATE
YOU is the defined response in the CVS protocol for authentication
failures. :)
You may have a bad password in your
Josh Babcock wrote:
Right, it would be silly to send all that data to the server when all it
needs to know is where your are and what you can see. Plus the position
data could be sent at low resolution.
The best way to do this is actually dynamic: the server gets to send
the X most important
Oliver Schroeder wrote:
I was thinking about oberservers, too. So it will be possible to
build radar stations (human operated) and tower controll etc,
without disdurbing the other clients (which would try to render the
observer).
Rather than special casing this (special case abstractions are
Frederic Bouvier wrote:
Oliver Schroeder wrote:
So the question is: How can I easily calculate the distance and how many
nautical miles are out of reach (thinking of e.g. radar systems) ?
You can compute distance at an altitude using SimGear functions
Ack, don't even *think* about doing
Ampere K. Hardraade wrote:
I think it will be more flexible if the networking portion of
FlightGear can be modified to exchange properties. For
starter, the nodes /accelerations, /positions, and
/surface-positions can be exchanged among users. Properties
under /accelerations can allow one
Ampere K. Hardraade wrote:
How about creating root-less nodes to act as seperated property
trees for these aircrafts? This way, it will be easier to fool
the animation files of these aircrafts into taking the proper
values.
Yes, exactly. They don't need to be rootless, just detached from
Vivian Meazza wrote:
I do use the cruise value - based on the full throttle
altitude. It's fine. YASim provides a good solution. Very
impressive.
Clearly I'm very confused then. You were asking for the boost
control to work during solution earlier. Is that not a
requirement? The cutout
I wrote:
We're about to go in circles again, and my blood pressure is rising.
So try this: DON'T reply to my message paragraph by paragraph.
Start from scratch, post a configuration file that you want to use
that does not work. Explain why. Use numbers. Ask for
suggestions. Don't touch
Vivian Meazza wrote:
You certainly are! The Boost Control works by adjusting the
_throttle_ (in accordance with reality and your earlier suggestion).
Why not just use a solution setting that doesn't involve the boost
control cutout? I'd think that a flat out solution would be most
likely wrong
Harald JOHNSEN wrote:
Is there a reason why we are using fans and not strips for tile
objects ?
These days, it's usually faster to use indexed vertices. Strips and
fans are faster because they reduce the number of vertices that need
to be transformed by (and sent to) the hardware by saving 1
Vivian Meazza wrote:
Back from a holiday in France. The modified software tests OK
here. One small snag: the MP is not ambient when the engine is not
running. Strictly, this should be turning, I suppose, because a
wind-milling supercharger will produce some pressure. Near enough
though.
Paul Kahler wrote:
I once downloaded a Velocity and a Starship for MSFS and they were
really fun to fly - not sure if the dynamics were correct at all
because they really wanted to fly in a way thats hard to
describe. OTOH I have read that canards really do like to fly compared
to other
Arnt Karlsen wrote:
..and utf-8 fonts? Supports far more languages, including all those
supported by ISO-8859-1.
Not supported by plib, unfortunately. The whole plib font mechanism
is based on an 8 bit lookup table; it would require significant
surgery to fix.
I believe the .txf font file
Jim Campbell wrote:
The modelling of a generalised rigid body with six degrees of
freedom in a rotating frame of reference should max out anyones and
everyones CPU!
People were doing that in real time with VAX 11/780's in 1981. :)
Seriously, no: the FDM takes up comparatively little CPU. Of
Jim Campbell wrote:
Hopefully I would like to start a discussion of Flightgear code
optimisation.
OK. The most important point to remember is that FlightGear is
generally not CPU bound at all. It spends the vast majority of its
time sending primitives to the hardware to be rendered, and then
Jon Foster wrote:
I'm having a problem with sound in FlightGear 0.9.8. When I
rename my .asoundrc to .asoundrc-bak, fgfs works fine and sounds
great. But when I try to use my .asoundrc I get line after line
of native_blitbuffer: select error occured and intermittent
sound (kind of a
Vivian Meazza wrote:
Meanwhile, you are distracting Andy from updating the awaited
supercharger code.
Heh, fair enough. This is checked in now, with a general rewrite
to clarify things and fix the bug where MP was reported before
the wastegate application.
The only new property is
Apparently there is no stencil in 16 bpp mode. Can someone check if
there is an alpha channel in 16bpp mode and how many bits in it ?
I actually see the same symptom in 32bpp, but I think I've found it.
Here's a partial explanation:
When the main window is created, it asks for the depth
bass pumped wrote:
Martin Spott wrote:
bass pumped wrote:
The website says the password is 'guest'. It doesn't work for me!
just stalls!!
Why do you yell at me !?
I'm sorry... I didn't think I was yelling at you. But if u feel I
did so, I sincerely apologize, that was not my
Simon Hollier wrote:
Andy Ross wrote:
[...] tought [...]
...and some of us were taught ;
Oh, the irony!
Mea culpa. But it would only have been ironic if I were criticizing
spelling, not usage.
You didn't punctuate your first sentence, by the way. Smileys don't
count. And your usage
Simon Hollier wrote:
Andy Ross wrote:
And your usage of the ellipsis is non-standard; it should
represent missing text.
It did represent missing text: Some of use were tought,
Except that text wasn't missing. You quoted it, remember? And even
if not, it was *my* text and can't
Josh Babcock wrote:
Is there a way to get button-release events from the clickable
panels, or do they just sense a button-press and touch off the
command then? I want to make some instantaneous switches for the
B-29. I have figured out how to do it with the keyboard and
joystick, but I also
Pete Buelow wrote:
I'm trying to build FlightGear for FC4 on an nifty new amd64 game
machine. I used to fly on a slightly slower Athlon, but want to
step up to the plate and see if things are that much better with
my new video card and 64 bit processor. Here's the issue.
[... a spot where a
[cc'd to flightgear-devel, as this is clearly an architectural issue
and not a bug report.]
The basic issue as I understand it is that apparently
SGPropertyNode::removeChild() has been (incorrectly, AFAICT) modified
to ignore nodes that have a reference count greater than one, which
interacts
Melchior FRANZ wrote:
Well, the theory is that the property tree is there to
inspect/access values. And the idea is that a remove function
shouldn't only detach property nodes that are then secretly used
behind the users back. If you want them to stay, don't remove them.
Reference counting
Erik Hofman wrote:
Andy, I have to agree with Melchior here. If you call removeChild you
have the intention that it will stay in the tree until refcount becomes
zero and then it will be deleted. If you call removeChild() and it just
detached from the tree (without cleaning it up at some point)
Melchior FRANZ wrote:
Andy Ross wrote:
* In this case: using the reference count to tell whether or not the
node is in the tree or detached.
Actually, it prevents nodes from disappearing from our property node
memory representation -- which is the property tree.
It sounds to me like
Martin Spott wrote:
Andy Ross wrote:
If someone can set me up with ssh access to a shell account (no need
to run the whole fgfs binary) on a Mac or SGI or whatnot, let me
know. :)
I could offer an account on an UltraSparc with GCC,
As long as the compiler generates 32 bit executables
[EMAIL PROTECTED] wrote:
I typed make and I got the following error:
FGNozzle.cpp: In method 'JSBSim::FGNozzle(JSBSim::FGFDMExec *,
JSBSim::FGConfigFile *, int =0)':
FGNozzle.cpp:74: implicit declaration of function 'int
JSBSim::snprintf(..)'
Does someone knows what is wrong?
Martin Spott wrote:
Erik Hofman wrote:
I've tried several approaches to get Nasal working for big-endian
(32-bit) systems but they all fail. I don't see a way to get this
working and this makes FlightGear unusable for IRIX at least:
Man, am I happy that I'm not the only one with disabled
Alex Romosan wrote:
Dave Culp [EMAIL PROTECTED] writes:
Just curious ... Is there any reason why OpenAl doesn't offer stable
releases?
probably because it's still under development? on their web page
(openal.org) they say they are migrating to openal 1.1 specifications.
as such i would
Melchior FRANZ wrote:
Actually, I have already changed it, and would like to commit. Just
want to make some more tests. Worked well so far. :-)
Sounds great to me.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Melchior FRANZ wrote:
http://members.aon.at/mfranz/fgfs_gui.jpg [80 kB]
Very nice. :)
Someone should start hacking at the puButton class, though. That
close button is starting to look kinda gimped with the cutoff highlight
lines and no image label.
Andy
Josh Babcock wrote:
One niggling feature request that I have is that these dialogs [...]
be resizable.
Doing resize for the dynamic layout dialogs wouldn't be that hard,
really. The existing drag code does almost everything that is
required, all that would be needed would be code to tell when
Arnt Karlsen wrote:
Andy Ross wrote:
Yeah, but that's a bug. There is only one manifold pressure.
Surely you don't want *both* mp-inhg
and supercharger-output-inhg, which mean exactly the same
thing.
..I beg to differ; flow always means there are flow losses.
The discussion was about
Vivian Meazza wrote:
What does it do for defined properties that contain null/nil?
It doesn't. The solver doesn't actually try to read properties during
solution (which would be madness -- you would get different solution
results by changing values that aren't in the aircraft definition
file).
Harald JOHNSEN wrote:
I have started to add some volumetric shadows in Flightgear. It
uses the standard stencil method to count shadow volume
Wow, nice work. How are you handling silhouette optimization?
For those interested, the basic idea behind stencil shadows is that,
for every triangle
Harald JOHNSEN wrote:
There is a pre process step where I look for the 2 triangles that
share an edge.
You're doing that per frame? Does it work well? I saw a huge CPU hit
from that test, but that was about 2.5 years ago on a slower machine
than is available now. Is the code complete enough
Oliver C. wrote:
Maybe it sounded in your first letter like that you may be one of
those Americans who allways try to make the USA the center of the
world.
It should be pointed out that those Americans live almost
exclusively in your television set. Real people, even republicans,
are
Oliver C. wrote:
In this case inch Hg is wrong, because it is not an SI-unit.
Pascal (Pa) is a SI-Unit so that should be used in the base code.
Conversion from none SI-Unit can still be done in nasal code.
Uh... except that aircraft gauges almost never read in SI units.
The point here isn't
Vivian Meazza wrote:
control-input axis=/controls/engines/engine[0]/boost-control
Here is the setting in the property browser
Controls/engines/engine/boost-control= 1.0
Case bug or just a typo?
Andy
___
Flightgear-devel mailing list
Vivian Meazza wrote:
OK with the name. PSI(gauge) is what we use over here, otherwise
it's inhg absolute for the US. Gauge-inhg makes no sense. In real
life there's no difference between the way the US and UK measure the
pressure, it's the zero on the gauge which is different, so I think
it's
Vivian Meazza wrote:
I found this in thrusters.cpp
Another potential pooh trap?
No, those are applied to the throttle setting after the input mapping has
happened. The code you want to be reading is in ControlMap.[hc]pp
Andy
___
Flightgear-devel
Vivian Meazza wrote:
I would deduce that the property:
Controls/engines/engine/boost-control
Does not exist when the solver runs.
It should still see a zero for undefined properties, although you can
make arbitrary property settings in the approach/cruise definitions up
at the top. Some of
Re: Re: FW: Re: Fwd: FW: Re: Re: Re : Re: Re : Re:
What was the subject again? Someone's mail client is obviously
very angry...
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Clifford Yue wrote:
Andy Ross wrote:
Re: Re: FW: Re: Fwd: FW: Re: Re: Re : Re: Re : Re:
What was the subject again? Someone's mail client is obviously
very angry...
any one can give me some hint about how to run the MS FS models
under flightgear?
Of all the messages to reply
Vivian Meazza wrote:
Good news: I've got Andy's code to run. Just a few minor changes.
Bad news: It doesn't work.
I've set the property /controls/engines/engine[0]/boost-control to
a fixed value. Yasim shows the correct Boost value. But there's no
power.
What does show the correct boost
Vivian Meazza wrote:
Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of
boost)
Can you try it with the CVS code? This may be interacting badly with
your local changes, which makes debugging difficult. Nothing in this
mechanism should require any of the new code.
Also on
Vivian Meazza wrote:
I like it very much indeed. Will it work in practice? Testing and
tuning will take some time as I don't have any exact data. Probably
into next week.
I suspect it should work fine. The real device would have been an
analog computer hooked to a (presumably) slow motor, so
Vivian Meazza wrote:
Additive? I.e. are the input axes added?
Yes, all control axes are added to get the final value (clamped to the
natural output range, of course); this is how trim works, for example.
Andy
___
Flightgear-devel mailing list
Vivian Meazza wrote:
Andy Ross wrote:
* For one, I still hate the boost function that goes negative at high
RPM
I have revised the curve: now a Hoerl power function. It's a good fit
over the rpm range up to x4 peak power rpm (unnecessary: x3 is too
much imho) and tails off thereafter
Vivian Meazza wrote:
It would be possible to simulate the Boost Control Cutout by
adjusting the wastegate on the fly to a very high number effectively
disabling it (I take that it is possible to do that). It's a hack, I
don't like it, but ...
The whole thing is a hack anyway; if we *really*
Vivan Meazza wrote (in a CVS checkin):
I've removed all the features that rely on the diff to YASim
that I posted recently, I don't expect any reaction from Andy
any time soon! I feel a bit inclined to remind him of his rant
against Cygwin recently. I'm willing to be favourably
surprised.
Gerard Robin wrote:
Something wrong ?
--prop:/nasal/local/script=![CDATA[ INIT = func { setprop
(/sim/rendering/clouds3d-cache-size, 4096); } ]]
nasal does give error message: Nasal parse error: parse error in /nasal
[0]/local[0], line 1
The --prop argument is not an XML parser. Just
Andy Ross a crit :
--prop:/sim/rendering/clouds3d-cache-size=4096
It should work but the program overload the data, only one way the
nasal way
That sounds like a bug to me. The command line should be overwriting
anything in the configuration files. Is the cloud code (over-)writing
Gerard:
--config=/home/tux-le-boss/.fgfs/preferences.xml
Error loading config file: Failed to open file
at /home/tux-le-boss/.fgfs/preferences.xml
Melchior:
Well, then this file just doesn't exist or has wrong permissions.
Gerard:
Yes Existing, good permissions
Melchior:
Try this:
$
Gerard wrote:
Melchior wrote:
Yes, and I was right: this file just doesn't exist! This is not an
fgfs message, but one of the operating system.
Not so Quick..
Oh do you remember i told you :
You can't really argue with a syscall result. The file isn't there.
Maybe there are some
Josh Babcock wrote:
Is there any king of piston engine temp modeling going on in YASim
yet? I see egt-degf but it looks like it's just the air temp.
No. There are actually many spots on engines where people like to
stick thermocouples. Oil temperature and cylinder head temperature
are the
Lee Elliott wrote:
One problem with using YASim for sea planes is that the fuselage
mustn't contact the surface as this equates to a crash. While I
was experimenting with the SR45 I found that I had to omit the
lower fuselage deck to achieve this, which must then affect the
flying accuracy.
Gerard Robin wrote:
I could not use JSB (no rotor FDM) and with the use of Yasim it has
been very difficult to find the right way which make that model to
stand correctly on water with gear-up.
To answer that, JSBSim gives a better flexibility.
Both JSBSim and YASim use manually placed gear
eagle monart wrote:
i am totaly lost. i ve tried different declarations of delay
functions but they starts infinite loops. i tihnk nasal expalined
only for xml usage but i didnt find a source to declare settimer()
in a source code . I need a reference...
The documentation for the function is
Gerard Robin wrote:
with Yasim we must find a medium way to get the same effect. About
retractable gears no problems, about contact points on the fuse big
problems .
I'm not understanding this at all; JSBSim and YASim have all but
identical* gear systems. Can you please post the YASim
eagle monart wrote:
i am tryng to add a delay in seconds before activation/
deactivation of cockpit functions. my aim is to declare
specific drag according to time within component cycle time. i
am trying to add an example decleration for that purposebut
function goes
Erik Hofman wrote:
Dave Culp wrote:
If the user sets the property /sim/pause-on-crash to true, then
the sim will pause on crash, which is the same behavior Yasim has,
so this should be the default for FlightGear. If the user sets the
property /sim/reset-on-crash to true, then the sim
theoreticle wrote:
Let's say someone comes up with a model for the old Pan Am Clipper,
that wants to land fully loaded with passengers and half loaded with
fuel. The actual aircraft will sink it's fuselage as far as 5 feet
into the water, perhaps more if landing in 'seas'. There absolutely
Martin Spott wrote:
I'm curious if it is possible to 'simply' define the whole model as a
contact point and let the OpenGL subsystem detect terrain collision.
Not meaningfully. The 3D geometry can tell you collision points
between polygons. It can't tell you whether those polygons are
landing
Melchior FRANZ wrote:
Sure. AFAIK, every nasal context can write into any nasal namespace.
This does include to overwrite an existing function there. I for one
am overwriting view.stepView() from my personal
$FG_ROOT/Nasal/local.nas. I've redefined controls.throttleAxis() to
grab the
Josh Babcock wrote:
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
if ( getprop(thisProp) == 1 ) {
but this
} elsif ( getprop(thisProp) 1 ) { Line 143
produces this error:
Nasal runtime error: nil used in numeric context
[EMAIL PROTECTED] wrote:
I know this is an incredibly dumb question.. but in Nasal an
elseif conditon is expressed as elsif?
Perl uses elsif like Nasal. C and derivatives (and Javascript) use
else if only because they hack their parser grammers to handle the
inherent ambiguity. The bourne
Drew wrote:
Is there a reliable way to determine the terrain height below the
aircraft that is independent of the view being used?
Subtract the AGL altitude from the MSL altitude? I'm pretty sure both
of these are available in the property tree.
Andy
Drew wrote:
Perhaps the FDM needs to set this, in which case, how would the FDM
model know what the terrain height is?
Yes, the FDM needs to set this, and it knows it because it needs it to
compute the gear forces. I know support is there in YASim; if you are
using a YASim model and this isn't
Drew wrote:
I'm not using a YASim model...it's a net-fdm interface...I'm only
using FlightGear as a scenery generator. Anyway, I just looked at
the YASim code, and it uses environment/ground-elev-m to derive
the height above terrain, which means it will also fail using tower
view.
Er, no.
Josh Babcock wrote:
Is there a way to tell YASim to add or subtract some drag? I
want to add some drag to the superfort when the bomb doors
open. They were supposed to really wreck the airflow, though
not as bad as the lg which doubled the drag!
Well, right now you could model them as landing
Josh Babcock wrote:
I don't think the LG thing will work, they have to be extended
independently of the LG.
Just tie a different property to the EXTEND input on the gear.
Nothing in YASim is hardcoded; all user inputs are configurable.
Speedbrakes would be great, though I would request that
Melchior FRANZ wrote:
I'd like to suggest to add the possibility to add a nasal
init block to joystick *.xml files:
This sounds fine to me.
but there's one questionable requirement: the nasal subsystem
must get initialized before the input subsystem. And
currently, a comment to the nasal
Melchior FRANZ wrote:
Andy Ross wrote:
I think it might be cleaner, though, for the Nasal subsystem to
provide for a callback or init script that can be set by a caller.
I'm not sure I understand. To request a callback I have to have Nasal
working already.
Yeah, that wasn't clear. I mean
Wow, very cool.
Torsten Dreyer wrote:
This is a kernel module for a linux 2.6 kernel on ix86 machines with
8250/16450 serial ports (standard pc hardware).
Comments *ARE* welcome!
Anybody out there, who can point me to a resource for developing joystick
drivers for MS?
No hints about
Torsten Dreyer wrote:
Well - it's not really a serial driver, the interface connects thru
the handshake lines rts/cts and dtr with rxd and txd left
unconnected since the LTC1090 speaks a synchronous protocol.
Oh, heh. Well, if the hardware is non-standard, then one hack is as
good as another.
Theo Reticle wrote:
I was getting that same No Python window in Blender 2.36, even
though I had followed all of the instructions for Python 2.4 for
Windows.
Hrm... maybe Blender should be using Nasal. With only 60k of object
code, you can link it right into the application without worrying
Melchior FRANZ wrote:
How would the filter read and write AC3D files? Without file IO
support?
It's written. Here's proof: http://plausible.org/andy/iolib.c
It probably won't compile against the SimGear nasal sources, though.
I really need to get my act together and make a new release.
Melchior FRANZ wrote:
But fgfs won't depend on pcre, right? Or do you plan to statically
link it? Sounds like great stuff, but how well would this work under
MICROS~1? Unix syscall? Or rather POSIX?
Right. The library stuff gets complicated enough that individual
projects will need to make
I wrote:
The property system does not support arbitrary byte arrays in the
string value. The SGPropertyNode::setStringValue() interface
supports only C strings (a char* with no length), which are always
nul terminated.
Well, char* doesn't require it to be NULL terminated and
Drew wrote:
I'm building a 3-D model of an aircraft, and for some surfaces, I
decided to use 2-sided polygons to simplify things. However, when
FlightGear renders the object, one side of the surface gets shaded
exactly the opposite of what it should. Is this a known issue?
Indeed. Normal
Erik Hofman wrote:
I don';t think the property tree cares much, I expect this is a
string handling problem in Nasal because it is written in C(++).
No, Nasal strings are arbitrary byte streams. You can have embedded
zeros. I understood the question to be about the property *name*, not
the
Sergio wrote:
I've automatically (pkg-get) installed FlightGear on my Solaris 10 :
all is here (plib, simgear, fgfs and base), a good scenery ; the
simulator starts normally, with a perfect sound, but... very too
slow.
What kind of 3D hardware/drivers do you have? FlightGear does not
work in
Ampere K. Hardraade wrote:
Andy Ross wrote:
Is there some sample code to exhibit the problem?
Do you mean something like this?
Yup, that will do it. :)
You're right. The property system does not support arbitrary byte
arrays in the string value. The SGPropertyNode::setStringValue
Ampere K. Hardraade wrote:
Why doesn't the property tree except the \0 character?
Is there any chance that it can accept the \0 character?
The zero is the ASCII NUL character, which has been used as the end
of string marker since the beginning of time (which we all know was
at midnight GMT on
Matthias Fröhlich wrote:
I recently profiled flightgear with gprof and with callgrind.
One of the functions most cpu intensive function under Linux (fedora core 3)
is the isspace() function in split.
That might be even worse with the windows implementation of isspace.
Well, at this point it's
Erik Hofman wrote:
Norman Vine wrote:
FWIW I think these apply here
http://www.catb.org/~esr/faqs/smart-questions.html#id3001405
http://www.catb.org/~esr/faqs/smart-questions.html#keepcool
These two contradict (You can't offend them but they can offend you).
It's a nice document on how
Vivian Meazza wrote:
The results of this patch are very encouraging:
Airports and Navigation Data Total
Before2 min 40 sec3 min 50 sec
After 1 min 40 sec2 min 50 sec
It's still the most significant part of
I wrote:
Attached is a little perl script that
does that. Untested. Use it as someting like:
Oops.
Andy
fgapt.pl
Description: Perl program
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Well, there's some progress. I have a cygwin build, and it's every
bit at slow as Vivian says it is. And I've kinda/sorta isolated the
problem. Here's a program:
// g++ -o aptdat aptdat.cc -I$FG/SimGear -L$FG/lib -lsgmisc -lz
#include simgear/misc/sgstream.hxx
#include
I wrote:
The bottom line is that this is a cygwin bug and we can't fix it,
sorry. Hopefully someone with more love for this platform than I
(I've done my time, heh) can forward this to them and get it fixed.
No, that's dumb. I may not like windows, but cygwin is one of the few
things that
I wrote:
No, that's dumb. I may not like windows, but cygwin is one of the few
things that makes it bearable. :)
[...]
I'll try to dig up a cygwin mailing list to which to submit this.
Well, I submitted it. Alas, it didn't go well. You can follow the
flame war here:
Dave Culp wrote:
Lately I've been flying around German terrain and have been getting
an FDM freeze at seemingly random occasions after flying for ten
minutes or so.
My guess is this is a crash due to weird collision detection in the
ground or gear code. The last I checked, JSBSim and YASim
Richard Bytheway wrote:
Would it be possible to have a compiled form stroed on disk, which
is automatically regenerated on startup of FGFS based on rules
similar to make. If the ASCII version is newer than the compiled
version, rebuild the compiled version.
Sorry, but that sounds dumb.
Vivian Meazza wrote:
Only a minute eh? Under Cygwin cvs takes nearly 5 minutes - time for
a brew a coffee - and that's on a pretty powerful machine.
Time from execution to fade in of the cockpit display is about 10
seconds on my laptop (1.8GHz Athlon64). I started trying to hunt this
down.
Dave Culp wrote:
One decision to make is what the handler should do once a crash is
detected. I have it calling the reinit code in order to reset the
sim to the starting position (below), while others may prefer to
have the sim close after a crash, or perhaps display a crash-splash
screen
Here's another startup speed patch (against plib this time) for
windows users to try.
The plib loader for the RGB texture format wants to do piecewise I/O
on the file. It will repeatedly seek to the beginning of a scan line
in the image, then read, then seek, etc... Because of the color
101 - 200 of 1282 matches
Mail list logo
