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

OpenFL + Nape, codesize too big? #51

Closed
starburst997 opened this issue Jan 28, 2015 · 8 comments
Closed

OpenFL + Nape, codesize too big? #51

starburst997 opened this issue Jan 28, 2015 · 8 comments

Comments

@starburst997
Copy link

Since this seems like a Neko issue I thought I would fill an issue properly.
See openfl/openfl#158 and deltaluca/nape#77

class Main extends openfl.display.Sprite {

 public function new () { 
 super();

 var tf = new openfl.text.TextField();
 tf.text = "Hi There";
 addChild(tf);


 var space = new nape.space.Space();
 }

}

With the 2.0.0 code this crash with a

Uncaught exception - std@module_read

Building the latest Neko from source fix this, however in my game it still output the same error, probably from the added codesize of my game?

Also on a probably related note, on another project I get invalid call on functions, putting them as inline will fix it but then it is another function that will have invalid call, and this seems to go in a logical order, is there a limit on the number of functions a program can have? Where could I bump this number.

@ncannasse
Copy link
Member

Could you try to debug in vm/module.c which cause is triggering the std@module_read error ?

@lewislepton
Copy link

ive been getting this recently as well using NAPE, which i would like to use. how can i work around it?
or where should i go to at least hopefully address this?
what steps to take?

thanks

@lewislepton
Copy link

actually someone has just helped with the outcome to bypass and allow it to run
in the project.xml, put in these 2 lines inside project.xml

<haxedef name="no-inline" />
<haxedef name="dce=full" />

hopefully something more full time can be implemented for future folk, but still its a nice work-around ;)

@thomasuster
Copy link
Contributor

I'm also hitting this for Pakka Pets, even with

<haxedef name="no-inline" />
<haxedef name="dce=full" />

@ncannasse
Copy link
Member

@thomasuster could you get some informations in vm/module.c to know where it stops ? Or if you can send me the broken .n privately.

@thomasuster
Copy link
Contributor

@ncannasse Wasn't able to get neko building on OSX. Is there a doc somewhere for this or should I not bother? Where should I send the .n to?

@ncannasse
Copy link
Member

send the .n to nicolas at haxe.org, I will look into it

@ncannasse
Copy link
Member

It was confirmed that it was a max code size limitation that was already increased in GIT version.

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

4 participants