The red kill app menubar button is greyed out on the Mac.  See if
this is the problem, and possible fix.

For GLUT's issue, the work around is not public API, but this should
not affect your case (it is only for non-bundled apps that end up
background only), as you should not have your app end up background
only. Please write a bug and submit a test case. The profiler
engineer I am sure can figure out what is strange about your bundled
app.

You may want to try:
ProcessSerialNumber psn;
GetCurrentProcess (&psn);
SetFrontProcess(&psn); // bring process to front

Or maybe we need something like the Rob Fletcher's glutWMCloseFunc()
callback glut patch for OS-X glut.  I think freeglut implemented
something similar.

Actually the Read Me for GLUT for Mac OS X (GLUT-3.2.8) says it
added the glutCheckLoop() and GlutWMCloseFunc() APIs.  Gotta try 
them.  (This may only be in the glut source distribution.)  

---------------------------

Consider adding a -reg command line arg to register MIME types on 
Windows to avoid this mess:

This tutorial works for Windows 98 and I think it's close enough for
2000, but naturally M$ made it even harder for XP. 

  http://www.ldraw.org/reference/tutorials/tips/mime/

I even tried some old command line functions that I think used
to work, but no luck.

  FTYPE ldraw.document=C:\projects\ldglite.exe -l3 -v4 "%1"
  ASSOC .dat=ldraw.document
  ASSOC .mpd=ldraw.document
  ASSOC .ldr=ldraw.document
  SET PATHEXT=.ldr;.mpd;.dat;%PATHEXT%

problem is that's only half of the solution.  Lugnet serves up LDR data
with the application/x-ldraw MIME type.  In win95 and win98 you could
create new MIME types in explorer.  See steps 5 and 6 of the tutorial. 

  http://www.ldraw.org/reference/tutorials/tips/mime/

But win2k and winXP only let you select from the list of MIME types
already in the registry.  I suppose they must consider it a security
risk to allow mere mortals to make new ones.  Anyhow, silly me.  It
turns out I solved this one myself two years ago when I first
encountered win2K.

---------------------------

For Internet Explorer in Win2k (and perhaps Millenium):

    Thank you Micro$oft.  In Win2k you can no longer create new MIME types
    from an Explorer window.  You must use regedit instead.

    1) Start/Run
       Type "regedit" in the box and click "OK"

    2) Right click on HKEY_CLASSES_ROOT.
       Add a new key and rename it to ".dat"
       Right click on (Default) for this new key and modify the value.
       Enter "ldlite.Document" for the Value data.

    3) Right click on the key HKEY_CLASSES_ROOT/.dat
       Add a new string value and rename it to "Content Type"
       Right click on "Content Type" and select modify.
       Change the Value data to "application/x-ldraw".

    4) Find the key:
       HKEY_CLASSES_ROOT/MIME/Database/Content Type.
       Under this key, create a key for application/x-ldraw.

    5) Under the application/x-ldraw key, create a string value:
       "Extension", with data ".dat".

    6) Quit regedit.

    7) Open an Explorer window (or any folder window).

    8) Select the "Tools->Folder Options" menu selection.

    9) Go to the "File Types" tab.

   10) Scroll down and double click on the "ldlite Document" line.
       (On Win2K search for the "DAT" extension)
           If there is no "DAT" extension line, click the "New" button
           and then click on the "Advanced >>" button.
           Enter "DAT" in the "File Extension" field.
           and scroll to select "ldlite Document" for "Associated File Type".
           (If you can't find it go back to step 1)
           Press OK.

   11) Press the "Advanced" button.

   12) If "open" is not listed under "Actions" click the "New" button.
       Otherwise click on "open" and then click "Edit".

   13) In the "Actions" field, enter "open" if it's not already there.
       For "Application...", browse to the location of ldglite.exe
       (or l3glite.exe)

   14) Add any extra command line arguments in the "Application..." field
       Mine says this (I use the l3 parser and a small window):
       C:\projects\ldglite\ldglite -l3 -v3 "%1"

   15) Press enough OK buttons to finish this up.


-----------------------------


Another alternative is to use a .reg file.  I think you can paste
the following into a file called ldglite.reg and run regedit ldglite.reg
to do it all at once.  Of course you have to edit the path to ldglite.exe
below before running regedit.  Is this too much work?  Perhaps I should
include a new program in the zip file to do this stuff?  Any thoughts on
this?

REGEDIT4

[HKEY_CLASSES_ROOT\.dat]
@="ldlite.Document"
"Content Type"="application/x-ldraw"

[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/x-ldraw]
"Extension"=".dat"

[HKEY_CLASSES_ROOT\ldlite.Document]
@="ldlite Document"
"EditFlags"=dword:00000000
"AlwaysShowExt"=""
"BrowserFlags"=dword:00000008

[HKEY_CLASSES_ROOT\ldlite.Document\shell]
@=""

[HKEY_CLASSES_ROOT\ldlite.Document\shell\open]

[HKEY_CLASSES_ROOT\ldlite.Document\shell\open\command]
@="C:\\projects\\ldglite\\ldglite.exe -l3 -v3 \"%1\""

----------------------------------------------------------------------

Argh, it's not just the radeon.  Rendering remotely via GLX from a
RedHat 9 box to XMing on a windows box also has problems with incomplete
updates. Unfortunately I get the Same VENDOR and RENDERER strings
as I get when I render it locally on the windows box, and it works
just fine that way.  Double Argh!!

  GL_VENDOR ='NVIDIA Corporation'
  GL_RENDERER ='Quadro NVS 140M/PCI/SSE2'

Maybe I should default to -n2 or -n4 and force the user to pick -n0
to see the drawing in the front buffer.

In addition, glut doesn't seem to do X pointer motion event compression
when rendering remotely via GLX, so it falls behind on the mouse
dragging.  Is there a glut fn to do that, or do I have to go straight to
X11 fns?  (Like this code from glut itself for expose events)

  /* compress expose events */
  while (XEventsQueued(__glutDisplay, QueuedAfterReading)> 0) {
    XPeekEvent(__glutDisplay, &ahead);
    if (ahead.type != Expose || ahead.xexpose.window != event.xexpose.window)
      break;
    XNextEvent(__glutDisplay, &event);
    }

----------------------------------------------------------------------

Add support for RUBBER and other materials in ldconfig.ldr

Add a command line option for only using NEW colors from ldconfig.ldr
because I like the default ldlite colors and especially the edge
colors better than the official ldraw.org ones.  You know, I could
make this really simple by just importing the NEW colors into 
lcolors.c and doing a new release.

Maybe consider parsing both ldconfig.ldr and ldliterc.dat.  I'm not
sure which should get preference though.  I'm leaning towards giving
preference to ldliterc.dat since ldconfig.ldr is distributed with 
the official parts and is thus less geared towards personal tastes.

----------------------------------------------------------------------

I suppose I should just recognise this GL_RENDERER string and force a
bunch of patch/hacks on it so that I can stand to work on the code
again.  Force the -w1.2, and the -n2 or -n4.  Also add a hack for ledit
mode to copy the screen to the back buffer and change drawing to there
right before running the glutBitMapCharacter() calls for the edit menu.
Hmmm, I've also seen uppercase RADEON 7000 in the GL_RENDERER string
with the same bugs in the driver.  Maybe I should do a case insensitive
check for "radeon 7000".  

I wonder if I can force it to use the Windows software driver, or the
mesa driver.  Either one of those should give acceptable performance 
without the bugs on any PC with a radeon in it.

----------------------------------------------------------------------

I have all sorts of trouble with the ATI Radeon 7000 SDR x86/SSE2 on Win XP.
It has trouble when I draw in the GL_FRONT buffer.  Some of the early 
geometry is just lost.  I can work around this with -n2 or -n4 which
force drawing in the back buffer.  But even with this the antialiasing
has problems.  The early geometry comes out the wrong width unless I
explicitly specify a width greater than 1.0 on the command line (eg -w1.2).

The KTX extensions are available, but cannot be used because
glBufferRegionEnabled() returns 0.  What's that all about?

The text printing via glutBitmapCharacter is godawful slow on this
thing.  It's almost unbearable.  Texture mapped fonts seem ok though.

Here's the opengl info.

GL_VERSION = 1.3.3302 WinXP Release
GL_EXTENSIONS = GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_c
ompression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_com
bine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored
_repeat GL_ARB_transpose_matrix GL_ARB_vertex_blend GL_ARB_window_pos GL_S3_s3tc
 GL_ATI_envmap_bumpmap GL_ATI_texture_mirror_once GL_ATI_vertex_streams GL_ATIX_
texture_env_combine3 GL_ATIX_texture_env_route GL_ATIX_vertex_shader_output_poin
t_size GL_EXT_abgr GL_EXT_bgra GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_ar
ray GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_packed_pixels GL_EXT_poin
t_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specul
ar_color GL_EXT_stencil_wrap GL_EXT_texgen_reflection GL_EXT_texture_env_add GL_
EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_tex
ture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_textur
e_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_vertex
_array GL_HP_occlusion_test GL_KTX_buffer_region GL_NV_texgen_reflection GL_NV_b
lend_square GL_SGI_texture_edge_clamp GL_SGIS_texture_border_clamp GL_SGIS_textu
re_lod GL_SGIS_generate_mipmap GL_SGIS_multitexture GL_WIN_swap_hint WGL_EXT_ext
ensions_string WGL_EXT_swap_control
GL_VENDOR ='ATI Technologies Inc.'
GL_RENDERER ='Radeon 7000 SDR x86/SSE2'
GL_RGBA_BITS: (8, 8, 8, 8)
GL_DEPTH_BITS = 24
GL_STENCIL_BITS = 8
WGL_EXTENSIONS = WGL_ARB_extensions_string WGL_ARB_make_current_read WGL_ARB_pbu
ffer WGL_ARB_render_texture WGL_ARB_pixel_format WGL_EXT_extensions_string WGL_E
XT_swap_control
The WGL_ARB_pbuffer extension is available
The GL_KTX_buffer_region extension is available
The GL_KTX_f1 = 692858E0
The GL_KTX_f2 = 69285900
The GL_KTX_f3 = 69285920
The GL_KTX_f4 = 69285940
The GL_KTX_f5 = 692858C0
glBufferRegionEnabled() = 0
Buffer Swap Mode = 0

----------------------------------------------------------------------
Fix the LEDIT mode File Save command to handle filenames with spaces.
It currently truncates the filename at the first space.  I think it
may also truncate filenames in the file if they don't have quotes.
The l3 parser doesn't handle spaces in the filenames inside an ldraw
file, but it handles them on the command line.  The ldlite parser 
seems to handle both.

----------------------------------------------------------------------
I can't change a type 2 line into a type 1 line in LEDIT mode.  I
think I have to change it to a comment first (type 0).  This
is probably also true for other linetypes.  Fix me.

I should also add a faster way to create new lines, quads, and  tris.
Inserting a part and then changing the linetype is too clumsy.

----------------------------------------------------------------------
When I try to display datfiles\foo.dat ldglite will instead display
%LDRAWDIR%\models\foo.dat if it exists (overriding my explicit path
on the command line).  This is perhaps OK for parts, but for the top 
level file it should look in the specified path first.  Both parsers
have this problem.  I should probably wait for the new Ldraw.ini 
configurable search strategy to happen before fixing this though.

----------------------------------------------------------------------
I should probably make an LSYNTH plugin.

----------------------------------------------------------------------
Fix the LD parser to handle Mac line endings on whatever platform I 
might run it on.  In ldlite.l it seems to do something for [\n] but
treats the chars [ \t\r] as whitespace.  I suppose a cheap hack would
be to treat [\r] the same as [\n] even though that would mean extra
parsing for DOS/Windows files which use \r\n.

Change this:

[ \t\r]		;
[\n]		{yylval.c = "EOL"; return tEOL;}

to this:

[ \t]		;
[\r\n]		{yylval.c = "EOL"; return tEOL;}

Then run lex/yacc, compile, and see what happens.

----------------------------------------------------------------------
Should mklist be available as a plugin?

----------------------------------------------------------------------
I wonder if Drag and Drop could be implemented in a wrapper app on
OSX which sends a ctrl-v to the app and then passes the data in
some way compatible with GLUT.  The same wrapper app could pass in
default commandline args.  (Or I could use an LDGLITEARGS env var)

Or maybe I can register an event handler (category method in cocoa?)
after GLUT does, and filter out Drop (open document?) events before 
passing things on to GLUT.

----------------------------------------------------------------------
Hey, for antialiased lines perhaps I could use a depth test of 
GL_LEQUAL to allow edge lines from adjacent quads to blend with
each other instead of just randomly letting one supercede the other.

----------------------------------------------------------------------
Now that I've expanded the glut menus beyond the 255 choices allowed
in the glut keyboard callback, perhaps I can add more image output
choices than just bitmap.  Maybe a whole picture submenu.

How about a spinmode submenu?  What else in the menus can be fixed now?

Make more nested submenus off of View menu:
View/Zoom (in(+), out(-), enlarge, reduce)
View/FOV submenu = (+1, -1, +10, -10)

----------------------------------------------------------------------
Reread Karim's Artemis project pages and see how ldglite fits into
that particular vision now that it supports plugins and all.

----------------------------------------------------------------------
Add a wrapper around the keyboard() fn and convert the key to an int
so I can use high numbers for things that come from the menus and not
via the GLUT keyboard callback.

----------------------------------------------------------------------
Test ~/foo.dat in the MUI open file dialog in linux (and OSX).

----------------------------------------------------------------------
Remember to strip and UPX any Windows Executables for distribution.

----------------------------------------------------------------------
Make some way to register ldglite since win2k and winXP do not allow
creation of new MIME types via explorer.  Either do something like
ldglite -reg or distribute a ldglite.reg file with instructions on how 
to set the directory path of the executable. 

Oh, Oh, I know.  This could be a plugin.  The registerme plugin.
That way I can distribute it with the windows binary only, and it'll
already know what directory the executable is installed in.  And it
should also know the name of the executable to register.  However it
should provide a GUI to change it, and add command line arguments.
This could get really fancy and incorporate the ldrawinfotip DLL and
registry settings.  Would this be useful to the lddp folks?

Hmm, maybe it could also create or add the ldraw.ini setting for 
the LDRAWDIR if it can't find it.

Hey, I wonder if that OSX bundle junk can be used to register the .LDR
extension on a Mac to make it launch ldglite on a .LDR file by clicking
on the file.

----------------------------------------------------------------------
Make an OSX bundle directory structure for ldglite with contents,
info.plist, icon etc so It can be launched by clicking on it.

Note that GLUT is a separate framework, and will chdir to the
Resources folder of your application bundle on glutInit! If you don't
want this to happen, the easiest way is to
getcwd(...);glutInit(...);chdir(...);. There is a command line
argument flag that you may pass to it, but I think getcwd/chdir is
easier than stuffing an extra flag into the argv.

----------------------------------------------------------------------
Consider rewriting all the the code that writes to GL_FRONT to write
to GL_BACK instead.  It's much, much faster on many systems, and less
buggy on OSX (with it's weird BACK buffer trickery).

----------------------------------------------------------------------
The MUI menu is a real CPU hog on slow systems like the 486.  Does it
have an Idle function.  If not, where can I put it to sleep?

----------------------------------------------------------------------
Add a fn to highlight (in dark red) the first char of each LEDIT menu
line and every char that follows a space char.  This would be a nice
hint about the menu keyboard accelerators.  If it's easier, I could
code up the menu strings with embedded & chars and replace them with
the color hints.

----------------------------------------------------------------------
Add an option to the LEDIT menu to hide it when not in use to maximize
screen space for the model and to minimize the annoyance of the flashing
menu when I'm not really looking at it.  I think it's just a matter of
checking that the first char of the command is a null.  This would fit
as "Hide" on either the main menu, or the options ment.

----------------------------------------------------------------------
Add mklist to the makefile, or at least make instructions for how to
build it.  Include mklist, glut dlls, plugins, and readme.txt in any
binary distributions from now on.

----------------------------------------------------------------------
Think about allowing both the MUI and GLUT menus.  Maybe launch the 
MUI GUI from the GLUT menu?  If so, fix up the stinky glut menu a bit
and make the File Open part of the glut menu an optional compilation

----------------------------------------------------------------------
Figure out another way to highlight a part in Mesa.  It's painfully 
slow to draw the XOR wireframe, at least it is on the PII-266 I tested
it on.  It was still slow, even with the stencil buffer turned off.
Moving parts in SOLID mode was quite reasonable though.  This might 
also be handy for Apple and TNT displays which have trouble with the
stencil buffer and thus have trouble with the double XOR from certain
view points.  

An unblended magic halo may work for Mesa (and all the others).  

MLCAD draws a rectangle around the part in the front, side, and top
views, and does nothing in the 3D views.  Perhaps I could adapt this
to fit my single view.  If it's a side view, use a rectangle.  For
Mesa, also use a Wire Box for any other view.  This may be fast
enough and obvious enough to work.

----------------------------------------------------------------------
Make a portable lddp style plugin.  For example, make a minifig
modeller in GLUI (or something else that's easy to learn and portable
to everything including OSX).  Attempt to build a plugin out of it.
Use the INI file from the LDDP plugin, and borrow the layout except
put the Fig preview between the left/right options (sorta like
leocad).  Since it's a plugin, I guess C++ and Non-opengl toolkits
like FLTK or wxwindows are OK as long as they work on all platforms.

OpenGL GUI toolkit choices include GLUI, MUI, PLIB/p-guide, GLOW, 
NGL/NUI, LibUFO/UGT, glgooey, ...

----------------------------------------------------------------------

In the part lookup, how about if the last part you looked up is
automatically selected each time you open the lookup menu, so that you
can quickly get to nearby pieces in the list? Since a lot of pieces
are grouped together (all the plates, all the minifig parts, etc) this
would speed things up if you were working on something that made heavy
use of a certain type of part (and would have no impact otherwise).

Also: how hard would it be to implement a new ledit command for
creating a new part, that would simply create a blank part (or
something basic like 3001) and go directly to the part selection
prompt? Basically, so that you could insert a new piece without
duplicating whatever the presently selected one, and to cut the number
of keystrokes in half (from "i" "p" to whatever the create-new-part
key is). The only reason the current insert method is ever a problem
(usually its good), is if its a complicated piece, or even worse an
entire sub-model, which would be duplicated before letting you specify
what new part it should be.

What if I leave the current LEDIT compatible method alone and
implement a new command that combines these two ideas into a new
speedy insert command?  If I can't find a suitable key I suppose I
could use capital "I".  I wonder if "n" is available.

----------------------------------------------------------------------
Figure out how to display stud logos so they're never mirrored.
Multiply the transformation matrix for each stud by it's determinant.
Or traverse Parts[0..nParts] looking for PartPtr->FromPARTS.  Then
traverse its subparts looking for PartPtr->IsStud with a negative
determinant.  Perhaps duplicate the part and mirror the bad studs.
Use Paul Easter's logo studs to test this.

----------------------------------------------------------------------
Make lddp plugins work with ldglite.  They should use the same sort
of code to select a plugin as the PARTS.LST lookup with one plugin
per line and searching for plugin names allowed.  

Figure out how to deal with plugins that require a selection.  It
might be nice to have a hint as to how many lines they require.  Maybe
I should code specific selections for known plugins, or just ask how
many previous (and/or subsequent) lines to include in the selection.

Make a plugin wrapper around Paul Easter's spring generator program?

----------------------------------------------------------------------

Add a parts.lst lookup.  This could use the current 4 line display to
show a search string and 3 lines from parts.lst.  Start the lookup on
'?' key.  End lookup with ESC or ENTER.  Show one red line and use the
code that displays the selected part to display the part on the red
line.  (We should already be in Part Lookup mode with a selected part
when the search is started.)  Read the entire parts.lst file into
memory the first time the '?' key is pressed.  Allow searching (like
ldlist) in the part list.  PGUP and PGDN should do something, as
should the UP and DOWN arrows.

----------------------------------------------------------------------

Add cmdline arg that prints cmdline usage message.  (-h -? --help)
Use the same help message in scrolling window in MUI GUI.

----------------------------------------------------------------------

Add some sort of wildcard option to -MSfilename.out to allow adding
step numbers to the suggested filename.  (FIXED: 05/??/03 use '#')

Fix it to work with twirl.  (Actually offscreen doesn't do twirl yet)

----------------------------------------------------------------------

Fix crash when you press an arrow key in LEDIT mode with no .DAT file
loaded yet.  (FIXED: 06/09/03)

----------------------------------------------------------------------

Add more MPD support to LEDIT mode.  Perhaps add a command to split 
off part of a file as MPD.  Or a command to start a new MPD section
with a filename.  Add a command to jump into the MPD parts and back
into the main file.  I think I already added support for saving the 
file as an MPD if it was one when I read it in.  This should be 
enhanced to save a newly MPDed file.  

The inliner can already be used to pull MPD content into the main 
file.  However it doesn't remove the MPD part, nor should it because
the MPD part may be used multiple times.  

The MPD splitter could split off from the current part to the end of
the file (or to a 0 ENDMPD marker comment, whichever comes first).
The splitter will also have to restructure the main file a bit if it
wasn't MPD already.  Don't forget to set the Parts[i].IsMPD flags.

I think I could allow editing inside the MPD portions by replacing
Parts[0] everywhere in L3Edit.c with a FirstPartPtr which is set to
point to Parts[n].  I could find my way to the MPD files by number
or by searching Parts[n] for the IsMPD flag and then comparing the 
name.

----------------------------------------------------------------------

Convert from Glut to SDL?  SDL seems to be available on ALL platforms
except perhaps MSDOS (and who cares about that anyhow).  It has better
keyboard support so I can get keystrokes while the mouse button is 
down (unlike in glut).  This should make the quake/freespace camera
code easier to create.  Maybe I should start with the SDUT code which
emulates parts of glut on SDL.  The only sticky point is the license
on the MUI gui code.  It should run on SDL since I don't use the
glut pulldown menus, but it does need the few small patches from the
base MUI source to prevent the crash problem and allow the scissor
function.  Maybe if I make a MUI patch and run the patch as part of
the makefile it'll solve the any license issues.

----------------------------------------------------------------------

Convert offscreen rendering functions into shared library/DLL 
functions.  Add entries to the makefile for DLL targets using
dlltool and and the like.  Probably need to compile special versions
of main.c and ldglpr.c for this.

----------------------------------------------------------------------

Also need to create instructions and a makefile for building a
staticly linked, offscreen only executable for headless servers using
OSMesa.  This should include a makefile that doesn't need any X,
Windows, AGL, or other libraries that assume you have a screen.

----------------------------------------------------------------------

Implement some sort of part spreading algorithm for drag and drop
of multiple parts.  I'm thinking some sort of fractal spiral would
look nice.

----------------------------------------------------------------------

Implement drag and drop for unix (and MacOs?) so they can at least 
pull in peeron style inventory lists, parts from an emacs window, 
and perhaps the HTML version of the printable parts catalog.

----------------------------------------------------------------------

Incorporate Andrews MacLdraw parser and it's nice premade display 
list parts.

----------------------------------------------------------------------

Finish up the MUI menus or replace them with something better.

----------------------------------------------------------------------

Come up with a texture mapped font (built into the executable) for
speed with hardware opengl and for the DOS version.  Investigate
glfont and the font code in freeglut.  Ldview now uses an internal
texture mapped font.  Consider borrowing this code.

----------------------------------------------------------------------

Add bezier/hoser code to LEDIT mode. 

----------------------------------------------------------------------

Document disabling the Alpha blended cursor on Win2k for laptops
and other computers without the hardware to keep up with that silly
piece of eye candy.

----------------------------------------------------------------------

Fix 2 pass rendering -q to work with things like 0 CLEAR.  This needs
work for both on and offscreen rendering.

----------------------------------------------------------------------

Implement the normal fixing curve smoothing algorithm based on 
type 5 lines, or the alternative algorithm that looks for the
lack of type 2 edge lines.

----------------------------------------------------------------------

Implement type 5 silhouette lines as a reverse BFC wireframe of 
the shaded polys.  This algorithm has the advantage that it can 
be done *inside* a display list.  Thus it should be much faster.

----------------------------------------------------------------------

Implement a display list for each part.

----------------------------------------------------------------------

Document ALL of the command line args, including the ldlite and LDRAW
args.

----------------------------------------------------------------------

Unify the VIEW code.  (Ortho/Perspective/LDRAW3D)  Pull any view 
xformation info out of the LDRAW -A view/model matrix.  How does
-A and -J on the command line work?  Should it be an error if -A
introduces a view transformation style shear element?  Should I 
keep the rotation, but toss the shearing?

Maybe the default view should be LdrawOrtho, -j ortho, -J perspective.

How about keeping the shear and applying it before glOrtho()...

void reshape (int w, int h)
{
// Oblique Projection
//{1,0,-cot20,0, 0,1,-cot10,0, 0,0,1,0, 0,0,0,0};
//float shear[16]={1,0,87.14,0, 0,1,84.29,0, 0,0,1,0, 0,0,0,0};
float shear[16]={1,0,87.14,0, 0,1,84.29,0, 0,0,1,0, 0,0,0,1};

glViewport (0, 0, (GLsizei) w, (GLsizei) h); 
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
glMultMatrixf(shear); 
glOrtho (-1.0, 1.0, -1.0, 1.0, 1.5, 20.0);
glMatrixMode (GL_MODELVIEW);
}

Can I just apply the LDRAW command line matrix this way?

----------------------------------------------------------------------

Finish off the Quake/Freespace style camera movement.  Consider using
the same key combo/visual cues as ldview to make things easier on
folks who might use both.

Paraphrased from the ldview help.html file:

--------Examine Mode------------

Left Mouse rotates the model.  (Same)
Ctrl Left pans (different from l3lab and ldglite)
Right Mouse zooms (different, and non-negotiable.  ldglite menu)
(Middle button is mouse wheel in windows glut patch)
Mouse Wheel zooms 
(glut seems to ignore wheel spin, press it gets a middle btn paste, yuk!)
Ctrl Right moves clip plane (different)

--------Fly-through Mode--------

Left Mouse turns the camera look at point.  
(I could use Ctrl-Shift left mouse for this.  Like ctrl-shift-arrows)
(Switch solid rotate to Alt-Lmouse)
(Switch shift LeftMouse to pan?  Consistent with arrow keys)
(Switch Ctrl LeftMouse to pan? not consistent with ldglite CTRL)

The camera can be moved using the keyboard.  Shift doubles the speed.
(I could avoid conflicts by using CTRL with these, since CTRL means camera
in ldglite) 

Camera Movement 	Key 
Forward:  		W 
Backward:  		S 
Left:  			A 
Right:  		D 
Up:  			R 
Down:  			F                                                                         
Camera Rotation		Key 
Rotate Clockwise:  	E 
Rotate Counter-Clockwise:  Q 


----------------------------------------------------------------------

Fix the POV camera dump code to write it to a file

----------------------------------------------------------------------

Fix the POV camera dump code to work with the projection

----------------------------------------------------------------------

Document what's in the various source files.  Here's a first pass
at it.

main.c contains most of the GLUT code.  It starts the app and runs
the event loop.  It also contains some platform specific hooks and 
manages the view transform, lighting, etc.

stub.c contains most of the opengl drawing calls.  Look at the
functions that begin with render_ to see how it draws each of the
5 LDRAW linetypes.

L3*.cpp implement the l3 parser from l3p and l3lab.

lex.yy.c and y.tab.c implement the ldlite parser.  They're generated
from lex sources (ldlite.l and ldlite.y?) and are almost unreadable
because of that.  I do most of my work with the l3 parser.  The .CPP
files that don't begin with L3* are the Windows MFC code from ldlite
and are not used ldglite.

l3edit.c my hack on the l3 parser and data structures to implement the
LEDIT emulation mode in ldglite.  It's not particularly well written
and the LEDIT keyboard command parsing routines in main.c that support
it are especially hideous.

ldglpr.c is my image file printing routines.

platform.c contains some platform specific functions.  Probably some
more functions from main.c should be in here.

dirscan.c contains the code used to search directories for the 
really cheesy GLUT menu file lookup.

ldglgui contains a MUI version of the GLUT menus.  It's got a slightly
better file browser dialog, and radio buttons for the drawing options
but I still don't really like it much.

Overall my coding strategy is to make it portable, but not necessarily
fast.  For example, there is some experimental code in main.c to use
a single large display list for the model, but because of problems
with type 5 lines and the default LDRAW view matrix I abandoned it
until sometime in the future.  Also because the ldlite parser doesn't 
build a data structure, the individual quads, triangles, and lines
are all passed to opengl one at a time.  I'd like to change this to
be more efficient, but I've been putting it off since I don't have
good hardware.  Ldglite could also use some sort of occlusion culling
to eliminate all the unseen studs.  It uses two sided lighting which
supposedly slows down some hardware to a crawl.

----------------------------------------------------------------------

From: James Reynolds

In using ldglite (on Mac OS X), I have noticed a few issues, mainly 
with the keys.

First, I don't think your webpage has been updated to show the 
changed hotkeys (the changes that occurred when you added LEdit 
emulation).   PGUP and PGDN and arrow keys are now used by LEdit.

Second, many of the keys don't work on the Macintosh.

For example, there is no INSERT key, so toggling LEdit emulation doesn't work.

I don't believe the BMP or PNG works.

V doesn't work.

I don't know what g does, so I couldn't tell.

+ and - are a bit of a mystery (_ and = seem to do the same thing...?)

Alt and Cntr arrow keys do not work (LEdit receives the commands as 
"move the piece"..).

Ctrl mouse drag doesn't work (but shift mouse drag does).

1-button mice don't do the right button stuff (usually on the Mac, 
cntr-click acts as the right button--this may explain why ctrl mouse 
drag doesn't work too).

2-button mouse (supported by Mac OS X) don't work either.

F10 and F9 don't work.

Anyway, I don't know if you have time to look at it much.  I was 
thinking you could have a text configuration file that could easily 
be modified to set to commands keys.

----------------------------------------------------------------------

In lugnet.cad, Steve Bliss writes:
> ..they're batched up currently, I write a file like:
> 1 0 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
> 0 STEP
> 0 CLEAR
> 1 0 0 0 0 1 0 0 0 1 0 0 0 1 3002.dat
> 0 STEP
> 0 CLEAR
> ...
> and put 100 parts through LDLite at one system call.

Ouch, I just tried this in ldglite with the following command

  ldglite foo.ldr -s3 -w3 -MS -q

and found not one, but 4 different bugs I have to fix.

1.  I need to increase the calculated image extents by the half
the linewidth to get all of the wide lines at the edges of the
saved cropped image files.

2.  I need to reset the image extents after a 0 CLEAR so the
second image is cropped correctly.

3.  I need to fix a bug with the -q switch.  When you use -q the
image after the 0 CLEAR shows only the nice antialiased lines.
(Something else to reset after a 0 CLEAR).  It works ok if you
skip the -q though.

4.  It put the bitmap files in the right directory, but it named
them foo1.bmp and foo2.bmp instead of foo---01.bmp and foo---02.bmp
like ldlite.  Not sure if I should really call this a bug, but
it might break any scripts you've wrapped around ldlite.

----------------------------------------------------------------------

In lugnet.cad.dev, Jeremy H. Sproat writes:
>Okay, this is a quick and dirty list, just what I've observed or confirmed
>today:
>
>Menu - The right-click menu is very confusing.  Why not put this in the menu
>bar and standard dialog boxes?  File browser is confusing, as is file filter.
>
>Menu - File browser skips files, I can't load my file if it falls within the
>last three slots in browser submenu.  I had to delete files from my
>LDRAW\MODELS directory before I could see my test file.

Yeah I've known about the problems with the menu for quite a while now.
I refuse to go to a 1.0 release number until I fix that.  However since
I'm running out of release numbers I've actually started to do something
about it.  Could you give me some feedback on the experimental menu
(still right click) in this recently escaped beta version of ldglite?

  http://news.lugnet.com/cad/?n=8490

I really wish someone would create some nice control widgets written
in C (not C++) that use opengl for all the drawing.  This would meet
my portability goals for ldglite.  But I've been waiting a long time
and it just isn't happening.  It looks like I'm gonna have to do it
myself.  Rats! 

>Window - Program starts with window bounds matching screen resolution; I'm
>missing the title bar due to my task bar.  Why not start at a smaller size,
>or have it remember window size between sessions?

I've gotten into the habbit of always putting a -v3 on the command line
because that's the size I like.  I even put it into the registry for 
when I load a file straight from lugnet.  But I did that manually 
because I don't want to put unportable registry code in ldglite.  I
suppose I could invent a new LDRAW meta-command for this and stick
it in the ldliterc.dat file.  But then I'd have to come up with a
license for the meta-command.  ;)

>Command-line Option - option -Bn doesn't work, bg always 15 (white).

Hey, you're right.  I wonder when I broke that.  I think it used
to work at one point.

>LEdit Mode Toggle - Why not put this in the menu?

That's a good idea, and an easy one too.  Thanks.

>Input Keys - ALT-F4 doesn't close the window.

That's an easy one, but is it any sort of standard beyond windows?
CUA perhaps?  Could you point me to a page where this is documented?
I'm guessing that pressing that key combo generates some Windows
message that's ignored by the glut library.  If so, I could catch it
myself in the ldglite keyboard handler when running on a Windows
platform, or everywhere if it's a standard in wide use.

>Redraw - Clears screen during redraw for any small reason - a tooltip from
>the task bar triggers this, sometimes a mouse movement will.  When this
>happens, after waiting for the redraw, it redraws again from the beginning.
>Can become an endless cycle in some circumstances.  Must kill program from
>task manager.
>
>Redraw - Won't restart redraw in middle of redraw, must wait until it's
>finished.  You can't input a command during a redraw.
>
>LEdit Mode - OpenGL text takes too long to redraw, why not use native font,
>or a subwindow that doesn't need to redraw constantly?

>> Do you have any numbers to back that up?
>
>I stand corrected.  LDGLite renders faster than LEdit on my box.
>
>I'm running on an AMD K6-500 with 192 Mb RAM, 1024x768x24.  In LEdit, my
>test file took 43 seconds; in LDGLite, 17 seconds (per redraw).  I note that
>it took 4 redraws in LDGLite before I could do anything, though, so it
>really took more than a minute before I could do anything with it.

Ah, Now we're getting to the speed issue.  It looks like it's not
actually the redraw speed, but the response time that's the issue.
LEdit scores high in this area.  It's quite good at responding
to key strokes right away and then fixing the rest of the display
later.  The glut Opengl library expects the redraw times to be in 
frames per second and not seconds per frame so it's not designed 
to be interruptable by keystrokes.  That makes this one a tough
problem to solve.  I can either break up the display loop somehow,
or figure out a way to make it redraw so fast I don't need to 
worry about it.

----------------------------------------------------------------------

I did some work on the other solution, rendering in the background.
Use -n2 to render each part in the backbuffer, -n4 does the whole
model.  Also the backbuffer is retained for faster refreshes on window
expose events.  I haven't gotten this to work in LEDIT mode yet
though.  

I also fixed the -b<color> bug.

>I like the L3P-like camera command-line options, except they don't seem to
>work.  Specifically, I'm using -cgx,y,z (is that x,y,z or lat,long,dist?)
>and -cox,y,z -- no matter what values I give the -cg the view never changes
>(or changes just slightly?)  This happens both with and without a -a option.
>Similarly, the -co doesn't seem to be moving the model origin.  Tested with
>both the release version and the "silver beta" version.

What's -cg?  I'm gonna assume you mean -ccX,Y,Z.  Anyhow, it's been a 
while, but I think it's X,Y,Z in opengl world coordinates (Which I think
are like ldraw world coords except the Y direction is reversed)  Some 
effects like distance from the camera aren't visible in orthographic
mode.  Try -J for perspective mode.  I think the default camera position
is 0,0,1000 so using -cc0,500,1000 will be looking at the model more
from above.  Using -cc0,250,500 will be looking from the same angle,
but closer in perspective mode.

I'm currently reworking much of the camera code while working on the
quake style navigation for moving and aiming the camera interactivly.

  http://news.lugnet.com/cad/dev/?n=7515

So now's the time to make suggestions.  You can get a sample of where
I'm going (but with a bad choice of keys) by holding ctrl-alt and left
mouse button and then wandering around the model on the latest beta.
Make sure you're in perspective mode first.  Oh yeah, the new menu
has a setting in the VIEW panel for FOV angle if you want to play
with that.  Hmm, I wonder how I could do that visually with the mouse...

>When you start up the window, is it possible to place it centered on-screen?
>It always comes up with the upper-left at 0,0 on my monitor, which places
>its title bar smack-dab underneath my task bar.  Right-clicking on its
>taskbar entry to get to the "Move" menu item is tricky, due to the tooltip
>causing the redraw.  :-,

Where's your task bar, at the top of the screen?  What are you some
kind of nut?  ;-)  I'll see what I can do, but I'm running out of
letters to use on the command line, and I don't think I can predict
where the task bar (or docking station or whatever) is gonna be.  I
don't particularly like the window popping up in the exact top left
corner either, but I think defaulting to the center of the screen
would irritate me even more.  How about something like +200,100
on the command line?  Give that a try in the beta version.

>I really like the -q option -- especially when I can catch it in mid-draw so
>that it clears the screen just when it starts drawing the line edges.  This
>is a nifty effect -- how about an option to draw *just* the line edges?

Use -fw for that.  That's an old ldlite option so it may not be in the
readme.txt file.  I guess I should add a section in the readme file
that covers all the ldlite compatible commandline options.

>That's all I have tonight.  Playing with the -fh, -W and -q settings, and
>the rendering is just gorgeous.  Wish I could position the camera quickly.

Feel free to tell me more about how you want it to work, both
interactivly and on the command line.

Don

----------------------------------------------------------------------

Sproat's wish list:

- L3View.cpp, function DrawPart()
   - linetype 3 and 4 render in constant color (can be bg color) 
   -- see render_triangle() in switch (LinePtr->LineType) case 3 
   -- see render_quad()in switch (LinePtr->LineType) case 4
   - color 24 can be same as color 16 
   -- see switch (LinePtr->Color)
   - amaze your CAD friends with tron-like graphics, among other things!  
   -- see http://www.sproat.us/l3glite-tron.png

- jitter in render_line, may cause sketch effects! 
  -- see http://www.sproat.us/l3glite-sketch.png
    - number of jitter lines, from 0+
    - endpoint jitter factor
    - random number seed

----------------------------------------------------------------------
