Release 0.9.0
starwed opened this issue · 18 comments
- Create testing branch and upload beta docs
- Automated tests pass
- Prepare updates to site + non-autogenerated docs.
Browser checks
Let's make sure that we at least nominally work in the full list of browsers (i.e. a basic scene will render.)
- IE9 (oldest browser we claim to support)
- IE11
- Edge (I saw some choppiness here, but I think it was my testing setup? Rendered correctly, though.)
- Firefox latest
- Firefox for Android
- Chrome latest
- Chrome for Android
- Safari
- Safari on iPhone (<-- I have no easy way to check this, but we do run at least some basic tests on iphone devices)
There are a couple of tests failing on saucelabs, due to "Unsupported OS/browser/version/device combo".
I'll probably have to update some combos to more recent systems.
Updated the tests targets in this commit, they now pass.
(Essentially we try to test the oldest browsers we support in addition to the most recent. SauceLabs makes it easy to specify the most recent with the latest keyword, but we have to manually update the tests targeting old browsers as they remove support for them.)
Here is the first release candidate.
In doing some browser checks, I noticed the following small issues:
- Chrome (desktop+android) seems to be applying the viewport transformations slightly differently for DOM layers. I think this is essentially fine -- the only reason why I noticed it is that my demo file has canvas/dom/webgl layers setup with background elements which are flush against each other, so even a single pixel difference in rendering the background image is noticeable.
- If you don't enable
multitouch, I found that firefox/chrome would sometimes trigger mouse events twice on a tap -- not 100% sure why that is. I'll see if I can figure that out, but I'm not sure I consider it a blocker; you can work around it by handling touch directly, and I suspect it might be present in older releases too?
What I also noticed is the documentation in the beta that is no longer working:
https://github.com/craftyjs/Crafty/blob/develop/src/spatial/collision.js#L483
Crafty.e("2D, Fourway, Collision, player")
.attr({x: 32, y: 32, w: 32, h: 32})
.collision([0, 16, 16, 0, 32, 16, 16, 32])
.fourway()
.bind('Moved', function(evt) { // after player moved
var hitDatas, hitData;
if ((hitDatas = this.hit('wall'))) { // check for collision with walls
hitData = hitDatas[0]; // resolving collision for just one collider
if (hitData.type === 'SAT') { // SAT, advanced collision resolution
// move player back by amount of overlap
this.x -= hitData.overlap * hitData.nx;
this.y -= hitData.overlap * hitData.ny;
} else { // MBR, simple collision resolution
// move player to position before he moved (on respective axis)
this[evt.axis] = evt.oldValue;
}
}
});
Since the Moved event per axis is no longer there, this type of collision detection with walls will no longer work.
The whole fixing of that proved to be quite complex, but I'm my game I did it like this:
So instead of using the 'Moved' event, I used the onHit and when a collision was there, I tried to recreate if a certain motion from the motionDelta would prevent that collision. When it does, I shift the player back to be bounced back by the wall/ceiling. This also works when items are moving against the player and pushing it back, when a correction needs to go in 2 direction on the same axis, it would mean the player is squashed and I kill it off. It proved to be quite complex, but at least it is working properly again, also when the player itself is standing still but objects around it are moving.
Yeah, this is definitely one of the bigger breaking changes in this release -- it essentially halved the cost of movement (including halving the number of collision checks), though, so it seemed worthwhile from a perf standpoint.
The simplest solution that I see is to just provide overlap, nx and ny for MRB collisions like we do for SAT. This would have a slight perf impact, I'd assume, so maybe we could make it configurable?
Does that seem like it would work for your use case?
Not sure what really should be done. It works in my case, but to have everything done properly, it does require some work. Crafty could help out I guess, but I'm not sure if it should be an option or just a method to convert that the user can decide to use it or not.
I would prefer the method so that the developer can make the choice for each specific use case.
I did some benchmarking between 0.8 and 0.9, and 0.9 is quite a bit faster.
Created a third rc that fixes the touch issue.
At this point I've checked the rendering in everything but IE9 and the iPhone. It does pass the basic DOM/Cavnas "render a square" tests in those browsers.
Created a wiki page that tries to cover likely pitfalls of the various breaking changes.
Not sure I have the best perspective on what's helpful here, though! @matthijsgroen feel free to update that page as you see fit, since you've just done such an upgrade.
Well the only thing I encountered was that shift of the 2D component could be called with a single argument, but now it has to be called with 2.
Is there a public url to test? I can test Safari iphone
Sure, I've been using two slightly wonky "games" to test with:
- triple-render.html -- this renders the same scene simultaneously in WebGL/DOM/Canvas, hitting all the transformations that we support (rotation, flipping, opacity, panning, zooming, etc.) It ends when the "player" gets back to the start and fades out, with the zoom not quite what it started as. (no input is tested here.)
- simple-jumper.html -- a really stripped down endless runner, as a very simple way to test input (including touch on mobile)
Both demos work exactly the same on Safari on iPhone as they do in the browser for me.
Thanks for testing that.
I should be able to prepare the small site updates necessary and run the release this weekend.
Merged to master and updated the site, so closing this issue!
Never did manually test in IE9, but that's increasingly irrelevant, so
(And we do have automated tests that run there.)