[EMAIL PROTECTED] writes:
The file at this link contains update to the preferences.xml
and keyboard.xml
for use with the pilot offset dialog. These are based on
current cvs.
Can you expand on what this is a little bit for me? This is important to me
because the configuration file for
D Luff writes:
Jon Berndt writes:
Did we goof somewhere? Do we need to change something?
Well, I suppose we ought to allow users to specify that the engine
is running at startup.
IMHO - a 'mouseless' interface to FGFS is mandatory !
so there should at least be a keyboard shortcut
Cheers
Mally writes:
It's probably too late to comment on this by now, but from a
user point of view,
it's very awkward when you've got the stick in one hand on
approach to key the
SHIFT-key options. I'm in favour of single key presses
wherever possible for the runtime functions.
A good point but
David Megginson writes
Sent: Thursday, Novembe
John Check writes:
I can't argue with that. Does anybody have suggestions for
keybindings?
How about 0, 1, 2, and 3 for the magneto positions?
I like the idea but how about if we extend it a little with
some borrowed ideas i.e.
ctrl-e 0
Richard Ki writes:
I have a problem with WinCVS connection to
[EMAIL PROTECTED]:/cvs/FlightGear. I got the Connection
refused answer after I tried log-in using guest password. I'm used
WinCVS 1.06 and 1.20. There is possible to set Use cvs 1.10
option in
preferences-general tab only (there is
Jon S. Berndt writes:
Next there is probably some bug in RESET menu option function, FG
crashes always then.
This does not yet work with JSBSim.
But it used too :-)
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Don Baker writes:
I have a couple of IBM RS6000s, which I continue to use because of some
NASA codes I have which won't run anywhere else.
Has anyone ever heard of anyone running FlightGear under AIX?
I haven't heard of anyone trying AIX.
Do they have accelerated hardware OpenGL support ?
If
Don Baker writes:
I have a couple of IBM RS6000s, which I continue to use
because of some
NASA codes I have which won't run anywhere else.
Has anyone ever heard of anyone running FlightGear under AIX?
They have OpenGL. I don't know how accelerated it is. :).
Sounds to me like you ought
David Megginson writes:
I'd like to propose changing some of the default keybindings.
Most PC keyboards have a 3x2 cluster of keys at
the top, with Insert/Delete on the left, Home/End in the middle, and
Page Up/Page down on the right. I'd like to rebind those as follows:
Are you sure that
David Megginson writes:
Are you sure that GLUT maps these keys differently then the ones
on the numpad ??
Unfortunately, not -- that's why I wanted to check.
AFAIK It does NOT !
see $glut_src / test / glut / keyup_test.c
I propose we investigate runtime assignment to the keyboard
esp
Andy Ross writes:
And it
wasn't a windows.h problem, but instead with cygwin.
FYI
THIS IS MORE THEN A CYGWIN PROBLEM
Following sniped from
http://lxr.linux.no/source/include/linux/ctype.h?v=2.4.13
1 #ifndef _LINUX_CTYPE_H
2 #define _LINUX_CTYPE_H
3
4 /*
5 * NOTE! This ctype does not
Andy Ross writes: :)
Oh yeah, and try flying around with the YASim planes and tell me what
you think and want changed.
Pretty neat :-))
Haven't got to much more time to experiment to night
but all of your planes seem to fly on my Cygwin box
and I can teleport with 'reset' and 'goto airport' so
Curtis L. Olson writes:
Norman, did you track down your FGKinemat build problem? I'm not
seeing it on any of my machines here.
YES
Sorry I did not make that clear in my earlier message.
BTW
Expect a bunch of changes from me tomorow to
get 'reset' and 'goto airport' 'kind of' working again
Curtis L. Olson writes:
Norman Vine writes:
BTW
Expect a bunch of changes from me tomorow to
get 'reset' and 'goto airport' 'kind of' working again
Ok, sounds good. I took a look at that yesterday and fixed one
potential problem in simgear (actually the problem is in flightgear,
but until
Martin Olveyra writes:
It
would be nice if the web page had a 3D model repository with a little
screenshoot for each.
see
http://home.t-online.de/home/Wolfram.Kuss/
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
VS Renganathan writes:
You can see the carrier in FlightGear by giving the lat,lon,alt in
~scenery.objects.txt.
Or use the 3dexplorer (windows only) shareware viewer. If you
are interested
I could send you the wavefront .obj file format specs. The
carrier model is
a simple low polygon one
Roman Grigoriev writes:
Could you please tell me how to use opengl extesions under cygwin?
What fuction should i use wglGetCurrentContext or glXGetCurrentContext?
Same as you would for Windows wglGet...
Cheers
Norman
___
Flightgear-devel mailing
Thought that I had sent this before but after
a fresh CVS up I noticed the minimal hud still
had a problem
$FG_ROOT / Huds / Instruments / Minimal / hudladder.xml
The attached gets rid of the 'munged' rungs cruft
Cheers
Norman
PropertyList
ladders
l1
nameartificialhorizon/name
Christian Mayer writes:
It would be really great if 0.8.0 - or even 0.7.9 works with MSVC. The
compiler errors are mostly fixed by now :), but I've got still problems
running FGFS w/o having the maths blow up during the first frame
(happens currently with both, JSBsim and LaRCsim, but on
Curtis L.Olson writes:
Norman Vine writes:
another problem is in simgear / sky / cloud.cxx
bool SGCloudLayer::reposition( sgVec3 p, sgVec3 up, double
lon, double lat,
double alt )
{
// now calculate update texture coordinates
if ( last_lon -900
Julian Foad writes:
Can any of you debug FlightGear using the CygWin GDB?
Whenever I try, I can use the basic functions (stepping,
breakpoints, view source code, etc) if I am very careful to
treat it gently, but when FlightGear crashes GDB tends to
crash too. I am using version 20010428-3
Christian Mayer writes:
Norman Vine wrote:
Christian Mayer writes:
All of those (i.e. LaRCsim and YAsim) work for me. JSBsim currently
doesn't. I'm still working on that.
Same here trying to run with MingW32 although Cygwin has no
problem
I am crashing during initialization
Julian Foad writes:
Ah, that's good. Thanks. It works. I have now found a
proper description of the situation in this announcement of
the combined (new and old) version:
http://sources.redhat.com/ml/cygwin/2001-12/msg00100.html
Ah -- good I had seen this but didn't have a link handy
So
Andy Ross writes:
Norman Vine wrote:
G..
One of those variables that only lives in the 'ether world'
A VERY GOOD REASON for these things to live in a real 'C'
variable ..
I think you misunderstood. It *does* live in a real C variable
(FGInterface::Tank1Fuel).
Ackk.. you
Curtis L. Olson writes:
3) And we'll need three very large folks to sit on Norman and hold him
down while we do this. :-) :-) :-)
No reason to sit on me,
As you know I have been resisting forking a different way
of doing things for a long time and this will be the little shove
that makes it
David Megginson writes:
Norman Vine writes:
but how about having the compile time option to turn it off
ie
#ifdef DO_TRACE // or any good memonic
#define DO_TRACE_READ(type) if(getAttribute(TRACE_READ))
trace_read(type)
#define DO_TRACE_WRITE(type) if (getAttribute
Paul Deppe
When compiling SimGear 0.0.16 with the latest Cygwin (Win2K) I get the
following compiler error. Has anyone else seen this? This is
a clean
SimGear with ./configure; make.
Everything goes well until...
Making all in simgear/metakit/unix
This is getting repetitive
Would someone
Jon S. Berndt writes:
Paul Deppe wrote:
When compiling SimGear 0.0.16 with the latest Cygwin
(Win2K) I get the
following compiler error. Has anyone else seen this?
This is a clean
SimGear with ./configure; make.
Everything goes well until...
I've got CygWin (pretty much the
Curtis L. Olson writes:
Norman Vine writes:
This is getting repetitive
Would someone who has SimGear CVS write privlidge
PLEASE change the CXXFLAGS variable in
SimGear/simgear/metakit/unix/Makefile.in to
# not normally compiled with -g, but you can specify it in
the make command
Erik Hofman writes:
Norman Vine wrote:
# not normally compiled with -g, but you can specify it in
the make command
CXXFLAGS = -O3 -fomit-frame-pointer -DNDEBUG
#CXXFLAGS = -fguiding-decls -Wall -pedantic -Wno-unused -g
#CXXFLAGS = @CXXFLAGS@ -DNDEBUG
Eh, no.
I need the CXXFLAGS from
David Megginson writes:
Curtis L. Olson writes:
Getting metakit to build properly from within SimGear has been a PITA
from day one. Right now I'm voting for de-bundling it.
I say yank it completely and either (a) store all of the data in
memory, or (b) split it into directories like the
Andy Ross writes:
Also, I was looking at the HUD code recently. Alas, it seems awfully
tied to a flat screen idiom, and uses pixel (!) coordinates at that.
Has anyone with more knowlege about the HUDs given any thought to
making them work in a virtual cockpit environment? It's looking to me
Norman Vine writes:
Well you can use glTranslate() to 'sort of' roll the HUD to stay in the
'straight ahead' position, but this is a 'hack' at best.
Here is some code to translate the HUD with the eye vector
for those that want to play :-)
add to mouse.cxx
#define TRANSLATE_HUD
// temporary
Andy Ross writes:
Norman Vine wrote:
Here is some code to translate the HUD with the eye vector
for those that want to play :-)
That won't work, though.
Hey I already said that :-)
Well you can use glTranslate() to 'sort of' roll the HUD to stay in the
'straight ahead' position
Curtis L. Olson writes:
Norman Vine writes:
Fine but ...
Just remember that in general we want to DECREASE the number of
files that need to be opened per tile as fopen() is a
'major' contributor
to the ' SIM stuttering' when loading a tile on some systems !
Oooo, , oh wait never
David Megginson writes:
Curtis L. Olson writes:
This can significantly increase load times ... which is a hassle if
you are doing a lot of compile/run testing ...
I just wrote a short ANSI C++ test program to read the airport
database from the text file into an in-memory hash table. The
David Megginson writes:
I think that mmap is Unix only; in any case,
Windows certainly has a mmap equivalent
in fact one could almost say that Win9X is a 'mmap hack'
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
D Luff writes:
Will someone *please* tell me which data sources we are using for
the currently available scenery build, specifically in the UK?
I'm assuming its DEM-30 and GSHHS,
I assume that is correct
but don't know what landcover data we are using -
just a quick post
saying vmap0 /
Jim Wilson writes:
If anyone is interested, here is the work on the c310 3d panel
so far. Sorry,
I couldn't get xwd to take a pic of it. Might be something with my X
setup...not sure. It can be viewed in ppe and of course ac3d.
http://www.spiderbark.com/fgfs/3dpanelpreview1.ac
Jim
I can't
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
I can't seem to load this in PPE
Could you load it into PPE and then save it as a '.ssg' file
then zip or tar it up
Done. Actually the tar contains both .ssg and .ac It loads fine into
my PPE here (0.0.1.pre.pre.alpha) so it must
John Check writes:
Eventually, I guess you could have a separate subdirectory for each
instrument, with a README, etc. Think of yourself as a fine
craftsman, like a watchmaker.
err.. uhh... umm.. whatever.
I'd like to stay away from excessive directories. Maybe if the
Wolfram Kuss writes:
BTW, Norman, do you have a new fgfs.exe? Maybe I overlooked a post?
I keep a copy of my most recent MINGW FGFS executable at
http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz
The current file was compiled against the CVS of Dec22
These executables usually have the
Curtis L. Olson writes:
Norman Vine writes:
Curtis L. Olson writes:
I don't see an alternate way of doing this that will work with
automake-1.4
Did you actually try my proposed fix ??
Well, I looked at the generated makefiles, and there is an important
system define in 'DEFS' that would
Derek Lisoski writes:
Does the new autoconf also require updates to the
missing script?
And could this be causing the syntax error as well?
Maybe, but my guess is that these are symlinks that didn't get
removed and are mismatched to the auto* version that you are
using.
Cygwin will use
Curtis L. Olson writes:
Bernie Bright writes:
Curtis L. Olson wrote:
Bernie,
I don't believe make allows 'circular' dependencies like
that. I know
at least some versions do not. Would be awfully convenient, but I
don't think it is allowed.
Curt.
On the other hand FOO
David Megginson writes:
For anyone not monitoring the CVS logs, I've just replaced the old
$FG_ROOT/materials file with a new $FG_ROOT/materials.xml file, using
the regular property-file format
!! Warning what seems to be my 'obligatory' follows !!
So now any program wanting to parse the FGFS
Marcio Shimoda writes:
To edit KLVK, extract KLVK.btg.gz, leaving the .gz file where it is.
Say btg2atg KLVK to convert the binary KLVK.btg into the ascii
KLVK.atg.
This atg file is the wavefront obj file?
Yes, well not really a wavefront .obj file but a FGFS
Scenery File which is a
Curtis L. Olson writes:
Norman Vine writes:
It appears as if recent changes in the CVS requires a
modification in the steps for building FGFS
1) for now, with Cygwin at least, you NEED to add
AC_PREREQ(2.13)
as the first REAL LINE in configure.in
I am investigating
Erik Hofman writes:
Norman Vine wrote:
I have been fighting this one for 'awhile' with no success
therefore my reccomendation for AC_PREREQ(2.13)
It is probably a shell syntax mistake or somesuch :-(
although this could be a cascade from autoconf failing with
configure.in: 145: error
Marcio Shimoda writes:
It is simply the ascii for of the btg.
ATG = Ascii Terra Gear
BTG = Binary Terra Gear
There is code to convert between them. If you have Windows,
I can give
you the source for at least one direction. If you have another OS,
then you need to call decode_binobj
David Megginson writes:
Curtis L. Olson writes:
Right now when flight gear detects a crash it simply
freezes the sim.
The idea is that if we have motion hardware connected up, we don't
want to overdrive the hardware beyond it's capabilities.
But, a nice
crash scene could be an
John Check writes:
Right. One of us needs to get around to writing a pop-up dialog box
when that happens, to let the user know what's going on.
#include GUI/gui.h
if( crashed )
mkDialog(Ooops Crashed\nto restart sim\nSelect FileMenu::Reset)
Maybe Collision might be a better term.
BERNDT, JON writes:
Right. One of us needs to get around to writing a pop-up dialog box
when that happens, to let the user know what's going on.
Could I use what Norman suggested within JSBSim.cxx:
...
...
for ( i=0; i multiloop; i++ ) {
fdmex-Run();
}
David Megginson writes:
Norman Vine writes:
The general rule of thumb for portable applications is to use
the lowest common denominator or in the case filenames
use the 8.3 rule
max 8 letters for a file or directory name
max 3 letters for a file extension
do not use case
David Megginson writes:
Erik Hofman writes:
As far as I know, only dos (and Windows3.1) do have this
restriction.
OS/2, MacOS, BeOS, all Unices and Win9x+ support more than
3 characters
in the extension.
I know that VFAT and FAT32 allow extensions greater than three chars,
but does
throttle1000 writes:
I am bretty busy with my moving map project at the moment.
Got a URL
Have you seen http://atlas.sf.net
And I have no idea about what is done in the FG project so far. To me it
looks a bit
messy. I would start by making it more solid. There seems to be lot of
coded ideas
throttle1000 writes:
I have been reading this FGFS stuff about a year now!
and after lurking for a year decide to make 15 posts or so
in the first 24 hours after decloaking, rehashing a very well
discussed topic !
(And programming 25 years)
You apparently have the skill but not the will
Thanks for the link. My project is more to use real scanned
maps. Calibrate them and show position etc. information on
them. Using GPS and other data.
The maps can be aeromaps, roadmaps or any special maps
with special information on them. The user scans the maps and
uses computer to keep track
Jon S. Berndt writes:
Norman wrote:
Please stick with 8.3 or else Win9X development will be 'hampered'
in a way that would be similar to what Unix development would
experience if we were to allow spaces in filenames.
It seems to be a non-issue in W2KPro.
Indeed but ...
Win9X is NOT
Alex Perry writes:
SO, ANY PROGRAM THAT NEEDS TO BE PORTABLE TO ALL VERSIONS OF
WINDOWS (that are capable of 3D support) NEEDS TO ALLOW FOR THE
FACT THAT IMPORTANT FILES MAY APPEAR TO HAVE 8.3 NAME LIMITATIONS.
for those REALLY interested a definitive document
James A. Treacy writes:
On Sun, Jan 06, 2002 at 08:20:14PM -0500, Norman Vine wrote:
Ross Golder writes:
Anyone thought about this before? Care to comment?
the PLib team has a long range goal of using freeglut as a base
for a 'better' gaming oriented library, but none of us have felt
David Megginson writes:
Another possibility would be to
build a tool to convert DEM data to VRML and back again,
google 'GeoVRML' if you want to go that route
so that a
user could hand-edit the mesh in a tool like Blender; then again, it
would be even more interesting to edit whole tiles in
David Megginson writes:
Norman Vine writes:
David Megginson writes:
BUT WHY use blender when there is PPE !!!
I've spent about 20 hours working in PPE -- I think it's going to be a
great program, but it's still in early days (or at least, I haven't
figured out how to do even basic
David Megginson writes:
Norman Vine writes:
No, I think you missed that this is operating on the scenery directly
as present in the current SceneGraph in the FGFS memory space.
PPE knows a LOT more about the SceneGraph then FGFS does :-)
Well, after that teaser, how about some details
Bernie Bright writes:
John Check wrote:
Latest CVS build dies with following error
make[4]: Entering directory
`/home/j4strngs/Repository/FlightGear/src/FDM/JSBSim'
c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include
-I/usr/X11R6/include -g -O2 -c FGTable.cpp
FGTable.cpp: In
David Megginson writes:
Norman Vine writes:
g++ 2.95.x lacks the Standard's ios_base class. One messy work
around is demonstrated in simgear/misc/zfstream.hxx. FWIW I've
been working on an alternative solution using namespaces that is
much cleaner. It compiles with gcc 2.95.x and 3.0
Erik Hofman writes:
David Megginson wrote:
And so it does, at least for G++ 3.0. I've committed Norm's change to
the FlightGear and JSBSim CVS repositories. Please let me know if
there are any further problems compiling with G++ 2.95 (or MSVC,
etc.).
I have to use
long flags =
Andy Ross writes:
[bouncing this to flightgear-devel from flightgear-flightmodel]
David Megginson wrote:
Curtis L. Olson writes:
[about sloping runways]
Depending on how much we trust the underlying DEM data,
they may or
may not be deliberate ...
We shouldn't trust our DEM
Geoff McLane writes:
Have you tried my Windows binary
http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz
Initially JSBSim went crazy during the cfg xml read
( JSBSim Flight Dynamics Model v0.9.1 [cfg v1.57])
but this is caused by the cvs update adding things
like the following to
Julian Foad writes:
I am working on the view scaling / FOV.
What I am doing is (re)defining the FGViewer::{get_,set_,}fov
members to mean the Nominal FOV, the exact meaning of which
will depend on the setting of FGViewer::scalingType, to one of:
// nominal Field Of View actually
Norman Vine wrote:
Geoff McLane writes:
When running your fgfs.exe the log ends abruptly with
...
/autopilot
/PropertyList
* After fgSaveFlight()
* Before globals-saveInitialState()
Aha this is my xtra instrumentation in fg_init()
bool fgInitSubsystems( void
Curtis L. Olson writes:
Cameron Moore writes:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.01.16 15:11]:
Thanks to Norman Vine's unique combination of genius hackery we now
support this as an option:
http://128.101.142.57:5501/
Server up and running for a short time so check it
Roman Grigoriev writes:
Hi ALL!
how to know version of glut in cygwin?
or any versions of packages in cygwin
Nothing special about Cygwin Glut is Glut
don't think there is a runtime call for this but
#include GL/glut.h
main()
{
printf(GLUT_API_VERSION)
}
Julian Foad writes:
In my experience, debugging FG (single-stepping, run-to-here,
etc.) is almost impossible under GDB and I believe the OpenGL
I'm in charge of the main loop philosophy is the main cause.
This is GLUT not OpenGL
Could we abuse OpenGL by making the idle function always
Christian Mayer writes:
Geoff McLane wrote:
My exe crashed on ada and just 'sat' on the runway
in 'balloon'. But with magic the system soared.
Well, the balloon lacks one significant thing for an FDM: enable the
plane to move around. The balloon model works nicely for raising and
sinking
Erik Hofman
Andy Ross wrote:
this. Frankly, if we really want to move away from GLUT,
for whatever reason, I'd suggest SDL instead.
Me too, I have threads/timing working for SDL (which basically means
threading for windows/MacOS is supported then) and I am working on the
sound code.
It
David Megginson writes:
Norman Vine writes:
Again I don't see any compelling reason to move to SDL
As an outsider, I'll mention that one advantage is the fact that so
many other high-end games seem to be using SDL now. I like PLib, but
it hasn't seemed to catch on in the same way.
SDL
Christian Mayer writes:
Norman Vine wrote:
Well if you just wanted to drift with the wind and be 'cheesy'
you could use the simgear direct geodetic solver to get a new lat lon
based on current position speed and course
The drifting is moddeled correctly and returnes me a displacement
Erik Hofman writes;
I've twice committed a patch wich gets audio (sort of) working
for Irix
(audio realy is crap in plib anyway) but it didn't get
included, without
a reason, without any notice.
Erik
Apologies for not checking up on your patch
I just assumed that it got included by one of
Erik Hofman writes:
Well, since plib is claiming Irix compatibility but obviously, but
doesn't apply my patch I drew my own conclusions.
I concider including my patch just as a way to have more time
to work on
SDL because the audio part of plib breakes about every rule of
computer controlled
Christian Mayer writes:
Norman Vine wrote:
Christian Mayer writes:
Norman Vine wrote:
Well if you just wanted to drift with the wind and be 'cheesy'
you could use the simgear direct geodetic solver to get a new lat lon
based on current position speed and course
int
Curtis L. Olson writes:
One thing I've noticed (from the magic carpet mode) is that if you
call geo_direct_wgs_84() with zero distance and zero direction
(i.e. zero velocity) you don't get *exactly* the starting lat/lon back
because of numerical precision issues. This is not a big deal at
Melchior FRANZ writes:
* Curtis L. Olson -- Saturday 19 January 2002 14:25:
* Melchior FRANZ writes:
I asked for --tile-radius, because I don't get enough tiles if I
fly at good visibility (--fog-disable or hitting 'Z' a few times).
And then it would be nice to see more than just one
David Megginson writes:
If you grab the latest SimGear, FlightGear, and base package from CVS,
you'll notice that fuel consumption is now working on JSBSim
piston-engine aircraft (well, the Cessna 310 doesn't have the right
number of tanks or the right fuel capacity, and the Cessna 182 has a
172
Martin Olveyra writes:
I haven't still synced everything so I haven't tested this new feature,
but for the sake of realness, we can perform a flight around doing scales
at airports, and then refill the tanks. If I remember correctly, some
properties can be setted in the menu, so we can refuel
Curtis L. Olson writes:
We now have the following properties (the last two are only stubbed
in):
/sim/freeze/master (implimented)
/sim/freeze/fuel(implimented)
/sim/freeze/position(not implimented)
/sim/freeze/time-of-day (not implimented)
Cool !
Question (to
Julian Foad writes:
Until this is fixed properly, you can fix this by adding the line:
AC_PREREQ(2.13)
at the beginning of configure.in, just after the dnl ...
lines which are comments. At least, this works for me.
Just running make again seems to work also
Don't ask me why
Norman
Michael Basler writes:
Julian Foad write:
Until this is fixed properly, you can fix this by adding the line:
AC_PREREQ(2.13)
at the beginning of configure.in, just after the dnl ... lines
which are comments. At least, this works for me.
One million thanks, Julian, this fixed the case for
Tony Peden writes:
Well, I've spent quite a few hours on this and AFAICT, the FPU
is being set up correctly, it's just not generating the exception
for a floating point divide by zero (or any other floating point error
I could induce). Integer divide by zero works just fine.
Tony
Try adding
Nice addition
No need for an 'expensive' derivation
of the rotation matrix though as you can
straight forwardly write it out all at once
model.hxx
class FGAircraftModel : public FGSubsystem
{
.
struct Animation
{
enum Type {
None,
Spin,
Rotate
decloaking
Hopefully the list administrators will allow this post from
a non-subscriber thru to the list :-)
Here are some of my thoughts on how the 'View'
please change this to 'Camera' should work.
2. The instruments rotate with the 3D cockpit but they don't tilt with
it (also
[A bunch of notes on Norm's notes. Basically, everything he wrote
(even the editorializing) makes sense to me, with a few exceptions as
detailed below]
Norman Vine wrote:
Easy beans - no gimble lock - infinitely stackable orientations -
everything has it's own logical spot - quick
David Megginson writes:
(and de-quat the mouse code)
exactly the kind of response that led me to coin the phrase
MAYDAY MAYDAY FlightGear has been hijacked
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Jim Wilson writes:
I could really use some help visualizing
the matrices. Which elements are which axis (in Plib)?
x is 1st
y is 2nd
z is 3rd up
where x cross y equals z
same as OpenGL xcept there Y is up
And what does the fourth row/col represent?
fourth column is scaling almost
Andy Ross writes:
While I'm thinking about it, can someone with knowlege please let me
know that I've got the right facts for the following coordinate systems:
What I'm fuzzier on is where
the origin is when the scenery tiles are drawn (it has to be local, as
floats don't have sufficient
Andy Ross writes:
For a quickie example, look at the places in the code that read the
view_offset and view_tilt stuff. These are the values that represent
the direction of the pilot's head, and as such should be used only by
the core view code to decide on a view direction for the 3D
Jim Wilson writes:
The mouse code should just output an RPH
vector similar to what the pilot offset code does.
The problem is IMHO the other way around the External
View code should be exporting a matrix instead of a vector
Which is exactly what the Mouse Code did except for the
vestigial
David Megginson writes:
The issue is code design --
Indeed !
the view code needs to be fully decoupled
It is
except for the
current_tilt
current offset
goal_view_offset
goal_tilt_offset
mechanisms.
These are dynamical properties that should be stored in either
a quat or a matrix and
David Megginson writes:
Norman Vine writes:
However I STRONGLY suggest that the first pass is written in
'pseudo code' and posted to the Net somewhere for Review and
Comment before anything is actually implemented.
A Wiki would be ideal for this kind of thing :-)
CVS is good
Curtis L. Olson writes:
Yup, that's definitely in the piss me off category. :-)
Hey - What kind of box GFX combo are you running on
to get 139 FPS with all those lights shining :-)
BTW -- Nice work !
Cheers
Norman
___
Flightgear-devel mailing
1 - 100 of 1238 matches
Mail list logo
