Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
Hi, So, since I wanted to get in touch with you anyway ... Good to hear from you! On Friday 26 June 2009 12:09:48 Petr Gotthard wrote: I'd like to bring up again the issue of standalone FlightGear modules (add-ons, plug-ins). You probably hear this question once a while, but I have a new argument. ;-) Although the FlightGear design fairly modular it's provided as a single binary. Everyone who wants to create a new I/O module must patch the FlightGear sources and compile the FlightGear binary from scratch. This may discourage those who want to use FlightGear as a tool and extend it in some way. Moreover, it's not always possible to include all functions in a single binary. Some functions may be mutually exclusive. I'm building a FlightGear interface for MS HLA simulations (http://virtualair.sourceforge.net/flightgear.html). There is a single standartized C++ API, but many HLA infrastructure (RTI) implementations. To use a particular HLA RTI it's necessary to re-compile and re-link FlightGear against a particular set of libraries. Thus there can never be a single HLA compliant FlightGear binary. To follow the do things right rule I think it would be great to implement a generic interface for standalone I/O modules. Both Micro$oft FSX and X-Plane have such interface. The MS HLA users would just need to build a shared module (.dll or .so) for a particular HLA RTI and load it via the standard FlightGear plug-in interface. So, as far as I knor HLA/RTI, your problem is divided in two parts: 1. The problem with different RTI implementation libraries. 2. The problem with different fom's Regarding the RTI libs: As far as I can see the RTI c++ interface is defined in a way that you do not need to recompile anything. Everyting is done with pure virtual classes and factories to get them. So however this is implemented in the shared object/dll you should just need to get a 'standard' implementation dependent RTI header and compile with that. So you should in theory be able to change the RTI library of an already compiled binary. For the case that a particular RTI implementation does not follow this rule, you need to compile flightgear explicitly for this particular library. I believe that this is accaptable. Regarding the different foms: I have seen your implementation and what I believe we can do more generic. Sure there is a part of your implementation that hard codes some attribute names of the foms into the binary. But this could be done in a more generic way, so that you can configure the attributes meanings at runtime instead. With this model, your two hardcoded implementaiton stubs for the those two fom's will be just a special configuration using the same c++ implementation. I for myself would like to have such a flexible implementation at hands. So all together I would prefer to include a more generic HLA/RTI implementaiton in flightgear than introduce a plugin mechanism. Greetings Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
I'm (still) against binary runtime modules for FlightGear. They are an invitation for circumventing the GPL, locking in users, and potentially harm cross-platformness. I find the prospect of a vendor offering a new device with closed source libraries for stock FlightGear worrying, and even more so if there's only a Windows DLL, but none for OSX and all the Unices/Linux. (Not that I'd want to run any secret binary blobs on my clean machine.) We offer more possibilities than X-plane and MSFS and all the others put together -- by letting people look at/modify/redistribute our source code. For free. That's very generous, if you ask me. That linking non-GPL modules would be illegal, anyway, doesn't make the situation any better. Unless you can offer us a *lot* of money, time and personnel for filing lawsuits. Otherwise the GPL protection is rather weak and only theoretical. We shouldn't encourage corporate entities to rip us off. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Generic input protocol delay
Hi All, I'm trying to put my own data into FG, with the native fdm and the generic input protocol at the same time. My problem is, that fdm works fine, but the data is send via UDP over the generic protocol has some kind of lag or rather delay. When I pause sending the data, the data in the property tree (createy by my own script) just keeps changing for 1 or 2 seconds. When I restart then sending, the variables just begin to response a few seconds later (and so on...). UDP shouldn't be the problem, because it's just sending an has no buffer itself (or am i wrong?). I tried different kinds of data transfer rates, nothing works. Furthermore the data is sent correct, I checked that with a Python script, there the delay doesn't appear. I tried different ports, too. My question is, does FG have any kind of buffer itself? When yes, how can I send correct, so that the data arrives at the same time with the fdm data? When no, what might be the reason for this delay? The problem is that I need this data to animate my model, so it's senseless if it doesn't arrive at the same time like the fdm data. My command line to call FG: fgfs --fdm=external --time-match-local --enable-random-objects --native-fdm=socket,in,60,,15710,udp --generic=socket,in,60,,15600,udp,peter_in --aircraft=... Thanks for help! Regards, Peter -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Splash Screen alpha bug (and black 3d clouds redux)
Re-sent without pic attachment. On Sun, Jun 28, 2009 at 1:19 PM, Nicolas Quijano nquij...@gmail.com wrote: Hello all, wonder if anyone is seeing this (link at the end), especially on nvidia cards as it would help determine that it's not specific to a driver or particular vendor (ATI GPU here). Basically, aircraft splash screens with alpha in them trigger a texture combine bug (that's a guess) in a repeatable, deterministic fashion. Two solutions, one for users, one for whomever maintains that code : For users, get rid of the embedded alpha : you don't need it in the final product, as it's a splash screen. And you can get the desired effects (often contours, I guess from using a mask layer in gimp or whatever) by merging your layers before exporting to .png, with no need for alpha in the file. The dev solution, the proper one, is to make sure that the splash screen is not used in a texture combine with the 3d cloud textures : that the OGL FSM is set to its canonical state before starting scene rendering after the splash screen. Link to Pic of slash screen bughttp://picasaweb.google.ca/lh/photo/_JxeKpvf4Wbf8TbnX4Eubw?feat=directlink I suspect the black 3d clouds I've mentioned before might be related, as it looks like inverted alpha and only affects one specific cloud type (pichttp://picasaweb.google.ca/lh/photo/B2zLgEeWT9RNFqPqU_RvsA?feat=directlink), as I don't quite think that's the intended effect somehow ;) -- Be Kind. Remember, everyone is fighting a hard battle. -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
Melchior FRANZ wrote: I'm (still) against binary runtime modules for FlightGear. I'm more curious as to whether we need them. The entire guts of FlightGear are available to almost anyone via external communications (e.g. sockets) and Nasal. Why not write a communications script or Nasal script that exposes the data required for your add-on over a socket, and use a similar tool at the add-on end? There is no license that will ever state that any application that *communicates* with it (whether it be a TCP socket, file, or Unix socket) needs to adhere to that license as well, since that would pretty much be the ultimate enforcement of copyleft. Simply put, the mechanics for doing this with FlightGear are already in place, you only need to take a slight detour over a communications link. This has its advantages too, such as added security (no possible code injection) and inherent networkability. Downside is that it takes a little more brain-food to make it work. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Atlas-devel] Map 0.4.0 error: Unable to initialize pixel buffer
Hi all,
Re: TestRenderTexture - a SG application.
The failure of TestRenderTexture in my
system turned out enormously easy to
track down ;=)) But how to fix?
I added some, about 50 ;=)), dbg_printf() statements
such as the follows, in SG/screen/RenderTexture.cpp :-
#define dbg_print printf
bool RenderTexture::_VerifyExtensions() {
dbg_printf(RenderTexture::_VerifyExtensions() called...\n);
[snip]
Display* dpy = glXGetCurrentDisplay();
int minor = 0, major = 0;
if (!glXQueryVersion(dpy, major, minor)) {
dbg_printf(_VerifyExtensions: glXQueryVersion(dpy, major,
minor) FAILED! returning false\n);
return false;
} else {
dbg_printf(_VerifyExtensions: glXQueryVersion(dpy, major=%d,
minor=%d)\n, major, minor);
}
int screen = DefaultScreen(dpy);
const char* extString = glXQueryExtensionsString(dpy, screen);
dbg_printf(_VerifyExtensions: glXQueryExtensionsString(dpy, screen)
returned -\n[%s]\n,
(extString ? extString : NULL) );
if (!SGSearchExtensionsString(extString, GLX_SGIX_fbconfig) ||
!SGSearchExtensionsString(extString, GLX_SGIX_pbuffer)) {
dbg_printf(_VerifyExtensions: does NOT contain
GLX_SGIX_fbconfig or GLX_SGIX_pbuffer! return false\n );
return false;
}
[snip]
And the text output result was :-
RenderTexture::_VerifyExtensions() called...
_VerifyExtensions: glXQueryVersion(dpy, major=1, minor=2)
_VerifyExtensions: glXQueryExtensionsString(dpy, screen) returned -
[GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context
GLX_EXT_visual_info GLX_EXT_visual_rating GLX_OML_swap_method
GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_visual_select_group ]
_VerifyExtensions: does NOT contain GLX_SGIX_fbconfig or
GLX_SGIX_pbuffer! return false
RenderTexture::Initialize: _VerifyExtensions() FAILED - returning false.
RenderTexture Initialization failed!
SO, my glX version 1.2 is MISSING 'GLX_SGIX_pbuffer'!!!
Now, to work out what I can do about it???
It looks like I should somehow 'upgrade' to say
version 1.3, or higher, which may then contain this
missing 'pbuffer' thingy, or SOMETHING... but Synaptic
does NOT list any upgrade!
Yahoo! got me a reference saying -
http://www.opengl.org/registry/specs/SGIX/pbuffer.txt
Overview
This extension defines pixel buffers (GLXPbuffers, or pbuffer for
short). GLXPbuffers are additional non-visible rendering buffers for an
OpenGL renderer. GLXPbuffers are equivalent to GLXPixmaps with the
following exceptions:
[snip]
Since that is exactly what we want - a non-visible rendering
buffer - this looks IMPORTANT ;=))
I THINK this may be via the libraries installed, as shown
by $ dpkg -l, but there seems no 'upgrade' available...
ii libgl1-mesa-dri 7.0.3~rc2-1ubuntu3 OpenGL API
ii libgl1-mesa-glx 7.0.3~rc2-1ubuntu3 OpenGL API
but maybe I am way OFF base here ;=))
One post I found Yahooing around mentioned GLEW, and
I already have 1.5 of that installed -
ii libglew1.5 1.5.0dfsg1-3ubuntu1 The OpenGL Extension Wrangler
and have now installed glew-dev... It MAY
all be possible adding :-
#include GL/glew.h
// before GL/gl.h
[snip]
int main( int arc, char **argv) {
GLenum err=glewInit();
if(err!=GLEW_OK) { //problem: something is seriously wrong
printf(Error: glewInit() FAILED! %s\n, glewGetErrorString(err));
return -1;
}
// and then try...
glutInit(argn, argv);
// [etc]
But I am paddling well over my head!
Any help appreciated ;=))
Geoff.
OS: Ubuntu 8.04 64-bit
VID: ATI Radeon HD 2600 XT
PS: Also posting this on the FG board, since
TestRenderTexture is a SG package... and maybe
someone there can point me in the right
direction ;=))
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic input protocol delay
Peter Völk wrote: Hi All, I'm trying to put my own data into FG, with the native fdm and the generic input protocol at the same time. My problem is, that fdm works fine, but the data is send via UDP over the generic protocol has some kind of lag or rather delay. When I pause sending the data, the data in the property tree (createy by my own script) just keeps changing for 1 or 2 seconds. When I restart then sending, the variables just begin to response a few seconds later (and so on...). I've seen something similar myself, but only when the sender sends the data more frequently than FlightGear is allowed to handle with the refresh parameter (60Hz in your example). My question is, does FG have any kind of buffer itself? When yes, how No They only buffer that is used it the OS's network buffer (as far as I know) can I send correct, so that the data arrives at the same time with the fdm data? When no, what might be the reason for this delay? The problem is that I need this data to animate my model, so it's senseless if it doesn't arrive at the same time like the fdm data. It sounds to me a mismatch in sender and receiver frequency. Maybe you should throttle the sender to only send data packets at 60Hz also? Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
