[Flightgear-devel] Rudder pedals
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 single 2" x 6" x 8' instead of project boards. That will cut the cost by $6 or $8. Rails for $12 and board for $4, and only a few other odds and ends and a little cutting and drilling will be all that's required for the mechanics. Feel very good even without considering the low cost, and will be rearranged so wood is about the only thing showing and can be finished off if desired. Just a bit left to do and then get the electronics working. Then get the yoke finished too. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Serial device
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 zero then axis etc. By just checking the high bit other things can be put in like this: F0 Fx 0y ax1 0y ax2 etc. Where the x can tell how many axes are coming, and button bits can be put in the 0 high bit bytes for y. It's not that this can't be gotten in the computer some other way, but development is a bit easier with a plain serial port, and everyone's got one plus they work in WinXP. Mainly looking for my rudder controller, but if someone does this I'll also put up a simple pic interface and code for RC transmitters. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
"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 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 trees and buildings. I still wonder why this brings the machine to its knees because there are a lot of applications out there, displaying fancy stuff on such a machine at reasonable frame rates. Maybe these applications' characteristics are not comparable to flight simulation and the software probaböy is specifically optimized for SGI's graphics subsystem. I also have a HP Visualize C240 (donation from a customer) but this one also has only 200 MHz CPU cycle. I have an RS6k with 200 MHz (per CPU, eight of them) which won't serve, the SPARC has only 90 MHz (maximum, depending on what CPU set I put into it). The old Motorola based machines will be _waaay_ too slow. I have e workplace at a customer's location with a PC where I plugged my own graphics card which serves as temporary FlightGear testbed, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
"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 end in a huge mess. This _is_ very pragmatic >> thinking, > I don't think this big mess is the fault of vendors with binary > drivers. 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 places. With NVidia (at least the last time I looked at their drivers) you have to: 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. _This_ is what I'd call a huge mess. I don't like ATI's approach either but these guys show that things could have been done at least in a significant better way. Yes, there was no 3D standard for Linux when 3D boards for PeeCees became affordable. But NVidia's driver effort was very late as well. They _would_ have had the chance to stick to DRI standards but they simply don't have any interest into doing anything different from "their own way". Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
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 places. > With NVidia (at least the last time I looked at their drivers) you have > to: I will address these points, since they are mostly false and/or misleading. > 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 already there. As far as I know it has always been this way. Depending on your system, one or the other may work better for you though, so the nvidia readme encourages try the "other" one if you have problems with the first. And nvidia does provide full source for their own kernel module. > b) replace the OpenGL libraries, Yes this is allowed. Unfortunately XFree86/Mesa don't (or at least didn't) put the opengl libs where the linux standard said they should, nvidia did. That causes a huge mess if you have multiple opengl libs on your system and you aren't sure which one's your app is picking up. Like I say, this was a big mess before nvidia got involved. Especially consider that prior to that, the only way to do opengl in a window on linux was with a voodoo3 card. To get this running, you pretty much had to grab XFree86 cvs tree and build it yourself. This was 100x harder to get running than the approach nvidia used. > c) run a special X Server. Nvidia gives you a new driver (nvidia vs. nv) for your X server, but you have never needed a special X server. > _This_ is what I'd call a huge mess. I will continue to assert that what nvidia was trying to plug into was already a huge mess in terms of supporting hardware accelerated opengl within XFree86. This is a hard problem and many smart people were struggling with it. They came up with a reasonable solution, DRI, but it just wasn't ready to go when nvidia was ready to go. You at least have to credit nvidia for going out on a bit of a limb at the time to even support linux. This was *huge* for people who had been struggling along with voodoo1,2,3 cards and were living with very frustrating bugs in Mesa or in mesa's interface to the voodoo cards. Suddenly along came nvidia and we were able to get fast and correct rendering for the first time ever under linux. This was huge! I personally am very greatful to nvidia for this. They made linux a viable 3d platform. > I don't like ATI's approach either but these guys show that things > could have been done at least in a significant better way. Yes, > there was no 3D standard for Linux when 3D boards for PeeCees became > affordable. But NVidia's driver effort was very late as well. They > _would_ have had the chance to stick to DRI standards but they > simply don't have any interest into doing anything different from > "their own way". nvidia's effort was a *lot* earlier than ATI's. Yes there was some disappointment that they didn't follow the DRI standards, but I think you can make a plausible argument that the DRI standard was not fully fleshed out when nvidia started developing their linux drivers. I still don't see how any of this rises to the level of causing someone to boycott their company. And as you say, you are running hp, sgi, and ibm machines. I can't imagine every byte of code on those machines is fully open source. If you are actually running all open source operating systems and drivers on all these machines, then you are definitely not doing any opengl on those machines. Again, I see absolutely no problem with running the vendor's os, or linux or whatever you want on those machines, but I find it a bit odd that you are arguing so strongly for others to not run any proprietary code or drivers, when clearly you must be doing this yourself. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
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 trees and buildings. I still wonder why this brings the > machine to its knees because there are a lot of applications out > there, displaying fancy stuff on such a machine at reasonable frame > rates. Maybe these applications' characteristics are not comparable > to flight simulation and the software probab=F6y is specifically > optimized for SGI's graphics subsyste= m. > > I also have a HP Visualize C240 (donation from a customer) but this > one also has only 200 MHz CPU cycle. I have an RS6k with 200 MHz > (per CPU, eight of them) which won't serve, the SPARC has only 90 > MHz (maximum, depending on what CPU set I put into it). The old > Motorola based machines will be _waaay_ too slow. Hi Martin, So should I assume that you are running fully open-source operating systems, and fully open-source drivers on all your own hardware? :-) > I have e workplace at a customer's location with a PC where I > plugged my own graphics card which serves as temporary FlightGear > testbed, I would love to hear which card/drivers you are using at your customer's location. Are there any rendering bugs? Any odd xserver crashes? What kind of performance are you getting compared to nvidia. If you have found a rock solid, high performance, correctly rendering open-source solution, I'm sure a lot of people would love to hear the specific details. For my day job I manage a research driving sim. We run linux on all our visual channels and are using nvidia hardware/drivers. For this system we can't tolerate driver crashes or rendering errors. This system isn't for play or hobby or expermentation, it is for doing real, paid research so it needs to work all the time. (To be fair, there are many other reasons why it doesn't work all the time, but none of them are video/3d/driver related.) If there is a 3d card with open-source drivers that could perform as well as nvidia in a do-or-die environment, I'd like to hear about it, because to date, I have yet to see anything else that compares. Regards, CUrt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LiveCD for FGFS - suggestion
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 earn my living from maintaining other people's UNIX/Linux servers and workstations (and networks in between) and my home collection serves as a testbed/playground for me - however you'd call it ;-) >> I have e workplace at a customer's location with a PC where I >> plugged my own graphics card which serves as temporary FlightGear >> testbed, > > I would love to hear which card/drivers you are using at your > customer's location. Are there any rendering bugs? Any odd xserver > crashes? What kind of performance are you getting compared to nvidia. 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 from XFree86-4.3.0.1) and the daily CVS build gives me 10 fps when sitting on the default location at noon. In the first days of playing around with FlightGear (some days in the summer of 2000) I used a so-called ATI Rage128, in the spring of 2001 I bought a used Voodoo3/3000. On the (ooops, funny date) 24th December 2001 I got my firstRadeon (7000) and since then I've been sticking to that (Radeon 7500/9100) I already gave most of them away I've seen quite a lot of rendering errors and crashes during _development_ of the DRI (I've been testing DRI CVS trees almost since I got the first Radeon) and by trying out experimental features (T&L). The only drawback was the official release of XFree86-4.3, which was released with a completely outdated and buggy Radeon driver. David Dawes knew that when he did the release :-/ Linux distributors knew that as well and put a working one into their distros (as far as I remember). XFree86-4.4 will be an excellent choice as long as you stick to boards up to Radeon9200 (I'd have to look up these numbers because I didn't bother to remember). 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 on the frame rate of FlightGear. At least I wasn't able to recognize any significant change when switching between these cards I mentioned above. Even the early PCI cards did a remarkable good job - with stock XFree86-4.x. > If there is a 3d card with open-source drivers that could perform as > well as nvidia in a do-or-die environment, I'd like to hear about it, > because to date, I have yet to see anything else that compares. Unfortunately my customer doesn't want me to spend large amounts of time with FlightGear, they even don't want me to plug pedals to the workplace :-) I'm happy that I can spend a few minutes per day to check out the daily build, so unfortunately I can't tell you anything about many hours' use but I'm still convinced that it is worth the effort to look at the Radeon cards - especially those from the mid-ages Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
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 themselves, they're actually significantly easier to install than a new DRI release is (yes, I've done both many times). And they have a release cycle of 3-4 months or so, instead of the 1 year you have to wait between X releases. Yes, they're proprietary software. But the installation quality is actually quite good. If you don't like proprietary software, then just say so and leave it at that. Don't invent problems and fan the flames. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LiveCD for FGFS - suggestion
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 > from XFree86-4.3.0.1) and the daily CVS build gives me 10 fps when > sitting on the default location at noon. Ideally what I like to shoot for is a solid 60hz. If you set your monitor to refresh at 60hz and then lock the rendering to the vblank signal, (and you can get a solid 60hz out of flightgear) then you get extremely smooth and fluid frame rates. It's *really* nice. It makes those little frame rate blips and glitches seem incredibly annoying after you've seen FG running at a solid 60hz. > I've seen quite a lot of rendering errors and crashes during > _development_ of the DRI (I've been testing DRI CVS trees almost since > I got the first Radeon) and by trying out experimental features (T&L). > The only drawback was the official release of XFree86-4.3, which was > released with a completely outdated and buggy Radeon driver. David > Dawes knew that when he did the release :-/ > Linux distributors knew that as well and put a working one into their > distros (as far as I remember). XFree86-4.4 will be an excellent choice > as long as you stick to boards up to Radeon9200 (I'd have to look up > these numbers because I didn't bother to remember). > > 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 on the frame rate of FlightGear. At least > I wasn't able to recognize any significant change when switching > between these cards I mentioned above. Even the early PCI cards did a > remarkable good job - with stock XFree86-4.x. The newer cards are faster. What that gives you is the ability to run at higher resolutions and still maintian your target frame rate. Or it gives you the ability to turn up the FSAA and still hit your target frame rate; or turn up anisotropic texture filtering and keep your frame rates going. FSAA can make a big difference in reducing aliasing artifacts and anisotropic texture filtering can make the texture (especially the runway marking textures) much sharper. Definitely play with these features if you haven't. Unfortunately, the older middle-ages cards, just don't have the horsepower to run these more advanced features at high resolution and still keep a decent frame rate. In my mind, that is the big win for the newer cards. As you point out, FG currently isn't using any advanced rendering tricks of the newer cards. Someday we'll probably want to look into some spiffier graphical effects, but hey, people need a reason to buy MSFS. We aren't here to put anyone out of business. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
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 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 application doing this in the past, it's probably one that was trying to do "autobaud" detection, which is a rats nest you don't need to worry about for custom hardware. Or maybe it was transmitting to broken hardware that wasn't fast enough to handle real RS232. You might want to put a "magic number" at the top of a packet to handle dropped bytes gracefully, but that's a slightly different problem. You certainly don't want to embed padding bytes in the message itself. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
"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 > already there. As my memory serves this was not the case with early GeForce drivers and I'm glad to hear that things changed in the meantime. > Depending on your system, one or the other may work better for you > though, so the nvidia readme encourages try the "other" one if you > have problems with the first. And nvidia does provide full source for > their own kernel module. There might be some misunderstanding here - I assume you mean the GART part of their kernel module. They still link the 'nv-kernel.o' binary object into their module. >> b) replace the OpenGL libraries, > Yes this is allowed. Unfortunately XFree86/Mesa don't (or at least > didn't) put the opengl libs where the linux standard said they should, > nvidia did. I'd expect libGL in /usr/lib/ where every other Unix puts it. To my knowledge XFree86 doesn't behave different by default - you can choose a different location on compile time by putting a 'host.def' with: #define NothingOutsideProjectRoot YES > [...] That causes a huge mess if you have multiple opengl libs > on your system [...] I'd try to avoid having multiple sets of the same libraries and I can confirm that this calls for trouble by default. I've been maintaining my own Linux 'distribution' with the compiler for nearly 10 years now and I must admit that I spent lots of time experiencing that you get really bad results if you compile and install a set of libraries without proper removing the remains of the previous version :-) >> c) run a special X Server. > Nvidia gives you a new driver (nvidia vs. nv) for your X server, but > you have never needed a special X server. Good to know, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
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 probably one that was trying to do "autobaud" detection, which is a rats nest you don't need to worry about for custom hardware. Or maybe it was transmitting to broken hardware that wasn't fast enough to handle real RS232. You might want to put a "magic number" at the top of a packet to handle dropped bytes gracefully, but that's a slightly different problem. You certainly don't want to embed padding bytes in the message itself. Has nothing to do with dropped bytes, has to do with figuring where the start is in a repeating variable length data stream. If I send you a few thousand FF's how do you propose to tell which ones are starts and how many channels? Did it start at the beginning or was it already running when hooked up? You have to have repeating patterns and then change the patterns for sync if you have full value data, or have output data to start and synchronize the packets, which is more trouble over just reading a sync. Just a magic number at the top can easily fail with full range data. You don't have to have repeating spacers but a nice simple easily understood format is always a good idea, and it's only the high bit anyway, the lower bits can still be used. I do microcontroller code, so I could easily change it to be as terse as possible and still easily synced to, but the bandwidth is so low for a controller vs what else is going on in a 3D PC it's hardly worth worrying about. Overall it's no different than sending IR data streams, you require a reliable sync signal to get started if you want to know where you are. Yep you can autobaud to it if done correctly, but you still need it for general sync unless you limit your data value range in some way. And it was really just a simple generic example anyway. No doubt if someone is up for it we will discuss it a bit and take it down to a minimum but expandable data format. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
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 Server. Nope - it just installs a new xfree driver, and changes the config to reference that (as nvidia instead of the old one as nv) You download 1 script, and run it. That's all. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LiveCD for FGFS - suggestion
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 on the frame rate of FlightGear. If you haven't seen a performance difference between old graphics cards and new ones then it sounds like it's running in software rendering mode. I just upgraded my graphics card and believe me it makes a HUGE difference in FlightGear. I was using a TNT2 and I was only getting 10 FPS max. I have just inserted a Ti4200 and I'm getting 50-60 FPS in FlightGear. That's a 500 to 600 percent performance increase using the same nVidia driver. Why don't you get yourself a decent card and check it out for yourself? Ti4200's are less than $100 nowdays. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal control bindings
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 to refcount it. Nasal did, which
caused the node to be prematurely freed. Trivial fix; horrific
debugging effort. :(
So I've started checking in my Nasal control/input changes. The
keyboard bindings are first, because they're easier to test. I'll get
to the joystick bindings as soon as I can. With one or two
exceptions, nothing should be visibly different to the user. Notable
changes:
+ The v/V bindings for stepping through views are no longer hardcoded
in the XML, and pop up a nice eye-candy label to tell you what view
you have selected. I'll leave it to someone else to come up with a
translation of "Chase View wo yaw" :)
+ Flap steppings are now settable per-aircraft. You can have as many
as you like; the up/down flaps bindings do the right thing. I set
up a sample in the 747-yasim-set.xml configuration. The syntax is
very simple (I have no idea if these values are right, though):
0.00
0.01
0.02
0.05
0.10
0.33
0.67
1.00
There is compatibility code in place so that aircraft without a
"/sim/flaps[n]" declaration will get the old 0.0/0.33/0.66/1.0
steppings. Note that only the *keyboard* bindings are currently
using this code.
+ Engine settings automatically detect and set properties for the
correct number of engines. No more need to duplicate XML bindings
for a "maximum" number. The XML files are a *lot* smaller for this.
+ The "popup tip label" used for the zoom and (now) view change code
is available for general use as "gui.popupTip('My tip message');".
+ There is a "slewProp()" implementation that handles realtime-based
motion of property values. This will eliminate the framerate
dependencies of trim and view direction changes for joystick
handlers. Note that this is *not* used by the keyboard handlers,
becuase the OS generates its own key repeats that we'll have to turn
off first.
I've tried to test this, but something probably slipped through. Let
me know if I broke something. I'll hopefully have a chance to work on
the joystick bindings tonight.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal code/continuous loop
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal code/continuous loop
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.
Probably the best way to do this is with interpolate(). This code
should swing the pitch linearly between -10 and +10 and back 5 times
over 10 seconds, and then set a timer to do it again:
rockBoat = func {
# Arguments: property, value, delta, value, delta, ...
# Start at 10 degrees immediately, then back and forth five times:
interpolate("/sim/ai/wherever/boat/pitch-deg", -10, 0,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1);
# When we're done, start it again:
settimer(rockBoat, 10);
}
With a little work, you could populate that table with random numbers,
etc... This avoids the need to run a Nasal script every frame to
iterate your animation; the interpolator is a C++ module.
A useful feature that doesn't yet exist would be the ability to
register a callback function for the end of an interpolation; this
would eliminate the need for the settimer call and any race conditions
that result from slightly different timeouts.
What you are asking for, the ability to run a script in a loop
forever, will require more work. This would essentially be a
multithreaded interpreter, and the NasalSys subsystem would have to
maintain separate execution contexts for each thread. That is, by
design, supposed to work in Nasal, But for this kind of animation
problem, it's probably not the right solution. The per-thread
overhead is rather high.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal code/continuous loop
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.
Probably the best way to do this is with interpolate(). This code
should swing the pitch linearly between -10 and +10 and back 5 times
over 10 seconds, and then set a timer to do it again:
rockBoat = func {
# Arguments: property, value, delta, value, delta, ...
# Start at 10 degrees immediately, then back and forth five times:
interpolate("/sim/ai/wherever/boat/pitch-deg", -10, 0,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1);
# When we're done, start it again:
settimer(rockBoat, 10);
}
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.
With a little work, you could populate that table with random numbers,
etc... This avoids the need to run a Nasal script every frame to
iterate your animation; the interpolator is a C++ module.
A useful feature that doesn't yet exist would be the ability to
register a callback function for the end of an interpolation; this
would eliminate the need for the settimer call and any race conditions
that result from slightly different timeouts.
That would be really nice.
BTW. No need to hurry on this, I was just experimenting with Nasal a bit
and (although I would get something like this implemented sometime) the
code to add an AI model using Nasal isn't available either.
What you are asking for, the ability to run a script in a loop
forever, will require more work. This would essentially be a
multithreaded interpreter, and the NasalSys subsystem would have to
maintain separate execution contexts for each thread. That is, by
design, supposed to work in Nasal, But for this kind of animation
problem, it's probably not the right solution. The per-thread
overhead is rather high.
Agreed, an event method would be best, but I couldn't find the right
solution.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal code/continuous loop
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; frame rate doesn't effect it. It runs only once per frame, but the property changes it manages are based on actual time deltas. The 5Hz update will affect the granularity of settimer() calls, but over 10 seconds the error is negligible. You might see a "skip" once every 10 seconds as the timer resets. Even that can be hidden by removing the first two arguments of the interpolate call (which set the value by "interpolating" over a zero time delta) and initializing the property somewhere else. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
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 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 > zero then axis etc. By just checking the high bit other things can be > put in like this: > > F0 Fx 0y ax1 0y ax2 etc. I have worked on a protocol for my own stuff... it includes analog axis and button state support. I've put up a picture of my protocol spec: http://cockpit.varxec.de/fgfs/PHCC2HostProtocol.xfig.png Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
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 worked on a protocol for my own stuff... it includes analog axis and button state support. I've put up a picture of my protocol spec: http://cockpit.varxec.de/fgfs/PHCC2HostProtocol.xfig.png Can't get there through the link. At any rate I am working more towards a simple reindexing scheme and any data after that than a single specific protocol. With flexible configuration with a serial.xml type file I'd expect to define how many channels and the data types and formats on the fly anyway. Have a few other applications and some other hardware in mind in the longer run besides just FG, so want it to be truly open. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
