here, i set the frame rate to 1, and tried to move the mouse 1 px persecond. i added traces for everything on both enterframe and mousemove events. you can start to see the asychronicity between setting the text and redrawing the stage:
onEnterFrame mc._x: 3.45 _xmouse: 149 text: 4 onMouseMove mc._x: 3.45 _xmouse: 150 text: 4 onEnterFrame mc._x: 4.45 _xmouse: 150 text: 4 onEnterFrame mc._x: 4.45 _xmouse: 150 text: 4 onMouseMove mc._x: 4.45 _xmouse: 149 text: 5 onEnterFrame mc._x: 3.45 _xmouse: 149 text: 5 On 2/28/07, Alain Rousseau <[EMAIL PROTECTED]> wrote:
onEnterFrame didn't give any better results either, it was definitely a case of how fast can Flash grab the exact _x postion when the button is released and the listener removed (or onEnterFrame deleted). Can't quite understand the logic of the sequence or timing, but it's definitely a case of asynchronous function call. John VanHorn wrote: > this seems to be tied to using a mouse listener. onMouseMove is not > synchronous with the frame rate, so it can fire more than once in between > frames....that being said, it still doesnt make sense that the _x > seemingly > increases if you drag left. > > if you use good ole onEnterFrame, everything works fine. > > On 2/28/07, Paul Hoza <[EMAIL PROTECTED]> wrote: >> >> >> Thanks for the reply... I tried what you're suggesting and still see the >> problem. I decided to make a quick example to see if anyone can see a >> problem in what I'm doing (and a demonstration of said funkiness.) This >> is out of context, so I think it's working okay as a demo. The code is >> included in case it sheds any light... the sample is pulled right out of >> my app, so it's the same controller I'm using (out of context, so there >> were tweaks to get it working standalone.) >> >> >> >> http://www.gamedevschool.com/samples/flashcoders/dragproblems/dragproblems.html >> >> >> Code: >> >> >> http://www.gamedevschool.com/samples/flashcoders/dragproblems/dragproblems.zip >> >> >> >> Thanks for any more insights! >> >> Paul >> >> >> >> Mick G wrote: >> > Perhaps it's doing some rounding because your mouse is sitting on half >> > pixels and it's not noticeable to the eye (if that's even possible). >> > Have >> > you tried putting a Math.ceil around the _x values to see if it helps >> > always >> > round the value up? >> > >> > >> > >> > On 2/28/07, David Cohn <[EMAIL PROTECTED]> wrote: >> >> >> >> Paul, >> >> >> >> I know it's no help, but I recently ran into this also and never >> >> found a workaround... >> >> >> >> I'd love to know if you find one! >> >> >> >> --Dave >> >> >> >> >> >> >> >> >> >> > Heya folks, >> >> > >> >> > This is baffling me (and making me very annoyed), and I haven't >> >> > found an >> >> > answer elsewhere, so here goes... >> >> > >> >> > I have a main movie with a custom drag "scrubber" control. At the >> >> > core >> >> > of my app (Flash 8 Pro) is this scrubber that needs to simply >> >> > return its >> >> > position so I can use it to display the proper frame of a movie >> clip >> >> > (with many frames). >> >> > >> >> > Problem is that dragging the scrubber in one direction very slowly >> >> > will >> >> > frequently get erratic and NOT just increase or decrease relevant >> >> > to the >> >> > drag direction. Now, I originally thought it could be poor >> rounding >> >> > math code on my part, but I finally put a text counter on the >> screen >> >> > that simply displays the value of "mcTheMovieClip._x" which is the >> >> > dragged clip. Here's what I mean by erratic: >> >> > >> >> > Dragging from left to right, ._x reports: >> >> > ..101, 102, 101, 102, 103, 104, .. >> >> > >> >> > What the friggin' poo?? What exactly causes a dragged movie >> clip to >> >> > jump back/forth a pixel or two? It's making an accurate, >> consistently >> >> > one-directional drag behavior to be roughly impossible! >> >> > >> >> > I'm miffed, but hopefully somebody has a clue on this and would >> be so >> >> > kind as to throw down some helpful bits. >> >> > >> >> > Thanks! >> >> > Paul Hoza >> >> >> >> _______________________________________________ >> >> [email protected] >> >> To change your subscription options or search the archive: >> >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> >> >> >> Brought to you by Fig Leaf Software >> >> Premier Authorized Adobe Consulting and Training >> >> http://www.figleaf.com >> >> http://training.figleaf.com >> >> >> > _______________________________________________ >> > [email protected] >> > To change your subscription options or search the archive: >> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> > >> > Brought to you by Fig Leaf Software >> > Premier Authorized Adobe Consulting and Training >> > http://www.figleaf.com >> > http://training.figleaf.com >> > >> _______________________________________________ >> [email protected] >> To change your subscription options or search the archive: >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> >> Brought to you by Fig Leaf Software >> Premier Authorized Adobe Consulting and Training >> http://www.figleaf.com >> http://training.figleaf.com >> > > > _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
-- John Van Horn [EMAIL PROTECTED] _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
