aboutsummaryrefslogtreecommitdiff
path: root/packages/noncvs/windows/extra/Gem/gem.release_notes.txt
diff options
context:
space:
mode:
Diffstat (limited to 'packages/noncvs/windows/extra/Gem/gem.release_notes.txt')
-rw-r--r--packages/noncvs/windows/extra/Gem/gem.release_notes.txt2036
1 files changed, 1018 insertions, 1018 deletions
diff --git a/packages/noncvs/windows/extra/Gem/gem.release_notes.txt b/packages/noncvs/windows/extra/Gem/gem.release_notes.txt
index e7b53ea5..5c0126db 100644
--- a/packages/noncvs/windows/extra/Gem/gem.release_notes.txt
+++ b/packages/noncvs/windows/extra/Gem/gem.release_notes.txt
@@ -1,1018 +1,1018 @@
-GEM ONLINE DOCUMENTATION CHAPTER 5: RELEASE NOTES
-
----------------------------------------------------------------
----------------------------- 0.91 -----------------------------
-this is the first release for 3 years, codename 'tigital'
-it includes many changes, so probably i have forgotten most...
-
-openGL runtime checks: GEM now uses GLEW to detect openGL-features
- at runtime this allows you to use all the cool features of
- your brand-new graphics card with the same binary as you
- used for your old gfx-card...cool
-
-w32-installer: there is now a w32 installer (based on NSIS) to
- ease the installation of GEM on windows.
-
-single vs dual context: GEM uses a dual context approach to establish
- a valid openGL-context at startup;
- you can now turn this OFF by setting the environmental
- variable "GEM_SINGLE_CONTEXT=1"
- this should allow you to work if GEM crashes otherwise
-
-SIMD: better MMX/SSE2 handling
-
-pixes: fiducial tracking, artoolkit,
- multitexture, texture sharing
- recording streams of images into movies,
- better movie reading support, better video in support,
- more sophisticated pix_buffer handling
- shared memory objects
-
-text: allow unicode characters
- use vera.ttf as default font instead of the
- copyrighted arial.ttf
- allow to override the default font with the environment
- variable "GEM_DEFAULT_FONT"
-
-
-bugfixes: like always we have removed (and introduced) numerous
- bugs, so all in all GEM should now run more stable
- for an incomplete list of fixed bug see the bug-tracker
- at http://sourceforge.net/projects/pd-gem
-
-openGL: generally use openGL-2.0 (if available)
- vertex/fragment shaders (GLSL and ARB/NV)
- framebuffers
-
-
-deletion:
- MarkEX has been removed from GEM and is now available as
- a separate library;
- hardware-interfacing objects like [gemorb] and [gemtablet]
- have been removed
-
-
-
-
----------------------------- 0.90 -----------------------------
-this is the same as 0.888
-just a naming issue
-
----------------------------------------------------------------
----------------------------- 0.888 ----------------------------
-
-this has taken a long time (2 years...)
-
-development is now done by several people:
- chris clepper
- günter geiger
- daniel heckenberg
- james tittle
- IOhannes m zmölnig <zmoelnig@iem.at>
-günter has removed himself from the splash-screen, but he still contributes stuff
-
-supported platforms: windows (XP,2000,...), linux, and (tadah:) macOS-X(>10.2)
-irix-support seems to be broken, but i cannot prove it
-
-architecture: up till now, the rendering-tree was statically built when rendering was
- turned on, so you couldn't add objects dynamically and editing was painful.
- now, Gem utilizes the normal pd-messaging system all the time: you can disable
- parts of the rendering tree with [spigot], render sub-trees multiple times with
- [t a a] and put objects into the gem-tree on the fly.
-
-documentation: added help for (almost ?) all Gem-objects (excluding openGL-wrappers)
- new reference-patches are now working out of the box (not the old "abstract" way)
- added a small pdf-tutorial
-
-
-openGL: GEM features now a full openGL-wrapper (supporting openGL-1.2)
- you can use any openGL-command like "glNormal3f" by creating a pd-object like
- [GEMglNormal3f] (note the "GEM"-prefix); this should be very powerful,
- however most of the objects are not (yet) tested.
- if you intend to use them and think they don't work,
- send me a bug report for the objects you need;
- i will try to fix them gradually.
- there will be not much help in GEM, since you might consult any openGL-reference
-
-text: we now use FTGL instead of GLTT (which is still available at compile time)
- for freetype-rendering. this is supported on all 3 platforms,
- looks better (at all sizes!) and allows the new [textextruded]
-
-geos: tube, curve3d, rubber, ripple, slideSquares, newWave
-
-manips: polygon_smooth for anti-aliasing of single objects
- [camera]
-
-controls: the output of [gemmouse] can now be normalized (by giving the maxVal for x/y as
- arguments: [gemmouse 1 1] will output coordinates between 0..1, no matter what
- dimensions the screen has.
-
-particles: now the underlying libparticle-engine can be used more directly.
- velocity-domains (like [part_velcone]) are deprecated and [part_velocity]
- should be used instead (allowing on-the-fly domain-switching)
- there are objects that allow to influence single particles
- (like [part_vertex])
- most interesting: with [part_render] and [part_info] you can now use any
- geo as particles (e.g: .obj-models) not only points/lines as before.
-
-texturing: [pix_texture] and [pix_texture2] has merged. so [pix_texture] will texture
- textures of any size (even non-power-of-2) and it will use hw-support if available
- (at least on macOS and on linux if the gfx-card supports it
- (at least nvidia does so))
-
-pixes: lots of new objects (too much to enumerate them here)
- we now support 3 different colorspaces: RGBA, YUV, Greyscale
- YUV is new and allows processing of coloured-images with far less memory/CPU
- than RGBA (factor 2) but without alpha.
- lots of pix-processing on apple-computers is ALTIVEC-enhanced (faster by numbers!)
- SIMD-enhancements for PCs (MMX/SSE2) is yet to come...
- as the new colorspace has been pushed, also a lot of objects has received
- greyscale-support
- the TV-class has been deprecated and is now part of pix_* again
- lot's of color-space converters (most of them not available as objects)
- the "pix_fx"-stuff is now built into all pix-objects
-
-video: on mac-OS the [pix_video] object supports all cameras that are supported by the OS
- on windows there is now support for DirectShow,
- which makes new (usb/ieee1394) cameras work most probably
- on linux there is some prelaminary(!) support for ieee1394 devices.
- the v4l-support is now multi-threaded which speeds up the whole thing significantly
-
-film-formats:
- windows: AVI; there is also some QUICKTIME-support
- (needs the quicktime-sdk at compile time and quicktime installed on execution time),
- but this crashes sometimes (haven't found out when).
- it should enable "a lot" of file-formats (MPEG, MOV)
- macOS: quicktime serves your needs
- linux: support for libavifile, libmpeg3 (or libmpeg1 but libmpeg3 is preferred),
- libquicktime (or libquicktime4linux; doesn't matter) and ffmpeg.
-
-codecs: macOS: everything that is supported by your system should work fine
- win: all codecs installed on your machine should work
- (if another program can play a avi-file, Gem should be able to do so too)
- linux: depends on how you compiled Gem. libmpegX will decode mpegs,
- libquicktime will (most likely) decode quicktime-files with non-proprietary codecs,
- libavifile decodes a lot of formats (avi, quicktime, divx, asf,...)
- and you can utilize windows-codecs (.dll-files; if you have them ;-))
- which enables you to play-back proprietary codecs!
-
-bug-fixes: probably lots of, but most of them seem to linger around for a while now.
-
-
-
----------------------------------------------------------------
----------------------------- 0.87 -----------------------------
-Added much documentation
-
-Added [gemkeyboard] and [gemkeyname] for keyboard-interaction in the GEM-window. However, Windows and Linux versions do not give the same results...
-
-Added Red/Green stereo
-Cleaned up the stereo-thing. we can switch between the different stereo-modes (including no-stereo) while rendering
-
-You can set the title of the GEM-window with the "title"-message. Up till now only one symbol is allowed.
-Added "fullscreen" mode
-Fixed "border" under linux
-"cursor" is now available on Windoze
-
-readded "externals" with additional libraries to close up with the windows version::
-Added pix_movie for Linux (mpeg2+quicktime-support)
-Added pix_film, which is in fact like pix_movie but does not write the pix-buf directly into a texture
-Fixed the model
-Added the stupid "teapot"
-Added a pix_write that let's you capture the current screen into a file (TIFF/JPEG)
-Added pix_hsv2rgb, pix_rgb2hsv (colour-space converters)
-Added pix_blob (center of gravity:: colour detection)
-Added pix_curves, pix_histo
-Added pix_set, pix_dump
-Added pix_pix2sig~, pix_sig2pix~
-
-Started a new class "tv" for pix-operations that change over time: like tv_movement (formerly: pix_movement), tv_biquad, tv_rtx; but i am not really happy with this...
-
-Started a new pix_fx class for inserting pix-FX. there is not much about it, but you can now bend the image.data pointer to wherever you like (including size-changes, format-changes) it will be bent back in the postrender()-thing
-
-Started to import classes from effecTV (by Fukuchi Kentarou): pix_aging, pix_puzzle; most of his FX are real crap, but some are ok and it's easy to import them
-Made a pix_rgba
-
-
----------------------------------------------------------------
----------------------------0.84-5 -----------------------------
-Bugfixes for gemwin "cursor" message (cursor [1|0])
-Removed "externals" with additional libraries, they are separated now
-Added a "freq" and "mode" message to Linux video object, you can watch
- TV now ...
-It is possible to add the display to the create command for X windows,
- whole initialization stuff is moved into the create method,
- so you can look at the patches without having succesfully generated
- an OpenGl context.
-Made the pix_video and pix_movie into real base classes of OS specific
- classes. The OS spezific classes for Windows and SGI have to be fixed ..
-
-
----------------------------------------------------------------
---------------------------0.84a -----------------------------
-text2d: added a message "alias", which toggles between antialiases
- and standard fonts. Usage "alias 1" or "alias 0"
-
-gemwin: additional message cursor, which hides the cursor in
- GEM windows
-
-
-
-
----------------------------------------------------------------
----------------------------- 0.84 -----------------------------
-Fixed a bug where delete [] was called instead of delete. This
-could explain a lot of random crashes.
-
-Fixed camera message routing.
-
----------------------------------------------------------------
----------------------------- 0.84 -----------------------------
-I long time ago, I changed the behavior for gemhead, so that
-matrices where automatically restored, etc. However, this
-broke the camera object. Use the view message to gemwin
-instead.
-
-Fixed a bug in GemMan. If you didn't use "border 0" and you
-requested a window size with "dimen # #", then the window
-size was likely to be wrong. This is now fixed.
-
-Fixed a bug in the view message to gemwin. There was an offset
-which should not have occured. You might need to change your
-view messages to account for it. Just subtract 4 from any
-Z values.
-
-There are some examples for pix_snap in
- examples/gemAdvanced/gemPixSnap.pd - Single buffered example
- examples/gemAdvanced/gemPixSnap2.pd - Double buffered example
-Keep in mind that pix_snap is a fairly slow operation...I also fixed
-a nasty memory bug which could easily cause crashes.
-
-I added Miller Puckette's pix_video for linux into the
-code base.
-
-If you load a movie in pix_movie with an open message, the
-object will output the number of frames to the right output. This
-will not work if you have a "pix_movie homer.avi" for your object
-since the output message cannot get processed correctly at
-startup.
-
-The disk object has an inlet on the rightmost side for the
-inner radius...turning the disk into a ring. If the inner
-radius value is just 0., then the disk is just a circle.
-
-Fog can be turned on in gemwin. Look at
- examples/gemAdvanced/gemFog.pd
-for examples. The various control messages are documented
-in the gemwin.pd help patch.
-
-These next objects are thanks to hannes - mailto:zmoelnig@iem.mhsg.ac.at
----------------------------
-Added OpenGL material objects -
- ambient, ambientRGB, diffuse, diffuseRGB, emission,
- emissionRGB, shininess, specular, specularRGB
- They provide much greater control over the color of objects.
-Look at
- examples/gemLighting/gem5.materials.pd
-for examples.
-
-Guenter found a bug in the ortho object. It is now fixed. The
-ortho object has the same general unit size as the normal
-perspective matrix. Look at
- examples/gemAdvanced/gemOrtho.pd
-for how to use the object.
-
----------------------------------------------------------------
----------------------------- 0.83 -----------------------------
-Added another outlet to counter. When the counter reaches
-the "count to" value, the right outlet will send a bang. The
-bang happens after the left inlet sends its float.
-
-Fixed a dumb bug in pix_2grey. It didn't calculate the
-number of pixels correctly.
-
-Adding some comments to the FAQ that pix_draw is almost
-always slower than pix_texture on PCs. Basically, graphics
-accelerators do not accelerate glDrawPixels().
-
-Added rectangle and cylinder.
-
-Cleaned up the text objects (text3d, etc). Should display
-text a bit better and manage memory more intelligently.
-
-These next objects are thanks to hannes - mailto:zmoelnig@iem.mhsg.ac.at
----------------------------
-Added pix_rectangle - creates a rectangle in a pix
-Added pix_a_2grey - only changes the pixel to grey based
-on the alpha component. See the help page and the example
-in manual/gem_pix/gemAlphaGrey.pd
-
----------------------------------------------------------------
----------------------------- 0.82 -----------------------------
-Free-view sterescopic rendering is possible. If you send
-'createStereo' message to the gemwin instead of a 'create'
-message, then your rendering area will be split in two. Send a
-'stereoSep float' message to set the stereo seperation. Send
-a 'stereoFoc float' message to set the focal distance. See the
-example patch gem_advanced/gemStereo.pd patch for an example.
-
-'color' message was registered twice in gemwin. The second should
-have been a 'perspec' message, for perspective. This also fixes
-the error which pd-0.29 gives about GEM now.
-
-primTri is a new object. It is a triangle primtive. Unlike the
-normal triangle object, it has 6 inlets. The first three inlets
-are for setting the vertex positions. The last three inlets
-are for setting the color at each vertex. The color can
-be either RGB or RGBA values. Look at gem_advanced/gemPrimTri.pd
-for an example.
-
-The particle objects are now frame rate independent. If you needed
-them to run at a certain speed, you can send a multiplier into
-part_head with the message 'speed float'. Run the fountain
-at 60fps to see how smooth it is. The particles still default
-to 20fps, which is GEM's default. You can slow down the particle
-systems or speed them up by sending a different speed value
-into the part_head.
-
-Thanks to Guenter for making the sgi image loader 64-bit compliant.
-
-Received new Gnu makefiles for Linux from Guenter.
-
-new particle objects - These all have help files. See
-gem_particles/gem6.target.pd for how the target objects work.
- part_damp - apply a damping force to the particles
- part_targetcolor - Change color of the particles toward
- the specified color.
- part_targetsize - Change size of the particles toward
- the specified size.
-
-Added some help files, mainly for the particle objects.
-
-Updated the FAQ.
-
----------------------------------------------------------------
----------------------------- 0.81 -----------------------------
-On WinNT, you can remove the window border. Send a 'border 0' message
-to gemwin to remove it, or a 'border 1' to put it back. The default
-includes the border.
-
-Fixed some bugs when in single buffer mode and in the pix_snap
-object.
-
-A bunch more help documentation is done. This includes reference pages
-and the html manual pages.
-
-The inlets for alternate and counter were backwards.
-
-Integrated unix event handling into the code base.
-
-Fixed other random bugs.
-
----------------------------------------------------------------
----------------------------- 0.80 -----------------------------
-A real manual has been started! This means that the doc directory
-will not be as important. The release notes will still be here and
-few of the other doc files, but hopefully most people will just be
-able to use the on-line manual. Look at gem/manual/index.html
-to get started.
-
-pix_movie has been added. It automatically does the texture mapping
-so you don't need to use pix_texture. This also means that you can't
-process the pix image. This will change in the future, but I wanted
-to get the object out and have people hammer on it. Also, only
-certain objects can texture the movie data correctly. They are square,
-triangle, circle, and cube. Cone and sphere will have a black region
-if the movie isn't a power of two (most movies are 320x160 or something).
-This will be fixed in the future. See gem_pix/gemMovie.pd for an example
-
-hsv2rgb and rgb2hsv have been added.
-
-There is no ambient lighting in the default case. If you want
-to have ambient lighting, send a message "ambient r g b" to gemwin.
-
-On WinNT, if you hit Ctrl + r in the GEM window, then rendering
-will stop. This does not go through the normal Pd interface, so it can
-be used if you accidentally create a patch which takes so much processing
-that you cannot turn it off because the patch UI is unresponsive.
-
-Fixed a really bad bug in the text rendering objects.
-
-Various other random bugs.
-
----------------------------------------------------------------
----------------------------- 0.79 -----------------------------
-The example patches have been organized a little bit. There is
-now a collection of directories which are installed with GEM.
-Eventually, they will be fleshed out a lot more (I hope), but for
-the time being, at least there is some order to them.
-
-The model and multimodel objects accept a "rescale 0" or "rescale 1"
-message. In previous versions, the model objects would resize your
-model to fit within the unit cube (all vertices where within -1 to 1).
-This made it dificult to coordinate diferent model files together,
-because they would all be resized by diferent factors. Now, if you
-send a "rescale 0" message into model or multimodel, it will not
-do resizing for any _SUBSEQUENT_ loading. In other words, if you
-have already loaded in a model, and you send a "rescale 0", the
-currently loaded model (or models) will not change. Look at the
-example patch gem_advanced/gemModelRescale.pd for how this works.
-The left model chain is much larger and a scaleXYZ object with a
-value of .1 is needed to even get the model into the viewport.
-The model and multimodel objects default to "rescale 1" so that it
-doesn't break any existing patches.
-
-The middle and right buttons work in gemtablet now. The outlets
-are all pretty close together now, so until you can resize objects,
-it will be difficult to select the correct outlet. Look in
-examples/gemTablet.pd for all of the outlets.
-
-I have upgraded to Visual C++ 6.0. I doubt that the GEM library
-is backwards compatible for people who are writing their own
-libraries. Sorry, but the IDE is a little less painful in 6.0.
-
-I removed the position inlet from the light object. If you want
-to move/rotate a world_light/light, then just put a translate
-or rotate object into the chain. It was broken before, but now
-there is no reason for the position inlet.
-
-light and world_light accept a "debug" message with a value of
-1 or 0. Look at the gemLightSphere.pd patch for an example.
-It was too hard to figure out where the light is, and this turns on
-a sphere for the light object (since it is a point light), and
-a cone for the world_light object (since it is a directional
-light). The world_light is NOT a spot light, even though
-its icon is a cone. The icons are the color of the light.
-
-MarkEx has been merged into GEM. I was tired of maintaining
-two libraries. Also, people didn't seem to be downloading
-MarkEx, and there are a lot of good objects in there, IMHO.
-
-The camera object is finally useable. It has an inlet for the
-translation and rotation vectors. Anyone who was using it
-before is now broken, but the change was very necessary.
-
-gemwin can accept a perspective message. This will set up the
-viewing paramaters for the window. You need to pass in 6 floats
-with the "perspective" message, for the left, right, bottom,
-top, front, and back. The defaults are -1., 1., -1., 1., 1., 20.
-If you send a reset message to gemwin, it will reset the perspective
-values as well.
-
-The big change in this release is a particle system. It is based
-on code from David McAllister. There are many new object, all
-of which interact in certain ways. One design issue is that
-there are far too many controls and variables to be able to
-expose directly in GEM. People who want to get complete control
-over all aspects of the particle system are going to need to
-write their own externals. However, most people should be fine with
-the particle objects. The new objects are:
-
-CREATION
---------
-part_head - The start of a particle group
-part_color - Set the range of colors for the new particles
-part_size - Set the size of new particles
-part_velsphere - Set the velocity based on a sphere distribution
- You need 4 args - xvel, yvel, zvel, and radius
-part_velcone - Set the velocity based on a cone distribution
-
-part_source - Generate particles
-
-MANIP
------
-part_follow - Particles will follow each other like a snake
-part_gravity - Have the particles accelerate in a direction
-part_killold - Remove particles past a certain age
-part_killslow - Remove particles below a certain speed
-part_orbitpoint - Orbit the particles around a specified point
-
-part_draw - Apply the actions and render the particles. Accepts a
- message "draw line" or "draw point" to change the drawing style.
-
-Look in the example files to get some idea how to use the particle
-objects. Notice that you still need a gemhead starting off the
-chain, but after that, you just use the part_* objects. Regular
-GEM manips like rotate, translateXYZ, and scale will affect the
-particles. In general, you start with part_head, then modify
-the particle parameters with the creation objects like part_color
-and part_velocity. Then use part_source to actual generate the
-particles. Next in the chain, use the manip objects to control
-the particles behavior. When you actually want to display the
-particles, use part_draw. Make sure that you remove particles as
-well. The best method is probably with part_killold. If you
-don't remove particles, then you will eventually not be able to
-add any new ones (the default number of particles at once is
-1000, set by part_head). You can also slow down the rate of the
-particle generation with the part_source object.
-
----------------------------------------------------------------
----------------------------- 0.78 -----------------------------
-If you don't want GEM to take control of the tablet if it finds
-one, set the environment variable GEM_NO_TABLET to the
-value "1" (no quotes of course). There will be a print out if
-GEM finds the environment variable.
-
-I added a few more setup access function so that people who
-use "-lib gem" or "-lib GEM" will work correctly.
-
-Lighting will now work under single buffer mode, but you have
-to destroy then create the graphics window to change the mode. This
-will not work with the GEM_SINGLE_CONTEXT variable.
-
-pix_data is a new object. It outputs color information from a pix.
- The first inlet accepts a bang to trigger it.
- The second inlet accepts a gem list (probably from pix_image)
- The third inlet is the x position (between 0 and 1)
- The fourth inlet is the y position (between 0 and 1)
- The first outlet is the gem list
- The second outlet is the color (an RGB list)
- The third outlet is the gray scale value (a float)
- See the example patches gemPixDataSimple.pd and gemPixDataComplex.pd
-for possible use.
-
-Fixed a pretty bad bug in the SGI image loading. Basically, unless
-the image was RGBA, it was going to core dump. Also, the orientation
-was wrong.
-
----------------------------------------------------------------
----------------------------- 0.77 -----------------------------
-GEM is now under the Gnu Public License. This should not affect
-any one. I also cleaned up the license information for the AuxLibs.
-All of the license and usage information can be found in
-GEM.LICENSE.TERMS
-
-GEM has a new home - http://www.danks.org/mark/GEM
-
-gemorb - a new object to interface with the SpaceTec SpaceOrb360.
-It is a 6DoF ball with 6 buttons that connects to your serial port.
-It is a very cool device, and is relatively cheap ($50 US). If gemorb
-is able to connect, it will print out a message, or an error if there
-is a problem. John Stone wrote the library.
-
-There is a particle system with a number of new objects. The system
-uses a library by David McAllister.
-ps I haven't had time to bring all of the objects online. particle
-is the only object right now. It just creates a fountain.
-
-accumrotate was added - three inlets to control the rotation. Each
-time a new value is sent in, it increases the rotation. Sending
-'reset' to the leftmost inlet sets the rotation matrix to
-identity (ie, it resets it to no rotation).
-
-rotateXYZ was added - three inlets to control the rotation. Order
-is X rotation, then Y, then Z.
-
-The tablet cleanup is a little better now on WinNT. There are still
-some bugs, like it doesn't return to normal mouse usage after GEM exits.
-However, the DLL is being released correctly...I just need to reset
-to the default state somehow.
-
-Cone and sphere have changed behavior as of 0.77. The middle inlet
-is now the size and the right inlet is the number of slices.
-
-depth used to be sending '1' would turn on depth testing, but this
-was conceptually wrong. It should be 1 to turn on the depth
-object (which would disable depth testing). This is now the
-current behavior.
-
-ortho was added. It changes the viewing from perspective to
-orthogonal. The size is the size of the window with (0, 0)
-being the lower left corner. I made this object for creating
-a background the size of the window, but you can probably
-find other uses for it.
-
-There is a matrix class for those who are writing objects.
-It is in src/Base/Matrix.
-
----------------------------------------------------------------
----------------------------- 0.76 -----------------------------
-Fixed a bug in spline-path. I wasn't doing the knot logic
-correctly. Thanks to Patrick Rost for finding this.
-
-A bunch of internal changes to get GEM working with Pd 0.22
-All instances of A_INT went away and the inlets and outlets are
-created in the correct "logical" order now.
-
----------------------------------------------------------------
----------------------------- 0.75 -----------------------------
-You can resize the window under WinNT and the viewport will change
-to reflect the new size.
-
-Also, the correct aspect ratio is maintained no matter what the
-width/height ratio is for the GEM window. The ratio is
-x:y -> (width/height):1. This is currently only under WinNT.
-
-gemmouse and gemtablet are new objects. They currently only
-work in WinNT. You should be able to create the object in
-the Irix/Linux versions, but you won't get any output. See
-gemmouse.pd and gemtablet.pd for examples.
-gemmouse outputs the current mouse position and button up/down
-for the GEM window.
-gemtablet outputs the current pen position, pressure, orientation,
-and pen up/down, with the GEM window mapped to the tablet. If
-GEM can connect to your tablet, a message will be printed at startup.
-If you don't see a message at startup from GEM about connecting to
-the tablet, then gemtablet will not output any values. You must
-have the wintab32.dll library installed. Your tablet's installation
-should do this.
-
-Added a bunch of utility functions (spline, bias functions, etc).
-
-linear_path and spline_path are new objects. If you give them
-an array, then they will generate a point from an index. linear_path
-will linearly interpolate between points. spline_path uses the
-points as knots for a curve. See gemSplinePath.pd and
-gemLinearPath.pd for examples.
-
-Added __declspec declarations for Windows. This should
-make it easy for people to use GEM as a dll.
-
----------------------------------------------------------------
----------------------------- 0.74 -----------------------------
-I replaced the images in the example directory with JPGs. They
-are alot smaller. However, in gemMoveImages.pd, you can see
-the effect that the compression has. Look at the red dancer. All
-of the "black" should be alpha masked out, yet there are little
-bits which get all jaggy.
-
-Got gltt-1.8 Looks like it fixes a bunch of bugs.
-
-Finally put an alpha test into the alpha object. This means that
-if the alpha of a pixel == 0., then it won't be put written into
-the frame buffer. Look at the example file gemMoveImages.pd for
-an example of this. Notice that the dancer is texture mapped to
-a sphere, yet you can always see her correctly. You can disable
-this behavior by sending a 'test 0' to the alpha object.
-
-Oh boy, were my texture coordinates off. Unknown to me, my reference
-image (dancer.tif) was actually upside down. This meant that all
-of the texture coordinates in the Geos objects were compensating
-for the rotation. Sorry if this messes anyone up, but it is now
-correct for all of the geos.
-
-I also now load in images in OpenGL format. This means that
-data[0][0] == lower-left corner. This shouldn't have any effect
-on anyone unless you are doing position sensitive image processing.
-
-Fixed the orientation problem when using pix_draw.
-
-imageVert handles gray8 pixes
-
-Fixed a problem if pix_multiimage loaded in images that were different
-formats or sizes.
-
-GEM supports search paths! Basically, GEM will look for auxiliary
-files (images, models, fonts, etc.) from whatever directory the
-patch is in (unless you use an absolute path name with '/').
-
----------------------------------------------------------------
----------------------------- 0.73 -----------------------------
-Fixed profiling on Unix
-
-Added text2d, text3d, textoutline. The text objects will render
-a truetype font (I have provided a couple fonts in gem/examples).
-text2d renders a flat bitmap...no rotation or Z movement. text3d is
-full polygonal text, so you can translate and rotate. textoutline
-is also polygonal, it is just a vectored outline.
- PS text2d has some problems...
-
-JPEG and SGI image file formats are supported! Depending on the number
-of color components, GEM will automatically convert them to grayscale
-or RGBA (just like TIFF files).
-
-pix_video is working slightly on WinNT. There are still some
-serious problems, so consider this version a complete pre-alpha. I'm
-releasing a version now to find out if it even works on other systems.
-I am using a Connectix QuickCam2.
-
-Shifted all of the auxilary libraries into a common directory. Considering
-that I'm currently using 6 outside packages, it is just easier.
-
----------------------------------------------------------------
----------------------------- 0.72 -----------------------------
-
-Did a bunch of cleaning so that the Linux compile is happier (and easier).
-This involved getting rid of some warning messages and changing
-the makefiles slightly.
-
-The strange core dump on WinNT went away...
-
-All of the code and extra files are under source code control (CVS).
-You can just ignore the CVS directories. Eventually, I will try to keep
-them out of the release build.
-
-Added profiling. If you send 'profile 1' to gemwin, then normal profiling
-is turned on (GEM displays the number of milliseconds per frame). If you
-send 'profile 2', then images will not be cached (ie, the pixes will always
-be processed). If you send 'profile 0', then profiling is turned off.
-
-pix_multiply multiplies the color components of two images together.
-It doesn't modify the alpha channel.
-
-Optimized pix code.
-
-Because Miller is removing the INT type, I have slowly been moving it
-out of the code. If any objects have stopped working, please let me know.
-I redid the construction macros in CPPExtern to reflect this change.
-If you have made any new GEM objects, you will probably need to
-change to the new macro format.
-
-Most of the dual input pix objects will process gray8 and RGBA data
-gracefully.
-
----------------------------------------------------------------
----------------------------- 0.71 -----------------------------
-
-Guenter got GEM working under Linux! The biggest impact is that I
-have changed all of the #ifdef __sgi to #ifdef _UNIX_ If specific versions
-of Un*x need certain things, then they can be #ifdef'ed with __sgi,
-or LINUX, or whatever.
-
-Fixed a bug in polygon and curve. I'm not sure why it ever worked on
-the SGI...
-
-All pix objects accept a 0 or 1 to turn on and off their processing.
-The 0 or 1 should just be sent to the first inlet.
-
-The inlets were backwards for colorRGB.
-
-Fixed a bug in turning on and off texture mapping in pix_texture.
-
-GemMan::initGem is now called from Gem_setup. There seems to be a problem
-with Linux creating the dummy static class to initialize GEM.
-
-Changes pix_texture so that it deal with OpenGL 1.1, GL_EXT_texture_obj,
-and base OpenGL 1.0 I think that every OS has the texture_obj
-extension, but just in case, I also have the OpenGL 1.0 technique of display
-lists.
-
-Removed some spurious print outs.
-
-I looked into using GL_BGRA_EXT for images on Windows. It is faster
-in the software version, but my Intergraph card doesn't support it.
-It only makes a difference for OpenGL in software...and texture
-download time isn't the primary problem then. With a 512x512 image
-using glDrawPixels in software, I got 6 frames/sec with RGBA and 7
-frames/sec with BGRA_EXT. Older SGIs like ABGR_EXT, but the newer machines
-want RGBA. Looks like I'm going to stick with RGBA for a while.
-
-You can now load in Gray8 and RGBA images and they will retain their
-format. Before, everything was slammed into an RGBA image, with A == 255.
-This means that you can have alpha masks on images, etc. The only pix
-object which can currently handle a gray8 is pix_mask. All of the other
-pixes throw errors if they get a gray8. This will slowly be fixed.
-
-Added some new functions to GemPixUtil (from a paper by Alvy Ray Smith).
-They should speed things up. Currently, only pix_composite is using them.
-
-The color channels of pixels should be gotten by the const ints that
-are in GemPixUtil (for instance, chRed, chGreen, etc). Using hard coded
-offsets like 0 or 2 for red and blue is asking for trouble.
-
-gemheads no longer push and pop the entire matrix state when renderGL is
-called. This should be faster (push/pop is slow on some platforms). Also,
-all objects are required to "reset" the OpenGL state when they are done,
-so it shouldn't be neccessary.
-
-Strangeness: There is an unreferenced memory exception on WinNT when you
-quit Pd. However, it only happens if you use pix_image. It doesn't
-happen while you are using Pd, only when you quit...
-
----------------------------------------------------------------
----------------------------- 0.70 -----------------------------
-
-All geos can now accept a size argument (they default to 1.0)
-
-I cleaned up the texture coordinate mapping. The order was slightly
-random before. The order is more logical now; it is counterclockwise
-starting at 0, 0. If you use pix_coordinate any where, you will need
-to fix the values.
-
-Fixed a bug in translateXYZ. The inlets where backwards.
-
-You can now move the GEM window under NT. NT doesn't automatically
-take care of the basic window functions unless you pass the messages
-through (unlike X Windows).
-
-Texture mapping can be turned on and off by sending a 0 or 1 to pix_texture
-
-Texture mapping defaults to GL_LINEAR. Send a quality message to pix_texture
-to change this. A "quality 0" means GL_NEAREST, "quality 1" means GL_LINEAR.
-
----------------------------------------------------------------
----------------------------- 0.69 -----------------------------
-
-Fixed a bunch of bugs in imageVert.
-
-Cleaned up some lingering problems in various objects (the open message to
-pix_multiimage didn't work as advertised for instance).
-
-Setting window color is now dynamic.
-
-multimodel now exists. Works just like pix_multiimage, only it reads in
-Alias/Wavefront files. It also has a caching mechanism.
-
----------------------------------------------------------------
----------------------------- 0.68 -----------------------------
-
-fixed pix_2grey so it uses real color weights, instead of just averaging
-the three colors.
-
-pix_image now works the same way as pix_multiimage. If you load in an
-image which another pix_image has already loaded, they will share the
-image. This means that if you create a bunch of dummy pix_image
-objects, you can send an open message to pix_images which have a gemhead
-connected to them and get instantaneous image changes.
-
-Found a MAJOR bug in the NT version of pix_texture. Basically, if you
-used it, the program would core dump.
-
-Found another bug in square. It involved texture mapping and texture
-coordinates (mainly when you don't designate them).
-
-Changed the default values for scaleXYZ (to 1, 1, 1) and translateXYZ
-(to 0, 0, 0)
-
----------------------------------------------------------------
----------------------------- 0.67 -----------------------------
-
-Forgot to add the arguments for the scale object. This has been fixed.
-
-Added translateXYZ, scaleXYZ, and colorRGB. These create three inlets
-which you can modify, instead of having to mess with vector messages.
-
-Fixed a bug in pix_image and pix_multiimage (or more, an unacceptable
-response to user error). Basically, if you started rendering without
-an image being loaded (or if an image failed to load, then you were
-_VERY_ likely to core dump. A check has been added, so this shouldn't
-be a problem anymore.
-
-pix_multiimage HAS CHANGED! It accepts up to four arguments:
-
-filename, number : will load the image files from 0 up to AND INCLUDING
-the number
-
-filename, lownum, highnum : will load the image files from the lownum up
-to AND INCLUDING the highnum
-
-filename, lownum, highnum, skiprate : will load the image files from
-the low num up to AND INCLUDING the highnum, but incrementing the counter
-by the skiprate, not by one.
-
-No matter how many images are loaded, you can change which image is
-displayed by sending a number. The number must be between 0 and the
-number of images which were loaded (notice that this number may not be
-the highnum!) If you try to display an image out of range, you will
-get an error.
-
-pix_multiimage now uses a shared cache. Basically, if you give two
-pix_multiimage objects the EXACT same values (filename, base number,
-top number and skip number), then they will use the same collection of
-images. This will save massive amounts of memory if there is any
-commonality between pix_multiimages.
-
-pix_flip - see help file
-
----------------------------------------------------------------
----------------------------- 0.66 -----------------------------
-
-Finished the port to NT (mainly had to get images working).
-
-Made pix_colormatrix - This is really good for things like saturation,
-hue rotate, etc. I will eventually include a bunch of matrices to do
-cool stuff. Check out Paul Haeberli's paper on color matrices at
-http://www.sgi.com/grafica/index.html
-
-I removed pix_color. It was a hold over from earlier days and I
-don't think that anyone (including myself) is using it any more.
-
-I got a title bar onto the graphics window, but you still can't move it
-around. I am not certain why this is the case, but I'll keep looking.
-
-I made general speed ups to most of the pix objects. Mainly, I have
-been removing GetPixel() and SetPixel() functions (they have a lot
-of overhead). I will continue to use Get/SetPixel() while I'm developing
-because they make things easy to deal with, but as objects get finished,
-I will remove them.
-
-Some of the manipulators (color, rotate, and translate) accept arguments.
-For instance, if you do color 1 0 0, it will automatically set the
-color to red. The objects try to be intelligent about their arguments.
-For instance, if color receives three args, it sets RGB, but if it
-gets 4, it sets RGBA. If rotate or translate get 3 args, then they just
-set the vector, but if they get 4, then they set both the vector and
-the value.
-
----------------------------------------------------------------
----------------------------- 0.65 -----------------------------
-
-GEM works under NT! I got the port working last night. I had to make some
-major changes to the underlying classes (specifically CPPExtern) because
-MS VisC++ puts the vtable pointer in the first four bytes...no matter what.
-This is a different behavior than SGI's compiler (and I think that it requires
-more work for MS VisC++'s compiler). While it was a pain to change things, it
-is good in the long run. The C++ standard doesn't say where the vtable is
-located, so this would have bitten me at some point.
-
----------------------------------------------------------------
----------------------------- 0.64 -----------------------------
-
-Because MS VisC++ really wants files to end in .cpp (how stupid...),
-I renamed all of the C++ files.
-
-I looked into making all of the pixes be float, instead of unsigned char. This
-would give increased flexibility because we could use negative numbers, not
-worry about wrap around on the unsigned char, etc. In running performance
-tests on an SGI O2, the performance difference is fairly great. If GEM
-was only an image processing program (ie, PhotoShop), then I would definetely
-have pixes be floats. However, since GEM is meant for real-time, I will
-continue to use unsigned chars to represent pixels.
-
-For the tech heads...I used to generate the rendering by creating a
-linked list of the GEM objects. The problem was that objects like
-separator weren't possible because it wasn't a true DAG. That is now
-fixed so that tree/leaf graphs are possible.
-
-Made render_trigger so you can know exactly when the rendering is occuring.
-
-Made pix_multiimage! Just give it a file with a * (like myfiles*.tif) and an
-integer for a range (the number of images).
-
-Made pix_invert, separator
-
----------------------------------------------------------------
----------------------------- 0.63 -----------------------------
-
-The src directory has been made into a tree.
-
-Made pix_add and pix_subtract
-Added a scale object
-
----------------------------------------------------------------
----------------------------- 0.62 -----------------------------
-
-A dummy glxContext is created at startup. What this means is that
-in the constructors of objects, OpenGL calls can be made, display
-lists can be constructed, etc. Eventually, I would like to have a
-single window which is always in existance that can change between
-single and double buffering, but that may be a little while.
-
-I put Sam Leffler's tiff library back in. All image files must be in
-TIFF format again. Basically, I think that Win NT would have trouble
-making SGI .rgb files, while anyone can make TIFF formats. Currently
-there is some code bloat because libtiff does more than just read in a
-TIFF file.
-
-The pix_coordinate object allows users to set the S,T texture coordinates
-for geos. For instance, by giving pix_coordinate 4 S,T pairs, the texture
-coordinates for a square can be changed on the fly. Not all of the geos
-can support this ability right now (currently only square, triangle, and
-polygon, but this will change in the near future).
-
-A FAQ has been started, but there really aren't any questions in it yet.
-As people think of them, please let me know and I'll add them.
-
----------------------------------------------------------------
----------------------------- 0.61 -----------------------------
-
-Cocoon html help files for developers have been created.
-
-GEM now uses an internally generated DAG for rendering. This
-removes a serious bug where by objects could still try to reference
-dangling pointers. GEM objects act like the tidle objects do
-from a users point of view. Even if you break a connection
-in a GEM chain, the GEM objects will continue to work. This
-means that it is safe to edit patches while a GEM chain is
-running. To rebuild the GEM patch, rendering must be turned
-off and then back on (just like the tilde objects).
-
-Using the td library from Evans & Sutherland by Nate Robbins to display
-Alias/Wavefront files (.obj). It also takes care of image
-loading, although it is only .rgb. If people complain enough,
-then I may return to the Sam's libTiff library, but it is so
-big that the td library is better. The td library can also be
-compiled on Windows (or else I wouldn't have used it). The new
-object is called model (although it may change its name some day).
-
-There is a new object which maps the color of a pix to the Z of
-a polygon. It is isn't overly useful right now, but it is a cool
-demo. It is called imageVert.
-
----------------------------------------------------------------
----------------------------- 0.60 -----------------------------
-
-Major changes to the internals of GEM. gemwin is now only
-an access point to the window manager, instead of actually
-being the window manager. This should make it easier to have
-multiple graphics windows.
-
-While I was getting the O2 video camera to work, I seem to
-have broken the Indycam object...
-
----------------------------------------------------------------
----------------------------- 0.50 -----------------------------
-
-Made the port from Max over to Pd. Redesigned the class
-heirarchy somewhat.
-
+GEM ONLINE DOCUMENTATION CHAPTER 5: RELEASE NOTES
+
+---------------------------------------------------------------
+---------------------------- 0.91 -----------------------------
+this is the first release for 3 years, codename 'tigital'
+it includes many changes, so probably i have forgotten most...
+
+openGL runtime checks: GEM now uses GLEW to detect openGL-features
+ at runtime this allows you to use all the cool features of
+ your brand-new graphics card with the same binary as you
+ used for your old gfx-card...cool
+
+w32-installer: there is now a w32 installer (based on NSIS) to
+ ease the installation of GEM on windows.
+
+single vs dual context: GEM uses a dual context approach to establish
+ a valid openGL-context at startup;
+ you can now turn this OFF by setting the environmental
+ variable "GEM_SINGLE_CONTEXT=1"
+ this should allow you to work if GEM crashes otherwise
+
+SIMD: better MMX/SSE2 handling
+
+pixes: fiducial tracking, artoolkit,
+ multitexture, texture sharing
+ recording streams of images into movies,
+ better movie reading support, better video in support,
+ more sophisticated pix_buffer handling
+ shared memory objects
+
+text: allow unicode characters
+ use vera.ttf as default font instead of the
+ copyrighted arial.ttf
+ allow to override the default font with the environment
+ variable "GEM_DEFAULT_FONT"
+
+
+bugfixes: like always we have removed (and introduced) numerous
+ bugs, so all in all GEM should now run more stable
+ for an incomplete list of fixed bug see the bug-tracker
+ at http://sourceforge.net/projects/pd-gem
+
+openGL: generally use openGL-2.0 (if available)
+ vertex/fragment shaders (GLSL and ARB/NV)
+ framebuffers
+
+
+deletion:
+ MarkEX has been removed from GEM and is now available as
+ a separate library;
+ hardware-interfacing objects like [gemorb] and [gemtablet]
+ have been removed
+
+
+
+
+---------------------------- 0.90 -----------------------------
+this is the same as 0.888
+just a naming issue
+
+---------------------------------------------------------------
+---------------------------- 0.888 ----------------------------
+
+this has taken a long time (2 years...)
+
+development is now done by several people:
+ chris clepper
+ günter geiger
+ daniel heckenberg
+ james tittle
+ IOhannes m zmölnig <zmoelnig@iem.at>
+günter has removed himself from the splash-screen, but he still contributes stuff
+
+supported platforms: windows (XP,2000,...), linux, and (tadah:) macOS-X(>10.2)
+irix-support seems to be broken, but i cannot prove it
+
+architecture: up till now, the rendering-tree was statically built when rendering was
+ turned on, so you couldn't add objects dynamically and editing was painful.
+ now, Gem utilizes the normal pd-messaging system all the time: you can disable
+ parts of the rendering tree with [spigot], render sub-trees multiple times with
+ [t a a] and put objects into the gem-tree on the fly.
+
+documentation: added help for (almost ?) all Gem-objects (excluding openGL-wrappers)
+ new reference-patches are now working out of the box (not the old "abstract" way)
+ added a small pdf-tutorial
+
+
+openGL: GEM features now a full openGL-wrapper (supporting openGL-1.2)
+ you can use any openGL-command like "glNormal3f" by creating a pd-object like
+ [GEMglNormal3f] (note the "GEM"-prefix); this should be very powerful,
+ however most of the objects are not (yet) tested.
+ if you intend to use them and think they don't work,
+ send me a bug report for the objects you need;
+ i will try to fix them gradually.
+ there will be not much help in GEM, since you might consult any openGL-reference
+
+text: we now use FTGL instead of GLTT (which is still available at compile time)
+ for freetype-rendering. this is supported on all 3 platforms,
+ looks better (at all sizes!) and allows the new [textextruded]
+
+geos: tube, curve3d, rubber, ripple, slideSquares, newWave
+
+manips: polygon_smooth for anti-aliasing of single objects
+ [camera]
+
+controls: the output of [gemmouse] can now be normalized (by giving the maxVal for x/y as
+ arguments: [gemmouse 1 1] will output coordinates between 0..1, no matter what
+ dimensions the screen has.
+
+particles: now the underlying libparticle-engine can be used more directly.
+ velocity-domains (like [part_velcone]) are deprecated and [part_velocity]
+ should be used instead (allowing on-the-fly domain-switching)
+ there are objects that allow to influence single particles
+ (like [part_vertex])
+ most interesting: with [part_render] and [part_info] you can now use any
+ geo as particles (e.g: .obj-models) not only points/lines as before.
+
+texturing: [pix_texture] and [pix_texture2] has merged. so [pix_texture] will texture
+ textures of any size (even non-power-of-2) and it will use hw-support if available
+ (at least on macOS and on linux if the gfx-card supports it
+ (at least nvidia does so))
+
+pixes: lots of new objects (too much to enumerate them here)
+ we now support 3 different colorspaces: RGBA, YUV, Greyscale
+ YUV is new and allows processing of coloured-images with far less memory/CPU
+ than RGBA (factor 2) but without alpha.
+ lots of pix-processing on apple-computers is ALTIVEC-enhanced (faster by numbers!)
+ SIMD-enhancements for PCs (MMX/SSE2) is yet to come...
+ as the new colorspace has been pushed, also a lot of objects has received
+ greyscale-support
+ the TV-class has been deprecated and is now part of pix_* again
+ lot's of color-space converters (most of them not available as objects)
+ the "pix_fx"-stuff is now built into all pix-objects
+
+video: on mac-OS the [pix_video] object supports all cameras that are supported by the OS
+ on windows there is now support for DirectShow,
+ which makes new (usb/ieee1394) cameras work most probably
+ on linux there is some prelaminary(!) support for ieee1394 devices.
+ the v4l-support is now multi-threaded which speeds up the whole thing significantly
+
+film-formats:
+ windows: AVI; there is also some QUICKTIME-support
+ (needs the quicktime-sdk at compile time and quicktime installed on execution time),
+ but this crashes sometimes (haven't found out when).
+ it should enable "a lot" of file-formats (MPEG, MOV)
+ macOS: quicktime serves your needs
+ linux: support for libavifile, libmpeg3 (or libmpeg1 but libmpeg3 is preferred),
+ libquicktime (or libquicktime4linux; doesn't matter) and ffmpeg.
+
+codecs: macOS: everything that is supported by your system should work fine
+ win: all codecs installed on your machine should work
+ (if another program can play a avi-file, Gem should be able to do so too)
+ linux: depends on how you compiled Gem. libmpegX will decode mpegs,
+ libquicktime will (most likely) decode quicktime-files with non-proprietary codecs,
+ libavifile decodes a lot of formats (avi, quicktime, divx, asf,...)
+ and you can utilize windows-codecs (.dll-files; if you have them ;-))
+ which enables you to play-back proprietary codecs!
+
+bug-fixes: probably lots of, but most of them seem to linger around for a while now.
+
+
+
+---------------------------------------------------------------
+---------------------------- 0.87 -----------------------------
+Added much documentation
+
+Added [gemkeyboard] and [gemkeyname] for keyboard-interaction in the GEM-window. However, Windows and Linux versions do not give the same results...
+
+Added Red/Green stereo
+Cleaned up the stereo-thing. we can switch between the different stereo-modes (including no-stereo) while rendering
+
+You can set the title of the GEM-window with the "title"-message. Up till now only one symbol is allowed.
+Added "fullscreen" mode
+Fixed "border" under linux
+"cursor" is now available on Windoze
+
+readded "externals" with additional libraries to close up with the windows version::
+Added pix_movie for Linux (mpeg2+quicktime-support)
+Added pix_film, which is in fact like pix_movie but does not write the pix-buf directly into a texture
+Fixed the model
+Added the stupid "teapot"
+Added a pix_write that let's you capture the current screen into a file (TIFF/JPEG)
+Added pix_hsv2rgb, pix_rgb2hsv (colour-space converters)
+Added pix_blob (center of gravity:: colour detection)
+Added pix_curves, pix_histo
+Added pix_set, pix_dump
+Added pix_pix2sig~, pix_sig2pix~
+
+Started a new class "tv" for pix-operations that change over time: like tv_movement (formerly: pix_movement), tv_biquad, tv_rtx; but i am not really happy with this...
+
+Started a new pix_fx class for inserting pix-FX. there is not much about it, but you can now bend the image.data pointer to wherever you like (including size-changes, format-changes) it will be bent back in the postrender()-thing
+
+Started to import classes from effecTV (by Fukuchi Kentarou): pix_aging, pix_puzzle; most of his FX are real crap, but some are ok and it's easy to import them
+Made a pix_rgba
+
+
+---------------------------------------------------------------
+---------------------------0.84-5 -----------------------------
+Bugfixes for gemwin "cursor" message (cursor [1|0])
+Removed "externals" with additional libraries, they are separated now
+Added a "freq" and "mode" message to Linux video object, you can watch
+ TV now ...
+It is possible to add the display to the create command for X windows,
+ whole initialization stuff is moved into the create method,
+ so you can look at the patches without having succesfully generated
+ an OpenGl context.
+Made the pix_video and pix_movie into real base classes of OS specific
+ classes. The OS spezific classes for Windows and SGI have to be fixed ..
+
+
+---------------------------------------------------------------
+--------------------------0.84a -----------------------------
+text2d: added a message "alias", which toggles between antialiases
+ and standard fonts. Usage "alias 1" or "alias 0"
+
+gemwin: additional message cursor, which hides the cursor in
+ GEM windows
+
+
+
+
+---------------------------------------------------------------
+---------------------------- 0.84 -----------------------------
+Fixed a bug where delete [] was called instead of delete. This
+could explain a lot of random crashes.
+
+Fixed camera message routing.
+
+---------------------------------------------------------------
+---------------------------- 0.84 -----------------------------
+I long time ago, I changed the behavior for gemhead, so that
+matrices where automatically restored, etc. However, this
+broke the camera object. Use the view message to gemwin
+instead.
+
+Fixed a bug in GemMan. If you didn't use "border 0" and you
+requested a window size with "dimen # #", then the window
+size was likely to be wrong. This is now fixed.
+
+Fixed a bug in the view message to gemwin. There was an offset
+which should not have occured. You might need to change your
+view messages to account for it. Just subtract 4 from any
+Z values.
+
+There are some examples for pix_snap in
+ examples/gemAdvanced/gemPixSnap.pd - Single buffered example
+ examples/gemAdvanced/gemPixSnap2.pd - Double buffered example
+Keep in mind that pix_snap is a fairly slow operation...I also fixed
+a nasty memory bug which could easily cause crashes.
+
+I added Miller Puckette's pix_video for linux into the
+code base.
+
+If you load a movie in pix_movie with an open message, the
+object will output the number of frames to the right output. This
+will not work if you have a "pix_movie homer.avi" for your object
+since the output message cannot get processed correctly at
+startup.
+
+The disk object has an inlet on the rightmost side for the
+inner radius...turning the disk into a ring. If the inner
+radius value is just 0., then the disk is just a circle.
+
+Fog can be turned on in gemwin. Look at
+ examples/gemAdvanced/gemFog.pd
+for examples. The various control messages are documented
+in the gemwin.pd help patch.
+
+These next objects are thanks to hannes - mailto:zmoelnig@iem.mhsg.ac.at
+---------------------------
+Added OpenGL material objects -
+ ambient, ambientRGB, diffuse, diffuseRGB, emission,
+ emissionRGB, shininess, specular, specularRGB
+ They provide much greater control over the color of objects.
+Look at
+ examples/gemLighting/gem5.materials.pd
+for examples.
+
+Guenter found a bug in the ortho object. It is now fixed. The
+ortho object has the same general unit size as the normal
+perspective matrix. Look at
+ examples/gemAdvanced/gemOrtho.pd
+for how to use the object.
+
+---------------------------------------------------------------
+---------------------------- 0.83 -----------------------------
+Added another outlet to counter. When the counter reaches
+the "count to" value, the right outlet will send a bang. The
+bang happens after the left inlet sends its float.
+
+Fixed a dumb bug in pix_2grey. It didn't calculate the
+number of pixels correctly.
+
+Adding some comments to the FAQ that pix_draw is almost
+always slower than pix_texture on PCs. Basically, graphics
+accelerators do not accelerate glDrawPixels().
+
+Added rectangle and cylinder.
+
+Cleaned up the text objects (text3d, etc). Should display
+text a bit better and manage memory more intelligently.
+
+These next objects are thanks to hannes - mailto:zmoelnig@iem.mhsg.ac.at
+---------------------------
+Added pix_rectangle - creates a rectangle in a pix
+Added pix_a_2grey - only changes the pixel to grey based
+on the alpha component. See the help page and the example
+in manual/gem_pix/gemAlphaGrey.pd
+
+---------------------------------------------------------------
+---------------------------- 0.82 -----------------------------
+Free-view sterescopic rendering is possible. If you send
+'createStereo' message to the gemwin instead of a 'create'
+message, then your rendering area will be split in two. Send a
+'stereoSep float' message to set the stereo seperation. Send
+a 'stereoFoc float' message to set the focal distance. See the
+example patch gem_advanced/gemStereo.pd patch for an example.
+
+'color' message was registered twice in gemwin. The second should
+have been a 'perspec' message, for perspective. This also fixes
+the error which pd-0.29 gives about GEM now.
+
+primTri is a new object. It is a triangle primtive. Unlike the
+normal triangle object, it has 6 inlets. The first three inlets
+are for setting the vertex positions. The last three inlets
+are for setting the color at each vertex. The color can
+be either RGB or RGBA values. Look at gem_advanced/gemPrimTri.pd
+for an example.
+
+The particle objects are now frame rate independent. If you needed
+them to run at a certain speed, you can send a multiplier into
+part_head with the message 'speed float'. Run the fountain
+at 60fps to see how smooth it is. The particles still default
+to 20fps, which is GEM's default. You can slow down the particle
+systems or speed them up by sending a different speed value
+into the part_head.
+
+Thanks to Guenter for making the sgi image loader 64-bit compliant.
+
+Received new Gnu makefiles for Linux from Guenter.
+
+new particle objects - These all have help files. See
+gem_particles/gem6.target.pd for how the target objects work.
+ part_damp - apply a damping force to the particles
+ part_targetcolor - Change color of the particles toward
+ the specified color.
+ part_targetsize - Change size of the particles toward
+ the specified size.
+
+Added some help files, mainly for the particle objects.
+
+Updated the FAQ.
+
+---------------------------------------------------------------
+---------------------------- 0.81 -----------------------------
+On WinNT, you can remove the window border. Send a 'border 0' message
+to gemwin to remove it, or a 'border 1' to put it back. The default
+includes the border.
+
+Fixed some bugs when in single buffer mode and in the pix_snap
+object.
+
+A bunch more help documentation is done. This includes reference pages
+and the html manual pages.
+
+The inlets for alternate and counter were backwards.
+
+Integrated unix event handling into the code base.
+
+Fixed other random bugs.
+
+---------------------------------------------------------------
+---------------------------- 0.80 -----------------------------
+A real manual has been started! This means that the doc directory
+will not be as important. The release notes will still be here and
+few of the other doc files, but hopefully most people will just be
+able to use the on-line manual. Look at gem/manual/index.html
+to get started.
+
+pix_movie has been added. It automatically does the texture mapping
+so you don't need to use pix_texture. This also means that you can't
+process the pix image. This will change in the future, but I wanted
+to get the object out and have people hammer on it. Also, only
+certain objects can texture the movie data correctly. They are square,
+triangle, circle, and cube. Cone and sphere will have a black region
+if the movie isn't a power of two (most movies are 320x160 or something).
+This will be fixed in the future. See gem_pix/gemMovie.pd for an example
+
+hsv2rgb and rgb2hsv have been added.
+
+There is no ambient lighting in the default case. If you want
+to have ambient lighting, send a message "ambient r g b" to gemwin.
+
+On WinNT, if you hit Ctrl + r in the GEM window, then rendering
+will stop. This does not go through the normal Pd interface, so it can
+be used if you accidentally create a patch which takes so much processing
+that you cannot turn it off because the patch UI is unresponsive.
+
+Fixed a really bad bug in the text rendering objects.
+
+Various other random bugs.
+
+---------------------------------------------------------------
+---------------------------- 0.79 -----------------------------
+The example patches have been organized a little bit. There is
+now a collection of directories which are installed with GEM.
+Eventually, they will be fleshed out a lot more (I hope), but for
+the time being, at least there is some order to them.
+
+The model and multimodel objects accept a "rescale 0" or "rescale 1"
+message. In previous versions, the model objects would resize your
+model to fit within the unit cube (all vertices where within -1 to 1).
+This made it dificult to coordinate diferent model files together,
+because they would all be resized by diferent factors. Now, if you
+send a "rescale 0" message into model or multimodel, it will not
+do resizing for any _SUBSEQUENT_ loading. In other words, if you
+have already loaded in a model, and you send a "rescale 0", the
+currently loaded model (or models) will not change. Look at the
+example patch gem_advanced/gemModelRescale.pd for how this works.
+The left model chain is much larger and a scaleXYZ object with a
+value of .1 is needed to even get the model into the viewport.
+The model and multimodel objects default to "rescale 1" so that it
+doesn't break any existing patches.
+
+The middle and right buttons work in gemtablet now. The outlets
+are all pretty close together now, so until you can resize objects,
+it will be difficult to select the correct outlet. Look in
+examples/gemTablet.pd for all of the outlets.
+
+I have upgraded to Visual C++ 6.0. I doubt that the GEM library
+is backwards compatible for people who are writing their own
+libraries. Sorry, but the IDE is a little less painful in 6.0.
+
+I removed the position inlet from the light object. If you want
+to move/rotate a world_light/light, then just put a translate
+or rotate object into the chain. It was broken before, but now
+there is no reason for the position inlet.
+
+light and world_light accept a "debug" message with a value of
+1 or 0. Look at the gemLightSphere.pd patch for an example.
+It was too hard to figure out where the light is, and this turns on
+a sphere for the light object (since it is a point light), and
+a cone for the world_light object (since it is a directional
+light). The world_light is NOT a spot light, even though
+its icon is a cone. The icons are the color of the light.
+
+MarkEx has been merged into GEM. I was tired of maintaining
+two libraries. Also, people didn't seem to be downloading
+MarkEx, and there are a lot of good objects in there, IMHO.
+
+The camera object is finally useable. It has an inlet for the
+translation and rotation vectors. Anyone who was using it
+before is now broken, but the change was very necessary.
+
+gemwin can accept a perspective message. This will set up the
+viewing paramaters for the window. You need to pass in 6 floats
+with the "perspective" message, for the left, right, bottom,
+top, front, and back. The defaults are -1., 1., -1., 1., 1., 20.
+If you send a reset message to gemwin, it will reset the perspective
+values as well.
+
+The big change in this release is a particle system. It is based
+on code from David McAllister. There are many new object, all
+of which interact in certain ways. One design issue is that
+there are far too many controls and variables to be able to
+expose directly in GEM. People who want to get complete control
+over all aspects of the particle system are going to need to
+write their own externals. However, most people should be fine with
+the particle objects. The new objects are:
+
+CREATION
+--------
+part_head - The start of a particle group
+part_color - Set the range of colors for the new particles
+part_size - Set the size of new particles
+part_velsphere - Set the velocity based on a sphere distribution
+ You need 4 args - xvel, yvel, zvel, and radius
+part_velcone - Set the velocity based on a cone distribution
+
+part_source - Generate particles
+
+MANIP
+-----
+part_follow - Particles will follow each other like a snake
+part_gravity - Have the particles accelerate in a direction
+part_killold - Remove particles past a certain age
+part_killslow - Remove particles below a certain speed
+part_orbitpoint - Orbit the particles around a specified point
+
+part_draw - Apply the actions and render the particles. Accepts a
+ message "draw line" or "draw point" to change the drawing style.
+
+Look in the example files to get some idea how to use the particle
+objects. Notice that you still need a gemhead starting off the
+chain, but after that, you just use the part_* objects. Regular
+GEM manips like rotate, translateXYZ, and scale will affect the
+particles. In general, you start with part_head, then modify
+the particle parameters with the creation objects like part_color
+and part_velocity. Then use part_source to actual generate the
+particles. Next in the chain, use the manip objects to control
+the particles behavior. When you actually want to display the
+particles, use part_draw. Make sure that you remove particles as
+well. The best method is probably with part_killold. If you
+don't remove particles, then you will eventually not be able to
+add any new ones (the default number of particles at once is
+1000, set by part_head). You can also slow down the rate of the
+particle generation with the part_source object.
+
+---------------------------------------------------------------
+---------------------------- 0.78 -----------------------------
+If you don't want GEM to take control of the tablet if it finds
+one, set the environment variable GEM_NO_TABLET to the
+value "1" (no quotes of course). There will be a print out if
+GEM finds the environment variable.
+
+I added a few more setup access function so that people who
+use "-lib gem" or "-lib GEM" will work correctly.
+
+Lighting will now work under single buffer mode, but you have
+to destroy then create the graphics window to change the mode. This
+will not work with the GEM_SINGLE_CONTEXT variable.
+
+pix_data is a new object. It outputs color information from a pix.
+ The first inlet accepts a bang to trigger it.
+ The second inlet accepts a gem list (probably from pix_image)
+ The third inlet is the x position (between 0 and 1)
+ The fourth inlet is the y position (between 0 and 1)
+ The first outlet is the gem list
+ The second outlet is the color (an RGB list)
+ The third outlet is the gray scale value (a float)
+ See the example patches gemPixDataSimple.pd and gemPixDataComplex.pd
+for possible use.
+
+Fixed a pretty bad bug in the SGI image loading. Basically, unless
+the image was RGBA, it was going to core dump. Also, the orientation
+was wrong.
+
+---------------------------------------------------------------
+---------------------------- 0.77 -----------------------------
+GEM is now under the Gnu Public License. This should not affect
+any one. I also cleaned up the license information for the AuxLibs.
+All of the license and usage information can be found in
+GEM.LICENSE.TERMS
+
+GEM has a new home - http://www.danks.org/mark/GEM
+
+gemorb - a new object to interface with the SpaceTec SpaceOrb360.
+It is a 6DoF ball with 6 buttons that connects to your serial port.
+It is a very cool device, and is relatively cheap ($50 US). If gemorb
+is able to connect, it will print out a message, or an error if there
+is a problem. John Stone wrote the library.
+
+There is a particle system with a number of new objects. The system
+uses a library by David McAllister.
+ps I haven't had time to bring all of the objects online. particle
+is the only object right now. It just creates a fountain.
+
+accumrotate was added - three inlets to control the rotation. Each
+time a new value is sent in, it increases the rotation. Sending
+'reset' to the leftmost inlet sets the rotation matrix to
+identity (ie, it resets it to no rotation).
+
+rotateXYZ was added - three inlets to control the rotation. Order
+is X rotation, then Y, then Z.
+
+The tablet cleanup is a little better now on WinNT. There are still
+some bugs, like it doesn't return to normal mouse usage after GEM exits.
+However, the DLL is being released correctly...I just need to reset
+to the default state somehow.
+
+Cone and sphere have changed behavior as of 0.77. The middle inlet
+is now the size and the right inlet is the number of slices.
+
+depth used to be sending '1' would turn on depth testing, but this
+was conceptually wrong. It should be 1 to turn on the depth
+object (which would disable depth testing). This is now the
+current behavior.
+
+ortho was added. It changes the viewing from perspective to
+orthogonal. The size is the size of the window with (0, 0)
+being the lower left corner. I made this object for creating
+a background the size of the window, but you can probably
+find other uses for it.
+
+There is a matrix class for those who are writing objects.
+It is in src/Base/Matrix.
+
+---------------------------------------------------------------
+---------------------------- 0.76 -----------------------------
+Fixed a bug in spline-path. I wasn't doing the knot logic
+correctly. Thanks to Patrick Rost for finding this.
+
+A bunch of internal changes to get GEM working with Pd 0.22
+All instances of A_INT went away and the inlets and outlets are
+created in the correct "logical" order now.
+
+---------------------------------------------------------------
+---------------------------- 0.75 -----------------------------
+You can resize the window under WinNT and the viewport will change
+to reflect the new size.
+
+Also, the correct aspect ratio is maintained no matter what the
+width/height ratio is for the GEM window. The ratio is
+x:y -> (width/height):1. This is currently only under WinNT.
+
+gemmouse and gemtablet are new objects. They currently only
+work in WinNT. You should be able to create the object in
+the Irix/Linux versions, but you won't get any output. See
+gemmouse.pd and gemtablet.pd for examples.
+gemmouse outputs the current mouse position and button up/down
+for the GEM window.
+gemtablet outputs the current pen position, pressure, orientation,
+and pen up/down, with the GEM window mapped to the tablet. If
+GEM can connect to your tablet, a message will be printed at startup.
+If you don't see a message at startup from GEM about connecting to
+the tablet, then gemtablet will not output any values. You must
+have the wintab32.dll library installed. Your tablet's installation
+should do this.
+
+Added a bunch of utility functions (spline, bias functions, etc).
+
+linear_path and spline_path are new objects. If you give them
+an array, then they will generate a point from an index. linear_path
+will linearly interpolate between points. spline_path uses the
+points as knots for a curve. See gemSplinePath.pd and
+gemLinearPath.pd for examples.
+
+Added __declspec declarations for Windows. This should
+make it easy for people to use GEM as a dll.
+
+---------------------------------------------------------------
+---------------------------- 0.74 -----------------------------
+I replaced the images in the example directory with JPGs. They
+are alot smaller. However, in gemMoveImages.pd, you can see
+the effect that the compression has. Look at the red dancer. All
+of the "black" should be alpha masked out, yet there are little
+bits which get all jaggy.
+
+Got gltt-1.8 Looks like it fixes a bunch of bugs.
+
+Finally put an alpha test into the alpha object. This means that
+if the alpha of a pixel == 0., then it won't be put written into
+the frame buffer. Look at the example file gemMoveImages.pd for
+an example of this. Notice that the dancer is texture mapped to
+a sphere, yet you can always see her correctly. You can disable
+this behavior by sending a 'test 0' to the alpha object.
+
+Oh boy, were my texture coordinates off. Unknown to me, my reference
+image (dancer.tif) was actually upside down. This meant that all
+of the texture coordinates in the Geos objects were compensating
+for the rotation. Sorry if this messes anyone up, but it is now
+correct for all of the geos.
+
+I also now load in images in OpenGL format. This means that
+data[0][0] == lower-left corner. This shouldn't have any effect
+on anyone unless you are doing position sensitive image processing.
+
+Fixed the orientation problem when using pix_draw.
+
+imageVert handles gray8 pixes
+
+Fixed a problem if pix_multiimage loaded in images that were different
+formats or sizes.
+
+GEM supports search paths! Basically, GEM will look for auxiliary
+files (images, models, fonts, etc.) from whatever directory the
+patch is in (unless you use an absolute path name with '/').
+
+---------------------------------------------------------------
+---------------------------- 0.73 -----------------------------
+Fixed profiling on Unix
+
+Added text2d, text3d, textoutline. The text objects will render
+a truetype font (I have provided a couple fonts in gem/examples).
+text2d renders a flat bitmap...no rotation or Z movement. text3d is
+full polygonal text, so you can translate and rotate. textoutline
+is also polygonal, it is just a vectored outline.
+ PS text2d has some problems...
+
+JPEG and SGI image file formats are supported! Depending on the number
+of color components, GEM will automatically convert them to grayscale
+or RGBA (just like TIFF files).
+
+pix_video is working slightly on WinNT. There are still some
+serious problems, so consider this version a complete pre-alpha. I'm
+releasing a version now to find out if it even works on other systems.
+I am using a Connectix QuickCam2.
+
+Shifted all of the auxilary libraries into a common directory. Considering
+that I'm currently using 6 outside packages, it is just easier.
+
+---------------------------------------------------------------
+---------------------------- 0.72 -----------------------------
+
+Did a bunch of cleaning so that the Linux compile is happier (and easier).
+This involved getting rid of some warning messages and changing
+the makefiles slightly.
+
+The strange core dump on WinNT went away...
+
+All of the code and extra files are under source code control (CVS).
+You can just ignore the CVS directories. Eventually, I will try to keep
+them out of the release build.
+
+Added profiling. If you send 'profile 1' to gemwin, then normal profiling
+is turned on (GEM displays the number of milliseconds per frame). If you
+send 'profile 2', then images will not be cached (ie, the pixes will always
+be processed). If you send 'profile 0', then profiling is turned off.
+
+pix_multiply multiplies the color components of two images together.
+It doesn't modify the alpha channel.
+
+Optimized pix code.
+
+Because Miller is removing the INT type, I have slowly been moving it
+out of the code. If any objects have stopped working, please let me know.
+I redid the construction macros in CPPExtern to reflect this change.
+If you have made any new GEM objects, you will probably need to
+change to the new macro format.
+
+Most of the dual input pix objects will process gray8 and RGBA data
+gracefully.
+
+---------------------------------------------------------------
+---------------------------- 0.71 -----------------------------
+
+Guenter got GEM working under Linux! The biggest impact is that I
+have changed all of the #ifdef __sgi to #ifdef _UNIX_ If specific versions
+of Un*x need certain things, then they can be #ifdef'ed with __sgi,
+or LINUX, or whatever.
+
+Fixed a bug in polygon and curve. I'm not sure why it ever worked on
+the SGI...
+
+All pix objects accept a 0 or 1 to turn on and off their processing.
+The 0 or 1 should just be sent to the first inlet.
+
+The inlets were backwards for colorRGB.
+
+Fixed a bug in turning on and off texture mapping in pix_texture.
+
+GemMan::initGem is now called from Gem_setup. There seems to be a problem
+with Linux creating the dummy static class to initialize GEM.
+
+Changes pix_texture so that it deal with OpenGL 1.1, GL_EXT_texture_obj,
+and base OpenGL 1.0 I think that every OS has the texture_obj
+extension, but just in case, I also have the OpenGL 1.0 technique of display
+lists.
+
+Removed some spurious print outs.
+
+I looked into using GL_BGRA_EXT for images on Windows. It is faster
+in the software version, but my Intergraph card doesn't support it.
+It only makes a difference for OpenGL in software...and texture
+download time isn't the primary problem then. With a 512x512 image
+using glDrawPixels in software, I got 6 frames/sec with RGBA and 7
+frames/sec with BGRA_EXT. Older SGIs like ABGR_EXT, but the newer machines
+want RGBA. Looks like I'm going to stick with RGBA for a while.
+
+You can now load in Gray8 and RGBA images and they will retain their
+format. Before, everything was slammed into an RGBA image, with A == 255.
+This means that you can have alpha masks on images, etc. The only pix
+object which can currently handle a gray8 is pix_mask. All of the other
+pixes throw errors if they get a gray8. This will slowly be fixed.
+
+Added some new functions to GemPixUtil (from a paper by Alvy Ray Smith).
+They should speed things up. Currently, only pix_composite is using them.
+
+The color channels of pixels should be gotten by the const ints that
+are in GemPixUtil (for instance, chRed, chGreen, etc). Using hard coded
+offsets like 0 or 2 for red and blue is asking for trouble.
+
+gemheads no longer push and pop the entire matrix state when renderGL is
+called. This should be faster (push/pop is slow on some platforms). Also,
+all objects are required to "reset" the OpenGL state when they are done,
+so it shouldn't be neccessary.
+
+Strangeness: There is an unreferenced memory exception on WinNT when you
+quit Pd. However, it only happens if you use pix_image. It doesn't
+happen while you are using Pd, only when you quit...
+
+---------------------------------------------------------------
+---------------------------- 0.70 -----------------------------
+
+All geos can now accept a size argument (they default to 1.0)
+
+I cleaned up the texture coordinate mapping. The order was slightly
+random before. The order is more logical now; it is counterclockwise
+starting at 0, 0. If you use pix_coordinate any where, you will need
+to fix the values.
+
+Fixed a bug in translateXYZ. The inlets where backwards.
+
+You can now move the GEM window under NT. NT doesn't automatically
+take care of the basic window functions unless you pass the messages
+through (unlike X Windows).
+
+Texture mapping can be turned on and off by sending a 0 or 1 to pix_texture
+
+Texture mapping defaults to GL_LINEAR. Send a quality message to pix_texture
+to change this. A "quality 0" means GL_NEAREST, "quality 1" means GL_LINEAR.
+
+---------------------------------------------------------------
+---------------------------- 0.69 -----------------------------
+
+Fixed a bunch of bugs in imageVert.
+
+Cleaned up some lingering problems in various objects (the open message to
+pix_multiimage didn't work as advertised for instance).
+
+Setting window color is now dynamic.
+
+multimodel now exists. Works just like pix_multiimage, only it reads in
+Alias/Wavefront files. It also has a caching mechanism.
+
+---------------------------------------------------------------
+---------------------------- 0.68 -----------------------------
+
+fixed pix_2grey so it uses real color weights, instead of just averaging
+the three colors.
+
+pix_image now works the same way as pix_multiimage. If you load in an
+image which another pix_image has already loaded, they will share the
+image. This means that if you create a bunch of dummy pix_image
+objects, you can send an open message to pix_images which have a gemhead
+connected to them and get instantaneous image changes.
+
+Found a MAJOR bug in the NT version of pix_texture. Basically, if you
+used it, the program would core dump.
+
+Found another bug in square. It involved texture mapping and texture
+coordinates (mainly when you don't designate them).
+
+Changed the default values for scaleXYZ (to 1, 1, 1) and translateXYZ
+(to 0, 0, 0)
+
+---------------------------------------------------------------
+---------------------------- 0.67 -----------------------------
+
+Forgot to add the arguments for the scale object. This has been fixed.
+
+Added translateXYZ, scaleXYZ, and colorRGB. These create three inlets
+which you can modify, instead of having to mess with vector messages.
+
+Fixed a bug in pix_image and pix_multiimage (or more, an unacceptable
+response to user error). Basically, if you started rendering without
+an image being loaded (or if an image failed to load, then you were
+_VERY_ likely to core dump. A check has been added, so this shouldn't
+be a problem anymore.
+
+pix_multiimage HAS CHANGED! It accepts up to four arguments:
+
+filename, number : will load the image files from 0 up to AND INCLUDING
+the number
+
+filename, lownum, highnum : will load the image files from the lownum up
+to AND INCLUDING the highnum
+
+filename, lownum, highnum, skiprate : will load the image files from
+the low num up to AND INCLUDING the highnum, but incrementing the counter
+by the skiprate, not by one.
+
+No matter how many images are loaded, you can change which image is
+displayed by sending a number. The number must be between 0 and the
+number of images which were loaded (notice that this number may not be
+the highnum!) If you try to display an image out of range, you will
+get an error.
+
+pix_multiimage now uses a shared cache. Basically, if you give two
+pix_multiimage objects the EXACT same values (filename, base number,
+top number and skip number), then they will use the same collection of
+images. This will save massive amounts of memory if there is any
+commonality between pix_multiimages.
+
+pix_flip - see help file
+
+---------------------------------------------------------------
+---------------------------- 0.66 -----------------------------
+
+Finished the port to NT (mainly had to get images working).
+
+Made pix_colormatrix - This is really good for things like saturation,
+hue rotate, etc. I will eventually include a bunch of matrices to do
+cool stuff. Check out Paul Haeberli's paper on color matrices at
+http://www.sgi.com/grafica/index.html
+
+I removed pix_color. It was a hold over from earlier days and I
+don't think that anyone (including myself) is using it any more.
+
+I got a title bar onto the graphics window, but you still can't move it
+around. I am not certain why this is the case, but I'll keep looking.
+
+I made general speed ups to most of the pix objects. Mainly, I have
+been removing GetPixel() and SetPixel() functions (they have a lot
+of overhead). I will continue to use Get/SetPixel() while I'm developing
+because they make things easy to deal with, but as objects get finished,
+I will remove them.
+
+Some of the manipulators (color, rotate, and translate) accept arguments.
+For instance, if you do color 1 0 0, it will automatically set the
+color to red. The objects try to be intelligent about their arguments.
+For instance, if color receives three args, it sets RGB, but if it
+gets 4, it sets RGBA. If rotate or translate get 3 args, then they just
+set the vector, but if they get 4, then they set both the vector and
+the value.
+
+---------------------------------------------------------------
+---------------------------- 0.65 -----------------------------
+
+GEM works under NT! I got the port working last night. I had to make some
+major changes to the underlying classes (specifically CPPExtern) because
+MS VisC++ puts the vtable pointer in the first four bytes...no matter what.
+This is a different behavior than SGI's compiler (and I think that it requires
+more work for MS VisC++'s compiler). While it was a pain to change things, it
+is good in the long run. The C++ standard doesn't say where the vtable is
+located, so this would have bitten me at some point.
+
+---------------------------------------------------------------
+---------------------------- 0.64 -----------------------------
+
+Because MS VisC++ really wants files to end in .cpp (how stupid...),
+I renamed all of the C++ files.
+
+I looked into making all of the pixes be float, instead of unsigned char. This
+would give increased flexibility because we could use negative numbers, not
+worry about wrap around on the unsigned char, etc. In running performance
+tests on an SGI O2, the performance difference is fairly great. If GEM
+was only an image processing program (ie, PhotoShop), then I would definetely
+have pixes be floats. However, since GEM is meant for real-time, I will
+continue to use unsigned chars to represent pixels.
+
+For the tech heads...I used to generate the rendering by creating a
+linked list of the GEM objects. The problem was that objects like
+separator weren't possible because it wasn't a true DAG. That is now
+fixed so that tree/leaf graphs are possible.
+
+Made render_trigger so you can know exactly when the rendering is occuring.
+
+Made pix_multiimage! Just give it a file with a * (like myfiles*.tif) and an
+integer for a range (the number of images).
+
+Made pix_invert, separator
+
+---------------------------------------------------------------
+---------------------------- 0.63 -----------------------------
+
+The src directory has been made into a tree.
+
+Made pix_add and pix_subtract
+Added a scale object
+
+---------------------------------------------------------------
+---------------------------- 0.62 -----------------------------
+
+A dummy glxContext is created at startup. What this means is that
+in the constructors of objects, OpenGL calls can be made, display
+lists can be constructed, etc. Eventually, I would like to have a
+single window which is always in existance that can change between
+single and double buffering, but that may be a little while.
+
+I put Sam Leffler's tiff library back in. All image files must be in
+TIFF format again. Basically, I think that Win NT would have trouble
+making SGI .rgb files, while anyone can make TIFF formats. Currently
+there is some code bloat because libtiff does more than just read in a
+TIFF file.
+
+The pix_coordinate object allows users to set the S,T texture coordinates
+for geos. For instance, by giving pix_coordinate 4 S,T pairs, the texture
+coordinates for a square can be changed on the fly. Not all of the geos
+can support this ability right now (currently only square, triangle, and
+polygon, but this will change in the near future).
+
+A FAQ has been started, but there really aren't any questions in it yet.
+As people think of them, please let me know and I'll add them.
+
+---------------------------------------------------------------
+---------------------------- 0.61 -----------------------------
+
+Cocoon html help files for developers have been created.
+
+GEM now uses an internally generated DAG for rendering. This
+removes a serious bug where by objects could still try to reference
+dangling pointers. GEM objects act like the tidle objects do
+from a users point of view. Even if you break a connection
+in a GEM chain, the GEM objects will continue to work. This
+means that it is safe to edit patches while a GEM chain is
+running. To rebuild the GEM patch, rendering must be turned
+off and then back on (just like the tilde objects).
+
+Using the td library from Evans & Sutherland by Nate Robbins to display
+Alias/Wavefront files (.obj). It also takes care of image
+loading, although it is only .rgb. If people complain enough,
+then I may return to the Sam's libTiff library, but it is so
+big that the td library is better. The td library can also be
+compiled on Windows (or else I wouldn't have used it). The new
+object is called model (although it may change its name some day).
+
+There is a new object which maps the color of a pix to the Z of
+a polygon. It is isn't overly useful right now, but it is a cool
+demo. It is called imageVert.
+
+---------------------------------------------------------------
+---------------------------- 0.60 -----------------------------
+
+Major changes to the internals of GEM. gemwin is now only
+an access point to the window manager, instead of actually
+being the window manager. This should make it easier to have
+multiple graphics windows.
+
+While I was getting the O2 video camera to work, I seem to
+have broken the Indycam object...
+
+---------------------------------------------------------------
+---------------------------- 0.50 -----------------------------
+
+Made the port from Max over to Pd. Redesigned the class
+heirarchy somewhat.
+