Questions on passing keypress events (other than from the keyboard) to MelonJS

[russel...@gmail.com]

I set up the melon tutorial game on my web site. This is a fantastic engine and I intend to use it, but my first thought was to get it working on my iPad. I created some arcade style buttons and loaded them in alongside the MelonJS JSApp.  You can see the results of that here:

http://www.russellbits.com/labs/bloop/ipad.html

I've set up the arcade buttons so that when they are pressed (via mouse or touch), they generate a keypress event through Jquery; like so:

var press = jQuery.Event("keydown");
press.which = 32; // # The 'SPACE BAR' key code value
press.keyCode = 32;

$('#btn').click( function() {
    $('#testInput').focus();
    $(document).trigger(press);
    console.info(press);
});

In addition, to insure that the keypress event was occuring, I added the following:

$(document).on('keydown', function(event) {
    alert(event.keyCode);
});

I get an alert with the correct keypress code but no reaction from melonJS. Is there a better way to pass this keypress event to Melon? Would it be better to give melonJS focus somehow?

[Jason Oster]

Hi!

You need to use melonJS's input class to trigger key events that melonJS will respond to: http://www.melonjs.org/docs/symbols/me.input.html#triggerKeyEvent

[russel...@gmail.com]

Awesome! I posted this on Stackoverflow and no one knew what I was even talking about.

For anyone else reading this, there's one more trick.  You need to assign the me.input.KEY.SPACE,true to mousedown in Jquery and then false in mouseup.

Like so:

$('#jumpBtn').mousedown(function() {

    me.input.triggerKeyEvent(me.input.KEY.SPACE, true);

});

$('#jumpBtn').mouseup(function() {

    me.input.triggerKeyEvent(me.input.KEY.SPACE, false);

});

Thanks a million, Jason!

[russel...@gmail.com]

Brother. Now I'm really in it. The code above works great when you're pressing the buttons on Safari with the Developer User Agent set to iPad Safari, but on an *actual* iPad--nothing.

I added 

me.input.unbindTouch();

to the mousedown event with no effect. Anyone have any ideas?

[melonJS]

did you somewhere (initialization code) do something like this :

// initialize keyboard events

me.input.bindKey(me.input.KEY.SPACE, "some actio name");

// map the touch event on the X key

me.input.bindTouch(me.input.SPACE);

[russel...@gmail.com]

On Monday, March 25, 2013 11:56:48 PM UTC-4, melonJS wrote:

did you somewhere (initialization code) do something like this :

// initialize keyboard events

me.input.bindKey(me.input.KEY.SPACE, "some actio name");

// map the touch event on the X key

me.input.bindTouch(me.input.SPACE);

No. That only seems to make the key work when the jsApp div is touched. The buttons I am creating exist outside the MelonJS div area. Which, I guess if I can't get my way to work, this might be another good route to take in order to get Melon to work on a touch device.

[Jason Oster]

Binding mousedown events on the element with jQuery may not work on mobile. Jquery mobile has support for binding "tap" events which may be what you need.

[russel...@gmail.com]

Well, I have another game---that one written entirely in Jquery---and through the use of the Jquery UI Touch Punch library, I'm able to make items draggable and tappable in the UI. This is accomplished with the typical $('#btn').click() method. Using that in the case of this MelonJS game works, *if* the click is coming from the mouse. The iPad recognizes the tap (I can insert a simple alert() message to demonstrate that) it just doesn't seem to be passing the message on to Melon. In fact, I can even set up a listener at the document level that will capture the button tap and even indicate the correct key code, but still no response in Melon.

[russel...@gmail.com]

Hmmm. Some success. Mousedown appears to work fine on the iPad with the exception that Melon seems to think that the button is being held down.  So right now, this code works:

$("#jumpBtn").mousedown(function(e) {

//alert('Tap event registered.');

me.input.triggerKeyEvent(me.input.KEY.SPACE, true);

});

The logical thing to do would be to then create a mouseup that calls the same key but with "false". This apparently happens so fast that keypress just doesn't register at all. I guess I might try to set an interval, but that seems wonky.

BTW, I just now noticed that there's no sound on the iPad; anyone know why that is?

[Jason Oster]

Sound is disabled on the latest release build for mobile browsers. It's because audio support is spotty at best. Even with the patches I made to help audio on at least iOS 6, its still very unstable. Loading audio files tends to crash the browser and just provide a very poor experience.

Things work much much better with CocoonJS. I recommend trying that. Don't bother with a pure HTML game on mobile. Not yet, anyway.

Side note: web audio API may be better on iOS 6. I haven't tried it.

[russel...@gmail.com]

Ah. That makes sense. I've used sound in javascript on the iphone/ipod—running iOS 6—and it's semi-responsive. But that's while doing a lot less processing of other kinds.

I haven't seen Cocoon; thanks for that. I have looked at Impact, which looks nice. But I think the general conclusion is HTML5 games on mobile have a ways to go. Have you seen Hexagame (http://hexaga.me)? Really beautiful HTML5 game and it works quite well on the iPad, but the authors general conclusion there was that "code once, run everywhere" is still a pipe dream. Oh well.

http://cubiq.org/hexagame-the-making-of-an-html5-game 

[Jason Oster]

Kind of disappointing hexagame doesn't have some kind of background music. I could totally go for a chill track with that game.

Though, there is no myth about code-once-deploy-everywhere; we've actually had that in HTML for decades. The myth lies in expecting it to look and work exactly the same everywhere. As with any multi-vendor environments, you either have to cater to the lowest common denominator (make it look and work exactly the same everywhere, at the expense of passing on the latest and greatest HTML has to offer) or cater to particular user base (e.g. targeting webkit-based Desktop browsers). And of course, frameworks will always be there to ease the burdon.

Anyway, the article is accurate to a point. ;)