How can I stop objects from disappearing? - buildbox

I'm developing a game with Buildbox and I'm facing a problem that I have no idea how to solve.
In practice I am making a vertical scrolling game where you can only go up. An endless climb in which to avoid obstacles, traps and so on.
To move the gameplay a little, I decided to insert a pinball section in which to hit objects with a ball to break free and continue the climb. The problem I have concerns the levers to hit the ball.
If I try the stage individually there are no problems, but if I pass the stage to come back again and continue the game normally, the sticks tend to disappear after a couple of interactions with them.
The yellow points are the levers, the blue points are the triggers that bring the levers back to the starting position if they should go out of place
I have already tried the following solutions:
Add a spawner command, but the result is a constant spawn of the stick in the starting position compared to what I need. Even if the lever receives interaction or command to move.
Tie the lever to other fixed elements of the scenario, but the result is that the lever does not move, rightly.
Tie the lever to other movable elements of the scenario.
Increase the back and side deletion threshold.
Cancel and redo the levers.
I noticed that the levers disappeared because I moved them while passing from one stage to another. They disappeared because the button to make the character jump is superimposed on the one to move the levers. I made sure that the buttons did not interpenetrate, but nothing changed, the only thing I got is that the levers are not already gone when I return to the stage, but that they disappear as soon as I move them again.
I also tried to remove the triggers, but the levers do a thousand turns on themselves and then disappear anyway.

Related

Do animations use juice while the view is hidden?

I have this small view V
v: UICrazyView
which has sundry animations, which run often, and which follow various annoying states and inputs.
Now on top of that, from time to time the whole thing is just hidden
var slideAwaySomePanel: Bool {
didSet {
.. do many other things
v.isHidden = slideAwaySomePanel
}
}
It might be hidden for a minute, an hour, forever, or never.
It occurred to me, while V is hidden ... are the animations still running?
Do they still use a lot of battery/performance?
I was about to override isHidden and start writing a whole lot of fragile PITA code that would know what to do as isHidden is toggled, but maybe that is pointless.
I wish to know
When you isHidden, do all the calculations (and even drawing?) continue for the ongoing animations? Are you still using battery? Should we carefully stop everything during isHidden to save battery / performance. Or, does isHidden stop everything anyway? Or does it still do the timers and curves, but not waste any power on drawing?
Do all the timers and so on actually "pause" when you go in to isHidden? If you have an endless repeating animation, or, a 10 second fade or such, does it "hold" at an exact position, and continue when you not isHidden? Or what happens?
In short should we carefully and tediously stop by-hand animations, when isHidden is in effect? Or is there no point?
(It occurs to me, this is very much like in cg where you either do or don't have animations or other physics ongoing when objects are occluded or out of the frustrum. For this reason game engines simply have a toggle to decide on exactly that behavior "keep going or not when I'm offscreen?")
I'm pretty sure, even though I have no reference, that hidden views are not animated because Core Animation was implemented very efficiently in terms of performance.
Core animation layers and animations have their own clock. The animation state is calculated from this time. The clock continues to run when the view is not visible. Since neither the layer nor the animation object are destroyed by hiding the view, the animation has exactly the same state after reappearing that it would have had if the view had not been hidden.
Apple gives some nice examples how to modify the animation timing for some use cases.

Find which bit of code is moving an iOS UIView

I don't know how, but after moving two of my UIViews, they are moving back to their starting x/y position every so often. I've checked the code and I'm not moving them back to their starting positions directly, but they are going back there somehow.
What technique would you suggest to find which bit of code is moving them?
(I am 'hiding' them at one point (alpha=0.5, userInteractionEnabled=NO) and then re-showing them. That couldn't be it could it?)

Animation/Redrawing of moving panels is flickering badly - suggestions?

Hoping some of you out there will be able to point me in the right direction to handle flickering/tearing/redrawing issues when I 'animate' some components in an application.
I have to preface this by saying that the 'animations' seem to work correctly (no flickering etc) when not in full screen mode - i.e. 1024*768, borderstyle=bsSingle. It's when the application takes over the full monitor and the borderstyle becomes bsNone, that this issue becomes more than apparent.
There are 2 'animations':
1 - Panels scrolling left to right using the Winapi AnimateWindow method
2 - TmsAdvPolyPager stepping through each one of its items and subsequently showing its 'page'
When scrolling the panels, the panel that is 'exiting' leaves a 'trail' and the animation seems to shudder, it's no longer smooth.
When stepping through the TmsAdvPolyPager items, the next item will sometimes not become highlighted and the page it shows often has 'residuals' from the previous panel.
Both animations are triggered by a timer - the AnimateWindow is in it's own thread, the PolyPager stepping is not.
So, basically - any thoughts on how to smooth out these animations and force a correct redrawing of the TmsAdvPolyPager component? First time trying this kind of stuff, so not totally sure what to look into it.
As always, help is much appreciated!
TPaintBox is what you need, possibly on a TScroller.
Dump the Panels and draw to rectangles on the TPaintbox canvas.
You have obviously written 99% of this code already so moving to defined rectangles shouldn't be a problem :)

Why is my UIWebView displaying nothing after I pull it onscreen?

I have a series of three UIWebViews, arranged side-by-side, each one sized to be full screen.
One of them is 'current', one is 'next', and the last is 'previous'. I have each one populated with test data currently (aptly named 'test one' 'test two' 'test three'). Long term I'll have more than three items to deal with.
Swipes cause the entire shebang to 'rotate' left or right, displaying the next / previous item in the cycle. The code for the rotation works, as far as I can tell, correctly. Current takes on the frame of previous, previous takes on next's frame, and next takes on the frame of current. I then adjust the pointers so that current is pointed to next (which is now placed as current) and so on. Sounds more complicated than it really is:
//code to animate this process properly ommited
previous.hidden=1
CGrect tempFrame=current.frame;
current.frame=previous.frame;
previous.frame=next.frame;
next.frame=tempFrame;
previous.hidden=0
//Adjust the actual pointers so they accurately describe their current positions
UIWebView *temp=current;
current=previous;
previous=next;
next=current;
My only issue is that the web views if you go 2 or more in a given direct slide in 'blank'. E. G. swipe right and you go from test 1 to test 2. Swipe right again, and you get a blank screen. THe frames are all correct, the webview is placed correctly, but it's contents are blank.
Confusing thing is, if you swipe once in the opposite direction, and then back, it displays properly. (E. g. swipe three right, you have a blank; swipe left then back right, and it displays the 'correct' screen.)
Does anyone have any ideas what could possibly be causing this? I suspect that once I go to my next step ('real data' where next / previous is loaded with the appropriate item when it's slid in) it'll cause the current issue to vanish, but I want to understand THIS issue.
Edit:
I've managed to trace the issue, partially, to my 'hiding' the panel that should NOT be visible. Past that, I'm still not sure what is going on.
Turns out that it's related to hiding the 'unused' view in the shuffle. Why it works when I move backwards to it I don't know. By moving the 'unused' view to the very back of the order, everything works right.

Suppess UIView re-layout when child view changes

See UPDATE below:
I am confused about UIView layout as subviews are moving. I have a "Surface" UIView with several "Item" subviews on it. The user is allowed to click on the items and drag them around the surface.
What I have noticed though is that whenever a Surface's Item subview moves (is dragged by the user), the Surface is marked as needing to be relayed out.
I do not want the Surface to layout the Items after the user moved them. That is pretty much the whole point, I am allowing the user to position them as they see fit. However, there are times, initial creation is a prime example, where I do need the Surface to place the items.
So I would like one of two things:
A) Suppress SetNeedsLayout() calls on the surface when one of its Item subviews changes (moves).
--OR --
B) Know why I was asked to relayout, and if it was caused by Item motion then do nothing.
I cannot imagine I am the first to have this question.... :)
###### UPDATE:
After more investigation, I discovered more about what is going on. It is not that moving the Surface's items causes a Surface relayout, as I originally thought. It was only the initiation of a drag which caused the relayout. In digging further I discovered that it wasn't even the drag that was the cause, but a call to the Surface's bringSubviewToFront.
I need to bring the Item to the front, so that when it is dragged it appears on top of the others.
I can understand why bringing a subview might trigger a relayout, but again it is not what I want to happen.
May be you should override layoutSubviews in your Surface UIView.

Resources