We love you, but we're not IN love with you

Tag: javascript

Pixi.js – HTML5 for Flash developers

pixi js Pixi.js is another javascript framework that attempts to recreate some of the features of Flash. It even replicates a lot of Flash components: MovieClip, Sprite, Stage, DisplayObject. It’s an impressive javascript library. You can download the source and some examples from github. I spent a little time hacking around on the examples and picking through the source code. Here’s a video introduction if you prefer that, or you can skip down to the text below the video…

Here’s a quick primer on Pixi.js:

It’s really comfortable for Flash/Actionscript developers. The folks who created Pixi.js are clearly very familiar with Flash and used a lot of Flash terminology in Pixi.js. It also feels like they worked hard to make it very easy to dig in and start creating cool stuff with minimal boilerplate code. I really appreciate that.

There is no built-in way to set a target frame rate in Pixi.js. Technically, there is no way to force a specific frame rate in javascript and it will only do the best it can, but Flash worked that way too and you could still give it an FPS target. The Pixi.js examples seem to rely on requestAnimationFrame() to run at 60 FPS. This is not reliable, so if you use Pixi.js, be sure to write some code to handle the rendering frame rate.

Pixi.js has a really clever renderer: It detects if your browser is WebGL enabled. If not, it falls back to an HTML5 canvas renderer. Not only is it cool that it handles this for you, but browsers with WebGL (Chrome, Safari) are hardware accelerated. This means that they can unload the rendering from the CPU to the GPU, making everything run much faster. Firefox also supposedly has WebGL capability, but from what I’ve read, the performance is questionable. The WebGL thing is going to be a big deal as it becomes more widespread. As usual, IE10 doesn’t support it, but it does have hardware accelerated canvas.

As a side note, the hardware acceleration is all based on your browser and hardware configuration. So, if you have a relatively new device and an updated browser, it just kicks in automatically. iPhones and iPads all support hardware acceleration and many Android devices do too. Obviously, how you handle older browsers is the challenge. In most cases, a less full-featured backup may need to be served up. In a few cases, the user may need to have hardware acceleration to run your game or app at a reasonable frame rate. A smart way to handle this is to check the frame rate of the game and alert a user if it drops below a minimum threshold.

So grab the Pixi.js code and start building some HTML5 goodness.

Using jQuery on a non-DOM HTML String

I had an interesting problem today at work – I needed to get the src attribute of an <img> tag that was not in the DOM.  I had a string containing HTML that was not actually part of the page, but I needed to parse it for information. I was not able to change the data, but I had access to an object with a property called “innerHTML” which contained the following string:

<img src="img/myimage.png" width="1700" height="500" />
<p>this is some text</p>

The easy (but ugly) way to solve this problem is to simply write the string into a hidden <div> on your HTML page, then extract what you need with jQuery. I really didn’t want to do this because I was going to be writing several large images into the page, and it just seems like a really lame way to handle the problem.

With a bit of help from this Stack Overflow thread, I found a better way to handle it. Simply cast your string into a jQuery object and you can use regular jQuery methods on it. here’s an example of how it works:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js">
</script>
<script type="text/javascript">
//create a sample object with a property containing HTML text:
var obj = {
    mystring: '<img src="img/myimage.png" width="1700" height="500"/>' +
        '<p>this is some text</p>'
}

$(document).ready(function() {
    //cast the string into jquery...
    //then use jquery's filter() function to isolate the image tag:
    var img_tag = $(obj.mystring).filter('img')[0];
    //to get the src attribute, we cast the above result into jquery again:
    var img_src = $(img_tag).attr('src');
    console.log(img_src); //ta da!!
});
</script>

This doesn’t come up very often, but it’s a good trick to have up your sleeve.

Why I Still Make Games in Flash/AS3 (for now)

As I look ahead to this year, I have several posts planned around game development in ActionScript 3 (Flash). So, I thought I should post a brief explanation about why I’m STILL developing games in AS3. After all, isn’t Flash dead? Aren’t we all living in a brave, new HTML5 world? Here are a few of the reasons why I’m developing in AS3:

actionscript vs javascriptAs of this post, HTML5 <canvas> support is still inconsistent across major browsers. Admittedly, the main issue is Internet Explorer, but they still have a HUGE market share and can’t be completely ignored. For most of our <canvas> projects at work, we still end up building a Flash backup. If you’re targeting desktop devices for your games, publishing to Flash gives you a bigger market share than HTML5 <canvas>.

HTML5 <audio> support is pitiful. In some browsers (*cough* Mobile Safari *cough*), it barely works at all. Then there are issues with preloading sounds so they are actually available when you need them.

Why does my javascript fail in Internet Explorer?

If you’re like me, you use Firefox or Chrome as your browser of choice for development. They’re both pretty web-standards compliant and they have nice developer tools. So, your javascript code is working perfectly and you test it in some other browsers…

It silently crashes in Internet Explorer! If you are using IE9, you hit F12 to look at the developer tools and track down the error, but it suddenly starts working perfectly! No Errors! You close the developer tools and it fails again. Huh?!

This is a common IE issue. Internet Explorer does not have a javascript console by default, so any calls made to the console will throw an error and crash the program. If you open the developer tools, then the console works and it stops throwing the errors. There are 2 basic solutions to this issue:

1) Comb through your code and remove all calls to the javascript console. Usually the problem is some random console.log() statement you added for debugging and forgot to remove.

2) The more elegant solution is to add some code that will stop the console from throwing errors in IE. Here is a snippet of code I often include at the top of my projects to fix the problem:

<script type="text/javascript">
  try {
    console //does the console exist?
  }
  catch(e) { //if not...
    console = {}; //create a console object for IE
    console.log = function() {}; //add a log method to the new console object
    //add other console methods here if you need them
  }
</script>

Note that this code only fixes console.log() calls. The javascript console has other methods that may need to be added to this script too. If you do some Googling around, you can probably find a nice little polyfill* that you can include in all of your projects that will take care of all the console functions.

*If you don’t know what a polyfill is, don’t feel bad. It’s basically a piece of code that inserts non-native functionality into javascript. In this case, the polyfill doesn’t actually do anything except prevent IE from throwing errors.

Disclaimer: there are some other javascript peculiarities to IE, so this may not be your problem, but ruling it out is a good place to start.

Powered by WordPress & Theme by Anders Norén