Detecting if zoomIn or zoomOut on 'zoomstart' - leaflet

I wrote a function which, on zoomstart, (should) do_something1 if I zoomIn and do_something2 when I zoomOut:
'var prevzoom = map.getZoom;
map.on('zoomstart', do_something);
function do_something(e){
var currzoom = map.getZoom();
var diff = currzoom - prevzoom;
if(diff > 0){do_something1}
else {do_something2}
prevzoom = currzoom;'
It behaves as follows:
1)when loading, if I zoomOut it do_something2 (and the second, third... time as well
2)when loading if I zoomIn it do_something2 (uncorrectly) but it do_something1 the second, third... time and so on...
3) when I change from ZoomIn to ZoomOut and viceversa the first time it behaves as the previous time and it behaves correctly on the second, third...time when zooming in the same way (i.e. In or Out).
I read in the post "Detecting if is zoom-in or zoom-out with leaflet" its it not possible to know if zoomIn or Out when the event zoomstart is triggered.
In my case it seems to work most of the time (which is not good anyway).
What I am missing/did wrong?
I have no knowledge in coding: thank you for help.
Giuseppe

Related

Fast alternatives for UIBezierPath

I'm making app, that can build graphs.
I'm working with UIBezierPath, and everything was fine until I decided to make it possible to move and scale the graph using gestures.
here's how i'm drawing:
var isFirstPoint = true
color.set()
funcPath.lineWidth = width
for i in 0...Int(bounds.size.width * contentScaleFactor) {
let cgX = CGFloat(i) / contentScaleFactor
let funcX = Double ((cgX - bounds.width / 2) / scale)
let funcY = function(funcX) * Double(scale)
guard !funcY.isNaN else { continue }
let cgY = -( CGFloat(funcY) - bounds.height / 2)
if isFirstPoint {
funcPath.move(to: CGPoint(x: cgX, y: cgY))
isFirstPoint = false
} else {
if cgY > max(bounds.size.width, bounds.size.height) * 2 {
isFirstPoint = true
} else {
funcPath.addLine(to: CGPoint(x: cgX, y: cgY) )
}
}
}
funcPath.stroke()
is there is a faster way to do it?
A couple of thoughts:
Rebuilding the path for every pixel can be an expensive process. One way to reduce this cost is to reduce the number of data points you render. For example, if you’re adjusting scale and rebuilding the whole path, you might want to use some step factor when updating the path mid-gesture, and replace your for loop with:
let step = 4
for i in stride(from: 0, through: Int(bounds.size.width * contentScaleFactor), by: step) {
...
}
Then, when the gesture ends, you might update the path one more time, with a step of 1.
The other way to do this is to not update the scale and call setNeedsDisplay each time, but rather to just update the transform of the view. (This can result in super fast behavior when zooming in, but is obviously problematic when zooming out, as portions excluded from the path won’t be rendered.)
If you’re testing this, make sure to test release (i.e. optimized) build on physical device. Debug builds, with all of their safety checks, can really slow down the process, which will stand out with something as computationally intensive as this.
By the way, it looks like the building of the path is buried in draw(rect:). I’d decouple the building of the UIBezierPath from the stroking of the path because while, yes, every time you update the function, you may want to update and draw the path, you definitely don’t want re-build the path every time draw(rect:) is called.
Once you do that, the draw(rect:) might not even be needed any. You might just add a CAShapeLayer as sublayer of the view’s layer, set the strokeColor and strokeWidth of that shape layer, and then update its path.
Generally moving and scaling is done by applying transforms to layers. Look at CAShapeLayer to hold your path. As the user gestures, apply transforms; then recreate the path when the gesture completes. In more advanced usage, you may recalculate the actual path more often than just when the user stops (such as if they pause without letting go), but these are refinements.
If you're able to describe the translation (pan) and scale as a CGAffineTransform then you can apply it to your UIBezierPath in one go using apply(_:).

Positioning Nodes At Below the Bottom of the Screen (Spritekit)

Hello I'm trying to spawn bullets at the bottom of my screen to travel upwards but the current code that I have spawns the bullets at the top of the screen. I've tried making the height negative and nothing happened. Here's the code I'm working with, thanks.
let randomBulletPosition = GKRandomDistribution(lowestValue: -300, highestValue: 300)
let position = CGFloat(randomBulletPosition.nextInt())
bullet.position = CGPoint(x: position, y: self.frame.size.height + bullet.size.height)
Some nice conversions will help you.
Now, do not do this all the time, this should be a one and done type deal, like in a lazy property.
First, we want to get the bottom of our view
let viewBottom = CGPoint(x:scene!.view!.midX,y:scene!.view!.frame.maxY) //In a UIView, 0,0 is the top left corner, so we look to bottom middle
Second, we want to convert the position to the scene
let sceneBottom = scene!.view!.convert(viewBottom, to:scene!)
Finally we want to convert to whatever node you need it to be a part of. (This is optional if you want to place it on the scene)
let nodeBottom = scene!.convert(sceneBottom,to:node)
Code should look like this:
let viewBottom = CGPoint(x:scene!.view!.midX,y:scene!.view!.frame.maxY)
let sceneBottom = scene!.view!.convert(viewBottom!, to:scene!)
let nodeBottom = scene!.convert(sceneBottom,to:node)
Of course, this is a little ugly.
Thankfully we have convertPoint and convert(_from:) to clean things up a little bit
let sceneBottom = scene.convertPoint(from:viewBottom)
Which means we can clean up the code to look like this:
let sceneBottom = scene.convertPoint(from:CGPoint(x:scene!.view!.midX,y:scene!.view!.frame.maxY))
let nodeBottom = node.convert(sceneBottom,from:scene!)
Then we can make it 1 line as:
let nodeBottom = node.convert(scene.convertPoint(from:CGPoint(x:scene!.view!.midX,y:scene!.view!.frame.maxY),from:scene!)
As long as the node is available to the class, we can make it lazy:
lazy var nodeBottom = self.node.convert(self.scene!.convertPoint(CGPoint(x:self.scene!.view!.midX,y:self.scene!.view!.frame.maxY),from:self.scene!)
This means the first time you call nodeBottom, it will do these calculations for you and store it into memory. Everytime after that, the number is preserved.
Now that you know where the bottom of the screen is in the coordinate system you want to use, you can assign the x value to whatever your random is producing, and you can subtract the (node.height * (1 - node.anchorPoint.y)) to fully hide your node from the scene.
Now keep in mind, if your node moves between various parents, this lazy will not update.
Also note, I unwrapped all optionals with !, you may want to be using ? and checking if it exists first.

Flipping a child sprite's xscale in Spritekit using Swift

Alright I'm offically stumped. I've been able to figure out my problems myself in the past but I'm lost on this one.
I'm trying to flip a child sprite's xscale. I want the flip to occur when the child's x position is negative. With the code below, the sprite does flip, every time the sprite reaches negative position, it loops back and forth flipping until reaching positive again.
I've tried numerous variations, but this is the code in it's simplest form. Any help or alternatives would be appreciative.
override func update(currentTime: CFTimeInterval) {
/* Called before each frame is rendered */
let pin = childNodeWithName(Pin1) as SKSpriteNode!
let guyPoint = guy.convertPoint(guy.position, fromNode: pin)
if guyPoint.x <= 0 {
guy.xScale = -1
}
else {
guy.xScale = 1
}
}
So if it is constantly flipping it's probably an issue of coordinate space. So check to make sure your convertPoint method is accurately returning the point you want. I would use println() to see what's going on there.
Probably what's happening is you want to flip the xScale when the child node is negative in the scene space or something (i.e. when the child is off the screen) but instead guyPoint might be the position of the child in its parent's coordinate space (so relative to the parent).
Also try with and without the else{} part to see if that changes anything.

Create custom transition in Corona SDK

I went through the docs and couldn't find anything.
Is it possible to create a custom transition?
I have to simulate a throw with custom easing etc.
In cocos2d I was able to just create a custom action, with corona I'm puzzled.
The docs are quite silent on the topic. However, if you do some trying out, you will find out that a custom easing function takes four parameters (only nil from the fifth parameter and up). Some playing around reveals that a custom easing function looks like this:
function easer(currentTime, duration, startValue, targetDelta)
...
end
Explanation
currentTime / duration: duration is self-explanatory, and currentTime is simply [0..duration] during the course of the transition.
startValue: Snapshot of the value at the beginning of the transition.
targetDelta: This is the value of the target-value, minus the startValue, i.e. the distance the easing-function "has to walk"
Annotated Example
Say you have the following code:
foo.frob = 1
transition.to(foo, {time=1001, frob=0.25})
I.e., you want a transition of foo.frob of [1..0.25]. Then:
function easer(currentTime, duration, startValue, targetDelta)
-- currentTime: [0..1001]
-- duration: 1001
-- startValue: 1
-- targetDelta: to-from = 0.25-1 = -0.75
return startValue + (currentTime/duration) * targetDelta -- a linear interpolator
end
Return Value
The return value should be startValue in the beginning, and startValue+targetDelta at the end. It is perfectly allowed to leave that range; however, once the transition stops, it automatically becomes startValue+targetDelta, so make it startValue and startValue+targetDelta at the beginning and end.
But you can be creative between the start and end, and let the function bounce back and forth, for example, like some of the included easing functions already do.
Well the answer is in the docs.
One of the params to transition.to is easing, which can be a custom function.

Discursive UIAlertView animation while continuous animation?

I'm trying to write a little app, where on the main screen, I animate a flying "bubble". This animation has to be continuous. (I reuse the bubbles, which fly off the screen) I heard that animations have to run on the main thread, as does every operation which changes the UI. Is this true? When I try to show a UIAlertView on this screen, it's animation becomes very discursive because of the continuous bubble animation. (this is a custom alertview with an indicator) The device is an iPhone 4, so I don't think it should be a problem to show a normal UIAlertView.
And I would like to ask if I use the correct method for the bubble animation. So first of all, I use an NSTimer, which invokes the startAnimation method in every 0.01 seconds (I start it in the controller's viewDidAppear: method). In the startAnimation method, at first I generate bubbles with random x and y coordinates (to see bubbles on the screen right after the viewdidappear), and I generate bubbles on the bottom with random x and y = 460 coordinates. In the startAnimation method, I run a counter (called frames), and when the value of this counter equals 35, I call the bubble generate method again.
The problem:
I store the generated bubbles in an array, and the 'gone' bubbles (which are off the screen) in another array. First I try to reuse the bubbles in the gonebubbles array, then if the array is run out, I generate new bubbles. While this operation is processed, the continuous animation stops, then continues. The break is about one second, but this is very disturbing.
Can anyone help in this problem? Thanks in advice, madik
- (void)viewDidAppear {
.
timer = [NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:#selector(startAnimation) userInfo:nil repeats:YES];
.
}
- (void)startAnimation {
self.current = [NSDate timeIntervalSinceReferenceDate];
double diff = (self.start - self.current);
if ( diff < 0 ) {
diff = (-1) * diff;
}
self.start = self.current;
frames++;
if ( shouldMoveBubbles ) {
[mug moveBubbles:diff];
}
if ( frames == 35 ) {
DebugLog(#"################################################################");
DebugLog(#"####################### FRAME = 35 ###########################");
DebugLog(#"################################################################");
[mug createNewBubbleOnTheBottomOfView:self.view];
frames = 0;
}
}
In the Mug class:
- (void)moveBubbles:(double)millisElapsed {
for (Bubble *bubble in bubbles) {
int bubbleSpeed = bubble.speed;
float deltaX = (float)(bubbleSpeed * -degrees_sinus * millisElapsed * 100);
float deltaY = (float)(bubbleSpeed * -degrees_cosinus * millisElapsed);
DebugLog(#"movebubbles x: %f, y:%f, speed: %d, sin:%f, cos:%f", deltaX, deltaY, bubbleSpeed, degrees_sinus, degrees_cosinus);
[bubble moveBubbleX:deltaX Y:deltaY];
}
}
And in the Bubble class:
- (void)moveBubbleX:(float)deltaX Y:(float)deltaY {
self.bubbleImage.center = CGPointMake(self.bubbleImage.center.x + deltaX, self.bubbleImage.center.y + deltaY);
}
This sounds like a memory problem. Slow UIAlertView animation is a sure sign of this. It sounds like the way you are generating bubbles is causing the problem. You mentioned the you keep two arrays of bubbles. You never say if you limit the number of bubbles that can be in either array at once. You also don't mention when you clean up these bubbles. It sounds like a memory "black hole". I'd recommend setting a maximum number of bubbles that you can show on screen at once.
Also, you mention a custom alert view. If you're modifying the UIAlertView, you're going to run into problems since that's not officially supported. Additionally, I've seen UIAlertView animation become slow when memory is tight. If you solve the memory issues with your bubbles, you'll probably solve this one too.
Finally, a word of advice. Making an animated game in UIKit is probably not a good idea. NSTimers are not as accurate as many people would like to think. UIImages are relatively expensive to load. Touching moving buttons is known to be unreliable at worst, hackish at best. I suggest looking into a game framework, such as Cocos2d-iphone.
Good luck!