HaxeFlixel UI plugin development?

There've been a few discussions on this on the forum, but no obvious "winner".... Here are some of the control packs that have been mentioned:

YAHUI:

https://github.com/ianharrigan/YAHUI

https://groups.google.com/forum/?fromgroups=#!topic/haxelang/RwaF0uQkgc4

StablexUI

http://stablex.ru/

asWing:

http://www.aswing.org/?p=405

http://www.aswing.org/?page_id=7

MinimalComponents

https://github.com/Beeblerox/MinimalCompsHX

Omni Components, though the link I found for it appears to be dead:

https://github.com/impaler/Omni-Components

and a discussion here:

http://www.haxeflixel.com/forum/general-discussion/best-controls-package...

I personally like the look of YAHUI, and know that the author @ianharrigan is actively working on it: I haven't got it fully integrated with HaxeFlixel though.... I'm sure anything you've done would be a nice addition to the list as well. I'll try and post a sample of where I've got to with YAHUI sometime soon....

bradparks, do you know the way how to integrate NME UI libraries with HaxeFlixel? (I suppose the UI libraties uses Sprite   class but HaxeFlixel draws directly on Sprite.)

That's a part that I haven't worked out successfully.... Here's a discussion about this exact point:

http://www.haxeflixel.com/forum/help/add-sprite-flxstate

I just put a sample with the latest YAHUI and a HaxeFlixel demo here:

https://dl.dropbox.com/u/274922/yahui_haxe_flixel_test.zip

It's really rough, and looks bad from a YAHUI perspective, but that's just me copying in the Yahui demo and seeing if I could get that running at all.

The problem I'm having is that it seems that having YAHUI above the "game" doesn't allow the YAHUI stuff to get inputs.

The demo here:

- is based off the "TileMapDemo" from HaxeFlixel

- only adds the Yahui stuff rignt now. Just uncomment this line in Main.hx and it'll add the TileMap stuff

      //main.addChild(new TileMapDemo());

 - Yahui is blocking the display of the TileMap stuff

- I changed the yahui/core/Screen.hx file, to return a sprite from the "initialize" method to try and get this to work. It's commented in the source.

- This copy of Yahui is from this morning (pulled this am)

If anyone could get this working, I'd be super appreciative ;-)

Thanks!

Cool! Thanks for that :)

The only real benefit I think my stuff has is that it's already written in Flixel, albeit As3 flixel, and version 2.35 at that...

If you want to see it in action, you can look at Defender's Quest here:

http://www.defendersquest.com/play_demo.html

It's got basic stuff like radio buttons, checkmarks, tabs, text entry fields, and everything is tab-navigatable.  It was just loose widgets though - I did everything the hard way with Defender's Quest 1 in as3, ie, all the actual layout, labeling, and callback setup is done by hard-coding, etc - kind of a mess.

I've started building a newer, cleaner version in HaxeFlixel which will be part of my eventual port of the engine, that all starts with a "FlxUI" object, which builds off a flxgroup, and reads from an xml file to do the layout, and then lets you assign callbacks, etc, and instantiate any widgets you want.  That way I can build-in things like tab-navigation and localization (including alt. translation labels as well as per-locale positioning of elements, because German Text Is Always Twice As Long(TM) )

Anyone got a good link for how to get started with contributing to a github project? I've never done anything but clone other people's repositories, but I can throw up my WIP code just so you guys can see what I've got and tell me if there's anything you can use there, and/or integrate with stuff other people have done. 

Hey, UI is a feature that is really missing in haxe + nme in my opinion.

I think any effort in this area is more than welcome, not only for flixel but the whole haxe and nme platform.

In my opinion aswing is simply the best UI out there, but the only problem is that the development stopped (or seems to have stopped) and new UI projects are starting because ppl feel its a too much complicated project.

Have a look at the configuration possibilities of the aswing interface components:

https://www.dropbox.com/s/9m660244whugxxy/AsWingIntro_en.swf

I would say it is almost perfect, its highly costumizable also, i have tested it on mobile android and it works great. it has a few issues for non flash platforms (frames drag, some text input isses etc..), i fixed some of them myself (tooltips for cpp) but then halted waiting to see what will be the next UI standart for haxe.

I have been considering to fork aswing myself, but its quite a big move, and maybe someone else will come up with something better (aswing comes back, or YAUI gets as good as aswing), it looks like haxe will still miss a complete UI solution for a while tho.

@sinnus you can call FlxG.stage.addChild(yourUISprite), you will maybe have some issues with input but those can be fixed.

Okay, wow, AsWing is pretty amazing.

As for flixel though, how hard would it be to integrate something like AsWing? I'm assuming it's using the vector engine, so to get native flixel components out of it might be a bit challenging, right? I suppose you could just layer it on top of your flixel game, but that might suit everyone's needs.

Thoughts?

i'm not too familiar with it, but AsWing doesn't seem too skinnable, which I think is a big problem. I don't want my game's UI to look like Windows  95 ;-) Are there any demos of drastically different skins anywhere? I'd love to see them!

Well, in any case, regardless of what's the "best" solution, I'm committed to making a lightweight, heavily-skinnable, localizable, tab-navigatable, haxe-flixel-based UI for my own purposes, so I guess my question is a little narrower:

1) Would this be of value to the Haxe/Flixel community?

2) If yes, what's the best way for me to get started? Just dump my stuff on GitHub and start posting about it?

3) Any major requests for stuff it should do?

Having a UI toolkit native to Flixel would be EXTREMELY VALUABLE. HaxeFlixel is looking to be a great engine to target mobile and in my opinion, the new "microconsole" markets (in adition to Flash and PC/Mac). Having a comprehensive UI solution based on bitmaps would be of great benefit to all. Having you spearhead the project would be fantastic, considering your experience building a complex UI for Defenders Quest.

I recommend you download GitExtensions if you're on windows. It's the best GUI client for woking on git that I could find. You have two options regarding how to set up your git. You could clone Beeblerox's HaxeFlixel and start making your changes there, using GitExtensions to commit and then push changes into your own clone of HaxeFlixel (and using pull requests to have Beeblerox integrate your changes into the main repo). The other option is to create a new repo just for your plugin, and clone that repo directly into your a folder within the plugins directory of HaxeFlixel. 

Getting started with git is kind of ridiculous. There's a lot to get used to, but once you're going it's awesome and simple. I'm usually available on Skype (you can find my skypename on my user page), I will do my best to help you in any way I can.

I think having a native HaxeFlixel UI is the most powerful and flexible solution. Go for it!

hey @larsiusprime .... definitely put yours up in a git repo somewhere... I think it's totally worth pursuing, since it sounds like you've done alot of the work already.... I'm a git noob myself, and I'm on a mac, but need to start figuring out how to do things with it other than "fork".....

I imagine a simple UI system for HaxeFlixel like this (would work with flash only, afaik): 

1. Load swf with sprites / movieclips (vectors);

2. Read xml to get names / positions / sizes / etc;

3. Adjust the sprites size, position, color, etc according to xml;

4. Bake the sprites into BitmapDatas and store them inside a class like FlxAssets or something;

5. Instantiate components directly without having to call loadGraphics;

The user could use the standard style provided with flixel, or could pass a different xml through FlxPreloader to load his specific assets. 

This could effectively reduce the number of assets for a lot of things.

Cool....I'll get started with that as soon as I clear this with my biz partner, I'm pretty sure he'll be up for it in any case.

Is GitExtensions better than say, the GitHub app?

EDIT: Anthony's cool with it, so as soon as I figure my way around Git I'll get started with this. Thanks all!

@Tiago Ling: I think doing anything with .swf  files is a bad idea, since that's not supported by cpp targets as far as I know.

@larsiusprime: "Is GitExtensions better than say, the GitHub app?"

>> I found the GitHub app to be awefully pretty and completely unusable. It wasn't easy to change the location of my cloned repos, and the UI is super custom, it looks nothing like a normal windows app, which really put me off. That was my experience though, maybe it'll be better for you, give it a shot!

I agree with crazysam. Flash only approach is not good because many people choose Haxe NME and HaxeFlixel because of iOS/Android platforms. It's a big power of Haxe NME.

Alright, installing GitExtensions now, I'll give that a shot as the GitHub app was a bit confusing to me. 

@crazysam - just sent you a contact request on Skype.

I'll get this up in the next few days :) So far I've got only a bit of it ported to haxe already but I'll start with a simple layout system and buttons and we'll build from there.  Once I've got it up we'll talk about architecture and general design decisions before I plunge too far into it? 

Additionally, I'll dump all my old as3-flixel loose widgets in their own folder with a cheap demo as raw source material to look at. 

i've got no clue as to how good it really works, but SWF's for visuals can be done in NME:

http://www.joshuagranick.com/blog/2012/01/24/embedding-swfs-makes-nme-me...

I don't think any code bindings (like click events or anything) can be used with them, but that cat animation is all SWF and works in C++ targets too!

@bradparks,

I thought of swf for just one reason: the ability to scale and change your assets without reducing image quality (since vector graphics are just a bunch of coordinates). This way, you could use a base button, a base window, etc, instead of having many of the same asset in many different sizes. Once the swf is loaded at runtime, the UI plugin could scale  it / change color / etc and then call BitmapData.draw to flatten it into a a bitmap which could be used by Flixel.

In this case, the swf would be used just to encapsulate the DisplayObjects (vectors). If NME is really capable of dealing with vectors in C++ it would be great, in fact, it would be one of the best news for me.

@Tiago :

If the above example works as advertised, there's no reason this couldn't be built into the asset pipeline of an otherwise bitmap-focused Haxe/Flixel UI library. Although complicated SWF stuff (animations, effects) would be hard to support, basic vector-y assets would be nice, especially for variable sized things (buttons, chrome, etc). 

SVG support would also be handy :D

Hey, everyone.

I'm working on StablexUI and it covers everything listed in first post of the thread (except scroll bars, wich i'm going to implement next week).

I think it can be easily integrated with HaxeFlixel, because StablexUI widgets can be attached to any nme.display.DisplayobjectContainer instance (Sprites, MovieClips, Stage).

I am not familiar with flixel yet, but i've heard flixel is using sprite to render graphics. So i think it's even possible to make flixel render to StablexUI widget.

You can access any gui component by it's ID (and several other ways), you can also write handlers with haxe right in xml to separate gui logic from game logic.

Feel free to ask any question if interested.

@RealyUniqueName:

Flixel basically overrides the central flash rendering loop with its own, using a single BitmapData to draw to at runtime based on its own internal logic and special object types, so this is the chief challenge, and the reason most UI libraries aren't easily compatibile with it.  

That said, a lot of flixel components are built on top of native flash ones, like TextField (with per-target abstractions for non-flash targets).

Do you have a link to your library?

https://github.com/RealyUniqueName/StablexUI

Can you point me to file(s)  in flixel wich handle render loop?

Here you go:

https://github.com/Beeblerox/HaxeFlixel/blob/flixelNME/src/org/flixel/Fl...

Look up the draw() function

Here's the implementation for one of the core objects, FlxSprite:

https://github.com/Beeblerox/HaxeFlixel/blob/flixelNME/src/org/flixel/Fl...

Everything boils down to drawing to a single bitmapdata framebuffer.

Here is screenshot with Flixel "Hello world" project with integrated StablexUI for cpp/neko target (propgress bar, button and tooltip): http://stablex.ru/ui/demo/Flixel_StablexUI.jpg

"Hello world" project was taken here: http://www.haxeflixel.com/articles/getting-started

Here is little "how to":

Create "hello world" project. Open Main.hx and find following lines:

var demo:FlxGame = new ProjectClass();
addChild(demo);

Replace it with:

var demo:FlxGame = new ProjectClass();

demo.addEventListener(Event.ADDED_TO_STAGE, function(e:Event){
    UIBuilder.init();
    Lib.current.stage.addChild( UIBuilder.buildFn('ui.xml')() );
});

addChild(demo);

That is all )

The only wierd-looking thing is a flixel cursor. It is moving under StablexUI components )

I have issues with haxe compiler on my system, so it is possible that flash example won't work in Chrome browser (it is not Flixel or StablexUI related): http://stablex.ru/hello_world.swf

@larsiusprime Fanastic if you can share your work, I think github is like the facebook of online colaborative vcs, its not that there arent alternatives that are free and opensource http://www.gitlabhq.com/, its just that its where everyone is and their hosting is pretty reliable considering their scale. You can also host free private and public repos on bitbucket.org.

I am curious about any limitations/difficulties you found with Defender's Quest ui or are you just wanting to improve your codebase generally. I have found complex ui is very hard to get the subtle things right and it takes time. At present developers are creating their own gui's as they go, so a few gui framework choices would be nice. I doubt one could cater for every requirement and use case. 

The only thing I worry about a flixel based ui is an overhead for things like complicated scrollcontainers etc and I am not sure how you would do a scrollrect for that matter, maybe have to use cameras ???. We need scrollcontainers with many people wanting their flixel games on mobile. 

On thatnote if anyone doing mobile wants a native approach and has some java/objective-c skills help out https://github.com/Randonee/Basis get native ui for haxe. I prefer however a more flexible theme system for games etc.

I am personally working on a more broader ui set that I want to use to make apps and games with. So I am using the classic nme.display.Sprite and drawing on it through an abstracted drawing interface class. I'll commit my refactor of it soon and show it off with a post probably next week. Its bascically a much improved https://github.com/impaler/As3-Bloom that Xin and I worked on.

@RealyUniqueName Its not weird at all that the Flixel cursor is moving under it. Flixel is rendering it inside itself and the components sprite is on top. You need to disable the Flixel cursor and write your own.

Flixel does not use any of the native as3 cursor api and in nme cpp there is no such native support.

@bradparks AsWing is entirely skinable since its based on a port of the very old Java Swing ui framework, look up the LAF classes "look and feel". Its really an impressive feat getting all that working in as3/haxe I have taken notes from its invalidation cycle to try and get a simpler version to my own.

Hey guys! It's ready!

https://github.com/larsiusprime/haxe-flx-ui

To test it out - clone the repository to somewhere on your computer, then you'll need to supply it with a flixel library at the top level of the cloned directory, named "flixel." 

The project is already set up to compile a basic example with at title screen and cheap mockup of a save slot screen. I'm using freely licensed fonts, sprites from opengameart.org, and my own cheapo assets I'm dedicating to the public domain. 

All layout is currently xml based, and I'll be interested in discussions about what you guys think of this format. I have a lot of widgets that still need to be ported over from Defender's Quest's AS3 codebase, so it's mostly just buttons, sprites, and layout code for now, though it should soon be able to support a lot more than that. 

Let me know what you think!

@larsiusprime thanks man it compiles without error on windows cpp and flash, someone could get it working on neko with a little work. One general idea for doing ui on multiple targets is some scale-9 slice scaling, so you could precache(important for cpu constrained mobile cpp targets) the bitmaps to the screensize before the game starts and draw from there. I am using these classes for my own gui wip https://github.com/impaler/Omni-Components/blob/dev/source/omni/componen....

As for xml formats I prefer to work with simple classes, its why I always avoided flex like the plauge :/ I plan to expand the basic idea of http://blog.soulwire.co.uk/code/actionscript-3/simple-flash-prototype-gu... for my components. But thats just a choice like someones favourite color, cheers 

Hey thanks!

Yeah, 9-slice scaling is a big priority, something I want to get in pretty early, that could save us a lot of time. I wonder if performance-wise there it's best to do something like the FlxTileBlocks where it just caches a minimal amount of graphic and then blits it at runtime, or cache the final state of the scaled element? Any advice there?

As for data format, there's no reason this can't be set up so you can just generate stuff at runtime, the real advantage of a data-based format is that it will let non-programmers and dedicated UI designers make stuff, especially if we can build an "in-flixel" editor for it, that can import/export to data in real time. Ideally this should support both xml and JSON, I'll investigate if there's any limitation in supporting both.

Yes thats what my classes do, you could do similar with FlxTileBlock, although I think one FlxSprite with the correct bitmapdata to draw would be less complicated. All of this bitmap drawing and number of objects becomes an issue for mobile.

So since your ui library is flixel based you could make use of Beeblerox's automatic texture atlas'. So with the result of bitmaps from the scaling with the classes I linked to you can generate a spritesheet for the ui. So ideally when your app starts it could find out the screen resolution etc and automatically create texture atlas' from that. I dont think anyone does this yet it would be awesome.

Cool about an "in-flixel" editor, yes I know some designers prefer xml what a shame 

maybe I'll port 9-slice component from here this weekend.

hey! I know YAHUI has 9 slice stuff in it.... it's MIT and it's here (paintScale9)

https://github.com/ianharrigan/YAHUI/blob/master/src/yahui/style/StyleHe...

Either of these solutions would be great.  Once we have a 9-slice scaling FlxWhatever, then it will be pretty easy to start whipping up re-sizable chrome elements and so forth.  

Any other votes on whether it's best to cache the resultant scaled image after the 9-slice scaling?

Also - another thought: from the looks of it, both of these classes implement scaling for the interior pieces (top, bottom, sides), which will work fine for smooth and untextured UI elements, but as pixel art stuff often has texture to it, it might be smart to add an optional parameter to our eventual implementation that makes the interior pieces tile instead of scale to preserve that integrity. To avoid noisy repetition, the artist could supply an oversized original asset, so that it just crops the interior pieces for smaller widgets and tiles for bigger ones.

Maybe I'm not very carefully read all this topic and maybe HaxeFlixel have this feature, but I don't find a way to do sprite clipping that will be strictly required for properly implement scroll view, tables etc.

@zzzzzzerg this can be done for flash target, but impossible (or very-very hard to achieve) on other

Here's what I'm thinking:

My current implementation uses an extension of FlxGroup called FlxGroupX, which basically allows you to move the whole group around as a unit without having to call reset(). In the as3 legacy code I'm porting from, FlxGroupX also has the ability to cache the entire contents as a single composited bitmap and render that instead of the individual members, so that you can apply transparency to the group and get a composited image with 50% transparency, rather than 50% chrome on top of 50% transparent buttons, etc. 

Of course, I might be doing things completely wrong here XD, so please let me know. 

If I port that functionality over, a thing I could do for scroll panes could make use of that: the scroll pane would have a FlxGroupX as its content, and it could use specific rendering code to only draw the portion in focus.  Special care would have to be taken to properly "dirty" and "refresh" the FlxGroupX so that buttons, etc, would update and draw properly. 

As an optimization, whatever solution is used, bounds checks could turn visibility on/off for the scroll content group members that are out of visible range.

Cameras don't use such technique for clipping views?

Hey, i just want to say that supporting an independent / dedicated UI project may be a good idea, because:

- It may have applications besides flixel + games.

- Its better for the haxe language/community in general.

- The existing UI project may already have a good structure, and now needs improments and features.

- Its a lot easier to use the mouse features of nme Sprites than of FlxSprites.

- Its easier to manage and work more efficiently for it. 

- Its more likelly to end up having better quality.

- Its more useful to help growing a single unified project than reinventing the wheel.

With that said StableX may be a good choice from what i have seen:

- It has a simple yet effective structure.

- More components with new behaviors can be added with ease.

- It has very good xml support.

- Component skins support both vector and raster images.

- Already has basic components.

- Its focused on compatibility with other targets (html5, cpp etc..).

I havent looked deeply into the source code, but i was surprised with the simple idea of it, tho some parts can be improved to be more easy / intuitive to use, i think it provides a good base that can be improved and scaled a lot in the future. 

Btw it is really easy to include a UI like StableX in flixel, it is encapsulated inside a Sprite, and it has got no dependencies on other components and has no strange runtime requirements, a simple solution is adding it to the stage :

stage.add(stablexSprite) and then send and listen events to and from stage to make the two libs communicate.

Peace, 

@ProG4mer:

I think your points are definitely valid! 

For the record, I don't see this as an either-or kind of thing - we can support more than one project here to meet everyone's uses.

My project already exists, and I'm just going to work on it in the open rather than in the dark like I've been doing, and if anybody finds it useful, that's fine by me :) It's scope is limited, but I think there's a big enough niche case for it to be useful to certain Flixel users.

cameras and flxsprites works in very different ways, and yes you can use cameras for clipping but it would be very limited solution

I'm with Lars on this one. The strength of Flixel is its many components, addons, and utilities built by the community over many years. Not everything is gold with Flixel, but when it comes to getting you started with a simple game there's nothing quicker.

A Flixel based UI solution that is skinnable would be an awesome addition to HaxeFlixel. In addition, a major feature like this could be a strong motivation for some of the guys in the Flixel.org forums to admit that the pure actionscript version of Flixel is dead, and get some more people to join our community.

HaxeFlixel is very strong at the moment because Beeblerox is a great programmer with crazy russian hacker skillz, and he's passionate about this project. But we need more people with the chops and motivation to extend HaxeFlixel and most importantly NME itself. Not sure recruiting people from the Flixel community would help us much in this regard, but growing our userbase won't hurt.

Cool - so, I should be able to put some time in on this each week as it is directly related to me getting off my butt and starting on Defender's Quest II coding, so I have some procedural questions:

1) Who's interested in working with me on this? (I'm okay with it just being me, but help would be nice :) 

2) What's the best way to roadmap this? Talk about it here, set up a project management page? (I like pivotal tracker myself)

My first focus will be to port all my Defender's Quest as3 widgets to the current scheme and get them basically functional. Once that is done, I will turn my attention to new elements such as chrome, more flexibile buttons/widgets (especially 9-slice-scale ones!), skinning, etc, as well as the layout system and hopefully an in-engine editor.

@ProG4mr your points are mostly what I am thinking and is why I will continue to make my own non flixel components. StableX has some steady quality work I am just bias to wanting a different structure and style system. Ideally too drawTiles support should be around for nme components to work on mobile which I have started playing with. 

There are now even a couple more nme UI projects I have seen being worked on around the place, I wouldnt say any of them are feature complete or tested enough to be considered production quality yet. Maybe in a few months itll be closer, its going to be great change from having no UI frameworks for nme 

@larsiusprime I played Defender's quest the other day its quite an inspiration and addictive, all the best with your port. You should get great performance from native targets do you plan on doing desktop only?

Yes, im also waiting for a UI project to become the standart, doesent need to be mega complete, but i must be sure it is consistent enough for me to port any apps to use that UI. I checked YAHUI again today, it seems to be going a very good way also. 

Okay, I just added support for 9-slice scaling. 

There's little visual change in the example project, but all chrome and button elements are now drawn with 9-slice scaling! 

I added Flx9SliceSprite, which is a simple FlxSprite descendant that wraps YAHUI's 9slice scaling code (I picked that b/c it had an explicit MIT license attached). Also, I added some more code to FlxUI to let it construct "chrome" elements (just simple Flx9SliceSprites) as well as load Flx9SliceSprites for buttons as well.

Static button example:

<definition id="big_button_blue" width="93" height="31" text_x="-2" text_y="0">
	<text id="hilight" use_def="sans14c"/>
	<text id="normal" use_def="sans14c"/>
	<graphic id="normal" image="ui/buttons/button_blue_up"/>
	<graphic id="hilight" image="ui/buttons/button_blue_over"/>
</definition>

9-slice button example:

<definition id="big_button_blue" width="93" height="31" text_x="-2" text_y="0">
	<text id="hilight" use_def="sans14c"/>
	<text id="normal" use_def="sans14c"/>
	<graphic id="normal" image="ui/buttons/blue" slice9="6,6,12,12"/>
	<graphic id="hilight" image="ui/buttons/blue_over" slice9="6,6,12,12"/>
</definition>

So pretty simple stuff for now. Right now, each chrome element is it's own single png file, Ideally I'd like to set something up with spritesheets, so you could have all your chrome and buttons in one neatly-packed sheet, but I know there's a lot of stuff going on in the background with generating atlases and caching and stuff, so I decided for a simple implementation first and then I'll check with you guys so I don't double-cache or create extra work, etc.

Today's latest commit adds optional support for tiling for the middle parts instead of scaling.

Today's commit adds support for Checkboxes and Radio button groups. 

Should we move this thread into "Development" ?

Lookin good lars, I moved it to development and made it a sticky.

Today's commit adds support for toggle-buttons and for tabbed menus.

Toggle-buttons are simple two-state buttons. You create these out of two separate buttons - one for the pressed state, one for the unpressed state, so that you have as much visual control as possible. In the example project I use this to make the text move by one pixel vertically and horizontally when pushed "down."

Tab menus are essentially a small window with a self-contained FlxUI within it.  Interactivity/Visibility for each tab's contents is turned on/off based on which tab is currently selected - so no need to worry about clicking on invisible things in other tabs!

Wow! Huge progress in a such small time!