Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Andy Ross wrote: Oliver Schroeder wrote: Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission Binary is fine. Uncooked memory is not. :) And FWIW, XDR seems awfully heavyweight to me. It involves a comparatively large amount of code for things that are really pretty easy, while at the same time making hand optimization of the packet format more difficult. The term binary is in fact not precise enough in this context. We need a way to encode the data in a host independent format, regardless of what data is send. XDR is a generalization of functions like ntohl(3) and htonl(3). If we implement it ourself with exactly what we need, it isn't bloated at all. Note that this hand tuning can be really beneficial, especially if the server is on a low bandwidth link. The multiplayer protocol I was thinking of (which these days is, I guess, mostly an idea box for the working version) managed to pack a full precision* position, velocity, acceleration, orientation and rotation rate into a block of 26 bytes. That's about 3x smaller than a naive implementations based on floats and doubles, which means that you can transmit data on 3x as many aircraft/objects over the same link. I don't understand exactly what you mean here, but as mentioned above: XDR is just an encoding standard for data. We can send whatever data we want and we should think about what data should really go over the wire. But that's a different story. Regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Oliver Schroeder wrote : Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission is the way to go, as it will fix problems with endianess and platforms not using IEEE-format for floats/doubles. That way multiplayer mode will even work on a VAX ;) I will look into it next week. There is no native xdr implementation with MSVC. We should provide our own implementation if it is the way we want to go. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
On Donnerstag 28 Juli 2005 18:32, Andy Ross wrote: Oliver Schroeder wrote: Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission Binary is fine. Uncooked memory is not. :) And FWIW, XDR seems awfully heavyweight to me. It involves a comparatively large amount of code for things that are really pretty easy, while at the same time making hand optimization of the packet format more difficult. Note that this hand tuning can be really beneficial, especially if the server is on a low bandwidth link. The multiplayer protocol I was thinking of (which these days is, I guess, mostly an idea box for the working version) managed to pack a full precision* position, velocity, acceleration, orientation and rotation rate into a block of 26 bytes. * Positions to within 1mm, orientations to within a degree over a typical inter-packet delay. That's about 3x smaller than a naive implementations based on floats and doubles, which means that you can transmit data on 3x as many aircraft/objects over the same link. Well, I was looking for an existing implementation of a non ascii format which will just work. Looking at that stuff I have found is not that heavyweight. That is just a kind of iostream like implementation to build up that network packets in a defined byte order and alignment. That would be just handy to use ... But if you have a better solution ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Mathias Fröhlich wrote: On Mittwoch 27 Juli 2005 14:55, Vivian Meazza wrote: It's a quick and dirty hack. Oliver and Norman are working on a proper fix. It compiles on gcc 3.4.4-1. If Cygwin users want to use multiplayer, then this patch allows it. It certainly should not find its way into cvs. With help from Norman I fixed the alignment in the used headers. The patch is available at http://www.o-schroeder.de/fg_server/patch.php But this patch again fixes only symtoms, not the problems. I suggest to put it into cvs anyway, as it will enable the majority to get experience with the multiplayer mode. Norman, Oliver, you might be interrested in that xdr stream implementation I have attached. Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission is the way to go, as it will fix problems with endianess and platforms not using IEEE-format for floats/doubles. That way multiplayer mode will even work on a VAX ;) I will look into it next week. Where this implementation is not 1000% waterproof (long doubles cannot work in the way they are implemented), it might serve as a very good starting point. Long doubles are not used, at least in multiplayer code, so this should not be an issue so far. More interesting is, if it will compile on the different platforms. I'm considering looking at XTL, too. (see http://xtl.sourceforge.net/) Any comments welcome. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Oliver Schroeder wrote: Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission Binary is fine. Uncooked memory is not. :) And FWIW, XDR seems awfully heavyweight to me. It involves a comparatively large amount of code for things that are really pretty easy, while at the same time making hand optimization of the packet format more difficult. Note that this hand tuning can be really beneficial, especially if the server is on a low bandwidth link. The multiplayer protocol I was thinking of (which these days is, I guess, mostly an idea box for the working version) managed to pack a full precision* position, velocity, acceleration, orientation and rotation rate into a block of 26 bytes. * Positions to within 1mm, orientations to within a degree over a typical inter-packet delay. That's about 3x smaller than a naive implementations based on floats and doubles, which means that you can transmit data on 3x as many aircraft/objects over the same link. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
On July 25, 2005 06:42 am, Vivian Meazza wrote: Radar Echoing Area is (REA) and is also known as the Radar Cross Section (RCS). It's not quite the same thing as the radar visibility range. RCS is a property of the target, and varies with the target aspect w.r.t. the radar, and also the radar frequency. Radar visibility range is a function of the RCS and the power density of the radar at the target. Depending on the level of realism you want for radar, we either need a crude visibility range as a property of the target, or the RCS (probably an estimate) and have the radar work out if the target is visible, taking into account the RCS and the radar horizon. Vivian The RCS idea also occured to me a while ago. In fact, I have actually given it some thought as to how such effect would work in FlightGear. The first idea involves estimating the radar reflection of aircrafts in real time. A camera with an aspect ratio of 0.1 will act as the radar and cycle its view through all the aircrafts in the vicinity at certain intervals. The camera will render what it sees off screen, without any light other than a spot light pointing in the same direction as the camera, without fog, without clouds, without billboard objects, with the sky as black and everything else according to their specular reflectiveness. The renderings will then be analyzed later, with the visibility of each plane corresponds to the average brightness of their rendering. This method will be slow, but it will give some nice effects. The most notable are probably terrain obstructions and interferences. The second idea involves mapping out the RCS values of the planes at different angles, and storing the results in 360x360 pixels, mono-color bitmaps. Then it is simply a matter of doing a look up in FlightGear to find out the RCS of a plane at any given moment, multiplying the value by the power of the radar, and dividing the result by the square of the distance between the plane and the radar This will be much faster than the first method, although it won't give such effects as terrian obstructions and interferences. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
