announcing snowkit, a collective of libraries for haxe

[Sven Bergström]

Hello Haxe community!

I am very excited to be able to share an alpha release of a few libraries and a new collective initiative for Haxe and it's users.

The first set of libraries are releasing today in alpha and include a high level game engine (luxe), a lower level platform framework (snow), and a generic build toolchain for Haxe (flow).

These currently focus on deploying to Mac, Windows, Linux, Android, iOS and WebGL only right now.

For the full scoop, links to documentation, and more information about the goals of the collective, 
I have written a full post about it over here.

http://notes.underscorediscovery.com/announcing-snowkit/

Please note that, at least during alpha, posts about the frameworks should remain on the community site 

(rather than on this mailing list) to keep a single focused place to get help and keep informed.

Also note that the haxelib versions of the libraries are empty and a release will be pushed when there is one.

Of course, replies to this thread itself are welcome,
I look forward to feedback.

Sven

[Tarwin Stroh-Spijer]

Looking pretty amazing. Thanks :D

Tarwin Stroh-Spijer
_______________________

phone: +1 650 842 0920

Developer at Fanplayr Inc. (Palo Alto)

Original at Touch My Pixel (touchmypixel.com)
_______________________

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[MJ]

I'm trying to promote Haxe in my company for future projects and as replacement of flash which we using at the moment for our games. It's not easy, but Haxe is really great . There have really great and smart people on the main Haxe team and I admire on their work.  One problem for me, as developer ,  is that separation which I found in Haxe . I'm still new in the Haxe language , but  I realy like the work on Hugh ( with hxcpp, nme, gm2d) , Joshua ( with Openfl) , Peter sHTiF Stefcek ( with genome2D, which I tried before to move to Haxe), Nicolas ( with heaps)  and Sven Bergström  ( with great library, Lime and this new toolkit), but I think maybe it's too much for me. It's not easy to promote new language in the company, and with so many libraries it get much harder. I know , I need to choose the one which will most suit our needs, but this separation of all of these great minds make me sad and not make easy any part of that ( to use Haxe as replacement of flash ( including for mobile) ). In one perfect work all we work together to make one great library for multiplatform use, but world is not perfect.

   Sven , your library really look amazing . Keep it with good work and I'll follow your progress. 

[Sven Bergström]

I appreciate the comment MJ. I understand your perspective, I do!

I will write a more comprehensive post about this at some point probably because there are many people suggesting that having the option between one or another library is a bad thing.
I do get this perspective - and spent much time (close to 2 years) building toward common goals - and continue to share code across these libraries you mention.
We still work together, whether it seems that way or not.

In development, and in life, people differ.
People, companies, developers they all have varying goals, plans and needs.
To imply that any one library can satisfy EVERY developer, and every need for every company that ever comes to use haxe is just crazy talk :)

That is not the nature of development and very much should not limit the growth of a vibrant, diverse, rich landscape for people to find when they come to look at what haxe has to offer.

Haxe deserves a landscape of opportunity in order to attract developers here. If there is one library, and it's based on paradigms people have probably left behind - their opinions might be tainted.
If instead they find multiple options, each with various visions and needs met, they most likely will find something to fit their requirements and everyone will be happier.

Variety is a good thing for a programming toolkit like haxe. 

Isn't that the entire point? To empower developers like us to reach our audience? 

[Alexander Kuzmenko]

I agree variaty is a good thing. But the problem is Haxe has relatively small community (compared to e.g. actionscript, Unity etc), so spraying community (not so big) force among different libraries solving the same goal is somewhat a waste.

However i understand it's hard to join someone's project if that project does not suit your workflow/vision :) Perhaps we need some "tool" or "organization" which will help us to solve such problems between devs and force more collaboration.

среда, 1 октября 2014 г., 13:18:06 UTC+4 пользователь Sven Bergström написал:

[Sven Bergström]

I think that you might maybe mis-attribute "solving the same goal".
Programming languages build programs. They solve the same goal. Should there be just one then?

If you want the community to grow we need to court developers of every kind.
To do that we cannot sit on our hands in small groups making things that fit one tiny slice of an audience.

Forward, and upward we go! :) 

[Juraj Kirchheim]

On Wed, Oct 1, 2014 at 12:20 PM, Alexander Kuzmenko <al...@stablex.ru> wrote:

I agree variaty is a good thing. But the problem is Haxe has relatively small community (compared to e.g. actionscript, Unity etc), so spraying community (not so big) force among different libraries solving the same goal is somewhat a waste.

Nine mothers can't make a baby in a month. Putting more people on a single project quickly becomes just as wasteful. And that does not even account for the problem of putting multiple inflated egos in a single room :D

[Sven Bergström]

Yes, exactly :)

I want to also stress that this is a public face of haxe as well, 

and when people are interested in what the community has to offer what do you think they want to see :

- life, movement, exciting projects, lots of people making lots of things
OR

- bunches of programmers yelling "get off my lawn!"

We must bear in mind that we are the community that is directly affecting the growth and adoption of haxe. 

We must be great, about ourselves and about our work. 

We should take pride and support others and build towards the potential that haxe so clearly has.

I love haxe, and I love you guys - let's push haxe forward together yea?

[Alexander Kuzmenko]

Perhaps my english is so bad i can't even explain my thoughts )

I don't mean we need to force people to participate in single project. Ability to solve problems in different ways is great. But i feel like Haxe community needs more collaboration.

среда, 1 октября 2014 г., 0:53:34 UTC+4 пользователь Sven Bergström написал:

[Sven Bergström]

I think in some ways this is true, but i think that may be a discussion best left for another thread.

[Sven Bergström]

That is - mostly because that is a long and different discussion to the point of this thread.

As mentioned, we already do a lot of collaborating and continue to work toward this goal.
Take for example https://github.com/native-toolkit/
I made this so that the native engines can all share the same code so there is more collaboration etc.

It's definitely important at the core of the way things move forward :)

[Saumya Ray]

Congrats! Keep up the good work.

Can not wait to try.

[Raoul Duke]

>> http://notes.underscorediscovery.com/announcing-snowkit/

unfortunately, the emphasis-through-color-effects on that page pretty
much make my eyes bleed.

[Sven Bergström]

Your opinion is noted, thanks :)

[TroyWorks]

Very cool

What does the build system run in?  and how would it work with other external elements (e.g. calling command line for webpack to modularize and pack js/css etc).

"With tools like stackable, transient and modal state machines, events systems, "

does it support HSM, enter and exit actions, cross actions? and is the event system bubbling/capture?

[Sven Bergström]

What does the build system run in?

it's written in node.js and bundles the binaries alongside it. you can read more about the structure here, http://underscorediscovery.github.io/flow/

 and how would it work with other external elements (e.g. calling command line for webpack to modularize and pack js/css etc).

The project file includes a pre and post build hook, which will load your hook file and execute a given function , 

passing you the processed project structure, which gives you the full power of node.js to use as a pre and post hook.
You can call pre or post hooks directly from the flow command, and if you want to run a third party tool it's easy to just spawn a process from the node script.

lot's of these tools for web include node.js modules that you can simply require too.

 does it support HSM, enter and exit actions, cross actions? 

The built in states are pretty straight forward. onenter/onleave is for modal states, activated with set('state')
transient / stacked states work with onenabled/ondisabled and are enable('state') disable('state')
of course you could write your own style, there is no pressure to ever import luxe.States;

and is the event system bubbling/capture?

The event system is a filtered message system, with queued or immediate events. there is no hierarchy in there so they don't bubble.

It's more like signals and slots. You can read more about this specifically here, where it shows the filtering etc.

Hope that answers the questions :)

[Andreas Söderlund]

Hi Sven and everyone else, this post is not meant to be specifically focused on snowkit, it's only because the topic is active. It could be any new framework/toolkit/library.

The post can also sound a bit grumpy. The people who knows me know that I'm not grumpy, just concerned. That aside, let's go:

Den onsdagen den 1:e oktober 2014 kl. 13:18:25 UTC+2 skrev Sven Bergström:

I want to also stress that this is a public face of haxe as well, 

and when people are interested in what the community has to offer what do you think they want to see :

- life, movement, exciting projects, lots of people making lots of things 

OR

- bunches of programmers yelling "get off my lawn!"

Yes, the inflated ego is certainly a big obstacle towards cooperation. It's a shame.

 

I love haxe, and I love you guys - let's push haxe forward together yea?

Would it be ok and/or useful to push Haxe forward by forking snowkit, renaming it to "growkit" or something similar and modifying the API a little, in the name of variety?

Why not a tool that lets anyone rename any library and its API to whatever they like? Of course a new library is more than naming (lessen not its importance), but behind it I see the same kind of structure as always. There are slots, signals, events, assets, streams, buffers, all put in a separate namespace. So it doesn't conflict with the other libraries/toolkits/frameworks with the same features that are part of the same project?

Is this the variety and growth we want in the OS community, a big collection of stuff doing pretty much the same thing, where the best package and sales pitch decides what is selected, like a dollar-store full of colorful plastic variety? IRL, do we need the choice of 10 electricity providers, 100 washing machines, 1 000 computer models, 10 000 car models, 100 000 mobiles, 1 000 000 shades of Grey and 10 000 000 social media sites to be happy? And is anyone who doesn't think so a communist?

When I explain DCI for people, I try to emphasize that it builds on deep architectural and cognitive ideas, not opinions. It's following what research shows how human mental processes works (when not colored by years of programming). That's what should be important when we make programs.

Anyway, snowkit exists and I'm sure you've put plenty of effort into it, Sven. I commend your hard work, and again this isn't focused on snowkit, but on the whole situation. I know it's a great feeling to create something. It's a nice learning tool, and the willingness to make it open source is great. But I still think we should take a larger perspective on things.

Lastly, I hope this isn't disregarded as "opinions", which seems to become more important than facts nowadays. A fact in a larger perspective is that the list of game engines, libraries and toolkits is enormous. If we want to keep going like this, we should seriously consider some "make your own framework" tool, or why not this renaming thing I mentioned.

/Andreas

[Raoul Duke]

on the other hand, whenever i go and use Somebody Else's Code it can
be a nightmare for my small purposes so i do end up writing my own, it
is a faster path to my goal quite often (short term anyway). and
getting involved and having your own take on it be accepted and pulled
and merged is a lot of work, potentially, so there are plenty of
forces involved socially and technically that makes people probably
reticent to just get involved with already existing stuff :-) damned
if you do damned if you don't. and while i appreciate some of DCI i do
not see it as the be-all end-all :-)

[Andreas Söderlund]

Yes, that sure is common and the nightmarish feeling is probably related to the lack of deeper ideas. It started on a whim and ended up as a patchwork. I think the popular CMS:es are suffering from this.

And I don't think DCI is the be-all end-all either, that would be silly. :) But it takes a more solid approach and gives way better results than what we observe today. I haven't seen you on the list for a while, you should voice your concerns there! I'm curious.

/Andreas

[Raoul Duke]

> Yes, that sure is common and the nightmarish feeling is probably related to
> the lack of deeper ideas. It started on a whim and ended up as a patchwork.

http://www.lambdassociates.org/blog/bipolar.htm

[Raoul Duke]

>> the lack of deeper ideas.

and i would like to point out that i do not believe this is actually
the sole answer, as much as i agree with it and often see it
empirically.

other things i see regularly are that there are actually ideas that
sound like what i want, but when i go to use them

(a) the documentation sucks. even if it was written at all, what was
written was not written by people who understand how to write docs. so
there are subconscious mind-sets involved which can be very
misleading. so the thing i thought would work doesn't, and i have to
figure out why. because it is broken? because the docs lie? because
the docs failed to clearly explain "it is X, but is not Y"?

(b) the code sucks. the actual design is bad in my opinion, and at the
very least is possibly misleading, in similar ways as the
documentation problems. when i look on the issue tracker i see other
people raising the issue and the reply is "as intended" or whatever
which to me means they come from a completely different planet than i
do as far as API design & documentation are concerned.

this has happened to me with haxe stuff and more recently with libgdx
stuff. there are simply times when i do not see eye-to-eye even with
something supposedly good & obviously used by lots of people. so then
i have to choose: do i spend weeks trying to learn that other mindset?
or do i just do it myself and get on with life asap? it would be ok to
invest if i trusted it would have payback in the long term. but i
really do not want to sell my soul pragmatically for my own home
projects, i do that enough for my day job. so i find it really
revolting to think, "well this sucks but i'll just have to swallow my
pride..." not just because i feel bad having to bend over backwards to
use that other mind-set, but because inevitably there will be bugs
that make me feel like my selling out wasn't even worth it in the end,
or that i will have to then REALLY go down the rabbit hole trying to
patch whatever i see as being wrong. (at that point it can ironically
come full circle to see that the thing hampering me is so fundamental
that it will be unlikely i can fix it or get a patch accepted cf.
apparent gc issues in hxcpp on android that i had with my game
https://www.facebook.com/pages/Mzzl/519660104758223.)

[Sven Bergström]

There is way too dense of a discussion going down here that is related but not really.

I think this type of discussion is not a bad thing, but I do think that it has a place in it's own thread.

I appreciate the feedback and viewpoints - but I am not going to continue to distract from an announcement thread.
The are tools for users and not a good place for existential unpacking of open source community and culture on a global scale.

As mentioned in an earlier post, I will be writing a post about my own viewpoint in the near future, and look forward to reading other peoples perspectives as well.

[Adam Harte]

I have just had a little time to have a good look into snowkit, and I got to say, it looks great!

I have used a number of libraries for making games in haxe. The last few game jams I have used HaxeFlixel, which has been great for quickly getting an idea up and playable, but I am at a stage now where I want to take things to the next level.

The shader driven pipeline sounds very appealing. I come from a flash background, and have been wanting to get into shaders etc for a while. These libraries seems like they are at a low enough level that I would have the control I might need without running into walls.

I am planning to give Snowkit a good go over the next month's and hopefully do my next game jam with it.

Very interested to see what is next. All the talk in this thread seems to be quite negative. I don't see any reason why a toolkit like this can't be one of the main draw cards for Haxe. It just needs time to flourish.

Keep up the amazing quality of work.

Adam

[Sven Bergström]

Thanks Adam!

Feel free to sign up on http://snowkit.org and share your thoughts as you dig in.

[Brennan Kinney]

Hi can you clear up the differences between Snow and Lime? I think I've heard Lime is coupled to OpenFL a bit still but there are plans to correct that. So at that point if choosing between Lime and Snow what are the pro/cons for each? 

They both use SDL right? One feature I miss from Adobe AIR is working with multiple displays, I read you support multiple windows can you also access monitor information such as resolution and the displays number along with alignment/fullscreen features? A developer added functionality to what Adobe provided that I found useful, when I've asked about this in the past with NME/OpenFL the support wasn't there, SDL2 apparently supports the ability to do this though: http://www.joristimmerman.be/wordpress/2009/03/03/screenmanager-expand-your-air-application/

Another big thing would be some way to play video like flv/mp4 files. I think someone was working on being able to do this with FFMPEG? Any chance Lime or Snow would provide cross platform video support?

[Pier Bover]

Hey Brennan

I haven't tried it, but it seems Roxlib support multiple screens.

https://github.com/rockswang/roxlib

As for video I'm also very interested in that. NME has StageVideo and I read somewhere that maybe it will be integrated in OpenFL.

https://github.com/nmehost/nme/tree/master/samples/StageVideo

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
Pier Bover
y...@pierbover.com

[Brennan Kinney]

Hi Pier, thanks for the links.

I think from looking quickly over the sourcecode the Roxlib is providing support for 'screens' as a ui element, similar to what FeathersUI does with Adobe AIR. I'm wanting hardware display support, so that I can say fullscreen window 1 on display 3, windows 2 and 3 split view on display 1(using half display resolution(displays resolution not the resolution spanning all displays) width, left/right edge aligning). This was possible with the linked screen manager lib for AIR, SDL2 I think provides such features just needs to be implemented with a haxe lib.

Thanks for the StageVideo info, hopefully it makes it can be supported with libs like OpenFL soon :)

[Sven Bergström]

Hi Brennan, 

First off, the display and all modes, counts and information like that is available from snow, exposed from SDL and the code is transparent on web so as not to get in the way.
If you look in the api docs you would find these for example

http://underscorediscovery.github.io/snow/api/snow/window/Windowing.html#display_count
and the (messy) test for the snow parts : 
https://github.com/underscorediscovery/snow/blob/master/tests/features/0_sink/src/Main.hx#L97-L117

These are accessible from luxe side too, for the curious. They will be wrapped up into the Luxe.screen api which is on the roadmap.

As far as video goes, this is something that will be done through the snow native sdk which is also being worked on (see the issues list on the snow repo for the discussion).
Video playback is something I have wanted too so it's not forgotten about, I just don't think it belongs in the main code as it's an extension for specific targets.
That's where the SDK comes in, which i'll post more about in near future.

The differences between lime and snow are fundamental.
You can look at two different vehicles and see the same components (wheels, steering etc) but they are not the same. 

Some vehicles are for recreation and some are for racing, their goals and purposes differ. 

This is the best way to describe the differences without writing an entire blog post (i might still).

I already wrote about why I made snow (after originally making the lime wrapper in the first place) here for some brief insight.
I don't think there needs to be a direct comparison for everything though, especially since snow is just announced and will change rapidly, just like the new version of lime.
Comparing now will leave the threads covered with a lot of outdated information, something end users hate, but still somehow want. :)

I look forward to revealing more and continuing the work on the alpha though, thanks for the questions.

[Pier Bover]

This sounds great Sven!

It seems Snow could become my main framework for doing projects for museums and mobile, which until now I've done with Air.

I took a look at Flow and it seems text is always using bitmap text. Is that correct? Are you planning to include support for ttf files?

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
Pier Bover
y...@pierbover.com

[Brennan Kinney]

That is fantastic to hear :D Like Pier it really make a difference for interactive display projects that span over many displays/configurations. I think I will wait until Snow is changing less rapidly and Luxe supports the screen api. I'm not sure if you are familiar with Starling framework which is very popular for Adobe AIR/Flash using the gpu for rendering. Snow/Luxe seems to do this, I looked at Luxe docs and api seems similar. What I really like about Starling was an amazing gpu based UI framework made for it called FeathersUI, I am not sure how portable it would be without also porting Starling to use Snow but if it could be ported to work with Luxe without too much trouble that'd be incredible, I really suggest you take a look at FeathersUI and see if it's a good fit for Luxe.

One other thing, with Starling a Sprite is more of a container/grouping object(Texture not used), does Luxe Sprite require a texture always? In Starling you would define a Texture object and that could be assigned to the Image class(Seems like Sprite in Luxe). The Image class was extended to support frame animation as MovieClip class, FeathersUI extended Image to provide Scale9(9 sections like your Nineslice) and Scale3(3 sections vertically or horizontally) as well as TiledImage, which let you define a rectangle width/height and provide a texture to repeat efficiently(using UV mapping I think). 

[Brennan Kinney]

It seems to be gpu based rendering, I'm not too familiar with low level stuff like this but with Starling everything was rendered into a context/region, there was another layer beneath it for video accelerated by gpu and another layer on top of it for traditional flash(does not perform well on mobile). For best performance they would use bitmap fonts, this was ok for games but become problem with text heavy apps, I had to use a UI list component and provide method to split my string into line groups(groups of quads representing single character from bitmap font atlas), this performed well and kept memory usage down, the list component was virtualized, supporting the changing of fonts, or their size, or type(bold italic regular) was a bit more difficult but I got it working.

You can avoid all that at least with Starling by rendering your ttf text into a texture and displaying that. Only problems are that you'd be using considerably more RAM and have to manage it much better as well as CPU usage if your app is text heavy. In addition the text isn't interactive(links/selection), like bitmap fonts you cannot scale them though by rendering on demand you can keep asset size down by not needing multiple versions(1x,2x,4x).

Bitmap fonts can get around scaling issues by either creating the font atlas dynamically at runtime specifically suited for the device, or by using distance field renderer(though text might not always be crisp, especially at small sizes). You can convert a ttf file into bitmap font but depending on conversion software the quality of how close it resembles that font when rendered may not be 100%. AngelCode does a fairly good job, I find Glyph Designer does the best job and has great support(however it's not free and OSX only). Usually the issues you'll run into with conversion are kerning.

I've seen one other option with Starling but can't recall the name for it, it would convert the vectors of the ttf font into polygons at runtime, it has it's own pro/cons for performance that are different from the ones mentioned above, depends on how you want to use text.

[Sven Bergström]

Pier And Brennan : 

You can see the current setup right here : including links to the mentioned tools.
http://luxeengine.com/docs/guide.fonts.html

The text support is currently bitmap only, as my primary focus has been games for the alpha especially. 

The SDF support is in the first alpha roadmap, which you will notice arriving on the snowkit.org site sometime soon, along with many various other fixes for text.

The text geometry is also batched automatically, only uses 1 geometry per texture, and long blocks of text can be set to "locked" which will reside in GPU, and draw more efficiently. 
That all said : you will even find roadmap mentions on the issues list regarding ttf fonts and further text improvements, so I don't discard those features - just a matter of time.

But I agree that Text is important and that it should offer a straight forward way to render them efficiently, which other approaches can sit on top of. So far this is almost there.

 does Luxe Sprite require a texture always

No, see the very first guide in the docs.
The way it works is Entity -> Visual -> Sprite.

An entity : component container, transform
A visual : an entity that contains any geometry
A sprite : a visual that contains a quad specific geometry with quad features, like flipx/flipy, UV coords for tiling etc.

In luxe, NineSlice extends sprite and provides a single geometry that wraps that all up for you into a simple enough API.

I am aware of feathers, I highly doubt it will translate directly code wise (and I don't think it's open source and flexible license?).

There are some UI components in the works though, so there will be some options to use as a baseline. 

UI is of course a task on it's own, so the focus is on the engine during the first alpha pushes and make sure that is a good place to work from.

If you have use cases (i.e I want to do X,Y,Z across multiple screens) the best thing to do is to post them on snowkit.org and tag them as usage.
This let's me go through as we move forward and make sure that things are possible, without having to cater to unknowns nearly as much. 

Of course there will be things you can't do, not without your own effort, especially now. 

But hearing that intent can help make the path more focused and help users learn earlier whether it fits their needs.

[Brennan Kinney]

Your doc link is much more useful, I came across your docs via the github link here: http://luxeengine.com/docs/ but clicking the design/guide links to each listed item didn't provide anymore information, perhaps that link is outdated? By single geometry do you mean a quad(two triangles), or do you mean a single draw call? If using a single quad to render the text are you creating a new texture(render texture?) for each text instance? Just curious how that affects performance/memory, I know that when I used Starling/FeathersUI for a project that was text heavy rendering a single text instance with several paragraphs was not viable, it also prevented changing fonts/colour/bold/italic within that paragraph, as FeathersUI treated each letter as a quad I could modify the class to support the features I was after.

I understand your more focused on other features and that UI is a huge task in itself, hence why I suggested looking into a port of FeathersUI or using it for reference. It's an excellent UI framework for gpu renderers and has tackled many issues as it's matured over the years(originally Foxhole). Far as I can tell it's open source and the license seems flexible? I'm not too knowledgable about licenses sorry, you can see FeathersUI license on their github here: https://github.com/joshtynjala/feathers/blob/master/LICENSE.md The developer is very friendly and responds in a timely manner should you need to contact him.

I've seen some projects provide a webpage that had users upvote features/ideas for the project, it seemed pretty practical since you could sort by demand to see what to focus on. No idea how much effort to get that going, might be something free/open source you can use? I think OpenFL has this(couldn't seem to find the link).

Thanks for the proper docs link, I'll give it a look later tonight.

[Sven Bergström]

Thanks Brennan,

I wasn't aware feathers was open source.

Those design/guide links are 404. Visit the actual guide page there is a big list there.

A single geometry means multiple quads in this case. If they share the same texture etc they all still are one draw call.
As mentioned none of this is final, it's just the basics first.

Right now I would prefer to finish the original vision before taking on more features and ideas from users, you will see what I mean by the announcement soon :)
The engine is not designed to have everything inside, but to facilitate building around anyway. Fancy rich text included - is a module.

Either way, thanks for the link.