We're taking advantage of WKWebview in Reflect, which has much better JavaScript performance. Glad to hear this speeds things up!
Well, the speedup was not by using Hype Reflect. I tested the project by loading it from a website.
It seems like the new WKWebview could be used to export Hype projects to mobile ā another way to make Hype more of a game development platform. (Export to iOS.)
I'll have to look more into this. I've been trying to port Hype projects to Xcode. If WKWebview worked for you, it will likely speed up my projects too.
Found this article which spells out some of the differences between the two. http://blog.initlabs.com/post/100113463211/wkwebview-vs-uiwebview
The blogger also links to an app in the app store that you can test any sites performance in both webviews.
WKWebView is the way to go. Apple says so themselves...
I tried converting my UIWebKit project to a WKWebKit project. It's in Swift, so I'm not exactly sure how to update it. That seems like my project for the weekend. Yet, there is an issue. You can see it in the comments of the article you linked.
Apparently, there's a bug with loading local files with WKWebView in iOS 8. It's fixed in iOS 9. So, my project supports iOS 7. WKWebView is iOS 8, but it's better in iOS 9. So, which platform do I target? (Tumult targeted iOS 8 with their app, and it's sorta loading local files, so maybe they figured something out... but Hype is basically running a local web server for project previewing.)
This all feels so unnecessarily complicated to me. Swift is supposed to make it easier to program, but it's still a lot of lines of code to load a web page in a box. Then there's the Main.storyboard to straighten out. Currently, my project has a blue box with "UIWebView" in the middle. I'm figuring that's not the right... ViewController? ...I'm not sure of the correct terminology. What I do know is that it's pretty annoying to have to drag a blue line from a box to a line of code. That process doesn't seem very intuitive.
The video linked above focuses on the "Safari View Controller", which I'm not sure is the right solution for running Hype generated, physics based, games on iOS/Apple. I'm thinking not because it's more focused on browsing. Games are for playing. I don't need forward-back buttons or a URL bar.
Again, I think Hype should just export to iOS.
Ha, I was wondering what happened here.
So, to recap, I posted B.R.O.O.M. to my website... B.R.O.O.M. ā Photics.com ...which stands for Bomb Removal & Ordnance Obliterating Machine. It's an attempt to create a game without a Physics API. In doing so, it highlights what might be good additions to a Hype Physics API.
As of version 0.1.1, I have WASD and Arrow key controls. By pressing an arrow key to move the main character, the web page itself was moving. Using the "event.preventDefault();" line stops the page from moving with the arrow keys.
window.onkeydown=function(event){
event.preventDefault();
moving = hypeDocument.isPlayingTimelineNamed('x') + hypeDocument.isPlayingTimelineNamed('y');
if (moving == false) {
if (event.keyCode == 37 || event.keyCode == 65) {
if (hypeDocument.currentTimeInTimelineNamed('x') > 0) {
hypeDocument.continueTimelineNamed('x', hypeDocument.kDirectionReverse);
}
} else if (event.keyCode == 38 || event.keyCode == 87) {
if (hypeDocument.currentTimeInTimelineNamed('y') > 0) {
hypeDocument.continueTimelineNamed('y', hypeDocument.kDirectionReverse);
}
} else if (event.keyCode == 39 || event.keyCode == 68) {
hypeDocument.continueTimelineNamed('x', hypeDocument.kDirectionForward);
} else if (event.keyCode == 40 || event.keyCode == 83) {
hypeDocument.continueTimelineNamed('y', hypeDocument.kDirectionForward);
}
}
}
Key Codes:
- Left = 37
- Up = 38
- Right = 39
- Down = 40
- A = 65
- W = 87
- D = 68
- S = 83
Basically, I have two timelines. One controls the X movement and another controls the Y movement.
It's a tile based game, so I stop the timeline with keyframes.
Controls are probably a good starting point for a Physics API. B.R.O.O.M. works because minimal collision detection is necessary. So far, I stop the actor from leaving the scene by going too far up or too far to the left.
I have to figure out if I'm going to scale the whole scene or make the level changebased on the screen size. That's where the "view" in Matter.js would be handy. It's probably easier to scale the whole scene. Heh, but I'm not sure what to do with the different ratios... 3:2, 4:3 and 16:9.
I was wondering what happened to @jonathan - I posted the example, but I didn't see any feedback. Was the example bad... or perhaps it was helpful and Tumult is keeping the new physics options secret?
I did see mention of something interesting though...
It seems that Tumult does have exporting Hype projects to standalone apps on their radar. That could be another cool Pro feature.
Also, I was surprised to see that @Daniel is in New York. Are you two on different coasts? Does that hurt or help development? I'm in NYC too.
Anyway, there wasn't much progress for me this week. Maybe this weekend I'll make some more progress on my Hype game.
Another good idea for a Physics API is collision detection by type.
Exampleā¦ if you have a tank and a helicopter, the helicopter should fly over the tank ā but the projectiles from the tank should hit the helicopter.
Iām not sure, but I think the terminology for this in Matter.js is collision filtering. The following thread seems relatedā¦ https://github.com/liabru/matter-js/issues/48
Over the weekend, I got Pac Man Championship Edition DX for iOS. Wow, time flies. I was playing it on the PS3 almost five years agoā¦ https://photics.com/pac-man-championship-edition-dx-review/
Anyway, as Iām playing this game, Iām thinking in my head about Hype. If there was a physics API, could this game be made with Hype? The one feature that really stood out was the ābullet-timeā. Whenever Pac Man is about to collide with a ghost, the game slows down. Itās a lot of fun. Iām thinking Matter.js could do this, as it has something called āTime Scalingā.
Wow, that would be interesting with Hype. Of course, thatās probably not easy to implement, as how would that work with the timeline? Yet, it if did, a whole project could be sped up or slowed down with a global āTime Scalingā setting.
I recently saw mention of Hype 3.5 by @stephen in another thread. So, maybe this thread will see some action again. Is Hype working on better Physics settings?!
Also, while not quite Physics related, I think Full-Screen view should be a default option in Hype ā a way to toggle between regular and full-screen modes. If Hype is going to have video game like features, full-screen is a great way to show that off.
The new Apple TV is supposedly comingā¦
ā¦and supposedly an SDK for third-party developers is on the way. If thatās true, one of the first things Iād probably look for is if āWKWebKitā is available. Iād be able to create a game once, but port it to so many different platforms.
It looks like things are about to get interesting.
Ha, that is an interesting way to do top/left movement with timelines! You'd probably want the general collision detection to be in javascript based on tiles and just allow changing direction based on that.
Sorry, the new forums are harder to track than our old ones and if I'm off the radar for a little bit I can lose posts to see or respond to!
We used to all be in SF together, but earlier this year Daniel's fiancee got a job in NYC and so he moved out there. It is nice having everyone in one office, but we have tools that help us collaborate and so it has gone pretty smooth.
Time scaling is indeed a cool feature; it'd be easy to implement (simply change the wall clock time by a multiple), but the Hype app interface would be confusing (since there'd need to be top-level keyframes for the "time" on the animation timeline!). Also for keyframe animations there's less of a need since animators have it within their control to do whatever they want.
Don't hold your breath for much difference in Physics in 3.5, sorry! The release is more focused on making lots of small improvements and Physics is a bigger item than we wanted to tackle in this specific version.
Iām working on the āInspector: Physicsā section in āA Book About Hypeā, and Iām noticing a few thingsā¦
- Gravity (both force and angle) should be timeline properties
- Density, Bounce, Friction and Air Drag can be set to negative. Iām thinking it probably shouldnāt be able to do that. Itās not logical and the results are weird.
- Density, Bounce, Friction and Air Drag donāt seem to affect elements with a āStaticā āBody Typeā. What if I wanted to make a trampoline or an icy walkway? I suppose there are other ways to do that. This is more of clarification. Is that intentional? If so, perhaps these four settings should be grayed out unless āDynamicā is selected.
- There should be another setting for rotation ā Allow Rotation / No Rotation. Sometimes I just want a ball to bounce up and down. With rotation, the results can be erratic.
I noticed that @jonathan mentioned this thread in another thread by @Franeko. The question was actually related to real world physics, like the accelerometer.
Itās actually really easy to get accelerometer data and use it in a Hype projectā¦
event.accelerationIncludingGravity.x
Maybe that should be part of the Hype Physics API too, but it seems too simple. This thread has been about accessing Matter.js. Iāve had success working with Accelerometer data in my Hype projects. Matter.js in Hype is different. Thereās so much potential there, but I canāt access it.
It looks like the Apple TV (tvOS) is on the way. Iām not sure, but itās looking like tvOS will support web views.
If this is the case that wellā¦very disappointed. Maybe they will open it up after it has been out for awhile.ā¦I hope
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...
http://brm.io/matter-js-docs/classes/Vertices.html#method_fromPath
I'm imagining a future ā one where Hype supports vector drawing and that shape is used as a custom collision shape.
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 .
Matter.js is impressiveā¦ http://brm.io/matter-js-demo-master/#svg ā¦but that version seems to be in development.
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.
The rounded edges in Hype look round. But in the Matter.js example, they look like lots of straight edges.