Posts made by Deeeds

@kamdroid When/if you lose the smoothness you've gained with 0.0166666 timers, it's because they've been rounded to 0.02, which sometimes happens just by touching them in the Behaviour Editor.

In this situation, you need to re-edit their time to 0.0166666.

Other times, you'll still be running smooth, but your timer behaviours show 0.02 seconds, rounded. This is because it's only a visual representation rounding UNTIL you touch them, when it becomes a physical rounding of this time.

Hope this helps. I've played with this, a lot, to get smooth and fast in hyperPad.

My advice, never use anything other than divisions and multipliers of frame time in timers. Unfortunately hyperPad doesn't let you use divisions of this, it rounds these up to a "tick", but not accurately, which is what it's doing if you put a zero in a timer.

Solving this problem, in the best possible way, would be providing accurate tick based timers, that can be divisions or multipliers of the underlying tick. This is going to be much more important later this year, when more iPads (and iPhones) move to ProMotion (120fps).

@kamdroid I'm also in this. It's very spasmodic. And highly annoying.

@shady91 There was a specific bug/fault with the manner in which physics pivots/origins responded to changing graphics sizes, incorrectly. Or, far less than optimal, if you'd gotten used to it.

Correcting this was/is/did break things in previous projects. The pay off, in this case, is that you can now change graphics as much as you like, and their sizes, and get consistent, predictable, non peculiar results.

@lulabay Sort of. That's a different issue, stemming from the same root cause. One that's famous and integral to an un-fixed cocos2D-iPhone, which hyperPad is based upon. I've supplied them with sufficient info on the fix, they've said they can't (or won't) do it, despite it being something universal, and without side effects.

At the core of cocos2D-iPhone is a reliance on the unreliable, and uncertain flipping flags of a thing called CADisplayLink.

The solution I've shared, for this problem, will likely fix the audio and timing issues prevalent in iOS 12, as iOS 12 far more aggressively asserts control over (and more variance upon) CADisplayLink. Ultimately CADisplayLink will be completely untethered from any connection to device reality as it's used for all manner of frame rate efficiency variance efforts within iOS.

ProMotion displays are coming to iPhones sooner rather than later.

The solution, base the game loop on absolute time, and do own calculations of when a frame should be ready to present. Every other engine does this, as does every fixed version of cocos2D-iPhone. Or, you can do a hybrid approach, get ready to draw then wait for a CADisplayLink call, which many others do. Relying on CADisplayLink, though, causes the problem, as it's not regular, nor reliable.

This causes a race condition, wherein memory/objects aren't released until the OS senses memory pressure, at which point you see that stutter.

The two creators of hyperPad maybe forced to make a fix for iOS 12 that relies on Mach (absolute) time. It's not hard, and somewhere on these forums I've even posted the code to do it.

@thecheater887 are you using an iOS 12 beta?

@thecheater887 another work around, scale them up in editor, then make the first action ever done by them, in isolation, be to scale to desired size at game start.

The inverse works well, too, with objects too big that intrude on touch areas when editing.

@murtaza this is from the iOS 12 betas. It’s also happening in the older version of hyperPad. I’m also using latest betas of iOS. All have had this problem.

There’s also timing issues, within iOS 12, probably related. It uses display refresh signals differently from iOS 11.

@murtaza yes, please!

@jack8680 Williams arcade machines did a startup test that featured something like this, often referred to as a rug wipe. First 3 seconds of this video:

Part of the charm was the low colour count.

If you want to try different colourings, perhaps tones of a contrasting pair of colours might work well. Something like this:

https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=2ahUKEwiHvPWHkZPcAhWGad4KHX6pBgEQjRx6BAgBEAU&url=https%3A%2F%2Fwww.viget.com%2Farticles%2Fcolor-contrast%2F&psig=AOvVaw2zEGCj_LCTlh4SVJ-5nuL_&ust=1531263994198158

@hamed this locking, from the reliance on CADisplayLink falling behind, is also why hyperPad drains batteries. It's 100% CPU usage essentially looking/waiting for the next CADisplayLink, but which isn't enough for it to get back in front of itself. A loop just flogging and thrashing the system, needlessly.

@hamed

Perhaps you have a better memory than me, and most others. I find Objective-C Block syntax notoriously, how do I say this nicely... obtuse, peculiar, arbitrary and mindbendingly hard to remember.

There's a quite famous little web site that features this information. I made it into an iPad wallpaper, so that it was always nearby, instantly. Just wake your iPad, and there it is.

@hamed I know it's not ACTUALLY a memory leak, but it does 'leak' memory.

I know the reason, too. The lock cocos2D takes on the thread that would normally release objects, due to the reliance on CADisplayLink falling a frame (or more) behind real time. This is the exact reason that creating an iOS level interruption permits an unlocking of this thread to release objects and release the "leak".

As to what you're saying is not feasible... what and why? You mean resorting to Mach time at the core loop level isn't feasible?

@thecheater887 It's disappointing to see this isn't fixed. It's a core and crucial issue with older versions of cocos2D, and easily fixable, with a side effect of massively increased stability and consistent performance.

@itap-development If it's fairly obvious, why does hyperPad only have one? If things that are fairly obvious to you are fairly obvious, how did you miss the second sentence of the OP: "Say you want time to freeze for 10 seconds for some reason."?

@thecheater887

"hyperPad (latest version) degrades in performance steadily, until about 30 minutes In, it crashes. "

That sounds exactly like a memory leak coming from not fixing the issue at the core of cocos2D, a game loop dependency on the (flawed and irregular) CADisplayLink. Apple claims to have made CADisplayLink more reliable since iOS 11. It's only true if you're not reliant upon it, and fully understand why it fluctuates. Nobody does. And Apple isn't about to tell us why, because that will likely indicate what they're planning in terms of higher speed displays and adaptive frame rates.

btw, the older version of hyperPad also leaks memory, and eventually crashes, too, even on the latest Apple iPads. I've watched it in Xcode's profiler. But it did take a lot of time before it crashed, hours of use. Not 30 minutes. It would get unstable for me, often, well before it crashed, creating all sorts of weird issues.

One "fix" you can try is to pull down the notifications tray whilst you're running your game in play mode. And then exiting back to editing mode. This causes a brutal flush of the memory (on the older version) that brings some stability back.

@thecheater887

YESS!!!

And, add "Fixed but pending release..." With an estimate of release date.

@itap-development Ignoring the reasons why to set it at 0, this is a generally useful ability.

Timers should have two possible modes of operation:

• Game World Time (indexed to the rate of the game)

• Mach Time (absolute time, regardless of Game World Time Scaling/Changes/Rates)

Here's the most famous usage of this differentiation:

@thecheater887 Perhaps go a bit further, make this wider known and the title clearer, about the frequency of crashes. This is valuable information. Thank you.

@hamed for you...

@gamecrazy I saw this the last few times I exported a project, too.