Everything is a placeholder. Only the motion is for wheel.
Jump & Spin.
From left to right, a lap to the chequered start/finish line. Hit the ceiling and gravity reverses, and the spin causes the opposite direction of travel.
I can't figure out how to embed the above video, so a screenshot to entice you to click on the above link...
Performance Tips:
Put everything you don't need interacting with your main characters on different layers. Just do it. The performance gains are real.
Make sure no images are stretched beyond 2048 pixels in any one dimension.
Crop your images as tightly as possible in image editor to get rid of as much extraneous Alpha pixels as possible
Use partial opacity sparingly, particularly on big images
Try to make everything you can think of a spawned item. When in doubt, spawn and destroy the original
Recycle particle systems by moving them to where you need them and restarting them instead of creating new ones
Edit sounds in audio editor so there's absolutely no clipping. OpenAL/cocos2D tries to reduce clipping and does so in a very costly manner
Don't be tempted to use the pitch change. It seems to be a live change and exasperates the clipping performance issue above. Record uniquely pitched sounds instead, and pick and play the ones you need
Preplay your sounds, with silent volume if need be, so they're cached before they need to be played. I don't know why this works, but it seems to make a big difference. I thought we were beyond the time in history when we needed to do things like this for audio on iOS.
Use Exponential eases on Colour changes with caution. They're costly. If at all possible, use Linear "eases". For colour changes, they're noticeably cheaper than others.
Push everything you need to store into central arrays. Use them as global storage. Faster and lighter and more reliable than Value and Box Containers.
Make everything you can into a Background image (not physics and not static/walls). Way less physics checking. If you can do this with things and not need to worry about them again, then you know these things are also suited to being put on another layer. So do that and forget about them.
Use broadcast and receive for every single thing you can think of. All the time. This way you can centralise everything and find anything and everything you need in little managers. Animation manager, Sprite Manager, Sound Manager, Creation Manager, etc.
Don't update labels frequently. They are unbelievably slow at any size that looks good.
If the Time Scale is set to 1/4 of normal time, the Move To Object Behaviour is only being updated every 4th frame.
Where's the updates?
News of updates?
introductions to your new programmers?
Any sign of momentum, at all?
@RobinsonX trust your own judgement. You'll know where and what to polish, and how and why to publish, and when you're onto something worthy of involving yourself in production completion. Until then, iterate, experiment and meander. Enjoy your increasing capacity for creativity through the very natural processes of discovery and discernment.
.mp4 or .m4v or whatever is natively easiest on iPad, into hyperPad as cutscenes, ending credits, pause screen backgrounds, level introductions, loading visuals, etc etc. Wherever they're used, however they're used.
Perhaps even as a background, if you can get it to run smooth and efficiently. But that's just games.
For the interactive entertainment and book crowd (not me, my daughter), it's a whole other level of usefulness. And a place where their viewers need controls like pause, skip, rewind, chapters, etc... which is where this comes in handy:
A while back, Apple finally made it a little easier to handle video with this: https://developer.apple.com/documentation/avkit
A lot less coding and research required to create players, etc. Almost straight forward. But still a very modern apple-ish framework. By which I mean "half arsed, under developed and the result of pseudo commitment to unexplained and uncertain initiatives baked in an oven fuelled by dreams from design-by-committee believers ignorant of quicktime's history."
Every bullet is fired from an anchor point of 100%, 100%, or top right, regardless of the rotation of the object.
ie it's not even listening to the orientation of the object, as it should be. So even in the sense it has, it's broken.
In terms of being inoperative: it doesn't matter what values are put into the anchor point to shoot from, they're disregarded.
I do a lot of thinking with an Apple Pencil™
My thoughts aren't as bright as they once were, but the Apple Pencil© is shiny.
It would be a huge help if you could license or import a drawing framework and permit me to do like the following in the Behaviours Editor:
Alternatively: BACKGROUND IMAGES! in the Behaviours Editor
let me import images into the background of the Behaviours editor where I can put screenshots of my notes so I can see them whilst editing Behaviours. Two options required here: Position Fixed and Float with Pan/Zoom.
Or... SPLITSCREEN!!!
add iOS Split Screen functionality so I can have my sketching app open to the side and refer to it whilst editing behaviours, and add notes when I fumble, fall, fail and flail.
This post may have been brought to you by Apple Pencil® Addiction
Behaviour On, Behaviour Off, Tags, Broadcast Messages, Receivers, etc.
Everywhere that a search can/could be performed have a search like this:
str
return results like:
myArrayString
myArrayStrange
myButton Strength
myScore_string
myXYZ_Strong
etc
@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.
@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:
@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.
