[Bugs] #1248 UNSP: Trace trajectories of bodies

SugarLabs Bugs bugtracker-noreply at sugarlabs.org
Sun Aug 30 00:12:20 EDT 2009


#1248: Trace trajectories of bodies
------------------------------------------+---------------------------------
    Reporter:  asaf                       |          Owner:  asaf                       
        Type:  enhancement                |         Status:  accepted                   
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by Release Team
   Component:  Physics                    |        Version:  Unspecified                
    Severity:  Unspecified                |     Resolution:                             
    Keywords:                             |   Distribution:  Unspecified                
Status_field:  Unconfirmed                |  
------------------------------------------+---------------------------------

Comment(by garycmartin):

 Replying to [comment:1 asaf]:
 > I started working on this. I'm attaching a sample. I have some
 questions.

 Could you make a clone of the git rep (there's a button in right of
 gitorus menu), and push you changes there. That way if I need to make a
 bug fix release before you're/we're done the main git rep won't be in a
 half edited state :-) Then once done the reps can be merged.

 > *Should the paint daub be attached to the center of mass of the body?

 No, I'd say where ever you click. That way you can attach a paint daub say
 on a circle rim to generate a spiral as it rolls.

 > *Should there be more than one pain daub per body?

 Yes. I'm not sure how the UI could indicate only one was allowed.

 > *Should the paint color match the body's color?

 Yes that sounds like a good plan.

 > (The screenshot came out a little strange)

 Cool :-)

 > I think it's a good idea to get the trace-painting to behave as we want
 it to and add the functionality to save traces to the journal later.

 Are these dots an ever growing array of points getting rendered? If so my
 worry with this approach is memory and cpu speed redrawing on every frame.
 Could get very slow, very quickly. Drawing into a bit map and blitting
 that onscreen as the buffer wiper seems to give us a fixed memory
 footprint and render speed however many and long the trails get (though
 needs testing to make sure it's not too expensive for the trivial case).

-- 
Ticket URL: <http://dev.sugarlabs.org/ticket/1248#comment:2>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system


More information about the Bugs mailing list