Pocket Animator
Vector Animation solution for your Microsoft Pocket PC (and beyond).

                   Version 1.0
                   September 11, 2001
		   Dan Bjorkegren



===REQUIRED LIBRARIES===

MFC + Win32
It shouldn't be too difficult to tear away the vector manipulation code from 
MFC. I'm guessing for any big porting work most of the application would need 
to be altered.


STL
I compile with stlport



Flash SDK
right now Pocket Animator uses Macromedia's SDK, which is buggy and not open 
source
http://www.macromedia.com/software/flash/open/licensing/fileformat/

**ASAP the project should be switched to use Jesse's SWFSource SDK**
http://www.virtuascape.net/swfsource.html

The reason this SDK isn't being used right now is that I couldn't get IOStreams 
to compile for Windows CE (but maybe I'm just lazy).

Before the switch, due to licensing problems you'll have to download and fix :( 
the Macromedia SDK yourself.

(It'd also be cool to output to SVG. Shouldn't be too difficult to add.)

===GET IT TO COMPILE===

-->In Macromedia's SDK:

Macromedia.h
change assert to ASSERT

in Macromedia.h, FObj.h and FSound.h
comment out #include <assert.h>



FDTShapes.h
make FCXFormWAlpha derive from FCXForm instead of FACXForm
comment out all FCXFormWAlpha member variables but alphaMultTerm and alphaAddTerm
make FCXForm::MinBits() and FCXFormWAlpha::MinBits() virtual
change the FCXForm's member variables from private to protected
make FCXFormWAlpha::FCXFormWAlpha call FCXForm with all of the arguments that FCXForm supports. ( FCXFormWAlpha::FCXFormWAlpha(...) : FCXForm(...) )
comment out the initialization of all variables in FCXFormWAlpha's constructor except alphaAddTerm and alphaMultTerm



-->Setting up STLport
(get it from http://stlport.org/. these directions are for stlport 4.5)
Unpack STLPort somewhere
In eVC go "Tools":"Options", Click the "Directories" tab
for each CPU and platform you plan to compile to, add [your STLPort directory]\stlport

stlport\stl_user_config.h
uncomment #define _STLP_NO_IOSTREAMS 1
uncomment #define _STLP_USE_MFC 1

stlport\stl\_site_config.h
uncomment #define _STLP_NO_EXCEPTIONS 1
uncomment #define _STLP_NO_NAMESPACES 1




===OBJECT MODEL / ARCHITECTURE===

--Shapes--
I use some base vector classes to describe objects that can draw themselves and 
respond to events:

VShape
|
|--VPolyLine
|
|--VEllipse

Conceivably, multimedia objects like sounds could be added easily if derived 
from VShape.


Points are stored as VPoints. 
Internally points are stored at 50x more precision than they are drawn (at 
100%). This is for a number of reasons:

 1) a Pocket PC's touchscreen has a 4x greater resolution than its display
 2) transforms are destructive (so adding a scale transform of 1% messes up 
your points)
 3) Flash stores coordinates in twips (20x)
 3) this way you can zoom in and draw for greater accuracy

Points are converted from screen coordinates to document coordinates in the 
ScreenState class.


--Self Editing--
Most objects in Pocket Animator (all properties and controllers) are capable of 
self editing. That is, they derive from the VAbstractEditable class, and in 
response to a CreateEditor request they return a new VAbstractEditor. A 
VAbstractEditor basically creates and destroys a window in response to requests 
by its parent.

All this means is that the parent window doesn't need to know the type of data 
being edited, rather the data knows how to present itself to the user.

To make this work, seemingly pointless data types (such as VEditable_Percent) 
had to be constructed but this is just so that the data can have a specific 
editor (a VEditable_Percent creates a VEditor_Int with a "%" label)

(Sadly, this stuff is all tied to Win32, and most is tied to MFC)


  --Color--
  Since the Pocket PC doesn't provide a standard color picker dialog box I made 
my own. Looks a bit PhotoShoppy. See CColorPopupDialog.
  This dialog is popped up from the VEditor_VColor editor (if you hit "..."). 
The color editor is snazzy. It stores all of the colors you've used since you 
started the app (this should probably be persisted in the registry).



--Properties and Controllers--
Pocket Animator borrows the Property/Controller methodology from Kinetix 3d 
studio max. That is, properties of a shape (such as line thickness, color, etc) 
are can be linked to a controller. This architecture provides a powerful way 
to, well, control the shapes.


Right now the only controllers available are VPathController (controls 
properties of type VPoint) VKeyController (generic keyframe based controller)



  --Keyframe Interfaces--
  There are two interfaces for dealing with keyframes, one generic 
(VGenericKeyIterator), one specific (VKeyIterator<T>). 
  
  The generic interface is used for areas that do not know the type of data 
contained within the keyframes (such as the property dialog, where 
self-editing is used, or this would be used in a timeline).

  The templated interface is used for direct manipulation of shapes. For 
instance, when a shape is dragged, its movement controller is queried using 
the SupportsDirectManipulation method. If the controller returns true, then 
it will be manipulated through its VKeyIterator<VPoint> interface.

  -- Property Interfaces--
  Similarly, properties have generic (VAbstractProperty) and specific 
(VProperty<T>) interfaces.

  Not much to say about that. Each property could conceivably layer controllers 
to make weird effects, but that doesn't really work well as far as a PocketPC 
interface is concerned.


Right now, to make a new controller you must derive from VController<T> (the 
controller must be either generic or specific to one type) and add your 
controller to those iterated by the property's VControllerFactory interface. 
Quite yucky.

What should be done:
1) Make a registration thingy to support easily plugged in controllers as well 
as properties.
2) Make another layer so that controllers are expected to give numbers between 
1 and 65536 (or something) and then properties manipulate the number to their 
desire (for instance, scale might equate 1 to 1% and 65536 to 1000%, while 
opacity might equate 0% and 100%, respectively). In addition to simplifying 
controller writing, this would make it possible to make one dimensional 
controllers (for most properties) useable for two and three dimensional 
properties (such as movement / location [x,y] and color [r,g,b]).



--Transforms--
Transforms are properties that maintain a link to the shape they modify. Each 
time its ApplyTransform method is called, a transform's Evaluate method is 
called, and the resulting value is passed to its virtual Do method. 
*Transforms modify the actual shape.*
That is, they are destructive. So don't scale to 0%. 
(This is probably bad design on my part, but it speeds drawing and reduces 
memory consumption)




--Flash output--
Pocket Animator tries to optimize the Flash that it outputs (but doesn't do 
that great of a job). Even though shape morphs are unsupported, Morph Shapes 
are outputted whenever colors or line widths are animated. That means that the 
point locations of the shape are reported *twice* even though they are 
identical. Blame it on Flash. This could be better handled. Also, non-animated 
shapes can be put into the same shape object (using the shapechange)

Since VEllipse and VPolyLine are the same except for their point locations, the 
main Flash output is handled in VShape::FlashSDKPushFrame.
VShape calls the virtual FlashSDKCreateShapeRecordForThisPoint function with an 
in/out parameter pnPoint so that the shape's edges can be iterated.

Note that future shapes derived from VShape can override FlashSDKPushFrame to 
make shapes (or multimedia!) that are not similar to VEllipse or VPolyLine.

Now, I wonder how much of this code must be redone to switch libraries.