My application works fine, but I have a function, what calculates a minimap based on the width of the original MC, but it doesn't work when the width is negative. So the question is basically, how can width be negative? what does it mean?
thanks
--edit:
sorry, I can't post any code, it's a 30K LOC project. The solution was to include this in another movieClip, where it worked better.
I expect your MC which width you're measuring is not on stage right now. I'm experiencing the same issue with my Sprite object, if it's not on stage its width is unreliable, while I have tried not asking for width, but asking for getBounds() instead. Try first adding it to stage, then requesting width.
I don't know your code. but i'm afraid overflow occur. MovieClip property width value is Number.
Numer of the range are as follows:
4.9406564584124654e-324 <= Number <=1.79769313486231e+308
if you've initialized a positive number to width, somewhere in the code will be occur overflow.
Related
I know that getBoundingClientRect() returns an object of type ClientRect or DOMRect, and each usually has properties like x, y, width, height, and more. And if you typeof those properties, you get Number.
So my question is, that Number is an amount of what? Pixels px, points pt, percentage %, and things like that are possible answers. I think it is pixels, but I am not completely sure about that. Could anyone confirm this?
Thank you to #Ken White for confirming the answer:
getBoundingClientRect() returns an array of Numbers that specify an amount of pixels (px).
For example there is an image using canvas with a rectangle in World Space. In doing so the camera/device can look around freely with the image placed into the "real" world. I wonder if there is a way to limit that "movement", spanning left to right, top to bottom but the device/camera view is limited at a certain point. Even if users turn the device/camera 360degrees, the view is stuck at a certain point. Say if the user pans left the camera/device stops at rotationY: 9, If right then stops at rotationY :-15, rotationX is stuck at 0.
I saw there's a BoundBox in the documentation but not sure what that is. There's a DeviceMotionModule but no idea how to use it. I don't know what the script example given is suppose to do.
Look into using DeviceMotion. https://sparkar.com/ar-studio/learn/documentation/reference/classes/devicemotionmodule
The script example rotates the 3d plane according to the rotation of the phone.
You will have to do some maths to position your objects according to rules and signal you get from DeviceMotion.
Using the reactive module you can access the "Clamp" method which is actually made to restrict values between two bounds. I recently found this out because I had a similar problem. From this page
clamp(x: ScalarSignal, min: ScalarSignal, max: ScalarSignal): ScalarSignal
Returns a signal with the value that is the value of the given x signal constrained to lie between the values of the given min and max signals.
Note: The behavior is undefined if min is greater than max.
I have a car object, and I want it to gradually rotate to the direction where the user clicked.
Every frame I did math to calculate the new direction it needs, and it's stored at car.direction. The actual direction is of course in car.rotation.
Now I want to update the rotation every frame until it's equal to the direction. However I tried everything and can't figure out how to do that.
By the way, I'm using FireFly, that is a gameengine built on top of Starling Framework, But I don't think it's relevant.
I would go with Marty's suggestion, use the smallestAngle function to determine which direction you should be rotating. Basically you can move some percentage of the smallestAngle during every frame update until the percentage of that smallestAngle is below some threshold (and have it "snap" the rest of the way).
Something like
//each time this is called it will get 1/4 closer, but never get to 0, hence the need for a threshold avoid paradoxes
//http://en.wikipedia.org/wiki/Zeno's_paradoxes#Dichotomy_paradox
var angleToMove:Number = smallestAngle()/4; //the divide by 4 here means get 1/4 of the angle gap closer each time this function is called, I assume this is on a timer or frame handler, making the 4 greater will make it follow more slowly, making it lower will make it follow more quickly, never reduce to or below 0 unless you want wonkiness
if(angleToMove<someRadianThreshold)
angleToMove = smallestAngle();
//use angleToMove to adjust the current heading/rotation
EDIT2: It seems that the big numbers are created because the movieclip doesnt hold any bipmapdata, but Im yet not sure about it, but my real mistake was that I just forgot "this" infront of one "getBounds" ... project size was to big and I couldnt find the bug =)
EDIT: tried to use seperate containers, for the movieclips, and did all this in the root class ... everything worked fine, when I used seperate containers and attached everything to the charakter class it got screwd up again
OLD:
Hey I am making a game right now and I want to get the bounds of the charakter body.
To understand how I did set the whole thing up I explain the hirarchy.
The class of my flash document is "game.as". "game.as" adds a Child of the class Charakter
my Charakterclass has a Movieclip for every body part, for example the "head"
every bodypart has a movieclip which contains the picture of the bodypart, in this case "head".
When I now try to use the getBounds(head.mc) inside the "head" class I get really weird results. ussualy something around x=64001, y=64001, width = 0, height = 0;
I found a way how to solve this problem by simply using the getBounds(head.mc) function not inside the head, but inside the Charakter class .... but this is not what I actually want to do, I would like to use the getBounds(head.mc) function inside the head class.
Any ideas why the results are so weird or what I have to do? Im very thankfull for every opinion, because this doesnt seem logical to me xD
getBounds() is inaccurate. Please read the following posts to understand the issue.
getBounds "wrong" results (Source)
When getting bounds of an object relative to it's OWN coordinate system,
those values will NOT be scaled.
getBounds() returning incorrect height (Source)
From inside head_mc, try getBounds(this.parent); (you may want to test to see if the parent exists first) - this should give you the bounds of your head_mc as its container sees it, which I think is what you want, but called from inside head_mc, as you request.
bitmapdata is right, though - getBounds() can sometimes give some odd results. It looks to me like you might be asking the question before you add head_mc to the stage, and are therefore getting the undefined values for width/height/x/y.
I need to do an endless horizontal scroll of elements within a parent MovieClip.
No matter what ever method I try, an element of 'drift' occurs and eventually the elements start to overlap.
I've tried using relative recursive tweening for each element according
but this method seems prone to quite a bit of error after repeated starts and stops.
//CODE START
function doScroll():void {
TweenLite.to(this, .25, {x:"20", ease:Linear.easeNone,onUpdate:checkPos,onComplete:doScroll});
}
//CODE END
I've reverted to doing absolute tweens to a predefined position using a contant speed. This seems to be more accurate but still some 'drift' occurs.
//CODE START
//_dest is predefined
var speed:Number = 500;
var dist:Number = this.x - _dest;
var distAbs:Number = dist < 0 ? -dist : dist;
//kludge to get constant velocity by recalculating time every frame
_time = distAbs / speed;
TweenLite.to(this, _time, {x:_dest, ease:Linear.easeNone,onComplete:reset});
//CODE END
Thought this should be very simple.
Can anyone point me to any possible tutorials or make any suggestions?
Any help appreciated.
Solution/Discussion at http://forums.greensock.com/viewtopic.php?f=1&t=6800
(warning: this is gonna require a rather lengthy explanation...)
It's a logic problem in your code. In your onUpdate, you were running conditional logic such that if the x position is beyond 980, it kills the tween and moves x back to -980 and starts things over. You're doing that for each individual item, each of which begins at a different position. That initial position affects when it crosses that threshold, thus when they reposition, the offsets are different.
For example, let's say item1 starts at an x position of 0 and item2 starts at 490 and both start moving at 400 pixels per second and your frame rate is 60, thus they'll move 6.66666 pixels per frame. Item1 will take 147 frames to hit 980. However, item2 will take 74 frames (actually 73.5, but there's no such thing as a half-frame) to cross the 980 threshold, but when it does so it will be at an x position of 983.333333. At that point it jumps back to -980 due to your conditional logic, but notice that it traveled an EXTRA 3.333333 pixels. You intended Item1 and item2 to travel at the exact same velocities and they do during the tween, but your onUpdate logic is misaligning them on the reposition such that in the end, some are traveling more than others which affects their overall velocity.
Another issue has to do with the fact that Flash rounds x/y coordinates of DisplayObjects to the nearest 0.05. So when you do your manual reposition (wrap), small rounding errors creep in. For example, let's say TweenLite sets the exact x value to 980.799. Flash will actually round that to 980.75. Then when you reposition it like this.x -= 980 and then tween it, the value would have just lost almost 0.05 pixels on that round. Do that many times and it can add up to a half-pixel or whole pixel (or more). All your items are crossing the threshold at slightly different spots, thus the rounding errors aren't the same, thus you start seeing slight variances in the spacing. Again, this is NOT an issue with the tweening engine. You'll see that the engine itself sets the values correctly, but Flash rounds them internally when applied to DisplayObjects.
A solution was posted at http://forums.greensock.com/viewtopic.php?f=1&t=6800 that includes an FLA and support files.
As others have suggested, I'd recommend having a single chunk of code that manages ALL the items that you're aligning/scrolling. It would lay things out from a single reference point so that everything lines up perfectly every time. You could tween a getter/setter that applies the logic. I use that technique all the time and it works great. You can see a smaller-scale example in the code I attached in the above URL (the scrollX getter/setter in ItemBase.as)
If you will be tweening all background elements at the same rate indefinitely on a single dimension - why not use a Timer and bypass tweening libraries entirely?