Skip to content
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

Closed
aduros opened this issue Aug 5, 2012 · 19 comments
Closed

No collisions in JS #39

aduros opened this issue Aug 5, 2012 · 19 comments

Comments

@aduros
Copy link

aduros commented Aug 5, 2012

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!

@deltaluca
Copy link
Owner

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

@deltaluca
Copy link
Owner

Sorry, not had time to check this out yet! I'll let you know as soon as I can get to it.

@aduros
Copy link
Author

aduros commented Oct 10, 2012

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.

@deltaluca
Copy link
Owner

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 :)

@deltaluca
Copy link
Owner

Speaking of which, has this actually been reported to Haxe devs? Maybe they just don't know about it

@aduros
Copy link
Author

aduros commented Oct 11, 2012

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.

@deltaluca
Copy link
Owner

hxcpp issue?

@aduros
Copy link
Author

aduros commented Oct 11, 2012

You mentioned DCE also breaks Nape under hxcpp.

@deltaluca
Copy link
Owner

Ah, I 'think' I solved that a while back (getting around some hxcpp bugs that were not expected to be solved any time soon)

@aduros
Copy link
Author

aduros commented Nov 6, 2012

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.

@deltaluca
Copy link
Owner

Okay, I'm going to allocate some time tonight to solve this for the next version of Nape :)

@deltaluca
Copy link
Owner

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

@deltaluca
Copy link
Owner

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.

@deltaluca
Copy link
Owner

Going through every single class and setting defaults (even if it's just false, 0, null) for all members, hope that solves it.

@aduros
Copy link
Author

aduros commented Nov 10, 2012

Thanks man! It seems like that would work. Let me know when there's a haxelib release and I'll try it out.

@deltaluca
Copy link
Owner

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)

@aduros
Copy link
Author

aduros commented Nov 10, 2012

Sounds good :)

@deltaluca
Copy link
Owner

Wow this is arduous :)

@deltaluca
Copy link
Owner

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:

class A {
   var x:A = null;
   function new() {}
}
class B extends A {
   function new() {
      x = this;
      super();
   }
}
var b = new B();
trace(b.x); // null, super() call sets it to null hah.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants