Pocket Animator Vector Animation solution for your Microsoft Pocket PC (and beyond). Version 1.0 August 30, 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. Basically, make FCXFormWAlpha derive from FCXForm in FDTShapes.h and FDTShapes.cpp. It'd also be cool to output to that SVG stuff. Shouldn't be too difficult to add. ===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) 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 (VSpecificKeyIterator). 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 VSpecificKeyIterator interface. -- Property Interfaces-- Similarly, properties have generic (VGenericProperty) and specific (VSpecificProperty) 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 (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 entry) 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.