Genome2D Haxe public beta

[sHTiF]

Hi guys,

so the beta is finally here you can download first swc with sample files at http://build.genome2d.com/haxe/

I will also release upcoming builds there as well, there is already one scheduled probably today/tomorrow that fixes first bunch of reported bugs.

Enjoy and any feedback is welcome.

[Enrique]

Hi Peter,

the game I'm doing currently uses nape physics. 

Genome2D.getInstance().physics property doesn't exist and the wrapper classes GNapePhysics and GNapePhysics throw a lot of errors.

Any advice?

[sHTiF]

Physics is not implemented yet as I pointed out in yesterday slides if you were watching. So there is just few abstract stuff atm. Physics is not something I focused on as you can always implement your own as they do in starling and its there just to make things easier within Genome2D so you don't need to focus on invalidation yourself. If you want to use physics with this beta I would suggest you implement your own approach and to per update invalidation of visual representation for the bodies, pretty simple.

P.

[Enrique]

Ok. I'll try to implement physics myself. I'm not a programmer and I feel more comfortable using frameworks like citrus+ starling than doing this kind of stuff.

By update invalidation you mean to create a visual representation and update its position and rotation with the equivalent physics body? Does it make sense to use the GBody class?

By the way, I can't see stats.

[sHTiF]

Nope don't use GBody its just abstract for GNapeBody. As far as I know Starling doesn't do physics not sure about Citrus it maybe has some helper classes for physics. Maybe you can use the current AS3 Genome2D instead if you want to make a game or something since this is 2.0 beta not ready for production. The current Genome2D has physics already with nape extension.

Will check the stats, asap.

P.

[Enrique]

I'll take a look on how they implement nape on citrus. 

Is there a big performance difference between this beta and AS3 Genome2D? 

I'm doing a racing mobile game like this (citrus+starling):

http://coldcherry.com/test/Coconut_Race.html

Basically I'm porting that to genome because I wanted to improve the performance since couldn't get 60 fps on the iPad2. 

Should I keep on developing with the as3 version and make the changes once the haxe version is ready for production?

[sHTiF]

If I were you I would definitely work with AS3 Genome2D http://build.genome2d.com/nightly/ (1195 build) you get performance boost anyway and if the Haxe is production ready the changes should be minimal so you can switch there without much effort although there will be API changes but nothing to worry about. You will also need this extension https://github.com/pshtif/Genome2DNape the example may be outdated though let me know.

BTW nice game, let me know how it goes.

P.

[Enrique]

I'll do that!

Thanks for your advice Peter.

[William R. J. Ribeiro]

It's indeed a cool little game! It's much harder than I thought it would be. Good job!

On Sunday, December 22, 2013 9:56:20 PM UTC+1, Enrique wrote:

[Enrique]

tx! I did that demo using citrus+starling

now I'm porting that to genome2D

[sHTiF]

Guys I am back to work on Haxe version once again back from holidays. So this week a new build is coming. Including:

- advanced particle systems

- context draw method for matrix (for skew for example)

- GShape (previously GSimpleShape in AS3 version)

- context draw method for polygon draws

- and many fixes reported

Guys any feedback is welcome, the more you test the sooner we will catch the AS3 branch and we can move forward to advancing it even more :)

[Mistakenness]

sHTiF about the GShape did you decided to go with just GSimpleShape ? you created a new one ?

I tell you that, cos GShape is better for big static texture (1000+ px) and GSimpleShape performs better at runtime.

[sHTiF]

The major decision is that GShape as it is now in AS3 version is too tight up with Stage3D it basically uses its own buffers etc. Not something that can be easily abstracted for the new version with non-stage3d targets etc. Personally I never used GShape anyway as I never needed such complex shapes but it can always be extended in that particular target to cache all the stuff to make it practically the old GShape. Other than the huge static vertex count advantage there are only disadvantages to the current GShape over GSimpleShape.

BTW the performance it has nothing to do with textures or size of the polygon its just the number of vertices in the polygon that count since they are updated/uploaded each frame for GSimpleShape whereas they are precached in GShape.

[Mistakenness]

Yes, "Other than the huge static vertex count advantage there are only disadvantages to the current GShape over GSimpleShape." The GShape I was talking about is a big road with a lots of curves :

http://youtu.be/XTG3JAPiAxY If you want to see how big it is :)

[sHTiF]

Yes I can definitely see why it has better performance as GShape since it has huge vertex count, what I was arguing is your argument with the big texture 1000+ px which has no effect on Shape performance.

[Mistakenness]

Yes, I expressed myself very bad :) 

[sHTiF]

Ok new beta build is here with the aforementioned features, test and report ;)

http://build.genome2d.com/haxe/Genome2D_1_0_232hx.swc

[Dhemitus Javanensis]

sorry, if there any documentation for this? i'm very very newbie in haxe

[Rodrigo López]

Is a Flash build (swc), no Haxe needed.

If u meant newbie in G2D, sadly the docs are not really useful (only for API reference maybe), but you have the old forums, blog posts, wiki page, etc.

Most of them are outdated though, but the concepts still apply. G2D had some API changes over the years, but u can fix the errors easily :)

Here's my "resource" list:

1. Peter's blog (outdated): http://blog.flash-core.com/
   
2. Peter Youtube's channel (5 good video tutorials): http://www.youtube.com/user/pshtif
   
3. wiki (outdated): http://wiki.genome2d.com/doku.php
   
4. outdated docs (not very useful): http://docs.genome2d.com/
5. oldest forum (really outdated): http://blog.flash-core.com/?forum=genome2d-forum
   
6. previous forum: http://forum.genome2d.com/
   
7. my blog (nothing really useful yet): http://blog.7interactive.com.ar/
   

Good luck!

[sHTiF]

The wiki and docs even though outdated are quite useful because the API changes aren't that huge. Anyway I would definitely download this http://build.genome2d.com/haxe/Genome2DHaxeBeta.rar since it contains examples.

Anyway guys if any of you know a solid way how to generate DOCs from Haxe code I can make new docs in a no time the problem is that all generators I tried were a dead end. :(

[Rodrigo López]

Some bugs, requests and questions:

1 - A better toString() in needed components to easily trace/debug: classes like GTransform, GNode to display number of childs, and the renderer classes to display at least the used texture Id and texture size.

2 - Why the cameras positions (camera.node.transform) works in the opposite direction ( *=-1 )?, is not intuitive at all.

3 - There's no access for the default camera, ( is not listed in the cameras array neither) only reference is for a GContextCamera, genome.g2d_context.g2d_defaultCamera. I can change the properties (x,y,scale,etc), but what is the difference between cameras?

4 - What is the difference between adding a camera with Genome2D.getInstance.addCamera(), and use root.addChild( camera.node )?

5 - color transformation in cameras doesn't work.

6 - no way to set the background color (GContextConfig::backgroundColor doesnt exists).

7 - There's no way to update the viewport rectangle (legally at least).... This is a basic feature, when u resize an app, or go to fullscreen.

genome.g2d_context.g2d_stageViewRect = viewport ;

Has some resizing issues, doesn't update the stage3d context background, and deforms the renderer.

Here's a pic:

8 - Can u add a getter for the GTransform::color?, I know the color setter parses the hex to the RGB ratio,

but it's way more easier to tween hex values directly from GTransform... just create a g2d_color variable

to assign and retrieve the value... it's up to the developer if the color is changed later with red, green, blue :)

9 - Missing methods from GTextureFactory (createFromColor was useful for quick prototyping).

10 - You were wrong in your feature description, the compiled class is GSimpleShape, not GShape.

11 - I guess u don't have access to the Vector.<> class in Haxe. Using arrays should decrease in performance, right? Specially in GSimpleShape

12 - Can't render GSimpleShape (bug):

TypeError: Error #1009: Cannot access a property or method of a null object reference.

at flash::Boot$/getTrace()

at flash::Boot$/__trace()

at MethodInfo-335()

at com.genome2d.context.stage3d.materials::GTriangleTextureBufferCPUMaterial/initialize()

at com.genome2d.context.stage3d.materials::GTriangleTextureBufferCPUMaterial/bind()

at com.genome2d.components.renderables::GSimpleShape/render()

Same issue applies to GStage3DContext::drawPoly()

13 - What is the difference between draw() and draw2(), the last param p_id ... what does it mean?

[sHTiF]

1) Will think about that, I don't think that adding all that info is crucial as its easily gettable by using numChildren for example etc. But we'll see.

2) It just works it wasn't done that way specifically its just how math works :)

3) Default camera shouldn't be accessed and you shouldn't even change its properties as it may result in uninteded behavior! I said this for AS3 version as well if you want to change even just scale you should always add your custom camera!

4) There is basically no diference addCamera is internally used by the camera component so you should never use it directly. Also don't forget that Haxe compiles every method as public in SWC so all my private methods are public so if you see a method it doesn't mean it can or should be used, thats how Haxe compiler works unfortunately. And thats why we need documentation ASAP to clearly document methods that can be used.

5) And it shouldn't camera don't and never will support color transforms. You should use nodes for this or in some cases postprocesses for more complicated stuff.

6) Yea this is something that is in TODO list.

7) Also something that should be added, it can be done since context offers reference to native context but you are right it should be done by GContext.

8) Yea I can, although I wanted to remove as much getters/setters as possible since this functionality is a hell to implement in Haxe for SWC target unfortunately :/

9) Wanted to keep it simple, but can add as its very simple to do, not a priority though as you can do it in single line anyway using createFromBitmapData and new BitmapData(...) thats basically what createFromColor does.

10) Yea my bad forgot to rename it :)

11) You do have Vector.<> in Haxe but it would work only for Flash target which is a no go, arrays in Haxe are as fast as Vector anyway since they are strongtyped Array<Float> for example. Don't know how this translates to SWC usage.

12) This seems like a forgotten trace which will result in error when used as SWC. Its easily solvable as for correct usage you should initialize any haxe SWC during startup using haxe.initSwc(mc); which will make Haxe internals work. I wanted to avoid this so tried as much as possible to avoid any such internals.

13) Draw2 is a test method for now its not complete and basically it reuses buffers instead of having global buffer and uses draw call IDs to idenity draw calls that came from the same element.

[Rodrigo López]

Ok, thanks for the clarifications, didn't have time to go through an extensive test yet.

Most of the "stupid" recommendations are just to simplify the code and make our development easier :P I know there's not a big priority for that kind of stuffs (as they're not bugs) but they're surely nice additions for a RC, and everyday coding.

For the point 12) I don't like to extend MovieClip in the main class :(, anyway, anybody can haxe.initSwc(new MovieClip()); to avoid the issue.

So far, so good Peter. Please, keep consistency with private/public method/properties in the next build, addCamera shold be g2d_addCamera, or __addCamera()... idk, it's up to u :)

Regarding documentation, I have no idea about haxe, but why don't u ask Deltuca how did he do it with Nape.?

El domingo, 22 de diciembre de 2013 08:07:05 UTC-3, sHTiF escribió:

[Rodrigo López]

Where's the GTextureBase::defaultFilteringType ? for linear and nearest.

El domingo, 22 de diciembre de 2013 08:07:05 UTC-3, sHTiF escribió:

[Rodrigo López]

I was hoping this version fix the nested transformation "bug" :(

Do you see a possibility of fixing this in a future release? I know the previous version worked the same way, and maybe the calculations to render the correct result are kinda complex, using matrices and stuff.

Just take a look at it, if it's possible to add at least the ability to render a node herarchy with correct transformations applied to children as well, maybe a flag or something that doesn't hurt performance.

El domingo, 22 de diciembre de 2013 08:07:05 UTC-3, sHTiF escribió:

[sHTiF]

Yep this is a known limitation and its exactly because of performance and there is unfortunately no way to calculate correct result without hurting performance significantly. You can always implement it using drawMatrix etc. at the moment there is no plan to add whole pipeline support as this is almost never required only for specific reasons where you should implement it separately using drawMatrix such as DragonBones, Spine etc.

[Dhemitus Javanensis]

thank you Rodrigo 

[Rodrigo López]

For what?

[Rodrigo López]

Idk how many features are missing from latest stable version (Genome2D.0.9.3.1195.swc), but the filesize decreased a lot, 187kb against 76kb, well done.

Nicely done with the display list approach for node. Now that u have the basic logic applied, can u apply the rest of the methods from DisplayObjectContainer?

Ordered by most used methods:

addChildAt(node:GNode,index:int):GNode;

getChildIndex(child:GNode):int

setChildIndex(child:GNode, index:int);

swapChildren(child1:GNode, child2:GNode);

removeChildren(beginIndex:int, endIndex:int);

swapChildrenAt(index1:int, index2:int);

getChildByName(nodeName:String):GNode;

And, another nice feature to add, I know is kinda complicated to implement based on g2d nature.... But easy access and modification of node size is SO NEEDED for most Flash developers.

Resizing through scale is messy and complicated, and requires more code to retrieve texture from a component, etc, i know, you don't have to check a for child sizes and stuff, and that makes it a lot faster... but if we can, somehow, have access to node.transform.width/node.transform.height, and node.getBounds() and things like that, with REAL representation of the values, that'll be a WINNING feature, believe me. I always wanted that in the framework, and now that u're refactoring everything from scratch, sounds like a good candidate, I'm not asking for a total refactoring at all, just additions to simplify coding. Most of the times, for me, dealing with mouse inputs or hierarchy transformations values is really complicated.

[Dhemitus Javanensis]

you give me your resource link

On Sunday, January 12, 2014 9:57:05 PM UTC+7, Rodrigo López wrote:

For what?

[Rodrigo López]

Oh, sure, no problem.... 

[Rodrigo López]

I was struggling to listen for mouse events,the issue was the default renderer camera, So, to capture mouse events, we need to add a custom camera first.

Nice choice, now by default all nodes has mouseEnabled and mouseChildren = true :) , does it hurt performance ?!

As far as i can see, nested node transformations works perfectly well with multiple cameras transformations... good job.

Stupid thing, but the new GNodeMouseSignal always gives a null target:

I have 1 container node, with 3 sprites as children, and the signals added to the container. The signals are dispatched but there's no reference to the container (target), only to the childs (dispatcher).

Also... is tricky, but mouseChildren should toggle the mouse capture in the children, not the parent. So, if i have a button with 3 sprites/nodes inside (background, label and icon), and i set mouseChildren=false in the main button node, this still should allow me to add/receive signals to the button as a whole. The g2d functionality doesn't work like this, and prevent any event from the current node too (if it doesnt have a GRenderable component attached). 

Also, can u add the so needed mouseX, mouseY (maybe a method in GNode to pass which camera to use, for a "stage" position, a local coordinates )? and node boundries (considering rendered child plus transformations).

Thanks.

[Rodrigo López]

trace( node.getWorldBounds()) ;

[trace] (x=10000000, y=10000000, w=-20000000, h=-20000000)

Anyway, as far as i can tell, getWorldBounds return a rectangle with min x, min y, max x, max y locations of child nodes WITH renderables, That is a bug... cause if i have:

nodeA

    nodeB (renderable) (x = 10 )

    nodeC (x=400)

         nodeD (renderable) (x=30)

nodeA.getWorldBounds() will return x:10,y:0,w:30,h:0 .... so, the recursive calls are there, cause the w=30, but the parent node transformation is not considered... in any case, this "bounds" should include the texture's size as well, right?

[sHTiF]

Default camera had bug in mouseX/Y handling will be solved in next build as it would be stupid to force user use custom camera just for mouse coordinates :)

mouseEnabled = true was a mistake and it will be changed to false in next build, this is something that irritated me in native flash by being true as its such a waste of performance by default.

I can't reproduce the bug with null target I always get both dispatcher and target correctly can you elaborate more?

Once you disable mouseChildren you will not be able to get the mouse signal for container such as in native flash, this is intended containers don't work as some huge renderables. This is due to various reasons from performance wise to design decisions.

LocalX/Y property will be there in next build however this is always local for the dispatcher not for the target which would involve additional calculations, we'll see in the future.

[Rodrigo López]

1 - The mouseChildren property worries me, i mean, is hard to re-implement that in the code for us. At least, can u create boundaries for the nodes? is just a hierarchy check for a hitTestPoint(), if u make it an optional call, could it hurt performance?. 

2 - The way to reproduce the bug is just tracing a node without renderables nodes inside, I'm assuming that getWorldBounds() should considere also the current node position, so if u getWorldBounds() to a node without children, it should give u only the position: x,y, and w=h=0.

var n:GNode = GNodeFactory.createNode();

var n2:GNode = GNodeFactory.createNode();

n.transform.setPosition(100,100);

n2.transform.setPosition(100,100);

n.addChild(n2);

genome.root.addChild(n);

trace(n.getWorldBounds()); // [trace] (x=10000000, y=10000000, w=-20000000, h=-20000000), should be: (100,100,200,200)

trace(n2.getWorldBounds()); // [trace] (x=10000000, y=10000000, w=-20000000, h=-20000000), should be: (200,200,200,200)

trace(genome.root.getWorldBounds()); // [trace] (x=10000000, y=10000000, w=-20000000, h=-20000000), I guess it should be: (0,0,200,200), although root is a special node.

[sHTiF]

Ok guys new 235 build is now up at http://build.genome2d.com/haxe/

[Release Notes]

- toString for GNode

- getBounds for GTextureQuad, GMovieClip, GSprite

- getBounds for GNode working with hierarchy and target space

- matrix for GTransform to get local transformations in matrix format

- getTransformMatrix for GTransform to get transformations in target space

- addChildAt, getChildIndex, setChildIndex, swapChildren, swapChildrenAt for GNode now that we have indexed child arrays

- backgroundRed, backgroundGreen, backgroundBlue, backgroundAlpha for Genome2D to set context background color

- new WiP hierarchical nonuniform scale/rotation detection so render graph use matrix instead of faster direct transforms for correct render output

Cheers, any feedback welcome.

[Rodrigo López]

Dylan found a bug:

config.enableStats = false ;

it always displays the Stats.

Also GStats.customStats is empty, and there're no more access to scale or position in the static class.....

[sHTiF]

Will check that out, also don't forget that config no longer propagates settings after initialization so if you want do disable/enable stats at runtime use Genome2D.getInstance().getContext().enableStats = false;

As for the custom stuff yep its not implemented yet.

[Dylan Meville]

Yep, I was setting the stats the line before calling init.

I may have found another small thing.

Setting the filtering type on an atlas doesn't appear to be changing anything.  Seems to be stuck on the default of NEAREST.

Drawing a scaled up sprite with the filtering type set to Linear still shows quite a fuzzy sprite.

[Celavra]

i've got:

createInstance is not a function.

in com.genome2d.Genome2D/init 

[sHTiF]

Can you send a minimal example that throws this error for me to reproduce?

[Celavra]

I think is error somewhere on my side... when a run an example form Genome2DHaxeBeta.rar (clean project) it's ok, but if I copy example to my project and compile it i've got an error in init on Genome2D. (of course libs and the same for both projects). I will look into it more soon.

[sHTiF]

1.0.236 build is out at http://build.genome2d.com/haxe so check it out.

CHANGES:

- GTextureAtlasFactory checks for power of 2 textures as requirement for texture atlas

- Refactored internal methods to g2d_ prefix as Haxe makes them public and they get in a way

- Texture dispose fixes, GTextureAtlas now correctly disposes and removes subtextures

- Mouse pixel interaction added for GSprite/GMovieClip and mousePixelThreshold to specify valid alpha value for mouse interaction, this works only on bitmap data sources where Genome2D is able to extract pixel information

- New low level context drawSource method that lets you override source rectangle of the GPU texture to render

- !BREAKING! GMovieClip huge changes to texture handling, it no longer needs textureatlas defined and you need to specify whole texture ids in the setTextureFrameIds method, this also generates texture lookups during setter and not per frame change so its way faster, additionally movieclips are now have different frames from different atlases which is handy for long movieclips that doesn't pack inside a single atlas. [textureAtlasId, setTextureAtlas, frames are now obsolete]

- fixed dead code elimination that could result in missing some crucial stuff

- GIntRectangle/GFloatRectangle were merged into GRectangle, which is typedefed to Rectangle in flash target for easier readability

Cheers

[sHTiF]

Genome2DExamples were updated to latest build, also added ContextDrawExample and uploaded the latest build to the lib as well. https://github.com/pshtif/Genome2DExamples

[Javi Castillo]

Peter, I've just updated to 1.0.236 and I can't find GAssetManager anywhere. Have you removed it temporary? Or have you changed its name?

Thanks

[sHTiF]

Sorry it got messed up as I separated it into common codebase when working on JS target. I rebuild and reuploaded the 236 so just download it again. 

[Javi Castillo]

You are the man!

[James Wrightson]

Good work!

How usable is the current HaXe swc compared to the AS3 version?

Only asking as I might want to switch to it for both web and android!

[sHTiF]

There are people already using it for live projects and I myself am switching to it as well.

Some features may be missing but most of them like flash components etc. can be brought from the AS3 github and refactored to the new version. So there are very limited features set that can't be ported atm like lights/shadows but that is not crucial for 99% usecases anyway.

Also Haxe version is faster because I came up with new batching algorithms during its development, also the pipeline is more streamlined. And there are features that are missing in the AS3 version as well or were limited, for example bounds calculations, matrix calculations, render graph matrix draws for nonuniformly scaled rotations etc.

And if there is any problem just let me know since the Haxe version is being developed almost daily any reported bugs are adressed asap.

[James Wrightson]

Thank you Peter,

The only thing I can't seem to find that was in the old as3 version, is how to pause/resume and change time scales.

Everything else feels a lot better and more obvious :)

[Javi Castillo]

It could be used for live projects today, but I guess you would like to wait for the fix of enableStats to publish your game unless you want to show your users how amazing G2D is and the performance you can get with it ;)

[sHTiF]

@James yep there is no timescale or pause/resume stuff added to todolist

@Javi I am not aware of any enableStats issue.Genome2D.getInstance().getContext().enableStats = false works for me, anyway they will be disabled by default in the next version as they probably should.

[Javi Castillo]

I think Rodrigo or Dylan already reported this issue, that's why I didn't say anything.

I din't know about Genome.getInstance().getContext().enableStats (that I see is not a property/setter but a method), I was using the enableStats property in GContextConfig. Anyway neither works for me.

private function initEngine():void{
   genome = Genome2D.getInstance();
   var config:GContextConfig = new GContextConfig(this.stage, new Rectangle(0,0,w,h), GStage3DContext);
   config.enableStats = false;

   genome.onInitialized.addOnce(initComplete);
   genome.init(config);
}

private function initComplete():void{
   Genome2D.getInstance().getContext().enableStats(false);
}

I'm using Flash Builder/AIR

[sHTiF]

Will look into that.

[xing...@gmail.com]

When would atf and userData(for sorting) be added?

[Rodrigo López]

@Javi     genome.getContext().enableStats(false); works fine on Genome2D_1_0_236hx.swc, so make sure you're using the latest build.

@xing... :P username stripped

Regarding node.userData, seems like Peter forgot about that really useful property :) ... You should implement IMap interface to create a typed Object :(

In the meantime, while he fixes that... you can work with the "private" properties (sorry Peter, I know you hate to expose that :D ), as long as you're conscious of what u're doing, u'll be fine.

Idk why the sort methods were removed from the Haxe builds, but is EXTREMELY easy to create your own implementation!, so i think is more powerful in terms of customisation, but maybe native Array sorting is slower than the old linked lists approach with thousands of child nodes.

var nodes:Array = myNode.g2d_children ;

// you can reverse the current children

// nodes.reverse();

// A custom sort based on X position. In this case, the nodes on the left, goes to the front...

nodes.sort(function(nodeA:GNode,nodeB:GNode):int{

if (nodeA.g2d_transform.g2d_localX < nodeB.g2d_transform.g2d_localX )

return 1 ;

else if(nodeA.g2d_transform.g2d_localX > nodeB.g2d_transform.g2d_localX )

return -1 ;

return 0 ;

});

So, you can do the same with Y, scale, or any property OR anything inside a node (like components).

When u work directly with the g2d_children Array, the changes will be invalidated right away in the context, as the context loops through the same array you're modifying.

----------

Regarding ATF support, I think it works fine since the first release: Genome2D_1_0_232hx.swc ... The latest Flash build used to have an issue with the newest ATF format specs, dunno if that was fixed.

Here's a post with the fix for the Flash version, if that's the issue it can be ported.

[xing...@gmail.com]

About user data, I'm using an independent value to sort. It's not in any node property. If the userData is comming, I'll wait.
About the atf support. ON Genome2D_1_0_236hx.swc, GTextureAtlasFactory does not provide any function to eat atf data. And the fix code got many things reported as undefined: GError.INVALID_ATF_DATA;GTextureSourceType.ATF_BGRA;textureAtlas.invalidate();

[Javi Castillo]

My bad! I was overriding the init function of the class I was extending (a basic G2D layout template) and skipping the line. I just wrote enableStats in the wrong place.

It works fine. Sorry!

[Rodrigo López]

So, i just testing Genome2D_1_0_237hx.swc

I noticed that u have to pass the stage to the variable instead of the constructor now:

genome = Genome2D.getInstance();

viewport = new Rectangle(0,0,800,600);

var conf:GContextConfig = new GContextConfig(viewport);

conf.nativeStage = this.stage ;

genome.onInitialized.addOnce(onGInit);

genome.init(conf);

In the latest version you'll probably see this error when u add a renderable node to the root:

Sorry If i missed the post with the notification of this change.

Anyway, u need to add the AGALMiniAssembler sources to your project's classpath, here is the zipped source with a version that I took from Feathers.

Hope this helps!

[sHTiF]

Hmm interesting,

yep the nativeStage stuff is something I forgot to mention due to the lost release notes. It was done to match the Haxe api exactly.

The AGAL stuff is strange though as I didn't run into this problem in my tests, and it is also part of the SWC so I don't see a reason why it shouldnt work. Thanks for the workaround.