-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No collisions in JS #39
Comments
I should have time to take a look at this tomorrow evening. --dead-code-elimination is also causing nape to fail on hxcpp after haxe 2.10 too siiiiigh |
Sorry, not had time to check this out yet! I'll let you know as soon as I can get to it. |
Hi! Any news on this? --dead-code-elimination is probably going to be on by default in a future version of Haxe JS, it would be great to have Nape working with it. |
Quite honestly, this hasn't been a high priority for me given that removing dead-code-elimination resolved it and I would really consider this a 'haxe' bug, rather than a 'nape' bug as dead-code-elimination is not supposed to break code. How desperate are you to get dead-code-elimination working with nape? There will (As soon as website is done) a new version of nape released which has a few breaking changes for a 'version 1' release, and If I can resolve the problems dead-code-elimination has it'd be useful to only solve this on the next release instead of the current depending on how long you can wait :) |
Speaking of which, has this actually been reported to Haxe devs? Maybe they just don't know about it |
It's not urgent, as long as it's still on your radar :) I'll bring this up on haxedev. I'm planning to propose a JS compiler change that would fix this. Although that will still leave the hxcpp issue, though maybe that's a different problem. |
hxcpp issue? |
You mentioned DCE also breaks Nape under hxcpp. |
Ah, I 'think' I solved that a while back (getting around some hxcpp bugs that were not expected to be solved any time soon) |
Apparently, this happens even without dead code elimination. The trigger is Type.getInstanceFields changing the structure of the JS output slightly. Including it means fields default to null, omitting it means fields default to undefined (and breaks Nape). Flambe must include it unused somewhere, and disabling DCE prevents it from getting stripped. So this means Nape doesn't often work with the default options for JS, and a fix isn't always as simple as disabling DCE. |
Okay, I'm going to allocate some time tonight to solve this for the next version of Nape :) |
Well that's nice, nme 3,4,4 : Variable initialization must be a constant value with haxe nightlies :) I'll continue without any graphics if possible |
Well i've found a few things that are NaN instead of integer 👍 starting to sort them out, would be lovely to be able to catch them all directly. |
Going through every single class and setting defaults (even if it's just false, 0, null) for all members, hope that solves it. |
Thanks man! It seems like that would work. Let me know when there's a haxelib release and I'll try it out. |
Given that this is going to take a few hours i think i'll only be doing it for the next version, i can send you a haxelib zip to test; but it will require transitioning to the new version (a few breaking changes, not loads) |
Sounds good :) |
Wow this is arduous :) |
Seems to be working from a simple test case tracing body positions, before it wasn't colliding and now it is. I also found a lovely 'bug' after doing this:
|
When I upgraded to Haxe 2.10, body collisions in Nape mysteriously stopped working in my JS demo: https://aduros.com/flambe/demos/physics/?flambe=html (Click to spawn objects, and compare with the working Flash version)
Here's a debug build that throws a Nape assertion: https://aduros.com/tmp/physics-debug/?flambe=html. When I go back to Haxe 2.09 or compile without --dead-code-elimination, it works once again.
I think the root cause is Haxe 2.10 modified the JS output to not include members in the prototype by default under DCE. Previously an uninitialized member variable would have been null, now it's undefined. Undefined has slightly different semantics in JS than null when casting to a number. (ie, Math.floor(null) != Math.floor(undefined))
The source for this test case is at https://github.com/aduros/flambe-demos/tree/master/physics if it helps. Thanks!
The text was updated successfully, but these errors were encountered: