What's odd is that I thought I saw something about a web browser being shown on the Apple Watch. I'm not entirely sure, as I don't have an apple watch, but I think it might support webviews. Why Apple would allow that for a watch, and not a TV, is strange.
The argument I've been hearing is that Apple wants high-quality apps for the Apple TV. Naturally, I disagree.
Anyway, I saw something interesting. I'm not sure if it was discussed...
As a detail: we do use the fromPath API already for the round rectangles and ellipse shapes. The version currently included in Hype didn't have support for concave polygons so that limited a lot of what we could do, but it has since been implemented so the door for shapes is quite open in the future .
A lot of projects become possible with Hype if SVG and custom (convex) collision shapes are available – especially if an image can be embedded into the SVG.
Update: I noticed something interesting in the SVG example. By clicking the “showInternalEdges” option, it shows that the collision shapes aren’t really convex. Instead, it’s just a series of concave shapes grouped together.
It looks like the shape edges are comprised of straight lines and not Bézier Curves. If the SVG isn’t flattened out too, that’s not a huge issue. The collision shape is invisible. I think this is what happens now with chamfering.
I noticed something different today. The keyCode numbers are different from Hype's "On Key Press" event than manually using the following JavaScript...
window.onkeydown=function(event){
I was working on getting Fullscreen mode to work, which is ideal for gaming, when I noticed the "F" keyCode was "70" when I used "onkeydown", but "102" when using Hype's "On Key Press" scene event.
It took me a while to realize what's going on. "On Key Press" appears to be case sensitive. It doesn't register the shift key right away. So if you've been following along in this thread, wondering why the keyCode numbers don't work, it might be the difference between onkeydown and onkeypress.
We feed a lot of small straight edges to matter.js; they take a "path" that is a series of points. We do the math to figure out a close approximation of roundness.
Note that this isn't related to Hype; it is just a difference between the keydown and keypress event. Hype does expose both, since they are (unfortunately) quite different. I'd recommend reading the post mentioned in here:
I think I might have landed on that page when trying to figure out what was going on.
I must have been really tired last weekend. I looked again and I can see that both are available. That's cool, because the difference is important for game development. An example would be pinball – where shift keys are great for flipper control.
Note to self... use event.location for detecting the difference between the shift keys.
This may be unrelated to the current thread but since finding out this thread I’ve been trying to analyse matterjs since it’s extremely fast on ipad but it’s documentation is really bare bone compared to something like physicsjs. Do you have any source of documentation apart from the docs page there you could share? Like any experiments you’ve found or experiments you’ve created using that library? I’d be very much interested in either of those to see it in use by others!
I mainly read the source code. At the time the documentation was good (at describing the APIs, not necessarily as tutorial material), but there were a few parts out of date.
While Hype still needs improvement with a Physics API, two new JavaScript APIs create lots of potential with game development. The “Bounce” project would have been a lot more difficult, if at all possible, before Hype 3.5. Good stuff is on the way!
It is more of an implementation issue - aside from timeline actions, they only have element properties. The gravity is a property of the scene/symbol. I understand the need to add this though (or at least give API access).
Controlling gravity dynamically would be a great bandaid fix until advanced physics settings / control can be added. It would be a way to move a hero actor, while still interacting other physics elements.
Hello. I joined the forums to make a suggestion to this post. I know I am very late to this post.
Why not use an established javascript physics or game engine and just import it?
I haven’t done heavy testing in Tumlut, but I think I have a good idea of its possibilities.
When creating the Physics feature, I evaluated several different physics engines to use. These were evaluated on features, ease in integrating with Hype, performance, file size/footprint, developer activity/community, and licensing. Matter.js seemed to hit the sweet spot on all of these aspects, and it continues to grow and add even more features I hope to take advantage of and expose to developers using Hype.
Of note, I did look at box2d-js, which is a JavaScript port of one of the more widely used physics engines for games. The minified size weighs in at over 700 KB and it would be practically infeasible for us to work with in Hype’s codebase.
Hype 3.5 does now expose a limited getter/setter API that allows for manipulations such as changing the position and rotation of elements. Theoretically if you wanted you could use your own physics engine and call into Hype’s APIs to manipulate elements if you wanted. (Though at this point I’d probably question why you’re using Hype instead of pure JS).
Well, it would be nice to see better game development tools added to Hype. Although, I just saw this… https://www.youtube.com/watch?v=hB6eY73sLV0 …and it looked impressive. Super Mario World was code-injected with Flappy Bird code. If people can program games using SNES controllers, then I really have to up my game development skills.
Surely there’s enough power in Hype – just as it is – to make something awesome.
Wow! Matter.js updates are packed full of potential. Chains, cloth and the stress and collision filtering,composite and soft body demos are wonderful.
Hope this does come to Hype 4
.
