RE: [Flightgear-devel] MP what data to send
Check out 'minilzo' for fast lightweight compression. My testing shows that compression is about 1/8 memcpy speed and decompression is about 1/3 memcpy speed. And, it compresses tight. http://www.oberhumer.com/opensource/lzo/ Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: Erik Hofman [mailto:[EMAIL PROTECTED]] Sent: Friday, July 12, 2002 10:39 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] MP what data to send ace project wrote: --- Billy Verreynne [EMAIL PROTECTED] wrote: All packets will (hopefully) support compression using zlib. At software level? I would be hesitant to do this myself. Compression and decompression can become an overhead and result in being the bottleneck, instead of network latency. As a multiplay configurable option, it makes a lot of sense. Ok, we'll make zip optional. We heard from a ID multiplayer programmer that the overhead was minimal compared to the profit gained (bigger packet, better support for low-bandwidth connections). We will just test how much time it takes to zip a packet ask yourselfs whether its worth it. Which reminds me. About two years ago I had some interrest in a *very small* real-time compression algorithm I saw on freshmeat.net It has absolute real time (small memory footprint) decompression and semi-realtime compression (if I recall all that correclty). Sadly I don't have the link anymore. Have to search for it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Not fixed in VC6. Fixed in VC7.
However, the STDLIB and STL implementations in VC6 and VC7 are very good.
But, they weren't written by Microsoft. They were written by P.J. Plauger's
company.
Regards.
Mark K Vallevand
Fat, dumb and happy. 2 out of 3 ain't bad.
I remember there was also perfectly good code that broke
under MSVC. Is this one fixed:
{
for (int i=0;i5;i++) {
// do something
}
for (int i=7;i13;i++) {
// do something else
}
}
The second for loop was causing problems with MSVC because
it choked on the for-block-scoped int i declaration.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Profiling run
Well, no, not specifically with operator=. But, my point is that operator= might not be involved. It also depends on the kind of profiler used. If its a profiler that is enabled with compiler switches and code to count calls is compiled in, then my point is not valid. However, some profilers poll the instruction pointer, or use the processor itself to capture profile data. The profiler has to associate an address with a function and sometimes gets it wrong. funca: code code ... ret code - what function is this address in? code funcb: code code ... jmp funcb-2 code ret I've seen this many times. Funca is getting counts that are really for funcb. Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: Tony Peden [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 27, 2002 1:26 PM To: FGFS Devel Subject: RE: [Flightgear-devel] Profiling run On Wed, 2002-02-27 at 09:00, Vallevand, Mark K wrote: I probably doesn't get called that many times. Most profiling software picks up some cruft. There is probably some bit of code located just after FGInterface::operator= that *is* called a lot, but doesn't have any debug information associated with it. So, as far as the profiler is concerned, its part of FGInterface::operator=. I see this all the time in the profiles I do here at work. Even with compiler generated operator=? Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. It seems very strange to me, however, that FGInterface::operator= would show up at all. According to that output, it was called almost 200,000 times. What's up with that? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with panel code
Sure. Scaling is not a problem with plib. The classes ssgTransform and ssgTexTrans are put in the scene graph to control object and texture transformations of their kids. One of the setTransform operations allows scaling. Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: David Megginson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Problem with panel code Jim Wilson writes: And the question that brings to mind is, how will we be able to set the z axis in a way that it can handle the panel? In other words, the scale is so large now that it'll disappear just like airplane model components do when viewed too closely. Can we have two different scales in the same tree/graph? Actually, I'm not sure -- any advice from the PLIB gurus? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with panel code
Yes, you are correct. In fact, this explains an artifact I'm seeing in one of my programs. The normals must be getting screwed up because of scaling because lighting is funny on a pair of identical objects that have been scaled and rotated. I'll have to chase that idea down. Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 3:15 PM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] Problem with panel code Vallevand, Mark K writes: Sure. Scaling is not a problem with plib. The classes ssgTransform and ssgTexTrans are put in the scene graph to control object and texture transformations of their kids. One of the setTransform operations allows scaling. Be careful with scaling objects though because this can screw up things like normal vectors (which would then screw up lighting.) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] NASA Aerospace Blueprint Report
Curt, is this the place? http://www.mapquest.com/maps/map.adp?pan=emapdata=afbX8DbyAoeelxrDJRScQoQ4C AIJ6NFZQl2NJCldgemct6CJ8%2fGJDqfPn5G%2fIixzDBWc0El1ZtongiO99grca0SIWRNOLpxhz Vbx70XYcZeTqphU15NfMvrYlEhGdCl9ch3SYQ3XgAToC4QtEoh7t%2bH8WNDd6j%2fb9LRiuQP7w 2U9oebJQHSzr2DEmEP3Y0cZQon0qvDyAkj6665%2fegSXADh6f%2fHAK7BIY8tujE%2fRQY2yDO8 %2fSdebNxOdAj3OP41jO4B%2bUr9Ck%2fwNfHf8Gi4xCIzNG7fMP%2bDTn0YTUkTpWaJc0uvVTC6 WyDLWqSjgIkA%2fE9cEsisBJI5D28%2bDqZoof4yXz7jP981YcvSRZdHRQatu%2bO%2fXU04FnQ% 3d%3d Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] NASA Aerospace Blueprint Report
I used to drive by Surfside going to the Middle School. I go to the High School more often now. I live a few blocks from Rice Lake Elementary. Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Sun and Moon reflections on water
Shadows done the traditional way with shadow volumes are pretty expensive: Two passes through the scene graph for objects and 2 passes for the shadows. I'd guess that reflections are about the same expense. But, there are many short cuts, especially for relatively static scenes like the moon or sun reflecting on the water. Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: David Findlay [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 1:13 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Sun and Moon reflections on water Now that would be a cool feature. Can it be done though without killing frame rate too much? Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: JSBSim BUG?
Perhaps you mean '=' instead of '=='?
void SetEngineNumber(int nn) {EngineNumber = nn;}
Regards.
Mark K Vallevand
Fat, dumb and happy. 2 out of 3 ain't bad.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 30, 2001 10:08 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [Flightgear-devel] Re: JSBSim BUG?
Hi Jon,
It looks like the compiler has got something here:
../FGEngine.h, line 186: warning(1171): expression has no effect
void SetEngineNumber(int nn) {EngineNumber == nn;}
Yes, I have just noticed that but cannot figure out what the
hell that's all
about. Am I missing something obvious?
[posted to the fgfs developer list]
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
