Haxe port already exists

[vroad]

Why did you create new one rather than forking my repo? You didn't know that, did you? https://github.com/vroad/starling-openfl

[peteshand]

Hey there. Yes I was aware of your port. however I decided to start from scratch for a few reasons. First and foremost I wanted to port the most current version of Starling 1.6.x (github master) as it would be much easier than trying to find what had been changed and update accordingly. Second I wanted to use the port as a learning exercise and lastly I thought it might make adding new platforms (primarily flash) easier if I was more familiar with the codebase

[vroad]

Okay I close this... Actually I was trying to update Starling to 1.6.x and make Flash compatible, but still unfinished.

[peteshand]

I do see your point though, it seems a bit silly having several completely separate repos all trying to achieve the same goal. but yeah the version is the biggest thing for me... which is actually something I haven't really worked out how I'm going to maintain as new versions of starling are released. On a side note, I noticed the benchmark results on your port are really good! It would be amazing if you were able to help @Type1J and myself achieve the same in our port!

[vroad]

Disabling multisample anti-aliasing improved performance a lot on Intel GPUs. I also switched to Typed Arrays from Vector in several places for faster uploading to GPU (which caused incompatibility with Flash). I could solve these problems with conditional compilation though.

[peteshand]

Hey

So looks like we're still building our respective ports of Starling, which is great, but obviously would be awesome for us to combine our efforts. We're probably a little far down the track to do this with our current ports, but with Starling 2.0 in the making I was wondering if you'd be interested in a combined efforts to port Starling 2.0 when it comes out. I've already got one of my workmates on board and having another person already familiar with porting Starling I think we could pull it off pretty quickly and offer a good select of supported targets. Let me know if you'd be interested.

Also on a side note I asked Daniel if could set up a dedicated section for Haxe in the starling forum. http://forum.starling-framework.org/forum/starling-haxe I mention you're port in the welcome post, feel free to add to it.

Cheers Pete

On Mon, Apr 27, 2015 at 10:18 PM, vroad notifications@github.com wrote:

Disabling multisample anti-aliasing improved performance a lot on Intel GPUs. I also switched to Typed Arrays from Vector in several places for faster uploading to GPU (which caused incompatibility with Flash). I could solve these problems with conditional compilation though.

— Reply to this email directly or view it on GitHub https://github.com/peteshand/haxe-starling/issues/7#issuecomment-96627850 .

[vroad]

Hi, I'm interested in porting Starling 2.0 with you. It would be better to have only one port rather than two ports as you said.

[peteshand]

Hey there

I've just setup a new GitHub organization called "Haxeling" (obviously a cross of Haxe and Starling). The idea of this organization is for us to have a place where we can call Starling 2.0 for Haxe. But for the time being I've forked both of our repo's in there. I've invited: You Tom Byrne and Michal Moczynski (Two guys from my team at work) Jay Slstar (Github ID: Type1J) He has worked on the C++ target in the past.

I think our goal with Starling 2.0 should be as follows:

• Support all the targets that are supported in both of our ports.
• rely on official 3rd party libs rather than our own forks (OpenFL, Lime) Anything else you can think of?

Also do you think we should wait for Starling 2.0 to be out for a while before we begin the port? I'm just concerned with a major release there might be a lot of subsequent minor release after that might be hard to keep track of.

Finally on a separate note: I've been doing quite a lot of work on my port over the last few weeks to resolve the last missing features for the HTML5 target (Filters, Masks, RenderTexture). There is a lot of WebGL stuff that is over my head, so I replied on your port quite heavily to get things working, or testing where the issues were, Starling or OpenFL/Lime, (as I saw that you reply on your own forks of OpenFL and Lime).

I was able to resolve most of the filter issues simply by using your filter classes, a long with a few other classes (so I much thank you for this). However render texture and masking required updates to OpenFL (I checked out your fork, you have some really awesome optimizations going on by the way! have you tried to get stuff merged with the master branch?). Anyway so I forked OpenFL the master branch and made small changes and made pull requests one by one and after about a week or so doing this Starling 0.4.2 on haxelib now has Filters, RenderTexture and Masking working all using the official OpenFL and Lime version.

Also what's your email address and name for that matter?

Cheers Pete

On Sun, Dec 13, 2015 at 12:15 PM, vroad notifications@github.com wrote:

Hi, I'm interested in porting Starling 2.0 with you. It would be better to have only one port rather than two ports as you said.

— Reply to this email directly or view it on GitHub https://github.com/peteshand/haxe-starling/issues/7#issuecomment-164208088 .

[vroad]

I would wait for stable release as developers of original starling may change its code a lot.

I also want to get this to work with official version, and I have been making pull requests one by one, but I think that we need much time to get this done.

You could get my e-mail address from my commit log. I'm not making my real name public, so please use my username for that. I'm also on OpenFL slack.

[peteshand]

Hey there

Just a quick FYI, I've started initial port of Starling v2 It can be found here. https://github.com/Haxeling/Starling-Framework-Hx-v2/tree/feature/HaxePort

I've got it to a point where it compiles, however it's currently not rendering anything.

On Tue, Dec 29, 2015 at 2:05 PM, vroad notifications@github.com wrote:

I would wait for stable release as developers of original starling may change its code a lot.

I also want to get this to work with official version, and I have been making pull requests one by one, but I think that we need much time to get this done.

You could get my e-mail address from my commit log. I'm not making my real name public, so please use my username for that. I'm also on OpenFL slack.

— Reply to this email directly or view it on GitHub https://github.com/peteshand/haxe-starling/issues/7#issuecomment-167706513 .

[vroad]

Hi, I'd like to try it out, but I've got 47 errors when I just tried to compile it for html5...

And what's the point of forking original starling repository? I don't think we will benefit from doing that, as we cannot simply merge changes from original repository. It'd be better to create separate repository for Haxe port.

[vroad]

Instead of forking original repo, I've used working branch which contains almost original code. That branch helped me in merging changes from original repo.

The code in that branch was almost original except for a few things:

• File extension is changed from as to hx
• Some manual replacements of Types (void -> Void, int -> Int, ...etc)

In your repo, you cannot even try to merge changes of master branch because you just added hx files alongside existing as3 files.

[peteshand]

Hey @vroad. Yep, I've not been testing against the html5 target yet. The first step for me was to convert all as3 classes into .hx classes and get a compilable sample app. For this step I've been targeting flash/air.

Now that I have this up and running the next step is to do the same for html5 and then it will be to move onto runtime issues. (for example while I can compile for the flash target nothing renders).

The point of forking the original repository is to track delta changes in the as3 code in further releases, so these changes can be manual ported as required. That being said I'm open to managing it differently if there are obvious benefits.

In regards to the merges you're referring to at https://github.com/vroad/starling-openfl. Has this merges been successful, as in is the sample app compiling and rendering?

[vroad]

Well I just don't want to see files and commits which don't have to do with the port. It's not neat to place as3 and hx in the same repo, is it? I've never seen Haxe programmers who released ported source code in that way. If you just want to refer to commit of starling, why not refer to them with git tag or commit hash?

I'm only working with Starling v1.x for now. Merge conflict occurred many times, though it was lot better than trashing all of previous code.

[peteshand]

Hmmm yeah ok, that's a fair comment. Would you prefer we fork one of our 1.x repos into the Haxeling organization then merge starling v2 changes into it? I don't mind forking your repo as long as we can move towards having dependencies of the official OpenFL and Lime, which I don't think will be to tricky... I've actually pulled a lot of your OpenFL changes across into the official version (though it wasn't easy, those guys are super slack at reviewing pull requests) and for anything that isn't accepted can be overridden like this:

package starling.openfl; #if (!flash)

@:native("openfl.display3D.Context3D") class Context3D {
public function new () {

}   

}

else

typedef Context3D = openfl.display3D.Context3D;

end

On a side note I'm really busy at work for the next few weeks (as in I'm working over Easter), so I'm not going to have much of a chance to work on v2 for a while... I'll let you know when I'm back on it.

[vroad]

I've started working on v2.0 recently. I choose to port v2.0 by myself to get familiar with new code base, and choose to continue working on my git repo. Basic stuff already works on cpp, nodejs and html5, but suffering from performance issues on nodejs and html5. Original AS3 version also has issues as well, though.

[peteshand]

Hey mate. Yeah the performance of 2.0 leaves a bit to be desired, it's actually quite a bit worse that v1.8.. even if you do get extra features, I'm not sure if it's worth it. I finish the Flash/AIR v2 port about a month ago, but didn't have a chance to move onto html5 and c++ before work got busy again... shame to hear to decided to not to do it together, but fair enough.