next »

[Richard Kain]

I've been working on my own game/application framework for Haxe + NME over the past few months. Thanks to increased amounts of free time (being unemployed) I've been able to make solid strides recently. Last week I ported Flixel's Keyboard solution over for use in my framework. This week I wrote a detailed tutorial on how the whole thing works. (complete with source code.

Haxe Mouse Button Tutorial
My New Haxe Keyboard Tutorial!

Big thanks to Adam Saltsman for all the work he's done on Flixel over the years. I've learned a lot from his flash game framework. Hopefully this tutorial will be useful to other aspiring developers.

[goshki]

Nice tutorial, Haxe and NME are on my radar since quite some time, so it's good to see it getting traction on TIGForums.

Btw. did you know, that there's a port of Flixel to Haxe + NME in the works? It even has identically ported the Flixel's keyboard code but it seems normal because porting ActionScript to Haxe is straightforward in most cases. I'm mentioning this project just as a heads-up in case it turns out that your framework is doing exactly the same and there's no point reinventing the wheel (apart from own programmer satisfaction).

[Richard Kain]

Btw. did you know, that there's a port of Flixel to Haxe + NME in the works?

I was actually aware of this. Not only Flixel, in fact, but FlashPunk is also being ported to Haxe. It's wonderful that we're going to be getting solid game programming tools like these working in Haxe.

I'm not worried about reproducing work. The framework I'm putting together is more basic than either of those game engines. I'm sticking with the standard flash rendering system, the display list, as opposed to the pixel blitting used in Flixel and FlashPunk. The game's I'm planning on producing with this framework are more menu-driven, and won't require as much processing power.

My next tutorial is going to be about bitmap fonts. I believe that's a feature that hasn't shown up in Flixel or FlashPunk.

[goshki]

My next tutorial is going to be about bitmap fonts. I believe that's a feature that hasn't shown up in Flixel or FlashPunk.

Not in vanilla Flixel but in PhotonStorm's Flixel Power Tools, there is. And IIRC HaxeFlixel ported also this class. But I may be wrong.

[pgil]

Someone also made some bitmap font classes for Flashpunk which supports variable-width characters. I stole it and added wordwrap:

http://flashpunk.net/forums/index.php?topic=885.msg23691#msg23691

[Moczan]

Do you know how to make stuff like alt+f4 work in NME? In my game pressing it equals pressing S instead of closing the app (desktop target on windows).

[Richard Kain]

Do you know how to make stuff like alt+f4 work in NME? In my game pressing it equals pressing S instead of closing the app (desktop target on windows).

Unfortunately, the keyboard solution I worked on for this tutorial doesn't use any of the function keys or the Numpad keys. There seems to be some sort of conflicting overlap in the C++ target for NME when it comes to key codes. The function and numpad keys use the same key codes as the letter keys. My tutorial takes this into account by adding Haxe compilation-target conditionals.

I think this issue exists because of NME's use of the SDL library for handling input. It should be possible to handle key combinations, but I don't think standard platform shortcuts are going to work by default.

[Richard Kain]

Not in vanilla Flixel but in PhotonStorm's Flixel Power Tools, there is. And IIRC HaxeFlixel ported also this class. But I may be wrong.

I'm not familiar with those projects. My own solution for bitmap fonts is based off of AngelCode's bitmap font application. It takes a generated PNG font character file, and an XML file with data for all of the character information, and then uses copyPixels to do the drawing. You give it a rectangle to draw into, point it at a BitmapData object, and let it do the rest. I've gotten left, right, center, and justified text aligns working.

[Richard Kain]

I've posted a new tutorial, this time covering standard mouse button interactivity. Here's the link...

Haxe Mouse Button Tutorial

This one is more my own creation. It's very simple, and will be pretty obvious for anyone who's used AS3 extensively. But it's still pretty useful, especially for a cross-platform language like Haxe + NME. I've tested it on several of the target platforms, and the only one I've had problems with is HTML5. For some reason, jeash just doesn't seem to handle mouse interactions as well as the other targets.

[ishlilith]

I don't get what you are trying to do there.

You created a class just to avoid typing this.addListener(blah,blah), and in doing that you destroyed type safety (I could understand at least MouseEvent->Dynamic instead of MouseEvent->Void, but only Dynamic?) and made the code way slower than a default implementation.

I think this can be useful for buttons, but at the very least the functionality of ButtonTrial needs to be merged with your Button class. My problem is with your statements "In this tutorial, we will be looking at a way to manage standard mouse interactions for Haxe + NME projects." and "The Button class is going to be the backbone of your mouse handling". When NME projects don't usually use sprites (drawtiles being faster), having a basic tutorial telling people to use sprites for their mouse needs is a fast way to "haxe is incredibly slow" when they invariably end up with 100 sprites on the screen.

So, is it a good idea to have a dedicated button class? No, it is not a good idea, it is a must, but it's just that, a way to make buttons, not a catch all way to handle mouse clicks.

But I really like that you are making tutorials for haxe, and would love to read more, even if I'm a bit of a dick.

[Richard Kain]

When NME projects don't usually use sprites (drawtiles being faster), having a basic tutorial telling people to use sprites for their mouse needs is a fast way to "haxe is incredibly slow" when they invariably end up with 100 sprites on the screen.

So, is it a good idea to have a dedicated button class? No, it is not a good idea, it is a must, but it's just that, a way to make buttons, not a catch all way to handle mouse clicks.

For the framework that I'm personally working on, I don't use "drawtiles." I considered it, but that rendering approach still isn't compatible with all of the Haxe + NME targets. And for the types of games I'm working on, that level of extra rendering performance isn't really necessary. I'm working on games that aren't going to be having thousands of interactive elements on screen at the same time.

The tutorial I wrote assumes that the standard display list is being used. But then, I don't try to hide that. And for basic GUI elements, the standard display list is a much better idea than rolling a new solution for mouse interactivity.

[Moczan]

For the framework that I'm personally working on, I don't use "drawtiles." I considered it, but that rendering approach still isn't compatible with all of the Haxe + NME targets.

Isn't drawTiles() the basic GPU rendering method on all desktop and mobile targets? It wasn't compatible with Flash, but as far as I know it works (obviously on CPU) now.

[Richard Kain]

Isn't drawTiles() the basic GPU rendering method on all desktop and mobile targets? It wasn't compatible with Flash, but as far as I know it works (obviously on CPU) now.

No, it isn't the default. It's a new GPU rendering option that was added for the desktop and mobile targets. (in order to improve rendering performance for those targets) And it still doesn't work with the Flash target, or with the HTML5 target.

It does seem to work fine for desktop and mobile targets, and that is good and well. But as ishlilith pointed out, using drawTiles disconnects the rendering from the standard Flash API display list. If you want mouse interactions in conjunction with drawTiles, you would have to rig up your own custom events, and perform hit detection on the rendered graphics yourself.

In theory, you could use the mouse button classes in this tutorial in conjunction with drawTiles. You would just need to give the button a transparent fill, and then tie the location of the button to the drawTiles-rendered graphic.