- this exposed a bizarre issue on Mac where dragging in <AGL/agl.h> in
extensions.hxx was pulling in all of Carbon to the global namespace
- very scary. As a result, I now need to explicitly include CoreFoundation
in fg_init.cxx.
- change SG_USING_STD(x) to using std::x
- re-enable od_gauge ("owner drawn" render-to-texture instruments)
- implement radar in c++ (unlimited number of clouds/ai/mp/... objects,
better performance)
- Well I finally licked it, the clipping works great now, in 16 and 32
bpp mode, on 2d and 3d panels.
- I tried glScissors, didnt work because clipping was done in screen
co-ordinates.
- Stencil buffer methods worked great for 2d panel, but messed up 3d
panels,(depth buffer problems I think), and only worked in 32 bpp mode.
- I then tried clip planes , and so far it appears to work with no
problem, and no framerate drop like I had with the stencil buffer
method...
I'm attaching the panel.cxx file for testing...
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
- replay.cxx :
corrected a bug, now reinitialize the recording data when replay is
deactivated
- fgclouds.cxx :
cloud layers and weather condition are saved when choosing a weather scenario,
added a new scenario 'none' so we can switch back to standard flightgear
weather
- navradio.cxx :
force a search() on init to initialize some variables, preventing a nearly
infinite loop when delta-time == 0 on the first update()
- electrical.cxx :
uninitialized variable in apply_load() for FG_EXTERNAL supplier
- panel.cxx, panelnode.cxx :
added a property "depth-test" for 2.5D panels so that they update the depth
buffer and are no more visible from the outside of the aircraft when the
aircraft uses textures without an alpha channel
- panel.cxx :
moved the computation of the instruments diffuse color outside the
texturelayer code since this is constant during a frame, this is a big speedup
for 2D panels
The "switch" layer type now takes any number of child layers, and will
use the first child that has a condition that evaluates to 'true' (no
condition is automatically true). Previously, it could take only two
children, controlled by a boolean property.
I've updated the instrument modulator code to allow tricks like the one
described by Andy. It is now possible to define <min>, <max> and
<modulator> in one layer and if <min> and/or <max> ore within the range
of the <modulator> tag, their value will be honoured.
So, if you define
<layer>
<min>0</min>
<max>50</max>
<modulator>100</modulator>
</layer>
The value will stay at 50, until the modulator forces it back to 0.
Ensure that if a condition for a panel mouse binding fails, other
bindings for the same area will have a chance to run.
Add a repeatable flag for panel mouse bindings (defaults to true).
I wrote:
> I can confirm this. Layers on the 2D panels (but oddly, only the 2D
> panels) aren't drawing over the background with the current ATI
> drivers.
OK, this turns out to be a trivial fix, although I still think it's a
driver bug. There are two calls to glPolygonOffset in the panel
rendering code (shared by both 2D and 3D panels). One is called
per-layer, and sets up a layer-specific offset. The other is called
for drawing the background textures, to lift them off of any
underlying cockpit geometry.
I was using different "factor" values for each, incorrectly. Patch
attached. It was affecting only 2D panels because the 3D ones don't
use background images.
Problem is, by my reading of the specification the bug should have had
the effect of pushing the background texture *farther* behind the
instruments, instead of pulling it on top of them. Either I'm reading
the spec incorrectly or ATI has inverted the sense of the factor
argument. Dunno, I'll submit a bug report to them and see what
happens.
> Jim Wilson wrote:
> > How hard would it be to have a property that toggles hotspot
> > visibility? It'd be nice to be able to turn it on and have yellow
> > rectangles show up on the hotspots...
>
> That's not a bad idea.
It's actually an astoundingly good idea, and implementable over lunch
to boot. :)
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property. I mapped a toggle event on this to a
spare joystick button, and had fun. :)
[dpm: bound to Ctrl-C]
avoid having the 2D instruments obscure 3D objects in front of them):
It's related to depth buffer precision. On my Geforce cards (2MX and
3), it never happens with the 24 bit depth buffer you get by default
at 32bpp. At 16bpp, it picks a slimmer depth buffer (probably 16 bit)
and the texture layers bleed through.
The code is using a pretty big argument to glPolygonOffset, and I've
never investigated how small it can be. If someone has a little time
the next time they see this issue, try changing the value of
POFF_UNITS at the top of Cockpit/panel.cxx. Decrease it until the
textures *just* start to interfere with each other, and post the value
that works for you.
