http://home.nc.rr.com/alan69/FlightGear/Rudder3/
Nearing completion on the basic prototype, last pic shows the
construction best. Angle was a bit steep for a desk chair, so added
screws to set the angle. Will change the cuts instead later. There are
eight 1' sections, may just use a
Anyone up for making a serial device? I only do a little programming
on the PC side of things, so am not currently up to the task I think.
Needs sync bytes, something like this is common:
FF FF 0 axis1 0 axis2 0 axis3 etc.
Really just check the high bit, 2 set in a row is the sync, then a
Curtis L. Olson [EMAIL PROTECTED] wrote:
I do look out for drivers _before_ I buy a card for my or my customers'
PeeCee (currently I don't even own a PC ;-)
Is it sgi machines that you run on?
It became sort of a hobby to collect used Unix workstations. I have an
Octane with MXI graphics
Curtis L. Olson [EMAIL PROTECTED] wrote:
Martin Spott writes:
Not many, but on the other hand you won't have much trouble with the
BIOS when you think about a standalone FlightGear CD. Dealing with a
bunch of different kernel modules for autodetecting different vendors'
cards might prove to
Hi Martin,
Martin Spott writes:
Especially the mess with NVidia's drivers is the manufacturer's fault.
ATI at least _tries_ to conform with the standards proposed by the DRI.
With ATI you can copy the DRI driver module and the kernel module
(after tweaking the build script) to the appropriate
Martin writes:
It became sort of a hobby to collect used Unix workstations. I have
an Octane with MXI graphics and TRAM as workplace at home, but this
machine (only 195 MHz) turned out not being able to keep up with
recent development. Its CPU is simply too slow and can't cope with
all the
Hello Curt,
Curtis L. Olson [EMAIL PROTECTED] wrote:
Martin writes:
It became sort of a hobby to collect used Unix workstations. [...]
So should I assume that you are running fully open-source operating
systems, and fully open-source drivers on all your own hardware?
No, absolutely not. I
Martin Spott wrote:
a) Unload the kernel's GART module during the autodetection and load
NVidia's special kernel module,
b) replace the OpenGL libraries,
c) run a special X Server.
Martin, just stop this flaming; b is true. a and c are not, and
have never been.
NVidia's drivers install
Martin Spott writes:
I never owned an NVidia card, so I can't compare performance. Maybe
someone else has the opportunity to do that: Currently I have a
Radeon7500 plugged into a Pentium3/600 (I believe this one is still
running at 66 MHz external clock) with standard SuSE-9.0 XFree (built
Alan King wrote:
Anyone up for making a serial device? I only do a little programming
on the PC side of things, so am not currently up to the task I
think. Needs sync bytes, something like this is common:
FF FF 0 axis1 0 axis2 0 axis3 etc.
RS232 is an async protocol, there's no need for any
Curtis L. Olson [EMAIL PROTECTED] wrote:
a) Unload the kernel's GART module during the autodetection and load
NVidia's special kernel module,
Nvidia's kernel module does have an AGP driver, but it is smart enough
to not activate this portion of the driver if the linux GART module is
Andy Ross wrote:
RS232 is an async protocol, there's no need for any synchronization in
the application (that's what the start bit is for). Just send the
data you want and it will come out the other side. If you saw an
It's for byte sync not bit sync.
application doing this in the past, it's
On Mon, 22 Dec 2003, Martin Spott wrote:
a) Unload the kernel's GART module during the autodetection and load
NVidia's special kernel module,
Nope - it'll use kernel GART, or its own internal one.
b) replace the OpenGL libraries,
The installer does this automatically
c) run a special X
On Monday, 22 December 2003 16:59, Martin Spott wrote:
What people have already been suggesting in the 'early days' and what I
refused to believe for quite a long period (which partially made me
purchase my first SGI): The performance of the graphics card appears
to have very little influence
I finally found the Nasal memory corruption bug this morning. I was
right that it was triggered by garbage collection, but it wasn't in
the Nasal code. The FGBinding implementation was holding a
SGPropertyNode* and assuming that its callees would never try to use
the SGPropertyNode_ptr interface
Andy,
What method would you recommend for a script that basically has to run
forever.
What I'm trying to do is add continuous motion to the sailship by
interpolating between +10 and -10 degrees pitch, but I haven't found a
clue on how to do this with Nasal.
Any ideas?
Erik
Andy Ross wrote:
Erik Hofman wrote:
What method would you recommend for a script that basically has to run
forever.
What I'm trying to do is add continuous motion to the sailship by
interpolating between +10 and -10 degrees pitch, but I haven't found a
clue on how to do this with Nasal.
Erik Hofman wrote:
I tried this with a linear interpolation table but I think a problem
right now is the fact that the timer is frame rate dependent. And
since I'm running at a frame rate of about 5 frames per second this
can be a problem.
The interpolator is realtime (er, simtime) based;
Hi Alan,
On Mon, Dec 22, 2003 at 02:48:02AM -0500, Alan King wrote:
Anyone up for making a serial device? I only do a little programming
you mean for the microcontroller side ?
on the PC side of things, so am not currently up to the task I think.
Needs sync bytes, something like this
Manuel Bessler wrote:
you mean for the microcontroller side ?
Hmm that could have been read the other way from what I meant. Nope
I do PICs that side is trivial for me. Just figured someone already
working inside FG could add a serial driver and serial.XML far faster
than I could.
I have
20 matches
Mail list logo
