* Vivian Meazza -- Wednesday 13 June 2007:
> Tim Moore has been hard at work recently (with the smallest of inputs by
> me), and has ported the improved weather radar already available for plib to
> OSG.
No objections and other comments since the patches were published
on 2007/06/20. Because of the nearing release (not that we have
the slightest idea when this could be :-) and the nature of the
patch I want to give developers one last chance to object: if
nobody does that until tomorrow 2007/06/23 20:00 GMT, then I will:
(a) apply those radar patches to sg and fg for osg and plib
(b) comment out the "delete rt" in src/Instrumentation/od_gauge.cx:89
PRO ------------------------------------------------------------
+ we have a nice c++ radar implementation in both branches, which
handles arbitrary numbers of AI/MP aircraft, ships, TACAN
emitting and other objects
+ we can drop the quite clumsy and limited & limiting XML radar
implementation
+ fixes a bug in AIManager (ask Vivian :-)
+ instantiates impact sub-submodels in correct order
CONTRA ---------------------------------------------------------
- bigger commit despite the near(?) release, with potential risk
to break something
BUT: + the patch touches only files that can hardly have side
effects on other subsystems, and isn't executed at all
when aircraft without od_gauge/radar are used (which
is the vast majority). So even if there'd be problems,
they would only affect the E3B, the T38(?), and ... the
harrier? And even then one could comment out the radar
instrument in the XML file and avoid all problems.
+ the patches were tested by, at least, Vivian, AJ,
Csaba "Jester"(?) and me, and found functional and not
causing problems, except the following (AJ and I):
- requires to comment out the destruction of the RTT class to
avoid crashes on exit on (some?) nVidia cards. That's hackish,
BUT: + that's exactly what the 3D clouds are doing since years!
They don't destruct the RTT class either! Nobody has
reported problems that could be linked to that, none
of the developers has observed such problems (AFAIK).
+ that's exactly what the TestRenderTexture.cxx test
application by the very author of the RenderTexture
class does. He doesn't destruct the class either (except
before creating a new one during mode changes on user
request).
+ it can be assumed that the card frees this resource
like all others, when the context is destroyed, so the
buggy freeing operation via glXDestroyPbuffer() should
be optional in this case.
m.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
