[Bugs] #1248 UNSP: Trace trajectories of bodies

SugarLabs Bugs bugtracker-noreply at sugarlabs.org
Sun Aug 30 01:26:35 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 asaf):

 Replying to [comment:2 garycmartin]:
 > 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.

 Done

 > > 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.

 Done


 > > Should there be more than one pain daub per body?
 >
 > Yes. I'm not sure how the UI could indicate only one was allowed.

 It currently allows only one paint daub. Let's see how it works out.

 BTW, I'm using an extra loop inside the activity's main loop just so I can
 draw the yellow dot that indicates where the paint is coming from. I'm not
 sure how badly it affects performance.

 I'm drawing the dots into a pygame surface and then blitting that
 onscreen. When we start working on saving the traces it will be as easy as
 {{{
 pygame.image.save(trace,'trace.png')
 }}}

 > 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).

 I think it is ready for testing but I'm not sure what you mean by the
 "trivial case". Also, I guess you're talking about testing it on an XO so
 I'll leave that to you.

 PS. Added another screenshot

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


More information about the Bugs mailing list