Atlas

>>>>> "Geoff" == Geoff McLane  writes:

    Geoff> BUT, in either case, it seems very logically flawed to even
    Geoff> have an 'All' unsubscribe case! In essence, each subscriber
    Geoff> should 'unsubscribe' as each 'subscriber' goes
    Geoff> out-of-context... that is only delete itself...

    Geoff> Simply there should be NO CASE where any ONE of the
    Geoff> 'subscribers' deletes _ALL_ other subscribers!  Each
    Geoff> 'subscriber' should be responsible to 'unsubscribe' itself
    Geoff> ONLY, at exit.

    Geoff> Does this make it CLEAR? How can ONE subscriber be
    Geoff> responsible for deleting _ALL_ other subscribers?

I don't think it is.  I've looked at the code and it looks correct to
me.  It's important to realize that _notifications is an vector of
notifications, not subscribers.  There are a fixed number of
notifications (Moved, Zoomed, ..., All), so _notifications is a
fixed-size vector.  Each entry in _notifications is a set of
subscribers.  So, if a subscriber subscribes to all notifications, that
means it will be added to each set in _notifications.  Removing a
subscriber from all notifications means checking each set in
_notifications and removing the subscriber from it.

Does that help?

Brian

Hi Brian,

Wow, how did I get into this? But just trying
to 'help'...

You are right! Thinking about it again, and 
understanding more, from your good explanation, there
is no doubt a specific 'Subscriber *' should
be able to cancel _ALL_ its 'subscriptions' in one
hit, and not have to remember each 'type' it
subscribed to...

Re: WIN32 - MSVC compiler

In WIN32, as stated, the problem is _ONLY_ that
post exit cleanup code clears the vector to 0,
initialized/allocated to 10 at startup, BEFORE the
subsequent 5 calls to ~Subscriber, thus the 'assert',
which is ONLY active in the DEBUG build, causes :-

Assertion failed: _notification.size() == All

dialog to popup, asking if I want to inform MS
of the app failure ;=)). 

Just a question of auto-cleanup order... and only
due to the active 'assert' in Debug mode.
 
No problem with Release version, since there is NO
'assert', and when the vector is cleared to 0, 
nothing is done...

You suggest the vector has a 'fixed' size, but
it is my understanding that such a vector must
have (auto) code to initialize it to the desired 
size, 10, via memory allocations, and it seems WIN32
also generates auto-code to clear this memory
allocation after the application has run.

Re: Ubuntu - gcc compiler

Maybe I have not got to the bottom of the beef in
Ubuntu that causes a 'dump' SOMETIMES... 

First, it does not seem to happen every time ;=((. 
I have only seen it once in this latest 
(of today), but have only run it about 10 times in 
here... In my setup, I use Atlas mostly in my WIN32 
machine... but see the new PS below ;=((

And adding some debug code -
(a) the vector stays at 10 after app exit, which 
seems to suggest gcc does not generate the cleanup
code, or it is run later, and 
(b) it seems only ONE(1) ~Subsriber All is called
after exit, not 5 as in WIN32, which is strange. 
That is AFTER cleanup() has run...

We agree Ubuntu and WIN32 should NOT 'crash' on
exit. They are at fault! The code as written
is 'perfect' ;=()

Maybe we should ALL switch to using OS X where 
there is _NO_ apparent 'crash' at exit ;=))

Sorry for the noise. ;=(( Will now shut up on
this topic, and 'quietly' apply my own fixes,
when needed.

Regards,
Geoff.

PS: UGH! UGH! UGH! Added a $HOME/.atlasrc giving 
my FULL Scenery-1.0.1 folder, putting me at YGIL,
and --zoom=20 now get REPEATED segfault on exit 
in Ubuntu ;=(( AND think I see some SLOW UP as 
well!! 

BAH! This is frustrating, and VERY TIME consuming... 
Ran it under gdb and here is a backtrace :-

[chop]
Enter gluMainLoop()
[Entered 'q' to exit]
Subscriber::~Subscriber:0xb909440: unsubscribe ALL
Notification::unsubscribe:0xb909440: with ALL. size=10
cleanup() done - App exit...
Subscriber::~Subscriber:0x2750f70: unsubscribe ALL
Notification::unsubscribe:0x2750f70: with ALL. size=10

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fbbbfcaa720 (LWP 15644)]
0x00007fbbbd5ecfd6 in std::_Rb_tree_rotate_left () from /usr/lib/libstdc
++.so.6
(gdb) bt
#0  0x00007fbbbd5ecfd6 in std::_Rb_tree_rotate_left ()
from /usr/lib/libstdc++.so.6
#1  0x00007fbbbd5ed53d in std::_Rb_tree_rebalance_for_erase ()
from /usr/lib/libstdc++.so.6
#2  0x0000000000409f39 in std::_Rb_tree<Subscriber*, Subscriber*,
std::_Identity<Subscriber*>, std::less<Subscriber*>,
std::allocator<Subscriber*> >::erase (this=0x6d2e30, __first=<value
optimized out>, __last=
      {_M_node = 0x6d2e38}) at /usr/include/c++/4.2/bits/stl_tree.h:1247
#3  0x0000000000409fc8 in std::_Rb_tree<Subscriber*, Subscriber*,
std::_Identity<Subscriber*>, std::less<Subscriber*>,
std::allocator<Subscriber*> >::erase (this=0x6d2e30, __x=<value
optimized out>)
    at /usr/include/c++/4.2/bits/stl_tree.h:1274
#4  0x0000000000409a87 in Notification::unsubscribe (s=0x2750f70,
n=<value optimized out>)
    at /usr/include/c++/4.2/bits/stl_set.h:373
#5  0x00000000004246e7 in ~AirportsOverlay (this=0x2750f70) at
AirportsOverlay.cxx:175
#6  0x0000000000422003 in ~Overlays (this=0x2750e80) at Overlays.cxx:73
#7  0x0000000000462809 in ~Globals (this=0x6ce380) at Globals.cxx:44
#8  0x00007fbbbd046110 in exit () from /lib/libc.so.6
#9  0x0000000000416831 in keyPressed (key=<value optimized out>,
x=<value optimized out>, 
    y=<value optimized out>) at Atlas.cxx:3792
#10 0x00007fbbbfa32723 in glutMainLoopEvent ()
from /usr/lib/libglut.so.3
#11 0x00007fbbbfa32c48 in glutMainLoop () from /usr/lib/libglut.so.3
#12 0x000000000041b9e5 in main (argc=5, argv=0x5dcad40) at
Atlas.cxx:4730
(gdb)
 
which seems to indicate still something to do with
'unsubscribe'...

And on chopping the 'All' case code, NO PROBLEM. AND 
this time I do see 5 more unsubscribe calls, like in 
WIN32 - like there should be - but the size() stays 
10... 
[chop]
Enter gluMainLoop()
[Entered 'q' to exit]
Subscriber::~Subscriber:0xb9096d0: unsubscribe ALL
Notification::unsubscribe:0xb9096d0: with ALL. size=10
cleanup() done - App exit...
Subscriber::~Subscriber:0x2750f70: unsubscribe ALL
Notification::unsubscribe:0x2750f70: with ALL. size=10
Subscriber::~Subscriber:0x2812f60: unsubscribe ALL
Notification::unsubscribe:0x2812f60: with ALL. size=10
Subscriber::~Subscriber:0x2822df0: unsubscribe ALL
Notification::unsubscribe:0x2822df0: with ALL. size=10
Subscriber::~Subscriber:0x49f4820: unsubscribe ALL
Notification::unsubscribe:0x49f4820: with ALL. size=10
Subscriber::~Subscriber:0xad0c990: unsubscribe ALL
Notification::unsubscribe:0xad0c990: with ALL. size=10

Program exited normally.
(gdb) q

But as stated, will now go QUIET on this topic ;=()
Something about flogging a DEAD horse ;=))

g.

>>>>> "Geoff" == Geoff McLane  writes:

    Geoff> Hi, Sorry to keep 'pushing' this, but just hope someone else
    Geoff> will have a 'clue'...

[...]

    Geoff> Hopefully, now with a very repeatable WIN32 scenario... but
    Geoff> HELP needed ;=((

I know the problem - you're using Windows. :-)

Well, I have to admit it has me stumped, but my best guess is that
somehow our viewing frustum is getting out of sync.  If you don't mind,
I'd like you to make a change to the code, and we'll see what results we
get.  So, at the start of Scenery::zoom, add this line:

    printf("left: %.0f, right %.0f, bottom: %.0f, top: %.0f, near: %.0f, far: %.0f\n",
	   frustum.getLeft(), frustum.getRight(), 
	   frustum.getBot(), frustum.getTop(),
	   frustum.getNear(), frustum.getFar());

It just prints out the viewing frustum.  Then do the same test you did
before (start Atlas with "--airport=YGIL --zoom=62", cover and uncover
the window, hit 'j', ...).  According to my tests, it should only be
called twice (since you don't do any zooming), and you should see
something like the following:

left: -24800, right 24800, bottom: -18600, top: 18600, near: -100000, far: 0
left: -24800, right 24800, bottom: -18600, top: 18600, near: -100000, far: 6372269

The exact numbers might be different (it depends on window sizes), but
they should be similar.  In particular, we should have left < right,
bottom < top, and near < far.

What results do you get?

Brian

Hi Brian,

Thanks for giving the problem some more thoughts...
and WOW, I 'think' I have found it, but first...

>> I know the problem - you're using Windows. :-)
Yes, I know this and _ONLY_ pursue it with rigor so
we can claim cross platform compatibility ;=)) no
other reason, right?

>> Output of frustum
After adding the debug code, as you predicted, it is
only output twice, and the values were exactly as
you stated - exactly - see :-
 http://geoffair.org/tmp/Atlas03.txt 

So I added more debug in mouseMotion. I had avoided
this previously since I knew this would be busy...

BUT, it did produce a rot(0,0,0,0) and maybe this
somehow caused the problem?!

This rot(0,0,0,0) was just before the first 5 min
paint, and then in a second 5 min paint, I noted
a rot(0,0,0,1.#QNAN0) - EEEK! See -
 http://geoffair.org/tmp/Atlas04.txt

So, to avoid this rot(0,0,0,0), I add the code -

static int curr_x, curr_y;
In mouseClick()
  if (scenery->intersection(x, y, &oldC))
     dragging = true;
     curr_x = x;
     curr_y = y;
     ... etc
     
Then in mouseMotion()
  if (dragging) {
    if ((x == curr_x)&&(y == curr_y)) {
        // do nothing, to avoid rot(0,0,0,0)
    } else {
        curr_x = x; // update current
        curr_y = y;
        SGVec3<double> newC;
        if (scenery->intersection(x, y, &newC)) {
           sgdVec3 axis;
           sgdMat4 rot;
           ... etc ...
        }
    }
  }
  
AND NO MORE SLOW DOWN ;=)) YIPPEE ;=))

Maybe the extra delay when windows must change
the z order allows a mouseMotion with the
'same' x,y to get through, where as normally
the first mouseMotion after the mouseClick
was always different... or...

Reading through the PLIB/sg code I can see no 
particular problem with a rot(0,0,0,0),
passed to rotatePosition(sgdMat4 rot), which
is then used to adjust eye, and eyeUp through
sgdXformVec3(eye, rot), etc...

Although I do note a possible division by a 
zero, or infinite! length, in -
sgdScaleVec3(eye, SGGeodesy::EQURAD / sgdLengthVec3(eye));
which ends with a -
 _move(); // This will inform the culler

And in trying to CAREFULLY trace through what
happens when the mouse position is unchanged,
I DO now SEE that eye and eyeUp variables are 
set to a very BAD - the MSVC debugger show -
eye[0] = -1.#IND
eye[1] = -1.#IND
eye[2] = -1.#IND
which, in _move(), is passed to gluLookAt -
 gluLookAt(eye[0], eye[1], eye[2],
 etc...
which CAN NOT BE GOOD ;=((

BUT MAYBE it is the fraction of a seconds delay
until the next mouse movement that fixes
things...

However in general it does NOT seem wrong to avoid
doing these changes when the mouse position
has _NOT_ changed in a mouseMotion() callback.

What do you think?

Would it be a good patch for _ALL_ platforms
to avoid changing anything, when the mouse
position has _NOT_ changed at all in the drag
case?

Maybe in certain ports the GL utility code,
gluLookAt() protects itself from being passed
an 'infinite/indefinite?' number? A quiet
NaN (Not a Number)?

Anyway, in ALL tests so far, I can _NOT_ get
the SLOW DOWN again ;=))

Will test for a few more days, just to assure
myself that this is SOLVED, before commencing
the task of backing out all the debug code.

Or maybe leaving it in place, but disabling
it. In most cases I used a dbg_printf, so it can
define it as 'nothing'...

PHEW! This was a LONG chase, and thanks again
for the inputs.

Regards,
Geoff.

PS: OT: Re FG
I do not know if it is me, or everybody, but
maybe others have noted the flightgear devel
list has been _VERY_ quiet for several days, and
this has allowed me the time to concentrate on 
Atlas ;=))

But wonder if something has happened to the FG
flightgear-devel@... list. I get
this Atlas and other sf messages without 
problems??? A small puzzle...

I have that freeze in windows too, but I thought that it was my local OS
problem.
Thank you for fixing it.


-- 
---
WBR, Vadym.

>>>>> "Geoff" == Geoff McLane  writes:

    Geoff> BUT, it did produce a rot(0,0,0,0) and maybe this somehow
    Geoff> caused the problem?!

    Geoff> This rot(0,0,0,0) was just before the first 5 min paint, and
    Geoff> then in a second 5 min paint, I noted a rot(0,0,0,1.#QNAN0) -
    Geoff> EEEK! See - http://geoffair.org/tmp/Atlas04.txt

    Geoff> So, to avoid this rot(0,0,0,0), I add the code -

    Geoff> static int curr_x, curr_y;
  
[...]

Good call!  It makes sense - as you can see in mouseMotion, there are
two vectors oldC and newC, which are basically lines from the centre of
the earth to the eye point.  We use the two vectors to determine how the
earth should rotate.  However, if they are the same, then we're
unconstrained - any rotation is possible.  That's why we're getting the
errors (a bit like dividing by 0).  To be honest, I'm still not sure how
mouseMotion() got called after there had been no motion, but perhaps
there's a bug in the Windows implementation of GLUT.

I don't think we need any more static variables though - it's probably
good enough just to compare oldC and newC for equality.  Since I can't
replicate the problem here, can you do a test for me?  Add a comparison
in mouseMotion, just before the "sgdVec3 axis" declaration.  The code
should look like so after you've finished (the new lines are the "oldC
== newC" comparison block):

    if (dragging) {
	SGVec3<double> newC;
	if (scenery->intersection(x, y, &newC)) {
	    // The two vectors, oldC and newC, define the plane and
	    // angle of rotation.  A line perpendicular to this plane,
	    // passing through the origin, is our axis of rotation.

            if (oldC == newC) {
                return;
            }

	    sgdVec3 axis;
	    sgdMat4 rot;

Brian

Hi Brian,

Glad you agree, AND yes, the comparison of the
vectors will also work, (I think), BUT -

>> I don't think we need any more static variables though

Really not sure what you have against static variables ;=))

I just did a speed test comparing simple integer math I 
DELIBERATELY chose, with the vector math you suggested :-

    MyTimer tm;
    int max = 100000000;
    int curr_x, curr_y, x, y, j;
    SGVec3<double> oldC, newC;
    srand(time(NULL));
    for (j = 0; j < 10; j++) {
       curr_x = curr_y = x = y = rand();
       oldC[0] = oldC[1] = oldC[2] = (double)x;
       newC[0] = newC[1] = newC[2] = (double)x;

       tm.reset();
       for (i = 0; i < max; i++) {
         if ( !((curr_x == x)&&(curr_y == y)) )
            printf("impossible!\n");
       }
       ouput(1,tm,max);

       tm.reset();
       for (i = 0; i < max; i++) {
         if ( !(oldC == newC) )
            printf("impossible!\n");
       }
       ouput(2,tm,max);
    }

I think you would be AMAZED, as I was, at the 
VERY BIG difference between CPU integer math in 
the first, and the FPU cost in the second 
loop ;=()

These stayed fairly constant around these values.
1: Elapsed 386.51 ms, av. 3.858076 ns.
2: Elapsed 7.77 secs, av. 77.674 ns.

That is the simple integer math wins hands down 
over the FPU math by a factor of 20+ times. ;=))
some 2000% slower...

So as stated, what is wrong with static variables?

If thought REALLY necessary you could obfuscate 
their names by putting them in a namespace and/or
a structure, and even allocating that space... but
not really required IMHO.

I do not want to take the time to add debug code
to the Ubuntu source, just to prove that I think
in _ALL_ ports the first call to mouseMotion()
could sometimes contain the SAME x,y as the click
point.

mouseMotion would be being called as the mouse
moved towards where the user finally depressed
the mouse button, so in simple terms this would
be different to that previous mouseMotion call,
if in fact GLUT (and/or the underlying OS)
are doing their message event on real position
change, which I hope they are...

It is my idea that since a 2nd, 3rd, etc
mouseMotion() callbacks, after mouse-down, happen
very quickly in other ports we just do NOT see the
slow down. Remember, it is the slowdown to minutes,
of the first points-equal paint that I think is the
'difference' in windows...

AND none of that changes that I saw the value
of the 'eye' vector filled with 1.#IND, which
is not-a-number, so I think there is a (quiet)
divide by zero when the rot is 0,0,0,0, or
somewhere...

But either way, no matter what the full facts are,
I hope you add something to CVS to fix this 'freeze'
problem, which now we know is experienced by
others, not just noisy geoff ;=))

Regards,
Geoff.

PS: Since I do HATE not knowing the facts, I did add some
minor debug to Ubuntu, and contrary to the above idea
I had, which now seems wrong, is does seem linux/glut 
does hold off the mouseMotion call until the mouse 
moves OFF the click point ;=()

AH HA! Adding MORE debug, it seems this sole
difference _IS_ the problem ;=)) Maybe it is just
that in windows the mouse click event is done
before the motion event which is due whether
there is a click or not... if you see what I mean...

AND I added some more debug code, to force the x,y
of the first motion callback after the click event
to equal the click x,y, and BINGO ;=((

I get NANs in rot, (but eye stays as zero?), and the
screen goes black, but nowhere near the same many-minutes 
paint delay I see in windows... just seconds
perhaps... did not spend a lot of time on it...

Debug output
A case where I do NOT move after the click
dragging commenced 246,581
dragging ended     246,581
so there are NO motion events in between.

Then I try a move, and get a BLACK screen, and
NANs... just like in WIN32...
dragging commenced 194,593
drag:1: 194,593 rot nan,nan,nan,nan eye 0.000000,0.000000,0.000000
dragging ended     262,590
And note, no more mouseMotion call backs, although the
mouse traveled a long way in between???

But since I put the debug stuff inside the 
  if (scenery->intersection(x, y, &newC)) {
maybe this returns zero, so it appears as no debug
displayed motion events, but they were there... or
something...

Anyway, enough time wasted on this very interesting
case ;=)) Look forward to 'some' CVS change to at
least 'fix' WIN32...

>>>>> "Geoff" == Geoff McLane  writes:

    Geoff> Hi Brian, Glad you agree, AND yes, the comparison of the
    Geoff> vectors will also work, (I think), BUT -

    >>> I don't think we need any more static variables though

    Geoff> Really not sure what you have against static variables ;=))

    Geoff> I just did a speed test comparing simple integer math I
    Geoff> DELIBERATELY chose, with the vector math you suggested :-

[...]

    Geoff> I think you would be AMAZED, as I was, at the VERY BIG
    Geoff> difference between CPU integer math in the first, and the FPU
    Geoff> cost in the second loop ;=()

    Geoff> These stayed fairly constant around these values.  1: Elapsed
    Geoff> 386.51 ms, av. 3.858076 ns.  2: Elapsed 7.77 secs, av. 77.674
    Geoff> ns.

    Geoff> That is the simple integer math wins hands down over the FPU
    Geoff> math by a factor of 20+ times. ;=)) some 2000% slower...

Part of the slowdown is caused by C++.  If you run the same test with
PLIB's sgdVec3 structures, the slowdown becomes 3 times (on my machine).

But I think this is missing the point.  Using the SGVec3<double>
comparison takes, as you said, about 78 ns.  That is eventually followed
by a call to glutPostRedisplay(), which means that redrawMap() is
called.  If I remember correctly, you had that timed at about 20 ms, or
approximately 250,000 times longer.  In other words, the time spent
doing SGVec3<double> comparison is absolutely immaterial to the speed of
Atlas.

    Geoff> So as stated, what is wrong with static variables?

You have to be careful to update them.  In this case it's not a big
deal, but state variable you add increases the chance of a logic error.
If introducing them is not critical (and in this case I don't think it
is), then they're best avoided.

I would add that, in a way, comparing oldC and newC is logically better
too.  The real problem is that we tried to define a plane with two
points (since oldC and newC were identical).  There are an infinite
number of planes that pass through 2 points, so the math broke down.  By
checking oldC and newC for equality, we're making sure that we'll never
get in that situation again.  Adding curr_x and curr_y may solve this
particular problem, but who's to say something unrelated to curr_x and
curr_y will result in oldC and newC being the same?

Brian

Hi Brian,

Thanks for the set of CVS updates. All very
good ;=))

Yes, I had missed that even though I used integer
math (for speed), I overlooked that I had left the
glutPostRedisplay() at a cost of some 20 ms ;=(( so
now, together with the other reason you gave, fully
agree with the simple :-
          if (oldC == newC)
               return;

What is some 73 ns between friends ;=))

Perhaps, since you seem in the mood to do some CVS
updates I could push you to do a few MORE ;=)) some
have been pending for over 9 months...

In each of these cases, although I first found/coded/tested
these in WIN32, I have also added them to my Ubuntu, done
a full re-compile and check runs, and the cvs diffs (patches)
attached are in Ubuntu, against the master repo... 7
in all... see atlas-patch-05.patch in the zip.

A little explanation of each...

1: File: Notification.cxx - notification.patch

While this may still be a little controversial with you,
and perhaps you have other ideas, but could we 'please' 
avoid, at least for now, the exit 'crash' in both 
unix/linux and WIN32, as reported both by me and
Raghvendra...

And I am sure others have run into it. At least until 
you get time to maybe fix this another way, just chop 
the '== all' code... the exit to the OS will clean up 
the memory...

2: File: Subbucket.cxx - subbucket.patch

I know you have resisted this change in the past due to
only wanting users to use a 'release' version of simgear,
but since there _IS_ now a simgear release 2.2.0, can we
drop the '2' from get_gbs_center2.

OR, to be more flexible, maybe there is a way through
say a configure.ac test of the simgear version, and
correctly make this a conditional compile, depending
on the SG version detected/used.

I would work on this if I thought there was a chance
you would adopt it. Then it would work for ALL
recent versions, including 2.0.0, without user
'hacks' of the code ;=))

3: File: AirportsOverlay.cxx - airportsoverlay.patch

I know you do _NOT_ particularly like this type of
variable name change, and we absolutely AGREE that 
<windows.h> is a massive namespace polluter, but 
there is just no other way to avoid such clashes.

They does not happen very often, so is not a BIG
problem...

Actually, IIRC, only the 'small' is a windows
name clash, but I did it to all 3 variables
so make them self consistent.

4: File: Atlas.cxx - atlas.patch

(a) deleteLastPoint() - 2nd _points to _segments
Looks like just a simple overlooked 'name'
error. Does not cause any harm, but maybe it
is better to get it right ;=))

(b) searchFinished(Search *s)
This re-use of 's' for a Searchable *s was no
problem until I added in some debug code, then
the MSVC compiler complained of 2 's' variables!

But it certainly 'reads' better now I changed the
second to 'match'...

(c) keyPressed() - ctrl+space to '\0'

This seems only for _MSC_VER.

I posted this 'bug' on the freeglut development list
and John Fay has agreed to 'fix' this, to be fully
consistent across platforms...

But since that will take some time, and there is
a likelihood that users may have older versions
of freeglut, then still suggest this 'fix'.

It does no 'harm' even if a later 'fixed' version
of freeglut, or other GLUT versions, are used...

5: File: misc.cxx - misc.patch

As spoken about at length (a) a size_t can not
be compared as < 0, and (b) we do not want
the string 'truncated', but fail, return -1, if 
insufficient space.

This is a fix, on a fix, on a fix ;=)) Hope to 
get it right this time...

6: File: Palette.cxx - palette.patch

This inclusion of "config.h" is just to quieten
some MSVC compiler warnings.

7: File: Map.cxx - map.patch

Finally, this is not all really a 'fix' but two 
NEW features for Map... 

(a) Although inside it _IS_ one VERY important
WIN32 'fix', and that is :-

@@ -333,7 +450,9 @@
     }
 #else
   #ifdef HAVE_SGGLEXT_H
-    Map_Exit_Ext( &fbo, &rbo );
+    if (renderToFramebuffer) {
+        Map_Exit_Ext( &fbo, &rbo );
+    }
   #endif
 #endif
    if (mapper) {

Simply, Map_Exit_Ext() should NOT be called
if NOT rendering to a frame buffer. To do
otherwise causes a seg fault!

(b) And another 'fix', for WIN32, is the location
of a 'HOME' directory, for the .atlasmaprc file,
since 'HOME' is NOT always defined in windows,
but there is a 'HOMEDRIVE' and a 'HOMEPATH', and
I tack 'Atlas' onto that...

@@ -375,6 +502,10 @@
     char* homedir = getenv("HOME");
     const char *atlasmaprc = ".atlasmaprc";
     AtlasString rcPath;
+#ifdef _MSC_VER
+    if (homedir == NULL)
+        get_win32_home(&homedir);
+#endif // _MSC_VER
     if (homedir != NULL) {
    rcPath.printf("%s/%s", homedir, atlasmaprc);
     } else {

I have put this 'service' in the win_ulib.lib,
so WIN32 users will need to update that,
which will come later...

(c) BUT in the main the patch covers TWO(2) _NEW_
features, and are all in an ADD_CHUNK_LIMIT
macro, which I default to ON.

1. --force

This is a simple option to OVERWRITE the map files.
As you have coded, normally Map will avoid writing
a 'new' map files if one already exists. This is a
good feature.

But this --force feature is convenient if you want
to say re-do all the maps with a new palette, or
some changed rendering options...

2. --chunk=<chunk>

What I found was that if you pointed Map at a _FULL_
scenery 1.0.1 folder, it would spend all afternoon
generating THOUSANDS of maps, takes HOURS, and using
lots of disk space, to process the 1.5 million scenery
files found...

This --chunk=e000n40 would limit Map to only producing
maps for this particular 10x10 degree CHUNK.

And multiple 'chunks' can be entered at one time,
like I found for ALL New Zealand --chunk=e150s40
--chunk=e160s50 --chunk=e170s50

I hope you consider these as 'GOOD' features.

As always, hope some or preferably _ALL_ find their 
way into CVS soon ;=))

And have updated my WIN32 build to CVS of yesterday,
and this SLOW DOWN BUG has been SQUASHED ;=)) But
still to decide what to do with all the DEBUG code
I added to get there...

Regards,
Geoff.

attached: atlas-patch-05.zip - containing 7 patch files,
and atlas-patch-05.patch with them all-in-one. It can
also be downloaded from the usual -
 http://geoffair.org/tmp/atlas-patch-05.zip

>>>>> "Geoff" == Geoff McLane  writes:

    Geoff> 1: File: Notification.cxx - notification.patch

    Geoff> While this may still be a little controversial with you, and
    Geoff> perhaps you have other ideas, but could we 'please' avoid, at
    Geoff> least for now, the exit 'crash' in both unix/linux and WIN32,
    Geoff> as reported both by me and Raghvendra...

    Geoff> And I am sure others have run into it. At least until you get
    Geoff> time to maybe fix this another way, just chop the '== all'
    Geoff> code... the exit to the OS will clean up the memory...

Well, my feelings really haven't changed about this.  I think we need to
find out exactly why it's crashing, rather than just removing code that,
to my mind at least, should work (and does work for me).  Moreover, by
understanding the problem, we might be able to come up with a more
palatable solution.

    Geoff> 2: File: Subbucket.cxx - subbucket.patch

    Geoff> I know you have resisted this change in the past due to only
    Geoff> wanting users to use a 'release' version of simgear, but
    Geoff> since there _IS_ now a simgear release 2.2.0, can we drop the
    Geoff> '2' from get_gbs_center2.

Are you sure there's a 2.2.0 release?  I haven't heard anything on the
mailing list.  I checked the SimGear website and 2.0.0 is listed as the
latest stable release.  I looked at the gitorious repository and there
is still a lot of activity on 2.2.0, indicating it's still under active
development.  Furthermore, although I can see releases tagged 'v2.0.0',
and '2.2.0-rc1', there's no '2.2.0' or 'v2.2.0'.  Finally SimGear
releases tend to be synchronized with FlightGear releases, and there is
no 2.2.0 release of FlightGear, making me doubt that SimGear 2.2.0 is a
stable release.

    Geoff> 3: File: AirportsOverlay.cxx - airportsoverlay.patch

Done.

    Geoff> 4: File: Atlas.cxx - atlas.patch

    Geoff> (a) deleteLastPoint() - 2nd _points to _segments Looks like
    Geoff> just a simple overlooked 'name' error. Does not cause any
    Geoff> harm, but maybe it is better to get it right ;=))

Actually the logic works out to be the same, but I changed it anyway.

    Geoff> (b) searchFinished(Search *s) This re-use of 's' for a
    Geoff> Searchable *s was no problem until I added in some debug
    Geoff> code, then the MSVC compiler complained of 2 's' variables!

Done.

    Geoff> (c) keyPressed() - ctrl+space to '\0'

Done.

    Geoff> 5: File: misc.cxx - misc.patch

Done.

    Geoff> 6: File: Palette.cxx - palette.patch

Done.

    Geoff> 7: File: Map.cxx - map.patch

I'm going to hold off on the changes to Map.cxx, the reason being that
I'm working on a major improvement/substitute for Map that incorporates
most of these changes.  You'll have to hold tight until it appears.

For a bit of background, I've noticed that nearly the #1 impediment to
using Atlas is the difficulty of generating maps, at least for those not
used to the command-line.  So I'm prototyping a user interface that will
hopefully solve that issue.  It should also make it easier to understand
at a glance the state of your scenery and maps, modify rendering
options, and to specify which ones to render.  Whether it will be a
substitute for Map, an alternative to Map, or the death of Map (by
incorporating it into Atlas) remains to be seen.

Thanks for the patch!

Brian

Hi,

Re: glutGetModifiers() warning

ARGH! This just gets more complicated ;=()

Just _NOT_ believing that one could NOT call
glutGetModifiers() in a 'special' key callback
I looked DEEPER into the freeglut (sourceforge) 
SVN source.

Most certainly one would WANT to be able to
differentiate between say F2 and shift+F2,
or ctrl+F2, etc, to get a larger range of keys... 

As stated, I was SURPRISED to find the callback
called for the Shift, Ctrl, and Alt keys themselves,
but note these callbacks are done in a different part
of the code. And that code is _ALL_ in an area
in an #if TARGET_HOST_MS_WINDOWS macro block.

AND, it is ONLY during these particular modifier
key callbacks that one gets a warning if 
glutGetModifiers() is called.

In _ALL_ other special keyboard callbacks, it _IS_
valid to call glutGetModifiers() ;=)) AS IT
SHOULD BE!!!

So now I feel I know the 'facts' - from the code
itself - I still have to ponder how to implement
this without LOTS if #ifdef WIN32 blocks...

So for WIN32 I have added a service -
 int is_special_specials(unsigned char key)
which checks if it is only a 'modifier' key
callback, and thus avoid calling glutGetModifiers()
if it is!

Now I can see say right-arrow key calls back the
'special' with GLUT_KEY_RIGHT value (0x66), and 
while shift + right-arrow, first calls back with
the shift, which is now ignored, and then calls 
back with the SAME value, and calling glutGetModifiers()
shows that the SHIFT key is down. ALL GOOD ;=))

You will note I have shifted in this case to using
a WIN32 macro, in place of _MSC_VER, since I would
assume this change would ALSO equally apply to
cygwin and mingw ports... but can not check this.

That was all done in my glutkbd app, which I have
now also compiled/run in Ubuntu, so have put up a
simple web page, with notes and the source -
 http://geoffair.org/projects/glutkbd.htm 

In Atlas, I have 'hidden' away the service -
 int is_win32_special_specials(key)
in my additional win_ulib.lib, in win_utils.cxx,
then, at the top of the specialGraphs(...)
callback, like :-

#ifdef WIN32
    // 2011-03-09: WIN32 calls back with the mod keys,
    // which can be ignored, thus avoiding a glut warning.
    if (is_win32_special_specials(key))
        return;
#endif // WIN32
    if (glutGetModifiers() & GLUT_ACTIVE_SHIFT) {
    ...

And no more GLUT warnings in WIN32 ;=))

Regards,
Geoff.

link: http://geoffair.org/projects/glutkbd.htm

On Mon, 2011-03-07 at 22:43 +0100, Alex D-HUND wrote:
> [snip]
> Subbucket.cxx:75: error: ‘class SGBinObject’ has no member named
> ‘get_gbs_center2’

Hi Alex,

If you read back in the archives you would
see this documented several times...

The simple answer, just chop off the '2' of
get_gbs_center2() function ;=))

It seems this get_gbs_center2() function was
dropped from simgear after 2.0.0, using only
get_gbs_center() in 2.2 (git) onwards...

Hope this helps.

Regards,
Geoff.

>>>>> "Geoff" == Geoff McLane  writes:

[...]

    Geoff> In other words, if the 'j' edit contains something, then, as
    Geoff> at present, the search is based on this partial... But if the
    Geoff> edit box is clear, but there is a previous route entry, then
    Geoff> fill in a search based based purely on the nearest to that.

Well, if the previous route entry is at the centre of the screen, it
will do exactly that.  Or am I misunderstanding your question?

Note that Atlas will reorder the list as you move around.  For example,
if you're at YGIL and search for 'cc', you'll get about 60 results, the
first being "NDB: CCK CHURCH CREEK (248)".  Hit escape, so that the
search results aren't cleared but the list goes away.  Now go to
Christchurch, New Zealand (but don't use the jump facility - just use
the usual zooming and dragging).  Now if you type 'j', you'll see the
first entry is "NDB: CC CAPE CAMPBELL (286)".

And I forgot to mention it previously, but you can also search by
frequency.  So if you remember that a VOR was 114.40, but can't remember
the name, just type in "VOR: 114.40" (or "114.4 VOR:" - order doesn't
matter), and you'll get a list.  You may also notice in passing that
what *does* matter is this - if you type in a few characters, Atlas will
happily match substrings.  So from YGIL if you type "coon", you'll get 8
matches.  If you add a space "coon ", you'll get none.  So the rule is,
an incomplete word (which is a word with no trailing whitespace) matches
all prefixes, while a complete word (a word with trailing whitespace)
has to match exactly (except for case, which is always ignored).

    Geoff> 4. Save and Load a route

    Geoff> Even before tackling the much BIGGER topic of a 'flight
    Geoff> plan', it would still be neat to be able to save and reload
    Geoff> this 'ROUTE' list as a simple text file of the entries
    Geoff> chosen. Like say -

    Geoff> AIR: YSDU Dubbo FIX: OKAPI AIR: YGIL Gilgandra AIR: YTWN
    Geoff> Tooaweenah NDB: CBB COONABARABRAN (200) etc

An example of a waypoint syntax is given here:

  http://flightgear.org/forums/viewtopic.php?f=6&t=1194&p=7206

  This uses the syntax STATION radial/distance@..., where all but
  STATION are optional.  So,

  "SFO 280/15" means "15 nm along the 280 radial from SFO VOR (altitude
  unspecified)"

Another is here:

  http://wiki.flightgear.org/index.php/Route_Manager

  This uses the syntax STATION/radial/distance@... (almost exactly
  the same).  An example is:

  "SPL/050/12.3@...", which means "12.3 nm from SPL VOR on the 050
  radial, at 2000 feet".

A third is here:

  http://flightgear.org/forums/viewtopic.php?f=6&t=2577&st=0&sk=t&sd=a

  There's only one example, but basically it's
  STATION[<>]radialDdistance, where '<' means inbound and '>' means
  outbound, and that 'D' must be typed as is.  For example,

  "TRN>41D30" means "30 nm outbound along the 041 radial from TRN".

  Unlike the previous two, this one specifies a heading (inbound or
  outbound).  I'm not sure if that's a good thing or not.  They also
  discuss the idea of altitude qualifiers - adding an 'A' to an altitude
  means "this altitude or above", while 'B' means "this altitude or
  below".  As well, altitudes can be expressed as flight levels:
  "FL210".

I think these would all be good ways to input and save a route.  We
should also add the ability to add airways.  Here, for example, is one
of the preferred routes from San Francisco to New York's JFK airport:

  SFO FMG J94 OBK J584 CRL J554 JHW J70 LVZ LENDY5 JFK

Very concise, and easy to type in.  You'll note it follows 4 airways
(J94, J584, J554, and J70).  To specify an airway, you specify the entry
point, the airway, and the exit point.  There's also a STAR at the end
(LENDY5).

    Geoff> And I looked for a way to re-open an existing route, and add
    Geoff> a new point to it, but see that after the second ctrl+space
    Geoff> closed that route, the next ctrl+space, and DEL, keys
    Geoff> completely deletes the route done - then I sort of wished I
    Geoff> had an un-do button ;=))

Type 'r' to toggle the active status of a route.  I had completely
forgotten I had put that in, but clearly I had anticipated your
question. :-)

    Geoff> PS: The only sample I found of an XML flight plan was here -
    Geoff> http://files.goneabitbursar.com/fg/egph-eham.xml but now can
    Geoff> not remember where I got that link - maybe from the
    Geoff> forum... there do not seem to be too many samples around...

That was from this discussion:

http://www.flightgear.org/forums/viewtopic.php?f=17&t=6267

where they were talking about a new syntax for flight plans.

Brian

Hi Brian,

1. 'j' edit box and list

Maybe I am not stating the 'idea' I have 
very correctly ;=(( And maybe it is a BAD idea!

I started Atlas with --airport=YGIL, so the 'eye' is
on YGIL. Then this sequence of keys, and mouse,
and actions seen -

j - brings up a blank edit box, no list - ok
Y - adds a list with AIR: YGIL at top - ok
click on YGIL - line is marked selected - ok
ctrl+space - adds route text - ok
BS - Deletes 'Y' and the list goes BLANK ;=((.

This is where I am suggesting the list should be
filled with items nearest to YGIL, even though
there is nothing in the edit box! But YGIL is
the last...

This is when I need some help. Some assistance
from Atlas on knowing, listing what are my 
nearest route choices, obviously in all directions
from YGIL.  But yes, as an alternative, I can sort
of zoom/drag the map around to see what is there...

Say I know I want to go to YSDU, so I could 
start typing Y but that 'Y' based list 'misses'
that there is FIX: OKAPI, more or less on my proposed 
route, that I may want to include.

Of course if I know it is there, then typing an
'O' will most certainly list it, but the list
will now not include YSDU...

Despite my previously mentioned 'stickiness',
which I want to 'forget' for now, the searching
seems _VERY_ efficient. Given that there are
nearly 400,000 entries (= _tokens.size()).

But from what I read in the code, it is then based
on matching strings. What I am suggesting here,
is a search based on distance from the eye
ALONE, so maybe this is not possible, feasible!

Since it is with no 'string' criteria, then the
list is always 400,000, so it would have to
have say a cut off distance/count... a limit to
the 'list'... like showing say the nearest 100...

And if I read correctly, the Searcher::_matches is
redone for each _comparator.center() change, so is
this not as simple as listing the first 100? Only
when blank, and as now once a letter has been
added...

And yes I had noted partial string, like 'VOR:
114.4' also works fine... and was beginning to
understand 'partials' = no trailing space, and
'complete' where there is a trailing space.

And yes, putting say 'cc' in 'j' edit lists some
60 entries with 'cc' nearest the 'eye'. And then
ESC, and zoom/drag to a new location, and another
'j' will list the closest 'cc' items near the
new 'eye'.
 
This is all GOOD, and reminded me that I do not 
have the NZ tiles in my maps ;=((

But 'lazy' me, I still wanted some list-of-possibilities
even when I have NOT yet provided any 'string'
clue as to what I am interested in, except that
the 'eye' is on YGIL... Where _CAN_ I go?

Maybe I am reaching for the sky ;=)) And do not
yet fully understand what is already available in 
this 'route' UI... but getting to 'know' it more,
and more...

You have obviously put quite some effort and 
thought into it, and as stated, it works fine...

So maybe I have exhausted this particular line of 
inquiry ;=))

Of course, I hope you have added some of your
very good explanations on all this to the growing 
'documentation' ;=))

2. Save and Load a route

Yes, as your great links point out, this could
be related to the route manager in fgfs, which
in turn is related to the bigger flight planning.
And with that, the suggested change to XML format.

And ultimately Atlas could support this, and like
the ruby based fgmap, which unfortunately refuses
to run in my Ubuntu 8.04, despite installed all that
seemed required, which uses OpenStreetMaps, Atlas
could feed this route directly into running fgfs
through telnet, but that seems some ways down the
line...

And I really must find the time to 'play' with
fgfs route manager... to learn more...

What I was seeking at this stage was only to save
and restore an Atlas displayed route, and thus
suggested a simple 'text' form, unrelated to
fgfs, as a step ONE.

And in this regard, what I tried was some code
to build up a string list of the 'route' as it
was being defined, support deletions, etc, and thus
being able to write that to a simple text file.

Then being able to load that file, do the searches
for the strings given, adding any un-named points,
and thus build up a simple route re-load capability,
but this is ongoing... very slowly...

And meantime have tested the great 'r' key, which
allows route extensions ;=)) Good anticipation!!!

Regards,
Geoff.

PS: On the 'bigger' topic, flight planning, below is a
list of some 'light' reading you noted ;=))

'Route', waypoint, route manager, flight plan,... URLS:
 http://flightgear.org/forums/viewtopic.php?f=6&t=1194&p=7206 
 http://wiki.flightgear.org/index.php/Route_Manager 
 http://flightgear.org/forums/viewtopic.php?f=6&t=2577&st=0&sk=t&sd=a 
 http://www.flightgear.org/forums/viewtopic.php?f=17&t=6267 
Others mentioned -
 http://airinc.ca/ 
 http://ndac.navigraph.com/www/fmsdata.asp 
And more -
 http://www.atlasaviation.com/flight_planning.htm 
 http://www.baseops.net/info/dd1801gouge.html 
 http://en.wikipedia.org/wiki/Flight_plan 
 http://www.fltplan.com/ 
 https://rubyforge.org/frs/?group_id=9572 

And of course, another of my other interests -
 http://forum.ivao.aero/ 
where I _MUST_ file a Flight Plan _BEFORE_ I connect to the
network, presently using MSFS and ivao s/w, but I hope one day
also with fgfs and ivao s/w... And FWIIW, the ivao WIN32 s/w 
keeps this IFP in an INI file format, like -
[flightplan]
title=YSDU to YCBB
type=VFR
departure_id=...
waypoint.0=...
waypoint.1=...
etc, etc... so is easy to repeat, or change the plan for next
time...

Still pouring through all this... and as stated, will come
back on a 'new' topic for this... say 'Atlas and Flight 
Planning '...

>>>>> "Geoff" == Geoff McLane  writes:

    Geoff> 1. 'j' edit box and list

    Geoff> Maybe I am not stating the 'idea' I have very correctly ;=((
    Geoff> And maybe it is a BAD idea!

Not at all - it just took me a while to cotton on to what you were
saying.  In fact, I've wondered about the same thing.  I'm not exactly
sure how to approach it, but I don't think the current jump facility
really fits the bill (although it is enticingly close).  And I would
agree that it would be very useful for flight planning.

One thing I was thinking about was a more graphical approach based on
being in a "navigation mode" (for lack of a better term).  When in this
mode, all navaids become active.  Those within range "lock on" to the
centre of the screen (or the mouse, depending on whether you're in mouse
or centre mode).  They would draw a beam from the navaid to the
centre/mouse, just as you see when viewing a flight track and have tuned
into a navaid, and indicate the heading to the navaid (and maybe its
range and frequency).  Instead of, or in addition to, a beam they could
draw a range circle.

Of course, this wouldn't solve the "what airports are nearby" question,
since the idea of being in range doesn't apply.  One possibility is to
have an adjustable range (probably on the interface somewhere, or maybe
as part of Atlas' preferences), so only airports within that range are
shown.  Again, we could draw a beam from the airport to the
centre/mouse, labelled with the airport name and its distance.

One nice thing about this approach is it can use code that has already
been written to draw flight tracks, so it wouldn't require a huge amount
of extra effort.  We'd probably need to be a bit clever about labelling,
just to ensure that it all remains legible, especially in congested
areas.

    Geoff> 2. Save and Load a route

[...]

    Geoff> Still pouring through all this... and as stated, will come
    Geoff> back on a 'new' topic for this... say 'Atlas and Flight
    Geoff> Planning '...

I think there's certainly room for a text-based flight plan format, as
separate from a more complicated format used to specify SIDs, STARs,
etc.  This could be implemented sooner, and probably wouldn't be too
tough (except for the UI, which is always a pain in the butt).  Ideally
it would be based on some standard, and which had a large base of
predefined routes.

Using a FlightGear standard would be really good, but we need to be sure
that (a) it's expressive enough, (b) well-defined, and (c) won't
suddenly disappear, to be replaced by yet another standard.  We could
support multiple standards, but the fewer the better.

Pushing the flight plan to FlightGear is very important, but we need to
understand how that works.  Failing that, we need to be able to save it
in a format that FlightGear can read in.

Anyway, I look forward to what you find out.

Brian

>>>>> "Jari" == Jari Häkkinen  writes:

    Jari> On 2011-03-06 06.37, Brian Schack wrote:
    >> One of the many nice things about LaTeX is that it's plain text,
    >> so that there's no problem putting under a source code control
    >> system.  And in general I don't like WYSIWYG editors, because
    >> they seem to get in the way more than they help (although LaTeX
    >> has one called LyX, and probably many others).

    Jari> My experience working in a team writing documentation using
    Jari> latex and WYSIWYG editors is that the editors make many
    Jari> unwanted and (by latex) not needed changes to the source
    Jari> files. It was some time ago so it may have changed.

    Jari> Working with latex I usually use emacs to edit, latex to
    Jari> create a dvi file and xdvi to show the result. xdvi can be set
    Jari> to reload automatically when the dvi file is regenerated. No
    Jari> need for a WYSIWYG editor but we all have different
    Jari> preferences.

I couldn't agree with you more - I much prefer LaTeX and emacs to a
WYSIWYG editor.

    >> As for the LaTeX to HTML conversion, it's certainly possible.
    >> The FlightGear manual, written in LaTeX, is online in HTML, so
    >> presumably they use some automatic conversion software.  I just
    >> tried using latex2html and another called tth, but not with any
    >> success.  I think successful use of these tools probably means
    >> restricting the LaTeX features I use, hopefully not to the point
    >> where the document is not aesthetically pleasing.

    Jari> Brian, I've used latex2html for a long time so I might be able
    Jari> to resolve your issues if you send me the source files.

That would be great!  It's a bit big though (the pictures take 5 MB).
If you're willing to try, I can bundle it into a tar file and send it to
you.

Brian

On 2011-03-07 07.07, Brian Schack wrote:
>>>>>> "Jari" == Jari Häkkinen  writes:
>
>      Jari>  On 2011-03-06 06.37, Brian Schack wrote:
>      >>  One of the many nice things about LaTeX is that it's plain text,
>      >>  so that there's no problem putting under a source code control
>      >>  system.  And in general I don't like WYSIWYG editors, because
>      >>  they seem to get in the way more than they help (although LaTeX
>      >>  has one called LyX, and probably many others).
>
>      Jari>  My experience working in a team writing documentation using
>      Jari>  latex and WYSIWYG editors is that the editors make many
>      Jari>  unwanted and (by latex) not needed changes to the source
>      Jari>  files. It was some time ago so it may have changed.
>
>      Jari>  Working with latex I usually use emacs to edit, latex to
>      Jari>  create a dvi file and xdvi to show the result. xdvi can be set
>      Jari>  to reload automatically when the dvi file is regenerated. No
>      Jari>  need for a WYSIWYG editor but we all have different
>      Jari>  preferences.
>
> I couldn't agree with you more - I much prefer LaTeX and emacs to a
> WYSIWYG editor.
>
>      >>  As for the LaTeX to HTML conversion, it's certainly possible.
>      >>  The FlightGear manual, written in LaTeX, is online in HTML, so
>      >>  presumably they use some automatic conversion software.  I just
>      >>  tried using latex2html and another called tth, but not with any
>      >>  success.  I think successful use of these tools probably means
>      >>  restricting the LaTeX features I use, hopefully not to the point
>      >>  where the document is not aesthetically pleasing.
>
>      Jari>  Brian, I've used latex2html for a long time so I might be able
>      Jari>  to resolve your issues if you send me the source files.
>
> That would be great!  It's a bit big though (the pictures take 5 MB).
> If you're willing to try, I can bundle it into a tar file and send it to
> you.

The mail size restriction I have is 14 MB so if the bundle is smaller 
than that just send it directly to me.


Jari