Programmer's notes for ORRERY

If you are not into programming and IZL, you can ignore this file.

Graphics:
========

-1-

The way I display the planets is to define a graphics object (View), fill its entire
surface with black ink (pen_color) then draw on it with white.
The "planets" are just small squares (5 pixels each side) that I hide-move-show
in the computed location.

I would have preferred to draw the picture of each planet on a separate tile 
(Earth with continents, Jupiter with the Red Spot, Saturn with ring etc.) and 
move those around. However, I only ever managed to get the drawing on the first
tile.
Although hide-show-move properly covers the orbit it is placing a tile over 
then uncovers it when the tile moves on, drawing normally (ie. black on white)
only produced broken orbit circles for all but the first orbit handled.


-2-

I started out with one object to show all three views, but found it intolerable:
it would cycle through all previous contents, even stuff I erased since showing
Some form of GEOS buffering must be at work here?

I wound up by drawing each view on its own object. ORRERY still redraws the 
orbits several times although I only do one 'show' for its frame.
This is painfully obvious when watching the OmniGo.


-3-

Orbits are being shown as circles in ORRERY which, in reality they are not.
I experimented long and hard (a week's evenings) with drawing ellipses but given up.
Here is why.

The problem is this: the 'ellipse' IZL primitive only draws ellipses whose axes are
parallel to the screen's sides (X and Y axes) and therefore share their major axes.

The planets' orbits do not share their major axes, they all turn this way and that way.
This left me tdrawing the ellipses myself. I found that computing an ellipse, even
only using every second degree took 78 seconds on the OG.

I put this calculation into a program that wrote the computed coordinates into a file.
I found that plotting the points using table lookup still took 13 seconds per orbit
on the OG - prohibitive.

Drawing circles is only a slight cheat: Pluto's orbit (the most elliptical) worked out
to have a major axis 6 pixels longer than its minor axis.. the Earth orbit's major
axis was 1 pixel longer than its minor. Not worth the trouble. In comparison, the
tiles I use as planets are 5 pixel-wide squares.

This entails another cheat: the planet moving olong the largest orbit of he screen
is orbiting around the screen's centre. The others do not, they orbit the point
where the Sun sits in relation of the largest orbit.


Astronomical accuracy
=====================
The algorithm I use for finding the heliocentric longitude for each planet is
only accurate within a few degrees. This is masked by drawing "huge" planets. I mean,
compared to their orbits, the 5-pixel squares I use for planets are out of scale
so much as to cover the calculation's inaccuracy.

The position of Pluto is even less accurate. In fact, if you look at the most detailed
algorith collections available, they give you no universal method for this planet.
There is not enough knowledge about its orbit yet!



Numerical representation
========================
To show the All planets view, I store the orbit sizes as percent of the largest
displayable radius (array CircRPct). In the Startup function, I convert these to pixel, writing
the new data back into the original array.

No problem under Ensemble, but the OmniGo looped! Using Trace showed huge numbers
and negative numbers for screen coordinates- the result of not completely overwriting
the original bytes. Solution; write the pixel data into a separate array (CircRPix).

It is likely that something similar is happening in NDO: IZL rejects the code!
The same IZL, the same code that it happily runs with under Ensemble and the OmniGo..


If you'd like to discus any of this, please drop me a line; cynpet@netspace.net.au

Peter Eros